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

バックアップしておくべき主な対象として、/etc、/var/lib/dpkg、/var/lib/apt/extended_states の中身、dpkg --get-selections "*" (引用符を忘れてはいけません) の出力などがあります。システムの管理に aptitude を使っている場合は、/var/lib/aptitude/pkgstates もバックアップしておくと良いでしょう。

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

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

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

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

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

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

アップグレード作業を行う場合、この作業に含まれるパッケージに関連しているサービスがあることと思います。この場合、アップグレードされるパッケージが置き換えられて設定される間、サービスが停止するかもしれません。この間、サービスが利用できなくなります。

これらのサービスに対する実際のダウン期間は、システム中でアップグレードされるパッケージ数に応じて違いますし、このダウン期間には (もしあれば) 各パッケージのアップグレードに対する設定の質問にシステム管理者が答える時間も含まれます。アップグレード作業が放置されたままでいて、システムがアップグレード中に入力を必要とした場合、非常に長期間^[4] サービスが利用できなくなる可能性が高いことにご注意ください。

アップグレードされるシステムが、ユーザあるいはネットワークに対して非常に重要なサービスを提供している場合^[5]、項4.4.4. 「システムの最小アップグレード」 で記述しているように最小限のシステムアップグレードを行い、次にカーネルのアップグレードと再起動 (項4.4.5. 「カーネルと udev のアップグレード」 参照) をし、そしてもっとも重要なサービスに関連するパッケージをアップグレードすれば、ダウン期間を減らすことができます。

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

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

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

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

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

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

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

	重要項目
	(tinc のような) VPN サービスを使っている場合、アップグレード作業中に使えなくなるかもしれません。 項4.1.3. 「サービスのダウン期間の準備」 を参照してください。

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

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

bug #512951 のため、splashy パッケージをアップグレードの前に完全に削除 (purge) しておく必要があります。

	# apt-get purge splashy

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

そのため、パッケージマネージャ aptitude において中断しているアクションがないか確認すべきでしょう。パッケージマネージャにおいて、あるパッケージが削除あるいは更新の対象となっているなら、アップグレード手順に好ましくない影響を与えるかもしれません。パッケージマネージャにおけるアクションの修正は、sources.list に stable や squeeze ではなく、lenny が指定されている段階でのみ可能なことに注意してください。項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 状態にしておかなければなりません。

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

# echo パッケージ名 hold | dpkg --set-selections

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

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

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

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

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

デフォルトの設定では、メインの 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/squeeze/main/binary-i386/...
http://mirrors.kernel.org/debian/dists/squeeze/contrib/binary-i386/...

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

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

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

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

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

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

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

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

deb file:/var/ftp/debian squeeze 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-squeeze.time -a ~/upgrade-squeeze.script

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

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

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

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

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

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

# apt-get update

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

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

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

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

アップグレードをするのに十分な領域がない場合は、apt-get が以下のような警告メッセージを出します:

エラー: /var/cache/apt/archives/ に充分な空きスペースがありません。

この場合、事前に領域を解放するのを忘れないようにしてください。以下のことを実行するとよいでしょう。

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

完全アップグレード (以下に記述しています) を直接行った場合、残しておきたいパッケージが大量に削除されてしまうことが時折あります。そのため、まずはこれらの競合状態を打開するための最小アップグレードを行い、その上で 項4.4.6. 「システムのアップグレード」 にあるような完全な dist-upgrade を行う、という 2 段階のアップグレード過程を踏むことをお勧めします。

これをまず行うには、以下のコマンドを実行してください:

# apt-get upgrade

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

システムの容量が少なく、容量による制約のため完全アップグレードが実行できない場合にも、システムの最小アップグレードは有用です。

squeeze のバージョンの udev は、CONFIG_SYSFS_DEPRECATED が無効に、そして CONFIG_INOTIFY_USER と CONFIG_SIGNALFD オプションが有効になっている 2.6.26 以降のカーネルを必要とします。lenny での標準 Debian カーネル (バージョン 2.6.26) は CONFIG_SYSFS_DEPRECATED が有効になっており、lenny 中のバージョンの udev は最新のカーネルが要求する機能をすべて提供していなかったため、アップグレードの際にはシステムを起動不可能な状態にしないように特別に注意を払う必要があります。

lenny の 2.6.26 カーネルを squeeze の udev と共に起動するとネットワークデバイスに正しく名前を割り当てることや、(disk グループによってアクセスされるような) ブロックデバイスに特定の追加パーミッションを適用するのに失敗することがあります。ソフトウェアそのものは動いている様に見えますが、いくつかのルール (例えば、ネットワークベースのルール) が正しく読み込まれません。従って、udev をアップグレードする前に互換性があるカーネルが利用可能になっているのを確実にするため、この時点でカーネルそのものをアップグレードすることを強くお勧めします。

このカーネルアップグレードを実行するには、次のコマンドを実行してください。

# apt-get install linux-image-2.6-flavor

カーネルパッケージのどのフレーバーをインストールすべきかの判断に手助けが必要な場合は、項4.6.1. 「カーネルメタパッケージのインストール」を参照してください。

grub ブートローダのユーザは、カーネルのアップグレードの一部分としてして update-grub が走るのを確認するか、手動で実行する必要があります。

カーネルのアップグレード直後に、古い udev と新しいカーネルを使うことによる非互換性のリスクを最小限にするため、新しい udev もインストールする必要があります ^[8]。これを行うには以下を実行します:

# apt-get install udev

一旦カーネルと udev の両方をアップグレードし終わったら、システムを再起動する必要があります。

これまでの手順を実行し終わったら、アップグレードの主要な部分を続ける準備ができています。以下のコマンドを実行してください:

# apt-get dist-upgrade

	注意
	他のリリースでのアップグレード作業では、アップグレードに aptitude の利用を推奨していました。このツールは lenny から squeeze へのアップグレードには推奨されません。

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

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

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

cryptloop のサポートは、Debian 6.0 の Linux カーネルパッケージから外されています。cryptloop を使っている既存のインストールは、アップグレード前に dm-crypt へ移行する必要があります。

squeeze へのアップグレード作業では、システム中のパッケージ削除を尋ねてくるかもしれません。実際のパッケージ一覧は、インストールしてあるパッケージの構成に従って異なってくるでしょう。このリリースノートでは、どのような方法をとるべきかに関する一般的なアドバイスをします。しかし、確信がもてない場合は、それぞれの方法でアップグレードを先に進める前に、どのパッケージを削除するよう提案されているのか、きちんと調べることをお勧めします。

削除されるだろうと予想されるパッケージには以下が含まれています: autofs (autofs5 で置き換え)、dhcp3 (isc-dhcp で置き換え)、madwifi-source、python-setuptools および python2.4 (python2.6 で置き換え)。squeeze で時代遅れとなるパッケージについての詳細な情報は、項4.10. 「時代遅れ (Obsolete) のパッケージ」を参照してください。

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 オプションを有効にして、必須パッケージを一時的に削除しなければならないかもしれません。その場合 apt-get はこのことを警告してアップグレードを中断します。apt-get のコマンドラインにオプション -o APT::Force-LoopBreak=1 を指定すれば、この状態を回避できます。

システムの依存関係の構造があまりに問題だらけで、手動での介入が必要となることもあります。通常、手動での介入とは、apt-get を用いるか、あるいは

# dpkg --remove パッケージ名

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

# apt-get -f install
# dpkg --configure --pending

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

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

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

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

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

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

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

システムのローカルコンソールを使ってアップグレードを実行している場合、アップグレードの最中に何回かコンソールが別の画面へ移動してしまい、アップグレード作業が見えなくなることに気づくかもしれません。例えば、デスクトップシステムで gdm が再起動した際に起こります。

仮想ターミナル 1 に戻るには Ctrl+Alt+F1、あるいはローカルのテキストモードコンソールの場合には Alt+F1 を使う必要があります。F1 は、アップグレードが実行されている仮想ターミナルの番号と同じ番号のファンクションキーと置き換えてください。異なったテキストモードのターミナル間で切り替えを行うには、Alt+左矢印 か Alt+右矢印 も使えます。

ほとんどの場合、lenny と squeeze 間でパッケージのアップグレードは順調に行われるはずです。稀なケースとして、アップグレード前、あるいはアップグレード中に調整が必要なものがあります。以下にパッケージごとの詳細を記述します。

lenny から squeeze への 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.26-2-686' の場合は linux-image-2.6-686 をインストールすることをお勧めします。利用可能なパッケージのうち最良のものを選ぶ手助けとして、次のように apt-cache を用いて各パッケージのパッケージ説明の詳細版を参照してもよいでしょう。

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

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

少し勇気のある人には、Debian GNU/Linux 上で簡単に自分のカスタムカーネルをコンパイルするやり方があります。kernel-package ツールをインストールして、/usr/share/doc/kernel-package にあるドキュメントを読んでください。あるいは、linux-source-2.6 で提供されるカーネルソースを使うこともできます。バイナリパッケージの構築には、ソース中の Makefile 中の dep-pkg ターゲットが使えます。この二つのやり方にはいくつか違いがあるので、それぞれのパッケージのドキュメントを確認してください。

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

lenny 以降では、ハードウェアの検出に関する新しいカーネルの仕組みは、システム上でデバイスが検出される順番を起動時ごとに変えるかもしれず、与えられるデバイス名が影響を受けます。例えば、2 つの異なるドライバと結び付いた 2 つのネットワークアダプタがある場合、eth0 と eth1 が参照するデバイスは入れ替わるかもしれません。

ネットワークデバイスについては、通常 udev の /etc/udev/rules.d/70-persistent-net.rules で定義することでこの並べ替えを回避します。このルールは lenny で既に導入されているので、固定のネットワークデバイス名の恩恵を受けるために squeeze へのアップグレードの際に追加の作業をする必要はありません。しかし、この udev の仕組みは、割り当てられたネットワークデバイス名が特定のハードウェアに紐付けられているということに注意してください。例えば、もしあなたが squeeze を導入したシステムでイーサネットアダプタを交換した場合、新しいアダプタは既存の名前ではなく新しいインターフェイス名を使います。既存のデバイス名を新しいハードウェアで使う場合は、/etc/udev/rules.d/70-persistent-net.rules から関連するエントリを削除する必要があります。

ストレージデバイスについては、initramfs-tools を使い、ストレージデバイスのドライバモジュールを現在読み込まれているのと同じ順番で読み込むように設定することで、この並び替えを回避することができるでしょう。しかし、項5.1.1. 「IDE から PATA サブシステムへのディスクドライバの移行」 で記述されている Linux カーネルのストレージサブシステムへの他の変更内容を考慮すると、これは大抵は労力に見合わないので、/dev/disk/by-uuid/ ディレクトリ中の UUID のエイリアス^[9] や /dev/mapper/ 中の LVM デバイス名などの長きに渡って安定していることが保証されているデバイス名を代わりに使うことが推奨されています。

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

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

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

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

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

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

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

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

アップグレード中、GRUB 2 を「チェーンロード」するオプションを進められることでしょう。これは GRUB Legacy をブートローダとして優先したままですが、GRUB 2 を読み込むオプションをそこに追加し、Debian GNU/Linux システムをそこから起動するようにします。これによって、GRUB 2 を使うという恒久的な変更を加える前に、GRUB 2 があなたのシステム上で動くかどうかを確認できるようになります。

GRUB 2 が動くことが確認できたら、これをちゃんと使うように切り換えをすべきです。チェーンロード設定は一時的な利用のみを意図しています。upgrade-from-grub-legacy を実行すれば、この切り換えが行えます。

GRUB マニュアルには、GRUB Legacy と GRUB 2 の違いについてより詳細な情報が載っています。このうちの幾つかは、複雑な設定の場合には必要な変更かもしれません。ブートローダの設定をいじっていない場合は、これ以上何もするべきことはありません。

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

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