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

目次

4.1. アップグレードの準備
4.1.1. あらゆるデータや設定情報をバックアップする
4.1.2. 事前にユーザに通知する
4.1.3. サービスのダウン期間の準備
4.1.4. 復旧の準備
4.1.5. アップグレード用の安全な環境の準備
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 の光学メディアソースの追加
4.4. パッケージのアップグレード
4.4.1. セッションの記録
4.4.2. パッケージリストの更新
4.4.3. アップグレードするのに十分な領域があることを確認する
4.4.4. カーネルのフレーバー選択について
4.4.5. システムの最小アップグレード
4.4.6. システムのアップグレード
4.5. アップグレード中の注意点
4.5.1. 「即時設定は動作しません」で dist-upgrade が失敗する
4.5.2. 予期されるパッケージの削除
4.5.3. 衝突 (Conflicts) あるいは事前依存 (Pre-Depends) のループ
4.5.4. ファイルの衝突
4.5.5. 設定の変更
4.5.6. コンソール接続へセッションの変更
4.5.7. 特定のパッケージに対する特別な注意
4.6. カーネルと関連パッケージのアップグレード
4.6.1. カーネルメタパッケージのインストール
4.6.2. ブートタイミングの問題 (root デバイス待ち)
4.7. 次期リリースへの準備
4.8. 時代遅れ (Obsolete) のパッケージ
4.8.1. ダミーパッケージ

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

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

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 パーティションをバックアップするか、アンマウントしてしまいましょう。

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

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

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

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

アップグレードを行うシステムが、ユーザーやネットワークにとって最も重要なサービスを提供している場合[2]「システムの最小アップグレード」 で記述しているように最小限のシステムアップグレードを行い、次にカーネルのアップグレードと再起動をし、そしてもっとも重要なサービスに関連するパッケージをアップグレードします。これらのパッケージのアップグレードは、「システムのアップグレード」 にある完全アップグレードより先に実施します。このようにすれば、これらの最重要サービスが動作しつづけ、そして完全アップグレード作業を行っても利用可能であることを保証し、サービスの停止時間を減らすことができます。

4.1.4. 復旧の準備

Debian はシステムがブートできる状態を常に確保するように努めていますが、アップグレード後のシステム再起動で問題に遭遇する可能性は常にあります。既知の潜在的な問題点の多くは、このリリースノートの本章と次章で述べられています。

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

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

最初に試すべきもっとも明白なことは、古いカーネルでの再起動です。しかしながら、これがうまくいくという保証はありません。

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

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

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

initramfs-tools パッケージは生成した initrd にデバッグシェルを収録します[3]。例えば、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.2. システムの状態をチェックする

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

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

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

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

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

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

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

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

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

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

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

# dpkg --audit

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

# 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 が squeeze を指定したままにしておくべきです。

4.2.4. proposed-updates セクション

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

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

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

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

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

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

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

リリースを指定するのに、コードネーム (squeezewheezy) と状態名 (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/wheezy/main/binary-i386/...
http://mirrors.kernel.org/debian/dists/wheezy/contrib/binary-i386/...

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

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

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

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

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

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

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

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

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

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

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

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

4.3.3. APT の光学メディアソースの追加

CD (や DVD、Blu-ray Disc) だけでインストールをしたい場合は、/etc/apt/sources.list 内の deb 行の先頭にハッシュ記号 (#) を置き、それらを無効にしてください。

CD-ROM ドライブをマウントポイント /cdrom にマウントできるようにしている行が /etc/fstab にあるかどうかを確認してください (apt-cdrom を使う場合は、マウントポイントを /cdrom 以外にはできません)。例えば /dev/scd0 が CD-ROM ドライブなら、/etc/fstab には次のような行が必要です。

/dev/scd0 /cdrom auto noauto,ro 0 0

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

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

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

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

[注記]注記

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

4.4.1. セッションの記録

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

# script -t 2>~/upgrade-wheezy手順.time -a ~/upgrade-wheezy手順.script

typescript を再度実行する必要がある場合 (例: システムを再起動する必要がある場合) は、どのアップグレード手順のログを取っているのかを示すため、別の手順番号を使ってください。typescript ファイルは /tmp/var/tmp のような一時ディレクトリには置かないでください (これらのディレクトリ内のファイルはアップグレードや再起動の際に削除されることがありますから)。

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

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

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

# scriptreplay ~/upgrade-wheezy.time ~/upgrade-wheezy.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 を実行してパッケージキャッシュを一掃すると、以前ダウンロードしたパッケージファイルをすべて削除できます。

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

    # apt-get autoremove
    

    余分なパッケージを見つけるのに、deborphandebfostercruft も使えます。これらのツールが表示したパッケージをやみくもに削除しないでください。特に、誤検出しやすい非デフォルトの凶暴なオプションを使っている場合はなおさらです。実際に削除する前に、削除を提案されたパッケージ (の内容やサイズ、説明など) を手作業で調べなおすことを強くお勧めします。

  • 多くの容量を占めていて現在必要のないパッケージを削除する (アップグレード後にいつでもインストールし直せます)。popularity-contest をインストールしていれば、popcon-largest-unused を使うことにより、容量の多くを占めていて使うことのないパッケージの一覧が得られます。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 が squeeze を指し示すよう設定を戻しておくことが望ましいです。

4.4.4. カーネルのフレーバー選択について

Debian の 686 カーネルは PAE (Physical Address Extension、物理アドレス拡張) を使う 686-pae に置き換えられました。現在、あなたのコンピューターが 686 で動作しているが PAE を持たない場合、代わりに 486 に変更する必要があるでしょう。コンピューターが PAE を持っているかを確認するには、以下を実行します:

$ grep -q '^flags.*\bpae\b' /proc/cpuinfo && echo yes || echo no

もしサポートしていない場合 (つまり上記のコマンドの実行結果が no)、linux-image-486 をインストールし、もし linux-image-686linux-image-2.6-686 が現在インストールされている場合は削除する必要があります。

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

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

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

# apt-get upgrade

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

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

apt-listchanges パッケージがインストールされていれば、(デフォルト設定で) アップグレードされるパッケージについての重要な情報をページャで表示します。読み終わったら q を押してページャを終了し、アップグレードを続けてください。

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

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

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

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

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

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

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

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

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

4.5.1. 「即時設定は動作しません」で dist-upgrade が失敗する

apt-get dist-upgrade の途中でパッケージをダウンロードした後に失敗となり、

パッケージ」の即時設定は動作しません。詳細については man 5 apt.conf の APT::Immediate-Configure の項を参照してください。

と表示することがあります。これが起きた場合は、代わりに apt-get dist-upgrade -o APT::Immediate-Configure=0 を実行することでアップグレードを進められるはずです。

この問題の暫定的な別の対処の可能性として、squeeze と wheezy の両方のソースを一時的に sources.list に追加して apt-get update を実行する方法があります。

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

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

4.5.3. 衝突 (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.4. ファイルの衝突

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

(<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.5. 設定の変更

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

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

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

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

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

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

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

4.5.7.1. sudo

/etc/sudoers を変更していた場合は、sudo 設定がどのように扱われるのかに関して、変更点に注意を払う必要があります。デフォルトの /etc/sudoers は以下の 2 つのディレクティブを含むようになりました:

Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
#includedir /etc/sudoers.d

アップグレード中、/etc/sudoers へはこれらのエントリは自動的には追加されません (それでも sudo コマンドはフルパスを指定すれば実行できます)。 ですので、新しい /etc/sudoers.d ディレクトリへ変更を移動してデフォルトの /etc/sudoers ファイルを使いたいと考えることでしょう。例えば以下の様にします:

# mv /etc/sudoers /etc/sudoers.d/mychanges
# mv /etc/sudoers.dpkg-new /etc/sudoers

不要な Defaults および #includedir エントリを削除するために /etc/sudoers.d/mychanges を編集する必要があるかもしれません。これには visudo を使いましょう:

# visudo -f /etc/sudoers.d/mychanges

4.5.7.2. screen

GNU Screen が screen クライアントと SCREEN サーバの間の通信に利用するプロトコルが squeeze 用と wheezy 用で変更されています。wheezy の screen パッケージにはパッチが適用されていて、screen クライアントとサーバのバージョンが違っていても最も重要な機能は確保されます。

クライアントに wheezy 用の screen を使って squeeze 用の screen で始められた screen セッションに接続する際にうまく動作しない機能で最も目立つのはターミナルのサイズを変更する (WINCH シグナル) 機能です。対処として一旦切断してから接続し直すことにより screen セッション内のターミナルのサイズを取得して適切に調整できます。

ncurses ベースのアプリケーション、例えば aptitude のビジュアルモードで、画面に以前の内容の痕跡が残るかもしれません。Ctrl+L を押すことによりこの問題は解決します。

バージョンをまたがった接続でのこういった (無害な) 症状として、他に screen が "Message 40 of 12376 bytes too small" のようなメッセージを発することがあります。

こういった問題はすべて、squeeze 用の screen で始められた screen セッションが終了すると消えます。

wheezy 用の screen パッケージに付属する /usr/share/doc/screen/NEWS.Debian.gz も読んでください。

4.5.7.3. Suhosin PHP モジュール

php5-suhosin パッケージは削除されています。PHP 設定に suhosin モジュールが含まれる場合、PHP のアップグレード後はロードに失敗します。dpkg --purge php5-suhosin を実行して /etc/php5/conf.d/suhosin.ini に残っている設定を削除してください。

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

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

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

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

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

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

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

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

どのパッケージを選択すればよいのかわからない場合は、uname -r を実行し、似た名前をもつパッケージを探してください。例えば、コマンドの出力が '2.6.32-5-amd64' の場合は linux-image-amd64 をインストールすることをお勧めします。「カーネルのフレーバー選択について」 も参照してください。利用可能なパッケージのうち最良のものを選ぶ手助けとして、次のように apt-cache を用いて各パッケージのパッケージ説明の詳細版を参照してもよいでしょう。

# apt-cache show linux-image-amd64

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

少し勇気のある人には、Debian 上で簡単に自分のカスタムカーネルをコンパイルするやり方があります。linux-source パッケージで提供されるカーネルソースをインストールしてください。バイナリパッケージの構築には、ソース中の Makefile 中の deb-pkg ターゲットが使えます。さらなる情報は、Debian Linux Kernel Handbook にあります。debian-kernel-handbook パッケージからも利用できます。

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

4.6.2. ブートタイミングの問題 (root デバイス待ち)

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

通常の症状は、「ルートファイルシステムがマウントできず起動に失敗し、デバッグシェルに落ちる」というものです。

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) 

しかし、後でチェックしても、必要なデバイスはすべて /dev に存在しています。この症状は、ルートファイルシステムが USB ディスクや RAID にある場合、特に LILO を使用している場合によく見られます。

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

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

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

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

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

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

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

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

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

  • mysql-5.1: 後継となるパッケージは mysql-5.5 です。

  • postgresql-8.4: 後継となるパッケージは postgresql-9.1 です。wheezy では、単に更新版の postgresql-plperl-8.4 パッケージを提供しています。これは、既存のインストール済み postgresql-8.4 を利用不能にせずに wheezy での新しいバージョンの Perl へのアップグレードを有効にする為、新しいバージョンの libperl に対してリンクをしています。オペレーティングシステムのアップグレードが一旦完了したら、pg_upgradecluster ツールを使って PostgreSQL 8.4 データベースクラスタを新しい PostgreSQL バージョン 9.1 へとアップグレードするのを計画する必要があります。

  • python2.5: 後継となるパッケージは python2.7 です。

  • portmap: 後継となるパッケージは rpcbind です。

  • sun-java6: 後継となるパッケージは openjdk-7 です。

  • gdm: 後継となるパッケージは gdm3 です。Xfce や LXDE のような軽量デスクトップ環境のユーザは、より軽量な代替として lightdm を考慮するのもいいかもしれません。

  • mpich: 後継となるパッケージは openmpimpich2 です。

  • compiz (OpenGL ウィンドウおよび合成マネージャー) については、バグ報告 #677864 (および #698815) を参照してください。

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

  • ウェブ上での共同作業を行う機能を提供するソフトウェア、Horde 3 パッケージはもはや古くなりすぎており (obsolete) すべて削除されています。これには、ansel1chora2dimp1gollemhorde-samhorde3imp4ingo1kronolith2mnemo2nag2sork-forwards-h3, sork-passwd-h3sork-vacation-h3turba2 が含まれます。Horde 4 パッケージは、wheezy リリース前に十分な品質に達していなかったため、利用できません。テスト版の php-horde-* パッケージが利用できるかもしれません。

  • グループウェアサーバー機能を提供する、Kolab パッケージの大半が削除されました。これには、kolab-cyrus-imapdkolab-webadminkolabdlibkolab-perlphp-kolab-filterphp-kolab-freebusy が含まれます。2012 年に、Kolab は大幅な書き換えが行われており、kolab パッケージとして以後の Debian リリースに含まれることになると思われます。注意: (以前は Scalable OpenGroupware.org という名前で知られていた) SOGo サーバーは、sogo として wheezy で利用可能になっています。

  • すべての OpenERP 5 は、もはや古くなりすぎており (obsolete) 削除されています。これには openerp-clientopenerp-serveropenerp-web が含まれます。

  • pootle 2.0.5 パッケージは削除されました。

  • uw-imapd および ipopd パッケージは削除されました。よりよい代替、例えば IMAP には dovecot-imapdcourier-imap、POP3 には dovecot-pop3dcourier-pop が存在します。

  • drupal6 パッケージは利用できなくなりました。drupal7 に置き換えられています。しかし、自動でアップグレードする道はないため、ユーザは Debian Wiki にある説明を見てください。

4.8.1. ダミーパッケージ

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

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



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

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

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

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

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