システムをアップグレードする前に、完全なバックアップを取っておくよう強くお勧めします。少なくとも、失いたくないデータや設定情報だけでもバックアップしておきましょう。アップグレードのツールや処理はきわめて信頼性の高いものですが、アップグレードの最中にハードウェア障害が起こると、システムに大きなダメージを与えることがありえます。
バックアップしたくなるであろう主な対象としては、/etc や
/var/lib/dpkg の中身、dpkg --get-selections
"*" (引用符を忘れてはいけません) の出力などでしょう。
アップグレードの過程では、/home
ディレクトリ以下は一切変更されません。とはいえ、(Mozilla スイートの一部や GNOME
や KDE のデスクトップ環境などのように)
ユーザが初めて新しいバージョンのアプリケーションを起動するときに、既存のユーザ設定を新たなデフォルト値で上書きしてしまうものがあるのも事実です。万一に備えて、ユーザのホームディレクトリにある隠しファイルと隠しディレクトリ
(いわゆる「ドットファイル」)
をバックアップしておくのがよいでしょう。古い状態に戻したり、再度設定する場合に役立つはずです。ユーザにもこのことについて知らせておいてください。
アップグレードの前には、その予定をすべてのユーザに知らせるとよいでしょう。しかしシステムに
ssh
接続などでアクセスしてきているユーザは、アップグレードの最中にそうと気付くことはほとんどないはずですし、作業を続行できるはずです。万一の用心をしたければ、アップグレードの前にユーザのパーティション
(/home)
をバックアップして、アンマウントしてしまいましょう。同時にカーネルもアップグレードする場合を除いて、通常は再起動は必要ないでしょう。
ディストリビューションのアップグレードは、ローカルのテキストモードの仮想コンソール
(あるいは直接接続されたシリアル端末) から行うか、リモートなら ssh
接続経由で行いましょう。
重要!
telnet、rlogin、rsh
を用いてアップグレードをしてはいけません。アップグレードマシンの
xdm、gdm、kdm などが管理している X
セッションからのアップグレードも行うべきではありません。これらのサービスはアップグレードの最中に切断されてしまう可能性が高く、するとアップグレード途中のシステムへの接続が不可能になってしまうからです。
あらゆるパッケージのインストール処理はスーパーユーザ特権で実行されなければならないため、必要なアクセス権を得るために
root としてログインするか su や sudo
を使ってください。
アップグレードに必要となる前提条件がいくつかあります。実際にアップグレードを実行する前にそれらを確認してください。
システムアップグレードの前には、残りのシステムのアップグレード, 第 4.4.4 節
で説明するシステム全体のアップグレードを開始するときに十分なハードディスク領域があるかどうかを確認しなければいけません。まず、システムにインストールされるパッケージを一時的にダウンロードするのに、/var/
を置いているファイルシステムパーティションに十分なハードディスクが必要になります。ダウンロード後にはおそらく、アップグレードされるパッケージ
(これらには、より大きなバイナリやより多くのデータが含まれている可能性があります。)
と、アップグレードに伴って引きずり込まれる新しいパッケージの両方のインストールのために、他のファイルシステムパーティションにさらに領域が必要になるでしょう。システムに十分な空き領域がない場合、アップグレードが不完全な状態で終わり、復旧が困難になる可能性があります。
aptitude と apt
のどちらを使っても、インストールに必要なディスク領域の詳細な情報を表示できます。次のように実行すると、実際にアップグレードを実行する前に、必要なディスク領域の推定値を見ることができます。
# aptitude -y -s -f --with-recommends dist-upgrade
[ ... ]
更新: XXX 個、新規インストール: XXX 個、削除: XXX 個、保留: XXX 個。
yyyMB 中 xx.xMB のアーカイブを取得する必要があります。展開後に追加で AAAMB のディスク容量が消費されます。
パッケージのインストールまたは削除。
アップグレードをするのに十分な領域がない場合、事前に領域を解放するのを忘れないようにしてください。以下のことを実行するとよいでしょう。
apt-get clean
を実行してパッケージキャッシュを掃除し、インストールするために以前
(/var/cache/apt/archive に) ダウンロードしたパッケージを削除する。
popularity-contest
をインストールしていれば、popcon-largest-unused
を使って、システムで使用していなく最も大きな領域を占めているパッケージをリストアップできます。deborphan
や debfoster を使って時代遅れのパッケージを見つけることも可能です
(時代遅れ (Obsolete) なパッケージ, 第 4.7 節
を参照してください)。
dpigs
(debian-goodies パッケージに含まれています。) や
wajig (wajig size を実行してください。)
を用いると、ディスク領域の大部分を占めているパッケージをリストアップできます。
/var/log/
の下にあるシステムログを一時的に他のシステムに移動するか、永久に削除する。
2.4.1 より前のカーネルを使用している場合、glibc
をアップグレードする前、つまりできればアップグレードを開始する前に、(最低でも)
2.4 系にアップグレードする必要があります。推奨されているのは 2.6
系のカーネルにアップグレードすることです。
[FIXME: Needs decision/documentation whether to upgrade userland or kernel first.]
この章で述べられているアップグレード手順は、サードパーティ製のパッケージを使っていない、「純粋な」sarge システムからのアップグレード用です。サードパーティ製のパッケージは先に削除しておくとよいかもしれません。
またこの手順は、システムが sarge の最新リリースにアップデート済であるものと想定しています。そうではなかったり、アップグレード済みかどうか不明なら、sarge システムのアップグレード, 第 A.1 節内の指示に従ってください。
特定のパッケージを安定版以外 (テスト版など)
のディストリビューションからインストールするように APT
を設定しているなら、当該パッケージが新しい安定版リリース内のバージョンにアップグレードできるように、(/etc/apt/preferences
内に保存されている) APT の pin 設定を変更する必要があるかもしれません。APT の
pin 機能に関するより詳しい情報は、apt_preferences(5) にあります。
アップグレードに使う手段に関係なく、まず全パッケージの状態を調べ、全パッケージがアップグレード可能な状態にあることを確認するよう推奨します。次のコマンドは、インストールが中断していたり設定に失敗したパッケージや、何らかのエラー状態にあるパッケージを表示します:
# dpkg --audit
dselect や
aptitude、あるいは次のようなコマンドを使ってシステムの全パッケージの状態を検査することもできます:
# dpkg -l | pager
または
# dpkg --get-selections > ~/curr-pkgs.txt
アップグレード前に、あらゆる hold 状態を解除しておいたほうがよいでしょう。アップグレードに不可欠なパッケージが hold 状態にあるなら、アップグレードに失敗するでしょう。
hold 状態にあるパッケージを記録するのに、aptitude は
apt-get や dselect
とは異なる手法を用いることに注意してください。aptitude
では、以下のように実行して hold 状態にあるパッケージを検出できます:
# aptitude search "~ahold" | grep "^.h"
apt-get でどのパッケージが hold
状態にあるのかを調べたければ、以下のように実行してください:
# dpkg --get-selections | grep hold
パッケージをローカルで変更したり再コンパイルしており、パッケージの名前を変えたりバージョン番号に epoch フィールドを追加していないなら、アップグレードしないよう hold 状態にしておかなければなりません。
パッケージの "hold" 状態を aptitude
で変更するには、以下のように実行してください ("hold"
状態を解除するには hold を unhold で置き換えます):
# aptitude hold package_name
修正が必要なことがあるなら、ソースリストのチェック, 第 A.2
節で説明されているように sources.list が sarge
を指定したままにしておくべきです。
自分のシステムに非 Debian
パッケージがあるなら、依存関係の衝突のためアップグレード中に削除されるかもしれないことに注意すべきです。当該パッケージが
/etc/apt/sources.list
に特別なパッケージアーカイブを追加することでインストールされたのなら、そのアーカイブが
etch 用にコンパイルされたパッケージも提供しているかをチェックし、Debian
パッケージ用のソース行と一緒にそのソース行も適切に修正すべきです。
自分の sarge システムに、Debian に存在するパッケージの 非公式にバックポートされた "新" バージョンをインストールしているユーザもいるでしょう。そのようなパッケージはファイルの衝突を引き起こすことにより、アップグレード中に問題を引き起こす場合がほとんどでしょう[1]。ファイル衝突が発生したときの対処方法については、アップグレード中の注意点, 第 4.4.5 節にいくつかの情報があります。
アップグレードを始める前に、apt の設定ファイル
/etc/apt/sources.list
を編集して、パッケージの取得先を決める必要があります。
apt は、"deb"
行にあるすべてのパッケージを見比べ、最も大きなバージョン番号のパッケージをインストールします。同じパッケージが取得可能な場合は、先に現れた行を優先します
(つまり、複数のミラーを指定している場合は、最初にローカルのハードディスクを、次に
CD-ROM を、最後に HTTP/FTP ミラーを指定するといいでしょう)。
一つのリリースを指定するのに、コードネーム (sarge や etch) と状態名 (旧安定版、安定版、テスト版、不安定版) の両方ともがよく使われています。コードネームによる指定は、新しいリリースが出た時にびっくりせずに済むという利点があるため、ここではコードネームを使っています。もちろんこれは、自分でリリースアナウンスを注視する必要があることを意味してはいません。代わりに状態名を使っているなら、リリースされた直後に利用可能なパッケージの更新が急に増えたことに気づくでしょう。
デフォルトの設定では、メインの Debian
インターネットサーバを使ってインストールするようになっています。ですがここでは、/etc/apt/sources.list
を編集して、他のミラー (できればネットワーク的に最も近いミラー)
を使うようにするほうがよいでしょう。
Debian の HTTP/FTP ミラーのアドレスは、http://www.debian.org/distrib/ftplist
を参照してください。一般には HTTP ミラーのほうが FTP ミラーよりも高速です。
例えば、一番近くにある Debian ミラーが http://mirrors.kernel.org/debian/ だったとしましょう。このミラーをウェブブラウザや FTP プログラムで見てみると、main などのディレクトリが以下のように構成されていることがわかります。
http://mirrors.kernel.org/debian/dists/etch/main/binary-ia64/...
http://mirrors.kernel.org/debian/dists/etch/contrib/binary-ia64/...
このミラーを apt で使うには、次の行を sources.list
ファイルに追加します。
deb http://mirrors.kernel.org/debian etch main contrib
`dists' は書かなくても暗黙のうちに追加されます。そしてリリース名の後の引数がそれぞれ用いられ、複数のディレクトリの各々のパス名に展開されます。
これらの新たなソースを追加したら、それまでの sources.list 中の
"deb" 行の先頭にシャープ記号 (#)
を置き、それらを無効にしてください。
インストールに必要なパッケージのうち、ネットワークから取得されたものは、/var/cache/apt/archives
ディレクトリ (およびダウンロード中のものは partial/
サブディレクトリ)
に置かれます。したがって、インストールを行う前には、十分な領域があるかどうか確認しなければなりません。割に大きめのインストールを行う場合には、ダウンロードデータとして少なくとも
300MB 程度を考慮しておきましょう。
HTTP や FTP のパッケージミラーを使うのではなく、ローカルディスク (多分 NFS
マウントされたもの) にあるミラーを使うよう、/etc/apt/sources.list
を変更したいこともあるかもしれません。
例えばパッケージのミラーが /var/ftp/debian/ にあり、main
などのディレクトリが次のように配置されているとします。
/var/ftp/debian/dists/etch/main/binary-ia64/...
/var/ftp/debian/dists/etch/contrib/binary-ia64/...
これを apt から使うには、次の行を sources.list
ファイルに追加します。
deb file:/var/ftp/debian etch main contrib
`dists' は書かなくても暗黙のうちに追加されます。そしてリリース名の後の引数がそれぞれ用いられ、複数のディレクトリの各々のパス名に展開されます。
これらの新たなソースを追加したら、それまでの sources.list 中の
"deb" 行の先頭にシャープ記号 (#)
を置き、それらを無効にしてください。
CD
だけでインストールをしたい場合は、/etc/apt/sources.list
中の "deb" 行の先頭にシャープ記号 (#)
を置き、それらを無効にしてください。
CD-ROM ドライブをマウントポイント /cdrom
にマウントすることを許可している行が /etc/fstab
にあるかどうかを確認してください (apt-cdrom
を使う場合は、マウントポイントを /cdrom
以外にはできません)。例えば /dev/hdc が CD-ROM
ドライブなら、/etc/fstab には次のような行が必要です。
/dev/hdc /cdrom auto defaults,noauto,ro 0 0
第 4 フィールドの defaults,noauto,ro の間にはスペースがあってはいけません。
これが正しく機能しているか調べるには、CD を挿入して以下を実行してみてください。
# mount /cdrom # マウントポイントに CD をマウントします
# ls -alF /cdrom # CD のルートディレクトリを表示します
# umount /cdrom # CD をアンマウントします
問題がなければ
# apt-cdrom add
を、Debian Binary CD-ROM それぞれに対して実行してください。各 CD に関するデータが APT のデータベースに追加されます。
以前の Debian GNU/Linux
からのアップグレード方法のお勧めは、パッケージ管理ツール aptitude
を用いる方法です。このプログラムはパッケージに関する判断を apt-get
よりも安全に行います。
まず、必要なパーティションが read-write
モードでマウントされていることを忘れずに確認しましょう (特にルートと
/usr の各パーティション)。以下のようなコマンドラインが使えます。
# mount -o remount,rw /mountpoint
次に、(/etc/apt/sources.list 内の) APT ソース記述が
"etch" か "stable"
のいずれかを指定していることを念入りにチェックすべきです。注意: CD-ROM
のソース行は "unstable";
を指定していることがよくあります。これは混乱の元ですが、変更してはいけません。
ここで強くお勧めしたいのですが、/usr/bin/script
プログラムを使って、このアップグレード作業の記録を取るようにしましょう。こうすれば何らかの問題が生じたときに、何が起こったかを記録しておくことができ、バグ報告の必要が生じた場合に、その正確な情報を提供できます。記録を開始するには次のように入力します。
# script -a ~/upgrade-to-etch.typescript
typescript ファイルは /tmp や /var/tmp
のような一時ディレクトリには置かないでください
(これらのディレクトリのファイルはアップグレードや再起動の際に削除されることがありますから)。
typescript はまた、スクロールしてスクリーンから消えた情報を見ることができるようにもしてくれるでしょう。(Alt-F2 を使って) 2 番の仮想コンソールに切り替えて、ログインしてから less ~root/upgrade-to-etch.typescript と実行すれば当該ファイルを見ることができます。
アップグレード完了後に script を停止するには、プロンプトから
exit と入力してください。
まず、新規リリース用として入手可能なパッケージの一覧を取得する必要があります。次のように実行してください[2]:
# apt-get update
アップグレード中の複雑な依存関係の解決には、apt-get や sarge の
aptitude よりも、etch 版の aptitude
のほうが優れていることがアップグレードのテスト中に判明しました。したがって、次のように実行してまずアップグレードすべきです:
# aptitude install aptitude
発生した変更点の一覧が表示され、承認を求めてくるでしょう。承認する前に提示された変更点、特にアップグレードによって削除されるであろうパッケージに注意を払ってください。
非常に多くのパッケージが削除対象としてリストアップされてしまう場合があります。この場合、aptitude
とともに事前にアップグレードするパッケージを選択しておくと、リストアップされるパッケージを減らせるかもしれません。わかりやすい例を挙げてみましょう
- すでに KDE がインストールされたシステムのアップグレードテスト中に、大量の KDE
パッケージや perl が削除対象になることがありました。ここでは install
aptitude ではなく install aptitude perl
とすると、うまくいくことがわかりました。
doc-base
をインストールしているなら、残りのシステムに先立ってアップグレードしなければなりません。この理由は、同時に
perl
がアップグレードされると失敗する可能性があるからです。同パッケージがインストールされているかどうかを知るには、次のように実行してください:
# dpkg -l doc-base
"i" で始まる行が出力されればインストールされているので、以降の作業を行う前にアップグレードしなければなりません。
# aptitude install doc-base
さて、アップグレードの主要部分を続行する準備が整いました。以下のコマンドを実行してください:
# aptitude -f --with-recommends dist-upgrade
これによってシステムの完全なアップグレードを行います。すなわちすべてのパッケージの最新版を入手し、パッケージのリリースが変わったことによって生じる依存関係の変更すべてを解決します。必要に応じて、新しいパッケージ
(通常は更新版のライブラリや、名前の変わったパッケージ)
をインストールしたり、衝突している古いパッケージ
(console-tools-libs など) を削除したりもします。
CD-ROM のセットからアップグレードする場合には、アップグレード作業の最中に CD を交換するよう、数回指定されることになります。同じ CD を複数回入れなければならないかもしれません。これはパッケージ間の相互依存関係のせいで、これらのパッケージが別々の CD に入っていることもあるからです。
現在インストールされているパッケージの更新版が、他のパッケージのインストール状態を変更しなければならないような場合には、そのパッケージは現在のバージョンのままになります
("held back" と表示されます)。この状態は、aptitude
でこれらのパッケージをインストール対象として選択するか、aptitude -f
install package を試すかのどちらかで解決できます。
--fix-broken (または単に -f)
オプションを与えると、apt
はシステムに存在する壊れた依存関係を修復しようとします。apt
は、壊れたパッケージ依存関係がシステムに存在するのを許しません。
etch で知っておくべき問題点, 第 5 章で明示的に述べられている問題もありますので、そちらも参照してください。
aptitude、apt-get、dpkg
の操作中に次のようなエラーが出た場合、
E: Dynamic MMap ran out of room
デフォルトのキャッシュ容量では不十分だということです。これを解決するには、/etc/apt/sources.list
から不要な行を削除もしくはコメントアウトするか、キャッシュサイズを増やします。キャッシュサイズを増やすには、/etc/apt/apt.conf
に APT::Cache-Limit
を設定します。以下のコマンドを実行すれば、アップグレードするには十分な値が設定されます:
# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf
ここでは、/etc/apt/apt.conf
ファイル内にまだこの値を設定していない場合を想定しています。
場合によっては衝突や依存関係のループのために、APT の APT::Force-LoopBreak
オプションを有効にして、必須パッケージを一時的に削除しなければならないかもしれません。その場合
aptitude
はこのことを警告してアップグレードを中断します。aptitude
のコマンドラインに -o APT::Force-LoopBreak=1
を指定すれば、この状態を回避できます。
システムの依存関係の構造が非常に混乱していて、手動での介入が必要となることもあります。通常これは
aptitude を用いるか、あるいは
# dpkg --remove package_name
として、目ざわりなパッケージを消す作業になります。または次の作業でもよいかもしれません。
# aptitude --fix-broken install
# dpkg --configure --pending
極端な場合には、コマンドラインから次のように入力して、再インストールしなければならないかもしれません。
# dpkg --install /path/to/package_name.deb
「純粋な」sarge システムからのアップグレードでは、ファイルの競合は起こらないはずですが、非公式なバックポートパッケージをインストールしているなら起こるかもしれません。ファイルの競合が起こると、次のようなエラーになります:
Unpacking replacement <package-foo> ...
dpkg: error processing <package-name-for-foo> (--unpack):
trying to overwrite `<some-file-name>',
which is also in package `<package-bar>
ファイルの競合を解消するには、エラーメッセージの最後の行に表示されたパッケージを強制的に削除します:
# dpkg -r --force-depends package_name
問題が修正できたら、先に示したように aptitude コマンドを繰り返し入力すれば、アップグレードを再開できます。
アップグレードの最中に、いくつかのパッケージの設定・再設定に関する質問が表示されます。/etc/init.d
と /etc/terminfo ディレクトリに置かれるファイルと
/etc/manpath.config
に関しては、パッケージメンテナのバージョンに置き換えるようにしてください。システムの整合性を保つためには
`yes' と答えることが必要になります。古いバージョンも .dpkg-old
という拡張子で保存されていますので、戻すのはいつでもできます。
どうすればよいかわからなくなったら、そのパッケージやファイルの名前を書き留めておいて、その問題解決は後回しにしましょう。typescript ファイルを検索すれば、アップグレードの最中に画面に表示された情報を見直すこともできます。
Linux
カーネルは、残りのパッケージとは別にアップグレードすべきです。そのようにしたい場合は、linux-image-*
パッケージのどれか一つをインストールするか、カスタマイズしたカーネルをソースからコンパイルするかします。カーネルのアップグレードに伴って生じる可能性がある問題に関しては、本セクションの情報を参照してください。
名前空間を整理するため、Linux カーネルパッケージは (kernel-* から) linux-* に名前が変わりました。
Linux カーネル安定版の 1 つ前の系列である 2.4 系は etch ではもうサポートされていないので、2.4 系のカーネルを使用中の場合は 2.6 系のカーネルにアップグレードすべきです。2.2 系のカーネルを使用中の場合は、その他のパッケージをアップグレードする前に、(最低でも) 2.4 系の、できれば 2.6 系のカーネルにアップグレードしなければなりません。2.6 系へのアップグレードに伴う問題がいくつか、(FIXME - the link is partly broken) に記載されています。
initrd-tools
はもうサポートされなくなり、initramfs-tools と yaird
がそれにとって代わりました。etch
のカーネルにアップグレードすると、デフォルトでは initramfs-tools
がインストールされます。初めて 2.4 系カーネルから 2.6
系カーネルにアップグレードする場合は、initramfs-tools
を使用しなければなりません。2.2 系や 2.4 系のカーネルの上で yaird
を実行すると、linux-image-2.6 のインストールは失敗に終わります。
etch では、devfs
のサポートはもう提供していません。ユーザは、動的な /dev の管理に
udev を使用するよう切り換えることが推奨されています。Debian のカーネルには
devfs のサポートがもう含まれていないので、devfs
ユーザは、etch
のカーネルにアップグレードする前に手作業でシステムを切り換える必要があります。
/proc/mounts に 'devfs'
という文字列が見つかる場合、あなたはおそらく devfs を使用しています。devfs
スタイルの名前を参照している設定ファイルはすべて、udev
スタイルの名前を使用するよう調整する必要があります。devfs
スタイルのデバイス名を参照している可能性が最も高いファイルには、/etc/fstab
や /etc/lilo.conf、/boot/grub/menu.lst
などがあります。
生じる可能性がある問題については、さらに詳しい情報がバグ報告 #351152 にあります。
マルチプロセッサシステムには、Linux カーネルの *-smp フレーバーはもう必要ありません。etch 以降の amd64、i386、ia64 では、-smp という接尾辞のない linux-image パッケージにマルチプロセッサシステム向けのサポートが追加されました。
etch は、以前のリリースよりも強固なハードウェア検出機構を特徴とします。しかし、それによってシステム上のデバイス検出順が変わり、それがデバイス名の割り当て順に影響するかもしれません。例えば、2 つの異なるドライバと結び付いた 2 つのネットワークアダプタがある場合、eth0 と eth1 が参照するデバイスは入れ替わるかもしれません。この新しい機構によって、例えば実行中の etch システムでイーサネットアダプタを交換するなどした場合、新しいアダプタにも新しいインタフェース名が割り当てられるようになる、ということに注意してください。
ネットワークデバイスについては、ifrename
ユーティリティを用いて起動時に物理デバイスを特定の名前に結び付けることで、この順序の変更を防げます。さらに詳しくは、ifrename(8)
と iftab(5) を参照してください。
ストレージデバイスについては、initramfs-tools
を用いて、initramfs-tools
が現在と同じ順序でストレージデバイスドライバモジュールをロードするように設定することで、この順序の変更を防げます。そうするには、lsmod
の出力に目を通し、システム上のストレージモジュールがロードされた順序を特定してください。lsmod
は、ロードされた順序とは逆の順序でモジュールをリストアップします。つまり、リストの最初のモジュールは最後にロードされていたものです。
しかし、最初に起動した後にモジュールを削除したりロードしなおしたりすると、この順序にも影響が出ます。また、一部のドライバがカーネルに静的にリンクされており、その名前が
lsmod
の出力に現れないかもしれません。/var/log/kern.log や
dmesg
の出力に目を通すと、これらのドライバの名前やロード順を解読できるかもしれません。
これらのモジュール名を、起動時にロードされるべき順序で
/etc/initramfs-tools/modules
に追加してください。モジュール名の一部は sarge と etch
では異なるかもしれません。例えば、sym53c8xx_2 は sym53c8xx になりました。
その上で update-initramfs -k all を実行し、initramfs
イメージを再生成する必要があります。
一旦 etch のカーネルと udev
を使用し始めたら、ドライバのロード順に依存しないエイリアスでディスクにアクセスするよう、システムの設定を変更してもよいでしょう。これらのエイリアスは
/dev/disk/ 階層にあります。
HP のマシンで MP のシリアルコンソールポート (三頭ケーブルに "console" というラベルのついたコネクタ) を使用している場合、このカーネルのアップグレードでコンソールが壊れます!
アップグレード前に以下の情報を読んでください。
ttyS0 から
ttyS1、ttyS2、ttyS3
のいずれかに変更されます。したがって、
/etc/inittab を編集し、/dev/ttyS1
(rx4640、rx5670、rx7620、rx8620、Superdome)、/dev/ttyS2
(rx1600)、/dev/ttyS3 (rx2600) のいずれかの getty
エントリを追加してください。
/etc/securetty
を編集し、ttyS1、ttyS2、ttyS3
のいずれかを追加してください。
/etc/inittab と
/etc/securetty の既存の ttyS0
エントリはそのまま残しておいてください。
/etc/elilo.conf を編集して "console="
引数を全て削除してください。
MP コンソールについては、"Acpi(HWP0002,700)/Pci(...)/Uart" をパスに含むデバイスを選択するよう注意してください。
これらの変更に関する詳細情報や問題解決のヒントは http://lists.debian.org/debian-ia64/2005/01/msg00008.html
で閲覧可能です。
sarge から etch への dist-upgrade を実行する際には、新しい linux-image-2.6-* メタパッケージをインストールすることを強くお勧めします。このパッケージは、dist-upgrade の過程で自動的にインストールされるかもしれません。次のように実行すると、このパッケージがインストールされたか確認できます。
# dpkg -l | grep '^ii linux-image'
何も出力されない場合は、新しい linux-image パッケージを手作業でインストールする必要があります。利用可能な linux-image-2.6 メタパッケージの一覧を見るには次のように実行してください。
# apt-cache search linux-image-2.6- | grep -v transition
どのパッケージを選択すればよいのか心配ならば、uname -r
を実行し、似た名前をもつパッケージを探してください。例えば、コマンドの結果が
'2.4.27-3-686' の場合は linux-image-2.6-686
をインストールすることをお勧めします。利用可能なパッケージのうち最良のものを選ぶ手助けとして、次のように
apt-cache を用いて各パッケージのパッケージ説明・詳細版を見てもよいでしょう。
# apt-cache show linux-image-2.6-686
インストールするカーネルイメージが決まったら、aptitude install でインストールします。新しいカーネルがインストールされたら、それを有効にするために再起動してください。
もうちょっと冒険したい人には、自分のカスタムカーネルをコンパイルする方法も
Debian GNU/Linux は提供しています。kernel-package
をインストールして、/usr/share/doc/kernel-package
の文書を読んでみてください。
aptitude dist-upgrade が終了したら、「公式」にはアップグレードは終了したことになります。しかし次に再起動する前に、面倒を見てやらなければならないことがいくつかあります。
X Window System
関連のパッケージのアップグレードに関する詳しい情報は、/usr/share/doc/xfree86-common/README.Debian-upgrade.gz
を読んでください。これは以前の Debian
リリースすべてのユーザに当てはまります。要するに、読め、ということです。
mdadm は、MD アレイ (RAID) を initial ramdisk
から再構築したりシステム初期化シーケンス中に再構築するのに設定ファイルを必要とするようになりました。パッケージのアップグレードを終えた後、再起動する前に必ず
/usr/share/doc/mdadm/README.upgrading-2.5.3.gz
に書かれている説明を読み、それに従ってください。このファイルの最新版は http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file
から入手可能です。問題が生じた場合は参考にしてください。
数千個の新規パッケージが導入された一方で、etch では sarge にはあった 2000 個以上の古いパッケージが破棄されたり削除されてもいます。これら時代遅れのパッケージをアップグレードする手段は提供されていません。時代遅れのパッケージを使い続けても構いませんが、Debian プロジェクトは通常 etch がリリースされてから 1 年後に[3]そのようなパッケージへのセキュリティサポートを打ち切り、その後は他のサポートも提供されないのが常です。もし存在するのなら、利用可能な代替品に置き換えることを推奨します。
あるパッケージが本ディストリビューションから削除された理由は、数多くあります - 上流ではもはや保守されていないため、そのパッケージを保守することに興味を抱く Debian 開発者がもはやいないため、提供していた機能が別のソフトウェア (あるいは新バージョン) に取って代わられたため、バグのために etch にはもはや適さないとみなされたため、などです。最後の場合では、当該パッケージが "不安定版" ディストリビューション内には存在していることがあります。
更新されたシステム内のどのパッケージが "時代遅れ"
なのかを検出するのは、パッケージ管理用フロントエンドが当該パッケージにその旨のマークを付けてくれるので簡単です。aptitude
を使っているのなら、当該パッケージが "Obsolete and Locally Created
Packages" 欄に列記されているのに気づくでしょう。dselect
も同じようなセクションを提供しますが、表示される一覧はわずかに異なっています。さらに、sarge
で手作業でパッケージをインストールするのに aptitude
を使っていたのなら、手作業でインストールされたパッケージの記録が取られており、依存元パッケージが削除されればもはや不要となる依存関係のみによって導入されたパッケージに時代遅れのマークを付けることができるでしょう。また
aptitude は、deborphan
とは異なり、手作業でインストールしたパッケージには時代遅れのマークを付けません
(依存関係によって自動でインストールされたものにはマークを付けます)。
時代遅れのパッケージを見つけるのに使える追加ツールとしては、以下のものがあります
- deborphan や
debfoster、cruft。deborphan
を強く推奨しますが、同プログラムは (デフォルトモードでは) 時代遅れのライブラリ
- "libs" や "oldlibs"
セクション内にあり、他のパッケージに使われていないパッケージ -
しか報告しません。これらのプログラムが表示したパッケージをやみくもに削除しないでください。特に、誤報しやすい非デフォルトのオプションを積極的に使っている場合はなおさらです。実際に削除する前に、削除を提案されたパッケージを手作業で調査
(その中身やサイズ、説明文など) することを強く推奨します。
Debian
バグ追跡システムは、パッケージが削除された理由についての情報を提供してくれることがよくあります。あるパッケージ自体についてのアーカイブ化されたバグ報告と、ftp.debian.org
pseudo-package のアーカイブ化されたバグ報告の両方を調査すべきです。
sarge のいくつかのパッケージは etch では複数のパッケージに分割されていますが、これは大半がシステムの保守性を改善するためです。この場合におけるアップグレードを容易にするために、etch はしばしば "ダミーの" パッケージ - sarge での古いパッケージと同じ名前で、新規パッケージを導入するための依存関係を備えた空のパッケージ - を提供しています。これらの "ダミー" パッケージはアップグレード後は Obsolete 扱いとされ、安全に削除することができます。
大半の (すべてではない)
ダミーパッケージの説明文には、その目的が記されています。しかしながらダミーパッケージの説明文は統一されていないため、自分のシステム内のダミーパッケージを検出するために
deborphan を --guess
オプション付で使うこともできます。いくつかのダミーパッケージは、アップグレード後に削除されることを意図しておらず、代わりに時間とともに変化するプログラムの利用可能な最新バージョンの記録用として使われることに注意してください。
Debian GNU/Linux 4.0 (`etch') リリースノート (IA-64 用)
$Id: release-notes.en.sgml,v 1.104 2006/11/21 08:06:49 jseidel Exp $debian-doc@lists.debian.org