第4章 Debian 5.0 (lenny) からのアップグレード

目次

4.1. アップグレードの準備
4.1.1. あらゆるデータや設定情報をバックアップする
4.1.2. 事前にユーザに通知する
4.1.3. サービスのダウン期間の準備
4.1.4. 復旧の準備
4.1.5. アップグレード用の安全な環境の準備
4.1.6. 衝突しているパッケージを削除する
4.2. システムの状態をチェックする
4.2.1. パッケージマネージャにおいて中断しているアクションの確認
4.2.2. APT の pin 機能を無効にする
4.2.3. パッケージの状態をチェックする
4.2.4. proposed-updates セクション
4.2.5. 非公式なソースとバックポートパッケージ
4.3. APT の取得先 (ソース) の準備
4.3.1. APT のインターネットソースの追加
4.3.2. APT のローカルミラーソースの追加
4.3.3. APT の CD-ROM/DVD ソースの追加
4.4. パッケージのアップグレード
4.4.1. セッションの記録
4.4.2. パッケージリストの更新
4.4.3. アップグレードするのに十分な領域があることを確認する
4.4.4. システムの最小アップグレード
4.4.5. カーネルと udev のアップグレード
4.4.6. システムのアップグレード
4.5. アップグレード中の注意点
4.5.1. squeeze の Linux カーネルでは cryptloop がサポートされません
4.5.2. 予期されるパッケージの削除
4.5.3. aptitude あるいは apt-get 実行中のエラー
4.5.4. 衝突 (Conflicts) あるいは事前依存 (Pre-Depends) のループ
4.5.5. ファイルの衝突
4.5.6. 設定の変更
4.5.7. コンソール接続へセッションの変更
4.5.8. 特定のパッケージに対する特別な注意
4.6. カーネルと関連パッケージのアップグレード
4.6.1. カーネルメタパッケージのインストール
4.6.2. デバイスの整列順序の変更
4.6.3. Boot timing issues (waiting for root device)
4.7. 次期リリースへの準備
4.7.1. GRUB 2 へアップグレードする
4.8. 廃止予定のコンポーネント
4.9. 時代遅れ (Obsolete) のパッケージ
4.9.1. ダミーパッケージ

4.1. アップグレードの準備

アップグレードの前には、5章squeeze で知っておくべき問題点 に書かれている情報も読むことをお勧めします。この章に書かれている問題点は、アップグレードの過程と直接は関係がないかもしれませんが、それでもアップグレードを開始する前に知っておくべき重要事項である可能性があります。

4.1.1. あらゆるデータや設定情報をバックアップする

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

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

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

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

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

4.1.2. 事前にユーザに通知する

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

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

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

4.1.3. サービスのダウン期間の準備

システムが提供しているサービスで、アップグレードに含まれるパッケージが関連するサービスがあるかもしれません。この場合、注意して欲しいのですが、アップグレード作業中に関連パッケージが置換・設定される際、これらのサービスが停止します。この間、サービスは利用できなくなります。

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

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

4.1.4. 復旧の準備

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

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

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

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

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

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

4.1.4.1. initrd を使った起動中のデバッグシェル

initramfs-tools で生成される initrd には、デバッグシェル[6]が含まれています。例えば、initrd がルートファイルシステムをマウントできなければ、デバッグシェル内に移るでしょう。このデバッグシェルは、問題の追跡、そしておそらくは修正の手助けとなる基本的なコマンドを備えています。

チェックすべき基本的事項としては、次のようなものがあります。/dev 内に適切なデバイスファイルが存在するか、どのモジュールがロードされているか (cat /proc/modules)、dmesg の出力にドライバのロード失敗のエラーが出ていないか、など。dmesg の出力はまた、どのデバイスファイルがどのディスクに割り当てられているのかも示してくれます。ルートファイルシステムが期待通りのデバイス上にあるかを確認するために、echo $ROOT の出力もチェックすべきでしょう。

問題点を何とか解決できたなら、exit とタイプすることでデバッグシェルを終了させ、起動プロセスを失敗した時点から継続できます。もちろん次回の起動時に再び失敗することが無いよう、根本的な問題を修正して initrd を再生成する必要があるでしょう。

4.1.5. アップグレード用の安全な環境の準備

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

[重要]重要

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

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

[重要]重要

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

4.1.6. 衝突しているパッケージを削除する

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

	# apt-get purge splashy

4.2. システムの状態をチェックする

この章で述べられているアップグレード手順は、サードパーティ製のパッケージが無い 純粋 な lenny システムからのアップグレード用です。アップグレードプロセスにおいて最大限の信頼性を確保するために、アップグレード開始前にシステムからサードパーティ製パッケージを削除しておいた方が良いでしょう。

5.0 (lenny) より古い Debian のリリースバージョンからの直接のアップグレードはサポートされていません。5.0 へのアップグレードは、まずDebian GNU/Linux 5.0 のリリースノートの指示に従ってください。

またこの手順は、システムが lenny の最新ポイントリリースにアップデート済みであるものと想定しています。そうではなかったり、アップグレード済みかどうか不明なら、「lenny システムのアップグレード」内の指示に従ってください。

4.2.1. パッケージマネージャにおいて中断しているアクションの確認

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

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

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

4.2.2. APT の pin 機能を無効にする

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

4.2.3. パッケージの状態をチェックする

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

# dpkg --audit

dselectaptitude、あるいは次のようなコマンドを使ってシステムの全パッケージの状態を検査することもできます。

# dpkg -l | pager

または

# dpkg --get-selections "*" > ~/curr-pkgs.txt

アップグレード前に、あらゆる hold 状態を解除しておいたほうがよいでしょう。アップグレードに不可欠なパッケージが hold 状態にある場合、アップグレードに失敗します。

hold 状態にあるパッケージを記録するのに、aptitudeapt-getdselect とは異なる手法を用いることに注意してください。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 を指定したままにしておくべきです。

4.2.4. proposed-updates セクション

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

4.2.5. 非公式なソースとバックポートパッケージ

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

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

4.3. APT の取得先 (ソース) の準備

アップグレードを始める前に、apt の設定ファイル /etc/apt/sources.list を編集して、パッケージ一覧の取得先を設定する必要があります。

apt は、あらゆる deb 行を通して見つかったすべてのパッケージを見比べ、最も大きなバージョン番号のパッケージをインストールします。同じパッケージが取得可能な場合は、ファイルで最初に現れた行を優先します (したがって、複数のミラーを指定する場合は、最初にローカルのハードディスクを、次に CD-ROM を、最後に HTTP/FTP ミラーを指定するといいでしょう)。

リリースを指定するのに、コードネーム (lennysqueeze) と状態名 (oldstablestabletestingunstable) のどちらもよく使用されます。コードネームによる指定には、新しいリリースが出たときに驚かずに済むという利点があるため、ここではコードネームを使用しています。当然ですが、コードネームを使用している場合は自分でリリースアナウンスに注意を払わなければいけません。代わりに状態名を使用している場合は、リリースが行われた直後に、パッケージが大量に更新可能になったことに気づくでしょう。

4.3.1. APT のインターネットソースの追加

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

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

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

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

新しいソースを追加した後、sources.list 内の既存の deb 行の先頭に、ハッシュ記号 (#) を追加して無効にしてください。

4.3.2. APT のローカルミラーソースの追加

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

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

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

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

deb file:/var/ftp/debian squeeze main contrib

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

新しいソースを追加した後、sources.list 内の既存の deb 行の先頭に、ハッシュ記号 (#) を追加して無効にしてください。

4.3.3. APT の CD-ROM/DVD ソースの追加

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 のデータベースに追加されます。

4.4. パッケージのアップグレード

Debian GNU/Linux の前回のリリースからのお勧めのアップグレード方法は、パッケージ管理ツール apt-get を用いる方法です。前回のリリースでは、この作業には aptitude が推奨されていましたが、apt-get の最近のバージョンでは同等の機能が提供されており、さらにより高い整合性により望ましいアップグレード結果をもたらします。

まず、必要なすべてのパーティション (特にルートパーティションと /usr パーティション) を read-write モードでマウントするのを忘れずに行いましょう。それには以下のようなコマンドを使います。

# mount -o remount,rw /マウントポイント

次に、(/etc/apt/sources.list 内の) APT ソースのエントリが squeezestable のいずれか一方を指定していることを念入りにチェックしてください。lenny を指し示すソースエントリが含まれてはいけません。

[注記]注記

CD-ROM のソース行は unstable を指定していることがよくあります。これは混乱の元かもしれませんが、変更すべきではありません

4.4.1. セッションの記録

ここで強くお勧めしたいのですが、/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

4.4.2. パッケージリストの更新

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

# apt-get update

4.4.3. アップグレードするのに十分な領域があることを確認する

システムアップグレードの前には、「システムのアップグレード」 で説明するシステム全体のアップグレードを開始するときに、十分なハードディスク領域があるかどうかを確認してください。まず、ネットワーク経由で取得してインストールする必要があるパッケージは、すべて /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/ に充分な空きスペースがありません。

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

  • インストールのために、以前 (/var/cache/apt/archives に) ダウンロードしたパッケージを削除する。apt-get clean を実行してパッケージキャッシュを一掃すると、以前ダウンロードしたパッケージファイルをすべて削除できます。

  • 忘れ去られたパッケージを削除する。popularity-contest をインストールしていれば、popcon-largest-unused を使って、使用していないパッケージのうち最も大きな領域を占めているものをリストアップできます。deborphandebfoster を使って時代遅れのパッケージを見つけることも可能です (「時代遅れ (Obsolete) のパッケージ」 を参照してください)。それらのツールを使う代わりに aptitudeビジュアルモード で起動すれば、古いパッケージは、廃止された、またはローカルで作成されたパッケージ の下に見つかります。

  • あまりにも大きな領域を占めており現在は必要ないパッケージを削除する (アップグレード後にいつでも再インストール可能なのですから)。dpigs (debian-goodies パッケージに含まれています) や wajig (wajig size を実行してください) を用いると、最も大きなディスク領域を占めているパッケージをリストアップできます。

    aptitude を使っても、ディスク領域の大部分を占めているパッケージをリストアップできます。aptitudeビジュアルモードで起動します。表示平坦なパッケージ一覧を新規に作成を実行し、l を押して、~i と入力します。S を押して ~installsize と入力します。すると、作業しやすい一覧が得られます。

  • 翻訳や地域化用ファイルが不要なら、それらをシステムから削除する。localepurge パッケージをインストールして設定すれば、選んだ少数のロケールのみがシステムに残るようにすることが可能です。これによって、/usr/share/locale の消費するディスク領域を減らせるでしょう。

  • /var/log/ の下にあるシステムログを、一時的に他のシステムに移動するか、永久に削除する。

  • 仮設の /var/cache/apt/archives を使用する。すなわち、別のファイルシステム (USB ストレージデバイス、一時的なハードディスク、既に使用されているファイルシステムなど) を仮設のキャッシュディレクトリとして拝借することができます。

    [注記]注記

    アップグレード中にネットワーク接続が途切れる可能性があるので、NFS マウントは使用しないでください。

    以下は、/media/usbkey にマウントされた USB ドライブがある場合を例とします。

    1. 今までに、インストールのためにダウンロードされたパッケージを削除します。

      # apt-get clean

    2. ディレクトリ /var/cache/apt/archives を、USB ドライブにコピーします。

      # cp -ax /var/cache/apt/archives /media/usbkey/

    3. 現在のキャッシュディレクトリに、仮設のキャッシュディレクトリをマウントします。

      # mount --bind /media/usbkey/archives /var/cache/apt/archives

    4. アップグレード後に、元々の /var/cache/apt/archives ディレクトリを復活させます。

      # umount /media/usbkey/archives

    5. 残っている /media/usbkey/archives を削除します。

    仮設のキャッシュディレクトリは、システムにマウントされているファイルシステムであれば何にでも作成できます。

  • システムの最小アップグレードを行う (「システムの最小アップグレード」 参照)、あるいは完全アップグレードにしたがって、システムの部分的なアップグレードを行う。これによって、システムを部分的にアップグレードが可能になり、完全アップグレード前にパッケージキャッシュの削除ができます。

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

4.4.4. システムの最小アップグレード

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

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

# apt-get upgrade

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

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

4.4.5. カーネルと udev のアップグレード

squeeze バージョンの udev には、CONFIG_SYSFS_DEPRECATED が無効で、CONFIG_INOTIFY_USERCONFIG_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]

4.4.6. システムのアップグレード

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

# apt-get dist-upgrade
[注記]注記

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

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

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

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

4.5. アップグレード中の注意点

以下の章では、squeeze へのアップグレードの最中に現れるかもしれない既知の問題を記述しています

4.5.1. squeeze の Linux カーネルでは cryptloop がサポートされません

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

4.5.2. 予期されるパッケージの削除

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

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

4.5.3. aptitude あるいは apt-get 実行中のエラー

aptitudeapt-getdpkg を使用した操作が次のようなエラーで失敗に終わるかもしれません。

E: Dynamic MMap ran out of room

この場合、デフォルトのキャッシュ容量では不十分だということになります。これを解決するには、/etc/apt/sources.list から不要な行を削除もしくはコメントアウトするか、キャッシュサイズを増やします。キャッシュサイズを増やすには、/etc/apt/apt.confAPT::Cache-Limit を設定します。以下のコマンドを実行すれば、アップグレードするのに十分な値が設定されます。

# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf

ここでは、/etc/apt/apt.conf ファイル内にまだこの値を設定していない場合を想定しています。

4.5.4. 衝突 (Conflicts) あるいは事前依存 (Pre-Depends) のループ

場合によっては衝突や事前依存のループのために、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

4.5.5. ファイルの衝突

純粋 な 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 のコマンドを再度入力すれば、アップグレードを再開できます。

4.5.6. 設定の変更

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

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

4.5.7. コンソール接続へセッションの変更

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

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

4.5.8. 特定のパッケージに対する特別な注意

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

4.5.8.1. Evolution

(GNOME デスクトップのメールクライアント) Evolution は、バージョン 2.22 から 2.30 へ更新されています。これにより、パッケージがローカルデータ用に利用している保存形式が変更されており、evolution が動作中にアップグレードが実施されると、データを損失する可能性があります。様々な関連コンポーネントがバックグラウンドで動作しているので、アプリケーションの終了だけでは十分ではありません。様々な問題の可能性を避けるため、squeeze へのアップグレード開始前に、デスクトップ環境を完全に終了しておくことをお勧めします。

アップグレード手順の一部として、evolution は関連プロセスが動作しているかをチェックし、終了することを勧めます。それから二回目のプロセスチェックが行われます。そしてもし必要であれば、残っているプロセスを終了するか、手動で状況を解決するためにアップグレードを途中で終了するかの選択が提示されます。

4.6. カーネルと関連パッケージのアップグレード

このセクションでは、カーネルのアップグレード方法を説明し、このアップグレードに際して生じる可能性がある問題点を明確にします。Debian で提供されている linux-image-* パッケージのいずれかをインストールしても、カスタマイズしたカーネルをソースからコンパイルしてもかまいません。

このセクションに書かれている多くの情報は、ユーザが Debian のモジュラーカーネルのいずれかを initramfs-toolsudev とともに使用しているのを前提にしている、ということに注意してください。initrd を必要としないカスタムカーネルを使用するのを選択した場合や、initrd 生成ユーティリティとして異なるものを使用している場合は、このセクションの情報の一部は適切ではないかもしれません。

4.6.1. カーネルメタパッケージのインストール

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.6.2. デバイスの整列順序の変更

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 デバイス名などの長きに渡って安定していることが保証されているデバイス名を代わりに使うことが推奨されています。

4.6.3. Boot timing issues (waiting for root device)

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 を指定してください。タイムアウトの値 (秒で指定します) は調整する必要があるかもしれません。

4.7. 次期リリースへの準備

アップグレードの後で、次期リリースに向けてできるいくつかの準備があります。

  • 「時代遅れ (Obsolete) のパッケージ」 で説明するように、時代遅れ (obsolete) のパッケージや、使用していないパッケージを削除してください。それらのパッケージが使用する設定ファイルを確認し、パッケージの完全削除 (purge) によって、設定ファイルも含めて削除することを検討してください。

4.7.1. GRUB 2 へアップグレードする

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

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

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

4.8. 廃止予定のコンポーネント

Debian GNU/Linux の次期リリース 7.0 (コードネーム wheezy) では、いくつかの機能が廃止されます。システムを 7.0 へと更新する際の手間を省くため、ユーザは他の代替へ移行する必要があります。

以下の機能が廃止予定となっています:

  • OpenVZ と Linux-Vserver: Debian GNU/Linux 6.0 は、メインライン外の Linux カーネルの仮想化機能を含む最後のリリースになります。これは OpenVZ と Linux-Vserver の機能は非推奨 (deprecated) だとみなされ、ユーザが、KVM や Linux コンテナ、あるいは Xen のような linux-2.6 の開発元で統合済みの仮想化ソリューションへ移行しなければならないことを意味します。

  • gdm パッケージ (GNOME ディスプレイマネージャー バージョン 2.20) は、書き直されたバージョンの gdm3 によって時代遅れなもの (Obsolete) となっています。詳細については 「GNOME デスクトップに関する変更とサポート」 を参照してください。

4.9. 時代遅れ (Obsolete) のパッケージ

squeeze では、数千個の新規パッケージが導入された一方で、lenny にあった 4,000 個以上の古いパッケージの破棄や削除が行われています。これら時代遅れのパッケージをアップグレードする手段は提供されていません。時代遅れのパッケージを使い続けても構いませんが、Debian プロジェクトでは通常、squeeze がリリースされてから 1 年後に[11]そのようなパッケージへのセキュリティサポートを打ち切ります。またセキュリティサポート期間内であっても、時代遅れのパッケージへの他のサポートは通常は提供しません。利用可能な代替品があるのであれば、代わりにそれを使うようにすることをお勧めします。

パッケージがディストリビューションから削除された理由は、数多くあります――もう上流で保守されていない、そのパッケージの保守作業に興味を抱く Debian 開発者がもういない、提供していた機能が別のソフトウェア (または新しいバージョン) に取って代わられた、バグのために squeeze にはもう適さないと見なされた、などです。最後の場合では、当該パッケージが 不安定版 ディストリビューション内にはまだ存在していることがあります。

更新が完了したシステム内のどのパッケージが 時代遅れ なのかを検出するのは、パッケージ管理用フロントエンドが当該パッケージにその旨のマークをつけてくれるので簡単です。aptitude を使っているのなら、当該パッケージが 廃止された、またはローカルで作成されたパッケージ 欄に列記されているのに気づくでしょう。dselect も同じようなセクションを提供しますが、表示される一覧はわずかに異なっています。

さらに、lenny で手作業でパッケージをインストールするのに aptitudeapt-getを使っていたのなら、手作業でインストールされたパッケージの記録が取られています。依存関係のみによって引きずられてインストールされたパッケージに対して、依存元パッケージが削除されてもう不要となった場合に、時代遅れのマークをつけることができるでしょう。aptitudeapt は、deborphan とは異なり、手作業でインストールしたパッケージには時代遅れのマークをつけません (依存関係によって自動でインストールされたものにはマークをつけます)。自動的にインストールされたがもはや使われていないパッケージを削除するには、以下を実行してください:

# apt-get autoremove

時代遅れのパッケージを見つけるのに使える追加ツールとしては、以下のものがあります―― deborphandebfostercruftdeborphan を強くお勧めしますが、同ツールは (デフォルトモードでは) 時代遅れのライブラリ―― libsoldlibs セクション内にあり、他のパッケージに使われていないパッケージ――しか報告しません。これらのツールが表示したパッケージをやみくもに削除しないでください。特に、誤検出しやすい非デフォルトの凶暴なオプションを使っている場合はなおさらです。実際に削除する前に、削除を提案されたパッケージ (の内容やサイズ、説明など) を手作業で調べなおすことを強くお勧めします。

Debian バグ追跡システムは、パッケージが削除された理由についての追加情報を提供してくれることがよくあります。そのパッケージ自体と ftp.debian.org 擬似パッケージの両方の、アーカイブ化されたバグ報告を調べてください。

非推奨パッケージ (obsolete) の一覧:

  • plone コンテンツマネジメントシステム。Unified Installer for Linux を使ってほしい、という開発者の要求に従って行われました。Unified Installer for Linux は、開発者らが唯一サポートしているとみなされるデプロイメントプラットフォームです。Debian GNU/Linux システム上で Plone をインストールするのにお勧めのツールは、http://plone.org/ からダウンロードできる Unified Installer です。

  • nessus 脆弱性スキャンサーバと関連のライブラリおよびその他のソフト。openvas-serveropenvas-client を含む OpenVAS によって提供されるソフトウェアがあるため、非推奨 (deprecated) となりました。自動的にアップグレードする方法はないので、手動で OpenVAS をインストールして Nessus のサービス設定 (ユーザ、証明書など) を OpenVAS に移植する必要があります。

  • postgresql-8.3: 後継となるパッケージは postgresql-8.4

  • mysql-server-5.0: 後継となるパッケージは mysql-server-5.1

  • python2.4: 後継となるパッケージは python2.6

  • sun-java5-jresun-java5-bin を含む Java 5 ソフトウェアは、Java 6 が後継となります: sun-java6-jre とその関連パッケージです。

  • apt-proxy が、今後提供されなくなったので、このツールの代替には apt-cacher-ngapt-cacherapprox があります。自動的にアップグレードする方法は存在していないので、apt-proxy のユーザは、手作業でこれらのパッケージのどれかをインストールすることによって代替品に移行が可能になります。

  • squeeze では、いくつかの Xorg のビデオドライバが時代遅れ (obsolete) なため利用できなくなりました。これには以下が含まれます: xserver-xorg-video-cyrixxserver-xorg-video-i810xserver-xorg-video-imsttxserver-xorg-video-nscxserver-xorg-video-sunbw2xserver-xorg-video-vga。これらはアップグレード中に削除されるでしょう。ユーザは、代わりに xserver-xorg-video-all をインストールするべきです。

  • lenny で起動時にスプラッシュ画面を表示するのに使われていたユーティリティ usplash は利用できなくなっています。plymouth に置き換えられています。

4.9.1. ダミーパッケージ

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

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



[4] debconf の優先度を、とても高いレベルに設定していると設定プロンプトを抑制できますが、デフォルト値があなたのシステムに合わない場合、サービスはそのままでは起動に失敗することでしょう。

[5] 例: DNS や DHCP サービス、特に冗長性やフェイルオーバー機能が無い場合。DHCP の例では、リースタイムがアップグレード作業が完了する時間よりも短い場合、エンドユーザはネットワークから切り離されるでしょう。

[6] この機能は、ブートパラメータに panic=0 を付加することで無効にできます。

[7] Debian のパッケージ管理システムにおいて、別のパッケージを置き換えるように指定されていないパッケージは、通常、別のパッケージの所有ファイルを削除したり置き換えたりすることはできません。

[8] 古いカーネルと新しい udev の間には、既知の非互換性があります。新しいカーネルで再起動後に問題が見つかった場合には、以前のものを使うために udev をダウングレードする必要があるでしょう。

[9] 「パッケージのアップグレード」 にあるようにアップグレードのログを取っている場合は、「システムのアップグレード」 で記述した作業の結果を取得するため、再度 script を使って再起動後にアップグレードの次の作業のログを取ってください。

[10] crypt、RAID、LVM で使われるようなデバイスには、UUID ではない安定した識別子があります。この場合、既に明確で安定しているこれらのデバイス名を使う必要があります。

[11] あるいは、1 年以内でも別のリリースが出るときに。一般に、どの時点でも、サポートされる安定版リリースは 2 つだけです。