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

バックアップしておくべき主な対象として、/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]、「システムの最小アップグレード」 で記述しているように最小限のシステムアップグレードを行い、次にカーネルのアップグレードと再起動 (「カーネルと udev のアップグレード」 参照) をし、そしてもっとも重要なサービスに関連するパッケージをアップグレードすれば、ダウン期間を減らすことができます。

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

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

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

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

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

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

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

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

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

	重要
	telnet、rlogin、rsh を用いてアップグレードをしてはいけません。アップグレードするマシンの xdm、gdm、kdm などが管理している X セッションからのアップグレードも行うべきではありません。これらのサービスはアップグレードの最中に切断されてしまう可能性が高く、そうなるとアップグレード途中のシステムへの接続が不可能になってしまうからです。GNOME アプリケーションの update-manager の利用は、このツールはデスクトップのセッションが利用可能であるのが前提であるため、新しいリリースへのアップグレードには全く勧められません。

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

	# apt-get purge splashy

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

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

この確認を行うには、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" 

apt-get でどのパッケージが hold 状態にあるのかを調べたければ、以下のように実行してください。

# dpkg --get-selections | grep hold

パッケージをローカルで変更・再コンパイルしており、パッケージの名前を変えたりバージョン番号に epoch フィールドを追加していないなら、アップグレードしないよう hold 状態にしておかなければなりません。

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

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

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

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

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

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

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

デフォルトの設定では、メインの 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-squeezestep.time -a ~/upgrade-squeezestep.script

tyupescript を再度実行する必要がある場合 (例: システムを再起動する必要がある場合) は、どのアップグレード手順のログを取っているのかを示すため、別の手順番号を使ってください。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

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

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

# apt-get -o APT::Get::Trivial-Only=true dist-upgrade
[ ... ]
アップグレード: XXX 個、新規インストール: XXX 個、削除: XXX 個、保留: XXX 個。
xx.x MB のアーカイブを取得する必要があります。
この操作後に追加で AAA MB のディスク容量が消費されます。

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

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

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

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

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

完全アップグレード (以下に記述しています) を直接行った場合、残しておきたいパッケージが大量に削除されてしまうことが時折あります。そのため、まずはこれらの競合状態を打開するための最小アップグレードを行い、その上で 「システムのアップグレード」 にあるような完全な 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

カーネルパッケージのどのフレーバーをインストールすべきか、判断に迷ったら、「カーネルメタパッケージのインストール」を参照してください。

ファームウェアのうちのいくつかが non-free アーカイブにある別のパッケージへと移動したこと (「ファームウェアは non-free セクションへ移動しました」 参照) により、いくつかのハードウェアをサポートするために、新しいカーネルへのアップグレード後に追加のファームウェアパッケージをインストールする必要が発生するかもしれません。アップグレードの前には正常に動作していたハードウェアの一部は、一旦カーネルがアップグレードされると動かなくなるかもしれません。カーネルのインストール、または initramfs 生成スクリプトによる警告メッセージに注意して、必要なファームウェアパッケージがインストールされていることを確認してください。

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

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

# apt-get install udev

一旦カーネルと udev の双方をアップグレードし終わったら、システムを再起動してください^[9]。

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

# 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、python2.4 (python2.6 で置き換え)。squeeze で時代遅れとなるパッケージについての詳細な情報は、「時代遅れ (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 と分けることで、一時的にでも起動不能なシステムにしてしまうことを極力避けられます。カーネルパッケージのアップグレードは、「システムの最小アップグレード」で説明した最小アップグレードの手順の後以外では行うべきでないことに注意してください。

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

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

The usual symptoms are that the boot will fail because the root file system cannot be mounted and you are dropped into a debug shell:

Gave up waiting for root device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/something does not exist.  Dropping to a shell!
(initramfs) 

But if you check afterwards, all devices that are needed are present in /dev. This has been observed in cases where the root file system is on a USB disk or on RAID, especially if LILO is used.

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

アップグレード中、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)。一部のダミーパッケージは、アップグレード後に削除されることを意図したものではなく、プログラムのどのバージョンが現在利用可能な最新版かを長期にわたって追跡するのに使われる、ということに注意してください。