システムをアップグレードする前に、完全なバックアップを取っておくよう強くお勧めします。少なくとも、失いたくないデータや設定情報だけでもバックアップしておきましょう。アップグレードのツールや処理はきわめて信頼性の高いものですが、アップグレードの最中にハードウェア障害が起こると、システムに大きなダメージを与えることがありえます。

バックアップしておくべき主な対象として、/etc、/var/lib/dpkg、/var/lib/aptitude/pkgstates の中身、dpkg --get-selections "*" (引用符を忘れてはいけません) の出力などがあります。

アップグレードの過程自体は、/home ディレクトリ以下は一切変更しません。とはいえ、(Mozilla スイートの一部や GNOME や KDE のデスクトップ環境などのように) ユーザが初めて新しいバージョンのアプリケーションを起動するときに、既存のユーザ設定を新たなデフォルト値で上書きしてしまうものがあるのも事実です。万一に備えて、ユーザのホームディレクトリにある隠しファイルと隠しディレクトリ (いわゆる 「ドットファイル」) をバックアップしておくのがよいでしょう。古い状態に戻したり、再度設定する場合に役立つはずです。ユーザにもこのことについて知らせておいてください。

あらゆるパッケージのインストール処理はスーパーユーザ特権で実行されなければならないため、root としてログインするか su や sudo を使って、必要なアクセス権限を得てください。

アップグレードにあたって事前に整えなければならない条件がいくつかあります。実際にアップグレードを実行する前にそれらを確認してください。

アップグレードの前には、その予定をすべてのユーザに知らせるとよいでしょう。ただ、システムに ssh 接続などでアクセスしてきているユーザが、アップグレードの最中にそうと気付くことはほとんどないはずで、また、作業を続行できるはずです。

万一の対策をしたければ、アップグレードの前に /home パーティションをバックアップするか、アンマウントしてしまいましょう。

lenny にアップグレードするときはおそらくカーネルをアップグレードしなければならないので、通常は再起動が必要です。通常、再起動はアップグレードが完了した後に行います。

ドライバやハードウェア検出、デバイスファイルの命名法や順序に関して etch と lenny との間ではカーネルに多くの変更が加えられたため、アップグレード後のシステム再起動で問題に直面するリスクが高くなっています。既知の潜在的な問題点の多くは、このリリースノートの本章と次章で述べられています。

上述の理由により、システムが再起動に失敗したり、リモート管理されているシステムならネットワーク接続の確立に失敗した場合に備え、復旧できる手立てを整えておくことが大切です。

ssh 接続経由でリモートからアップグレードを行うのなら、リモートのシリアル端末からサーバにアクセスできるよう、必要な事前準備をしておくことを強くお勧めします。カーネルをアップグレードして再起動した後、(項4.6.2. 「デバイスの整列順序の変更」 で述べるように) 一部のデバイス名が変更され、ローカルコンソール経由でシステム設定を修正しなければならないことがあります。また、アップグレード中に誤ってシステムが再起動された場合にも、ローカルコンソールを使って復旧する必要に迫られることがあります。

最初に試すべきもっとも明白なことは、古いカーネルでの再起動です。しかしながら、本文書の別の場所で述べられているいくつかの理由により、これがうまくいくという保証はありません。

古いカーネルでの再起動に失敗するなら、システムを起動してアクセス・修復するための代替手段が必要となるでしょう。1 つのオプションとしては、特別な復旧イメージや Linux ライブ CD を使うことがあります。これらを使って起動した後は、ルートファイルシステムをマウントし、chroot でその中に入って問題点を調査・解決できるはずです。

お勧めしたい別のオプションとしては、lenny 用 Debian Installer のレスキューモードを使用する方法があります。同インストーラを使う利点は、多くのインストール手段の中からあなたの状況に最適なものを選べることです。より詳しい情報は、インストールガイドの第 8 章にある 「壊れたシステムの復旧」 セクションや、Debian Installer FAQ を参照してください。

ディストリビューションのアップグレードは、ローカルのテキストモード仮想コンソール (あるいは直接接続されたシリアル端末) から行うか、リモートなら ssh 接続経由で行いましょう。

リモートでのアップグレード時にさらなるセーフティマージンを得るために、screen プログラムが提供する仮想コンソール内でアップグレードプロセスを実行することを提案します。同プログラムは安全な再接続を可能にし、リモート接続プロセスが切断された場合でもアップグレードプロセスが中断しないようにしてくれます。

	重要項目
	telnet、rlogin、rsh を用いてアップグレードをしてはいけません。アップグレードするマシンの xdm、gdm、kdm などが管理している X セッションからのアップグレードも行うべきではありません。これらのサービスはアップグレードの最中に切断されてしまう可能性が高く、そうなるとアップグレード途中のシステムへの接続が不可能になってしまうからです。

LILO ブートローダを使用しているユーザは、デフォルトの設定では initramfs-tools が生成する initramfs が大きすぎて、LILO でロードできなくなっている、ということに注意してください。initramfs が大きすぎて LILO でロードできないというユーザは、grub を使うようにするか、または /etc/initramfs-tools/initramfs.conf ファイルを編集して、

MODULES=most

という行を次のように変更してください。

MODULES=dep

しかし、/etc/initramfs-tools/initramfs.conf にこのような変更を加えると、initramfs-tools が実行されているハードウェア自体に必要なモジュールだけが initramfs にインストールされる、ということに注意してください。initramfs を生成したマシンだけでなく他のハードウェアでも動作するブートメディアを生成したいのであれば、行を

MODULES=most

のままにしておき、LILO を使わないようにしなければなりません。

パッケージをインストールするのに aptitude の代わりに apt-get を使用すると、時として、aptitude がそのパッケージを 「使われていない」 とみなし、削除対象とすることがあります。一般的には、アップグレードを先に進める前に、システムが完全に最新かつ 「クリーン」 な状態となっているかを確認するべきです。

そのため、パッケージマネージャ aptitude において中断しているアクションがないか確認すべきでしょう。パッケージマネージャにおいて、あるパッケージが削除あるいは更新の対象となっているなら、アップグレード手順に好ましくない影響を与えるかもしれません。パッケージマネージャにおけるアクションの修正は、sources.list に stable や lenny ではなく、etch が指定されている段階でのみ可能なことに注意してください。項A.2. 「ソースリストのチェック」 も参照してください。

この確認を行うには、aptitude を 「ビジュアルモード」 で起動して g (「Go」) を押してください。何らかのアクションが表示されたなら、その内容を確認して、修正するかあるいは提案されたアクションを実行すべきです。いかなるアクションも提案されない場合は、「インストール・削除・更新予定のパッケージがありません」 というメッセージが表示されるでしょう。

特定のパッケージを安定版以外のディストリビューション (テスト版など) からインストールするように APT を設定しているなら、当該パッケージが新しい安定版リリース内のバージョンにアップグレードできるように、(/etc/apt/preferences 内に保存されている) APT の pin 設定を変更する必要があるかもしれません。APT の pin 機能に関するより詳しい情報は、apt_preferences(5) にあります。

アップグレードに使う手段に関係なく、まず全パッケージの状態を調べ、全パッケージがアップグレード可能な状態にあるのを確認することをお勧めします。次のコマンドは、インストールが未完了のパッケージ (Half-Installed) や設定に失敗したパッケージ (Failed-Config)、何らかのエラー状態にあるパッケージを表示します:

# 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 状態にしておかなければなりません。

aptitude でパッケージを 「hold」 状態に変更するには、以下のように実行してください。

# aptitude hold パッケージ名

「hold」 状態を解除するには hold の代わりに unhold を使用してください。

修正が必要なことがあるなら、項A.2. 「ソースリストのチェック」で説明するように sources.list が etch を指定したままにしておくべきです。

/etc/apt/sources.list ファイルに proposed-updates セクションを含めている場合は、システムのアップグレードを試みる前に、それらのセクションをファイルから削除してください。これは、衝突の可能性を減らすための予防策です。

システムに Debian 以外のパッケージがインストールされている場合、依存関係の衝突のためアップグレード中に削除されるかもしれないことに注意すべきです。当該パッケージが /etc/apt/sources.list に Debian 以外のパッケージアーカイブを追加することでインストールされたのなら、そのアーカイブが lenny 用にコンパイルされたパッケージも提供しているかをチェックし、Debian パッケージ用のソース行と一緒にそのソース行も適切に修正すべきです。

非公式にバックポートされた、Debian に存在するパッケージの 「新バージョン」 を etch システムにインストールしているユーザもいるかもしれません。そのようなパッケージはファイルの競合に繋がる可能性があるので、アップグレード中に問題を引き起こす場合がほとんどでしょう^[3]。ファイルの競合が発生した場合の対処方法については、項4.5.8. 「アップグレード中の注意点」にいくつかの情報があります。

デフォルトの設定では、メインの Debian インターネットサーバを使ってインストールするようになっています。ですが、/etc/apt/sources.list を編集して、他のミラー (できればネットワーク的に最も近いミラー) を使うようにするほうがよいでしょう。

Debian の HTTP/FTP ミラーのアドレスは、http://www.debian.org/distrib/ftplist にあります (「Debian ミラーサイト一覧」 のセクションを参照してください)。一般には HTTP ミラーのほうが FTP ミラーよりも高速です。

例えば、一番近くにある Debian ミラーが http://mirrors.kernel.org/ だったとしましょう。このミラーをウェブブラウザや FTP プログラムで見てみると、主なディレクトリが以下のような構成になっていることがわかります。

http://mirrors.kernel.org/debian/dists/lenny/main/binary-i386/...
http://mirrors.kernel.org/debian/dists/lenny/contrib/binary-i386/...

このミラーを apt で使うには、次の行を sources.list ファイルに追加します。

deb http://mirrors.kernel.org/debian lenny main contrib

`dists' は書かなくても暗黙のうちに追加されます。リリース名の後の各引数は、パスの末尾につけて、複数のディレクトリとするのに用いられます。

新しいソースを追加した後、sources.list 内の既存の 「deb」 行の先頭にシャープ記号 (#) を追加して、それらを無効にしてください。

HTTP や FTP のパッケージミラーを使うのではなく、ローカルディスク (おそらくは NFS マウントされたもの) にあるミラーを使うよう、/etc/apt/sources.list を変更したいことがあるかもしれません。

例えばパッケージのミラーが /var/ftp/debian/ にあり、主なディレクトリの配置が次のようになっているとします。

/var/ftp/debian/dists/lenny/main/binary-i386/...
/var/ftp/debian/dists/lenny/contrib/binary-i386/...

これを apt で使うには、次の行を sources.list ファイルに追加します。

deb file:/var/ftp/debian lenny 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 のデータベースに追加されます。

ここで強くお勧めしたいのですが、/usr/bin/script プログラムを使って、このアップグレードセッションの記録を取るようにしましょう。こうすれば、何らかの問題が生じたときに何が起こったかを記録しておくことができ、必要に応じてバグ報告に正確な情報を含めることができます。記録を開始するには次のように入力します。

# script -t 2>~/upgrade-lenny.time -a ~/upgrade-lenny.script

typescript ファイルは /tmp や /var/tmp のような一時ディレクトリには置かないでください (これらのディレクトリ内のファイルはアップグレードや再起動の際に削除されることがありますから)。

また、typescript で記録することで、スクロールしてスクリーンから消えた情報をもう一度見ることができるようにもなります。(Alt+F2 を使って) 2 番の仮想コンソールに切り替えて、ログインしてから less -R ~root/upgrade-lenny.script と実行すれば当該ファイルを見ることができます。

アップグレード完了後に script を停止するには、プロンプトから exit と入力してください。

script に -t スイッチをつけておいた場合は、以下のように scriptreplay プログラムでセッション全体をリプレイできます。

# scriptreplay ~/upgrade-lenny.time ~/upgrade-lenny.script

まず、新しいリリースで利用可能なパッケージの一覧を取得する必要があります。そのためには以下のコマンドを実行してください。

# aptitude update

このコマンドを初めて実行して新しいソースへと更新する際、ソースが取得可能でないという警告がいくつか表示されます。これらの警告は無害なもので、コマンドを再び実行したときには表示されません。

システムアップグレードの前には、項4.5.7. 「残りのシステムのアップグレード」 で説明するシステム全体のアップグレードを開始するときに十分なハードディスク領域があるかどうかを確認しなければいけません。まず、ネットワーク経由で取得してインストールする必要があるどのようなパッケージも、/var/cache/apt/archives (およびダウンロード中には partial/ サブディレクトリ) に保存されます。したがって、システムにインストールされるパッケージをダウンロードして一時的に保存できるよう、/var/ を保持しているファイルシステムパーティションに十分な空き領域があることを確認しなければなりません。ダウンロード後にはおそらく、アップグレードされるパッケージ (これらには、より大きなバイナリやより多くのデータが含まれている可能性があります) と、アップグレードに伴って依存関係に引きずられて新たにインストールされるパッケージの両方のインストールのために、他のファイルシステムパーティションにさらに領域が必要になるでしょう。システムに十分な空き領域がない場合、アップグレードが不完全な状態で終わり、復旧が困難になる可能性があります。

aptitude と apt のどちらを使っても、インストールに必要なディスク領域の詳細な情報が表示されます。アップグレードを実行する前に、次のように実行して必要な領域の推定値を見ることができます。

# aptitude -y -s -f --with-recommends dist-upgrade
[ ... ]
更新: XXX 個、新規インストール: XXX 個、削除: XXX 個、保留: XXX 個。
アーカイブ yyyMB 中 xx.xMB を取得する必要があります。展開後に AAAMB のディスク
領域が新たに消費されます。
パッケージのダウンロード・インストール・削除をおこないます。

	注意
	アップグレード手順の初めにこのコマンドを実行すると、以降のセクションで説明するような理由でエラーが発生する可能性があります。その場合は、このコマンドを実行してディスク領域の推定値を見る前に、まず項4.5.6. 「システムの最小アップグレード」で説明するとおりシステムの最小アップグレードを行い、さらにカーネルをアップグレードする必要があります。

アップグレードをするのに十分な領域がない場合、事前に領域を解放するのを忘れないようにしてください。以下のことを実行するとよいでしょう。

パッケージを安全に削除するための注意として、項A.2. 「ソースリストのチェック」で説明するように、sources.list が etch を指し示すよう設定を戻しておくことが望ましいです。

Several bug reports have shown that the versions of the aptitude and apt packages in etch are often unable to handle the upgrade to lenny. In lenny, apt is better at dealing with complex chains of packages requiring immediate configuration and aptitude is smarter at searching for solutions to satisfy the dependencies. These two features are heavily involved during the dist-upgrade to lenny, so it is necessary to upgrade these two packages before upgrading anything else.

The following command will upgrade both aptitude and apt:

# aptitude install aptitude apt dpkg

This step will also automatically upgrade libc6 and locales. At this point, some running services will be restarted, including xdm, gdm and kdm. As a consequence, local X11 sessions might be disconnected.

Upgrading with apt

Please note that using apt-get is not recommended for the upgrade from etch to lenny. If you do not have aptitude installed you are recommended to install it first. If you want to perform the upgrade with apt or if the upgrade with aptitude failed and you want to try the upgrade with apt' dependency chain resolution algorithm, you should run: # apt-get install apt Note that you will have to adapt other aptitude commands to use apt-get instead.

aptitude は、自動的にインストールされたパッケージ (例えば、別のパッケージの依存パッケージとしてインストールされたもの) の一覧を保有しています。lenny では、apt にも同様にこの機能がつきました。

lenny に含まれるバージョンの aptitude を初めて実行すると、aptitude は、自動的にインストールされたパッケージの一覧を読み込んで、lenny に含まれるバージョンの apt が使えるようにそれを変換します。aptitude がインストールされている場合、少なくとも 1 回は aptitude コマンドを発行して、この変換を行ってください。この変換の 1 つのやり方として、存在しないパッケージを検索するという方法があります:

# aptitude search "?false"

etch で必要なパッケージの一部と lenny で必要なパッケージの一部が衝突するため、直接 aptitude dist-upgrade を実行すると、多くの場合、システムに残しておきたいパッケージが多数削除される結果となります。そのため、まずはこれらの競合状態を打開するための最小アップグレードを行い、その上で完全な dist-upgrade を行う、という 2 段階のアップグレード過程を踏むことをお勧めします。

まず、次のコマンドを実行してください。

# aptitude safe-upgrade

このコマンドには、アップグレードしても他のパッケージをインストール・削除する必要がないパッケージだけをアップグレードする、という効果があります。

次のステップは、どのようなパッケージ群がシステムにインストールされているかによって変化します。このリリースノートでは、どのような方法をとるべきかに関する一般的なアドバイスをします。しかし、確信がもてない場合は、それぞれの方法でアップグレードを先に進める前に、どのパッケージを削除するよう提案されているのかきちんと調べることをお勧めします。

どの場合でも削除されるだろうと予想されるパッケージには、base-config、hotplug、xlibs、netkit-inetd、python2.3、xfree86-common、xserver-common があります。lenny で時代遅れとなるパッケージについてさらに詳しく知りたい場合は、項4.10. 「時代遅れ (Obsolete) のパッケージ」を参照してください。

いよいよアップグレードの本体部分へと進む準備が整いました。以下のコマンドを実行してください:

# aptitude dist-upgrade

これによってシステムの完全なアップグレードが行われます。すなわち、すべてのパッケージの最新版がインストールされ、リリース間で発生しうるパッケージの依存関係の変化すべてが解決されます。必要に応じて、新しいパッケージ (通常は、新しいバージョンのライブラリや、名前の変わったパッケージ) がインストールされたり、衝突した古いパッケージが削除されたりもします。

CD-ROM (または DVD) のセットからアップグレードする場合には、アップグレードの最中に、特定の CD を入れるよう何回か指示されることになります。同じ CD を複数回入れなければならないかもしれません。これは、相互に依存しているパッケージが別々の CD に分散しているためです。

現在インストールされているパッケージを新しいバージョンへとアップグレードする際に、他のパッケージのインストール状態を変更しなければならないような場合には、そのパッケージは現在のバージョンのままになります (「固定されている」 と表示されます)。この状態は、aptitude でこれらのパッケージをインストール対象として選択するか、または aptitude -f install パッケージ名 を実行してみると、解決できます。

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 パッケージ名

で問題の原因となるパッケージを消す作業になります。または次の方法を用いてもよいかもしれません。

# aptitude -f install
# dpkg --configure --pending

極端な場合には、コマンドラインから次のように入力して、再インストールしなければならないかもしれません。

# dpkg --install /path/to/パッケージ名.deb

「純粋」 な etch システムからのアップグレードでは、ファイルの衝突は起こらないはずですが、非公式のバックポートパッケージをインストールしているなら起こるかもしれません。ファイルの競合が起こると、次のようなエラーになります:

(<package-foo-file> から) <package-foo> を展開しています...
dpkg: <package-foo> の処理中にエラーが発生しました (--install):
 `<some-file-name>' を上書きしようとしています。これはパッケージ <package-bar>
 にも含まれています
dpkg-deb: サブプロセス paste がシグナル (Broken pipe) によって強制終了しました
 以下のパッケージの処理中にエラーが発生しました:
 <package-foo>

ファイルの衝突を解消するには、エラーメッセージの最後の行に表示されたパッケージを強制的に削除します:

# dpkg -r --force-depends パッケージ名

問題が修正できたら、先程説明した aptitude のコマンドを再度入力すれば、アップグレードを再開できます。

アップグレードの最中に、いくつかのパッケージの設定・再設定に関する質問が表示されます。/etc/init.d ディレクトリと /etc/terminfo ディレクトリに置かれるファイルや /etc/manpath.config ファイルに関しては、パッケージメンテナのバージョンに置き換えるようにしてください。システムの整合性を保つためには `yes' と答えることが必要になります。古いバージョンも .dpkg-old という拡張子をつけられて保存されていますので、戻すのはいつでもできます。

どうすればよいかわからなくなったら、そのパッケージやファイルの名前を書き留めておいて、その問題解決は後回しにしましょう。typescript ファイルを検索すれば、アップグレードの最中に画面に表示された情報をもう一度見ることもできます。

etch から lenny への dist-upgrade を実行する際には、新しい linux-image-2.6-* メタパッケージをインストールすることを強くお勧めします。このパッケージは、dist-upgrade の過程で自動的にインストールされるかもしれません。次のように実行すると、このパッケージがインストールされたか確認できます。

# dpkg -l "linux-image*" | grep ^ii

何も出力されない場合は、新しい linux-image パッケージを手作業でインストールする必要があります。利用可能な linux-image-2.6 メタパッケージの一覧を見るには次のように実行してください。

# apt-cache search linux-image-2.6- | grep -v transition

どのパッケージを選択すればよいのかわからない場合は、uname -r を実行し、似た名前をもつパッケージを探してください。例えば、コマンドの出力が '2.6.18-6-686' の場合は linux-image-2.6-686 をインストールすることをお勧めします。(注意すべきなのは、k7 フレーバーはもう存在しないということです。k7 カーネルフレーバーを現在使用中の場合は、代わりに 686 フレーバーをインストールしてください。) 利用可能なパッケージのうち最良のものを選ぶ手助けとして、次のように apt-cache を用いて各パッケージのパッケージ説明詳細版を見てもよいでしょう。

# apt-cache show linux-image-2.6-686

インストールするカーネルイメージが決まったら、aptitude install でインストールします。新しいカーネルがインストールされたら、再起動できる機会に再起動し、新しいバージョンのカーネルを有効にしてください。

もうちょっと冒険したい人には、自分のカスタムカーネルを容易にコンパイルできる方法も Debian GNU/Linux は提供しています。kernel-package ツールをインストールして、/usr/share/doc/kernel-package の文書を読んでみてください。

可能なら、カーネルパッケージのアップグレードをメインの dist-upgrade と分けることで、一時的にでも起動不能なシステムにしてしまうことを極力避けられます。カーネルパッケージのアップグレードは、項4.5.6. 「システムの最小アップグレード」で説明した最小アップグレードの手順の後以外では行うべきでないことに注意してください。

lenny は、これまでのリリースよりも強固なハードウェア検出機構を特徴としています。しかし、それによってシステム上のデバイス検出順が変わり、それがデバイス名の割り当て順に影響するかもしれません。例えば、2 つの異なるドライバと結び付いた 2 つのネットワークアダプタがある場合、eth0 と eth1 が参照するデバイスは入れ替わるかもしれません。この新しい機構によって、例えば実行中の lenny システムでイーサネットアダプタを交換した場合、新しいアダプタに新しいインタフェース名が割り当てられる、というような現象が発生することに注意してください。

ネットワークデバイスの並び替えを防ぐには、udev のルール、具体的には /etc/udev/rules.d/70-persistent-net.rules^[4] を使用します。そのほかには、ifrename ユーティリティを使用して、起動時に物理デバイスに固有名を割り当てることもできます。詳しくは ifrename(8) と iftab(5) をご覧ください。この 2 つ (udev と ifrename) は同時に使用しないでください。

ストレージデバイスについては、initramfs-tools を用いて、現在と同じ順序でストレージデバイスドライバモジュールをロードするように設定することで、この順序の変更を防げます。このためには、lsmod の出力に目を通し、システム上のストレージモジュールがロードされた順序を特定してください。lsmod は、ロードされた順序とは逆の順序でモジュールをリストアップします。つまり、リストの最初のモジュールは最後にロードされていたものです。以上は、カーネルが安定した順番で読み込むデバイス (PCI デバイスなど) にしか、効果がないことに注意してください。

しかし、最初に起動した後にモジュールを削除したりロードしなおしたりすると、この順序にも影響が出ます。また、カーネルには静的にリンクされたドライバが含まれている可能性があり、そのようなドライバの名前は lsmod の出力に現れません。/var/log/kern.log や dmesg の出力に目を通すと、これらのドライバの名前やロード順を解読できるかもしれません。

これらのモジュール名を、起動時にロードされるべき順序で /etc/initramfs-tools/modules に追加してください。一部のモジュール名は etch と lenny では異なるかもしれません。例えば、sym53c8xx_2 は sym53c8xx になりました。

その上で update-initramfs -u -k all を実行し、initramfs イメージを再生成する必要があります。

一旦 lenny のカーネルと udev を使用し始めたら、ドライバのロード順に依存しないエイリアスでディスクにアクセスするよう、システムの設定を変更してもよいでしょう。これらのエイリアスは /dev/disk/ の下にあります。

initramfs-tools で生成した initrd を使用してシステムを起動する場合、時として、udev によるデバイスファイルの作成が、起動スクリプトの動作に間に合わないことがあります。

通常の症状は、「ルートファイルシステムがマウントできず起動に失敗し、デバッグシェルに落ちる」というものです。しかし、後でチェックしても、必要なデバイスはすべて /dev に存在しています。この症状は、ルートファイルシステムが USB ディスクや RAID にある場合、特に LILO を使用している場合に観察されています。

この問題を回避するには、ブートパラメータに rootdelay=9 を指定してください。タイムアウトの値 (秒で指定します) は調整する必要があるかもしれません。

(etch をインストールしたときに場合によってはデフォルトのブートローダとなる) lilo をブートローダとして使用している場合は、アップグレード後に以下のように lilo をもう一度実行しておくことを強くお勧めします。

# /sbin/lilo

注意しなくてはならないのは、システムのカーネルをアップグレードしていない場合でもこの操作が必要になるということです。それは、パッケージのアップグレードによって lilo の第 2 ステージが変更されているからです。

また、/etc/kernel-img.conf の内容を調べ、do_bootloader = Yes と書かれていることを確認してください。この設定のとおり、カーネルをアップグレードした後には必ずブートローダが再実行されます。

lilo を実行しているときに何らかの問題が発生した場合は、vmlinuz と initrd へのシンボリックリンクが / 内に存在するか、また /etc/lilo.conf の内容に食い違いがないか、確認してください。

再起動する前に lilo を実行しなおすのを忘れたり、手動で実行しなおす前にシステムが偶発的に再起動してしまった場合、システムは起動できなくなるでしょう。その場合、システム起動時に lilo プロンプト全体は表示されず、最初の LI だけが表示されます^[5]。この状態からシステムを復旧させる方法について知りたい場合は、項4.1.3. 「復旧の準備」 を参照してください。

起動のたびに変化しない識別子をルートファイルシステムに用いると、この問題を完全に防ぐことができます。識別子を用いる方法としては、2 つが考えられます。ファイルシステムにラベルをつける方法と、ファイルシステムの汎用一意識別子 (UUID) を用いる方法です。これらの方法は、Debian では「etch」リリースからサポートされています。

2 つの方法のどちらにも長所と短所があります。ラベルをつける方法は可読性が高いのですが、マシン上の別のファイルシステムに同じラベルがついている場合に、問題が発生する可能性があります。見た目はよくありませんが、UUID を用いる方法では、2 つの UUID が衝突することはまずありません。

以下の例では、ルートファイルシステムが /dev/hda6 上にあるものと仮定します。また、システムには動作する udev がインストールされており、ファイルシステムは ext2 または ext3 であると仮定しています。

ラベルをつける方法は、次のようにして実行します:

UUID を用いる方法は、次のようにして実行します:

etch の一部のパッケージは lenny では複数のパッケージに分割されていますが、これは大半がシステムの保守性を改善するためです。このような場合のアップグレード手順を容易にするために、lenny はしばしば 「ダミーの」 パッケージ―― etch での古いパッケージと同じ名前で、新規パッケージが自動的にインストールされるような依存関係を備えた空のパッケージ――を提供しています。これらの 「ダミー」 パッケージはアップグレード後は Obsolete 扱いとされ、安全に削除することができます。

(すべてではないのですが) 大半のダミーパッケージの説明には、その目的が記されています。しかしダミーパッケージの説明文は統一されていないので、自分のシステム内のダミーパッケージを検出するには、deborphan を --guess オプションつきで使うのが便利でしょう。一部のダミーパッケージは、アップグレード後に削除されることを意図したものではなく、プログラムのどのバージョンが現在利用可能な最新版かを長期にわたって追跡するのに使われる、ということに注意してください。