第4章 以前のリリースからアップグレードする

目次

4.1. アップグレードの準備
4.1.1. あらゆるデータや設定情報をバックアップする
4.1.2. 事前にユーザに通知する
4.1.3. 復旧の準備
4.1.4. アップグレード用の安全な環境の準備
4.1.5. LILO 用 initramfs の準備
4.2. システムの状態をチェックする
4.2.1. パッケージマネージャにおいて中断しているアクションの確認
4.2.2. APT の pin 機能を無効にする
4.2.3. パッケージの状態をチェックする
4.2.4. proposed-updates セクション
4.2.5. 非公式なソースとバックポートパッケージ
4.3. パッケージのマークを手作業で外す
4.4. APT の取得先 (ソース) の準備
4.4.1. APT のインターネットソースの追加
4.4.2. APT のローカルミラーソースの追加
4.4.3. APT の CD-ROM/DVD ソースの追加
4.5. パッケージのアップグレード
4.5.1. セッションの記録
4.5.2. パッケージリストの更新
4.5.3. アップグレードするのに十分な領域があることを確認する
4.5.4. まずは apt と aptitude の両方または一方をアップグレード
4.5.5. aptitude の「自動的にインストールされたパッケージ」の一覧を apt と共有する
4.5.6. システムの最小アップグレード
4.5.7. 残りのシステムのアップグレード
4.5.8. アップグレード中の注意点
4.6. カーネルと関連パッケージのアップグレード
4.6.1. カーネルメタパッケージのインストール
4.6.2. デバイスの整列順序の変更
4.6.3. 起動タイミングの問題
4.7. 再起動の前にすべきこと
4.7.1. lilo の再実行
4.8. システムの起動が Waiting for root file system とともにハングしてしまう
4.8.1. アップグレードの前に問題を防ぐには
4.8.2. アップグレードの後で問題を解決するには
4.9. 次期リリースへの準備
4.10. 時代遅れ (Obsolete) のパッケージ
4.10.1. ダミーパッケージ

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

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

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

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

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

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

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

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

4.1.1.1. 適切なカーネルを使用していることを確認する

lenny に含まれるバージョンの glibc は、どのアーキテクチャでも 2.6.8 より古いカーネルでは動作しません。一部のアーキテクチャでは、要求するカーネルのバージョンがさらに大きくなります。アップグレードプロセスを始める前に、etch のカーネル 2.6.18 または 2.6.24、あるいはバージョン 2.6.18 以降のカスタムカーネルにアップグレードしてテストしてみることを、強くお勧めします。

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

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

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

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

4.1.3. 復旧の準備

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

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

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

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

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

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

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

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

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

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

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

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

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

[重要項目]重要項目

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

4.1.5. LILO 用 initramfs の準備

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

MODULES=most

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

MODULES=dep

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

MODULES=most

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

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

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

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

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

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

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

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

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

# dpkg --get-selections | grep hold

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

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

# aptitude hold パッケージ名

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

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

4.2.4. proposed-updates セクション

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

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

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

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

4.2.5.1. backports.org パッケージの利用

backports.org は、Debian GNU/Linux 開発者が提供する準公式のリポジトリです。このリポジトリでは、主に 「テスト版 (testing)」 アーカイブに含まれるパッケージをビルドしなおすことで、安定版 (stable) リリースに含まれるものよりも新しいパッケージを安定版 (stable) リリースに提供します。

backports.org リポジトリに含まれているパッケージは、主に 「テスト版 (testing)」 に由来していますが、そのバージョン番号はテスト版 (testing) のものより小さくなっています。そのため、etch 用バックポートパッケージから lenny 用パッケージへのアップグレードパスもうまく機能します。しかし、一部には、不安定版 (unstable) 由来のバックポートパッケージも存在します。セキュリティアップデートに加え、Firefox や Linux カーネル、OpenOffice.org、X.Org といった例外です。

If you do not use one of these exceptions, you can safely upgrade to lenny. If you use one of these exceptions, set the Pin-Priority (see apt_preferences(5)) temporarily to 1001 for all packages from lenny, and you should be able to do a safe dist-upgrade too.

4.3. パッケージのマークを手作業で外す

依存関係に引きずられてインストールされたいくつかのパッケージが aptitude によって削除されてしまうのを防ぐために、それらが自動的にインストールされた (auto) パッケージであるというマークを手作業で外す必要があるでしょう。そのようなパッケージとしては、デスクトップインストール用の OpenOffice や Vim などがあります。

# aptitude unmarkauto openoffice.org vim

さらにカーネルメタパッケージを使ってインストールした場合、2.6 系のカーネルイメージも対象となります。

# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6.*' | cut -f1)
[注意]注意

以下のように実行すると、aptitude 内でどのパッケージに auto マークがついているのか確認できます:

# aptitude search '~i~M'

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

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

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

[ティップ]ティップ

DVDCD-ROM については、GPG チェックの例外指定を追加する必要があるかもしれません。次の行がまだ /etc/apt/apt.conf.d/00trustcdrom に含まれていない場合は、/etc/apt/apt.conf に追加してください:

APT::Authentication::TrustCDROM "true";

ただし、これは DVD/CD-ROM イメージファイルを扱うものではありません。

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

4.4.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/lenny/main/binary-amd64/...
http://mirrors.kernel.org/debian/dists/lenny/contrib/binary-amd64/...

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

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

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

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

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

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

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

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

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

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

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

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

4.4.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.5. パッケージのアップグレード

Debian GNU/Linux の前回のリリースからのお勧めのアップグレード方法は、パッケージ管理ツール aptitude を用いる方法です。このプログラムを用いると、直接 apt-get を実行する場合よりも、パッケージのインストールについて安全な判断ができます。

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

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

次に、(/etc/apt/sources.list 内の) APT ソースのエントリが 「lenny」 と 「stable」 のいずれか一方を指定していることを念入りにチェックしてください。etch を指し示すソースエントリが含まれないようにすべきです。

[注意]注意

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

4.5.1. セッションの記録

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

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

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

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

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

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

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

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

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

# aptitude update

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

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

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

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

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

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

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

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

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

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

    You can list packages that take up most of the disk space with aptitude. Start aptitude into 「visual mode」, select ViewsNew Flat Package List (this menu entry is available only after etch version), press l and enter ~i, press S and enter ~installsize, then it will give you nice list to work with. Doing this after upgrading aptitude should give you access to this new feature.

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

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

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

    [注意]注意

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

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

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

      # apt-get clean

    2. ディレクトリ /var/cache/apt/archivesUSB ドライブにコピーします:

      # 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 を削除します。

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

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

4.5.4. まずは apt と aptitude の両方または一方をアップグレード

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

The following command will upgrade both aptitude and apt:

# aptitude install aptitude apt dpkg

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

[注意]Upgrading with apt

Please note that using apt-get is not recommended for the upgrade from etch to lenny. If you do not have aptitude installed you are recommended to install it first.

If you want to perform the upgrade with apt or if the upgrade with aptitude failed and you want to try the upgrade with apt' dependency chain resolution algorithm, you should run:

# apt-get install apt

Note that you will have to adapt other aptitude commands to use apt-get instead.

4.5.5. aptitude の「自動的にインストールされたパッケージ」の一覧を apt と共有する

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

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

# aptitude search "?false"

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

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

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

# aptitude safe-upgrade

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

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

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

4.5.7. 残りのシステムのアップグレード

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

# aptitude dist-upgrade

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

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

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

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

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 ファイル内にまだこの値を設定していない場合を想定しています。

場合によっては衝突や事前依存のループのために、APT の APT::Force-LoopBreak オプションを有効にして、必須パッケージを一時的に削除しなければならないかもしれません。その場合 aptitude はこのことを警告してアップグレードを中断します。aptitude のコマンドラインにオプション -o APT::Force-LoopBreak=1 を指定すれば、この状態を回避できます。

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

# dpkg --remove パッケージ名

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.6.2. デバイスの整列順序の変更

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

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

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

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

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

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

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

4.6.3. 起動タイミングの問題

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

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

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

4.7. 再起動の前にすべきこと

aptitude dist-upgrade が終了したら、「公式」にはアップグレードは完了したことになります。しかし、次に再起動する前に面倒を見てやらなければならないことがいくつかあります。

4.7.1. lilo の再実行

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

# /sbin/lilo

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

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

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

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

4.8. システムの起動が Waiting for root file system とともにハングしてしまう

/dev/sda となってしまった /dev/hda の復旧手順

一部のユーザからの報告によれば、アップグレードを実行すると、システム再起動後にカーネルがシステムのルートパーティションを見つけられなくなるようです。

このような場合、システムの起動は、以下のメッセージを最後にハングアップしてしまいます:

Waiting for root file system ...

そして数秒後に、busybox プロンプトがむき出しとなります。

この問題は、カーネルのアップグレードによって新しい世代の IDE ドライバが導入される際に発生する可能性があります。古いドライバでは IDE ディスクの命名規則が hdahdbhdchdd となっていました。これに対して、新しいドライバは、同じディスクにそれぞれ sdasdbsdcsdd という名前をつけます。問題は、アップグレードによって、新しい命名規則を考慮に入れた、新しい /boot/grub/menu.lst ファイルが生成されないときに生じます。起動中に、カーネルが検出不能なシステムルートパーティションを、Grub がカーネルに渡してしまうのです。

アップグレード後にこの問題に遭遇した場合は、項4.8.2. 「アップグレードの後で問題を解決するには」に飛んでください。アップグレード前にこの問題を防ぎたい場合は、このまま読み進めてください。

4.8.1. アップグレードの前に問題を防ぐには

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

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

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

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

  1. 次のコマンドを実行して、ファイルシステムにラベルをつける (名前は 16 文字未満でなければなりません): e2label /dev/hda6 rootfilesys

  2. /boot/grub/menu.lst を編集して、次のような行を:

    # kopt=root=/dev/hda6 ro

    次のように変更する:

    # kopt=root=LABEL=rootfilesys ro

    [注意]注意

    行頭の # を削除しないでください。この文字は行頭にある必要があります。

  3. update-grub コマンドを実行して、menu.lst 内の kernel 行を更新する。

  4. /etc/fstab を編集し、/ パーティションをマウントするための、例えば次のような行を:

    /dev/hda6     /     ext3  defaults,errors=remount-ro 0 1

    次のように変更する:

    LABEL=rootfilesys     /     ext3  defaults,errors=remount-ro 0 1

    ここで問題となる変更は最初のカラムです。この行の残りのカラムは変更する必要はありません。

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

  1. Find out the universally unique identifier of your filesystem by issuing: ls -l /dev/disk/by-uuid | grep hda6. You can also use vol_id --uuid /dev/hda6 (in etch) or blkid /dev/hda6 (if already upgraded to lenny).

    次のような行が得られるはずです:

    lrwxrwxrwx 1 root root 24 2008-09-25 08:16 d0dfcc8a-417a-41e3-ad2e-9736317f2d8a -> ../../hda6

    UUID は、/dev/hda6 を指しているシンボリックリンクの名前、すなわちこの場合は d0dfcc8a-417a-41e3-ad2e-9736317f2d8a です。

    [注意]注意

    ファイルシステムの UUID は別の文字列でしょう。

  2. /boot/grub/menu.lst を編集して、次のような行を:

    # kopt=root=/dev/hda6 ro

    次のように変更する:

    # kopt=root=UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8 ro

    [注意]注意

    行頭の # を削除しないでください。この文字は行頭にある必要があります。

  3. update-grub コマンドを実行して、menu.lst 内の kernel 行を更新する。

  4. /etc/fstab を編集し、/ パーティションをマウントするための、例えば次のような行を:

    /dev/hda6     /     ext3  defaults,errors=remount-ro 0 1

    次のように変更する:

    UUID=d0dfcc8a-417a-41e3-ad2e-9736317f2d8  /  ext3  defaults,errors=remount-ro 0 1

    ここで問題となる変更は最初のカラムです。この行の残りのカラムは変更する必要はありません。

4.8.2. アップグレードの後で問題を解決するには

4.8.2.1. 解決方法 1

この方法が適用可能なのは、起動したいエントリを選ぶためのメニューインタフェースを Grub が表示してくれる場合のみです。そのようなメニューが現れない場合は、カーネルが起動する前に Esc キーを押して、メニューを表示させてみてください。このメニューに入れない場合は、項4.8.2.2. 「解決方法 2」項4.8.2.3. 「解決方法 3」を試してみてください。

  1. Grub のメニューにおいて、起動したいエントリをハイライトします。その上で e キーを押し、このエントリに関するオプションを編集します。オプションはおそらく次のようになっているでしょう:

    root (hd0,0)
    kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro
    initrd /initrd.img-2.6.26-1-686

  2. 次の行をハイライトします:

    kernel /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro

    e キーを押して、hdXsdX に置換します (X は、システムによって異なりますが、abcd のいずれかです)。上の例では、置換後にこの行は次のようになります:

    kernel /vmlinuz-2.6.26-1-686 root=/dev/sda6 ro

    その上で、Enter を押して変更を保存します。もし他の行にも hdX がある場合は、それらの行も同様に変更します。root (hd0,0) のようなエントリは変更しないでください。すべての変更が終わったら b キーを押してください。システムが通常どおり起動するはずです。

  3. システムが起動したら、この問題を恒久的に解決する必要があります。項4.8.1. 「アップグレードの前に問題を防ぐには」に飛んで、提示されている 2 つの手順のうちいずれかを実行してください。

4.8.2.2. 解決方法 2

Debian GNU/Linux のインストールメディア (CD/DVD) から起動し、プロンプトが出たら rescue を選択して、レスキューモードを立ち上げます。言語と国、キーボードマップを選択し、その上で (成功するにせよ失敗するにせよ) ネットワークの設定を行います。暫くすると、ルートファイルシステムとして使用したいパーティションを選ぶよう言われます。選択肢として提示されるのは、次のようなものでしょう:

/dev/ide/host0/bus0/target0/lun0/part1
/dev/ide/host0/bus0/target0/lun0/part2
/dev/ide/host0/bus0/target0/lun0/part5
/dev/ide/host0/bus0/target0/lun0/part6

どのパーティションにルートファイルシステムが含まれているのか分かっている場合は、適切なものを選んでください。分からない場合は、とりあえず最初の選択肢を選んでみてください。ルートファイルシステムのパーティションとして不適切だというエラーメッセージが出た場合は次の選択肢を試し、それでもエラーメッセージが出た場合はさらに次の選択肢を試し……、というようにして探してください。順々にパーティションを試していっても、それらのパーティションが壊れることはないはずです。ディスクに 1 つのオペレーティングシステムだけがインストールされている場合は、適切なルートファイルシステムパーティションが容易に見つかるはずです。ディスクに複数のオペレーティングシステムがインストールされている場合は、どのパーティションが適切なパーティションか、予めきちんと知っておいたほうがよいでしょう。

パーティションを選択したら、様々な選択肢が提示されます。選択したパーティションでシェルを実行するという選択肢を選んでください。選んだときにエラーメッセージが出たら、他のパーティションで同じ操作をしてみてください。

これで、/target にマウントされたルートファイルシステムに、ユーザ root としてシェルでアクセスすることが可能になるはずです。ハードディスクの /boot ディレクトリや /sbin ディレクトリ、/usr ディレクトリの内容にもアクセスできる必要があります。これらは、それぞれ /target/boot/target/sbin/target/usr でアクセス可能になっているはずですが、必要であれば、これらのディレクトリを他のパーティションからマウントしてください (どのパーティションをマウントすればよいか分からない場合は、/etc/fstab を参照してください)。

項4.8.1. 「アップグレードの前に問題を防ぐには」に飛んで、提示されている 2 つの手順のうちいずれかを実行し、この問題を恒久的に解決します。その上で、exit と入力してレスキュー用のシェルから抜け出し、reboot を選択してシステムを通常どおり再起動します (起動可能なメディアを取り出すのを忘れないでください)。

4.8.2.3. 解決方法 3

  1. お気に入りの LiveCD ディストリビューション (例えば Debian Live、Knoppix、Ubuntu Live など) から起動します。

  2. /boot ディレクトリが置かれているパーティションをマウントします。どのパーティションに /boot ディレクトリがあるか分からない場合は、dmesg コマンドの出力を用いて、ディスクが hdahdbhdchddsdasdbsdcsdd のいずれであるか調べてください。どのディスクを調べればよいか分かったら、次のコマンド (ディスクが sdb である場合の例) を発行してそのディスクのパーティションテーブルを表示し、適切なパーティションを見つけてください: fdisk -l /dev/sdb

  3. /mnt/boot/grub/menu.lst ファイルを編集します。ただし、適切なパーティションを /mnt にマウントしており、このパーティションが /boot ディレクトリやその内容を含んでいるとします。

    次のようなセクションを見つけます:

    ## ## End Default Options ##
    
    title           Debian GNU/Linux, kernel 2.6.26-1-686
    root            (hd0,0)
    kernel          /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro
    initrd          /initrd.img-2.6.26-1-686
    
    title           Debian GNU/Linux, kernel 2.6.26-1-686 (single-user mode)
    root            (hd0,0)
    kernel          /vmlinuz-2.6.26-1-686 root=/dev/hda6 ro single
    initrd          /initrd.img-2.6.26-1-686
    
    ### END DEBIAN AUTOMAGIC KERNELS LIST

    hdahdbhdchdd をそれぞれ、sdasdbsdcsdd に置換します。次のような行は変更しないでください:

    root            (hd0,0)

  4. システムを再起動し、LiveCD を取り出します。これでシステムは適切に起動するはずです。

  5. システムが起動したら、項4.8.1. 「アップグレードの前に問題を防ぐには」で提示されている 2 つの手順のうちいずれかを実行して、この問題を恒久的に解決します。

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

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

  • 新しいカーネルイメージのメタパッケージが、古いものの依存関係で引きずられてインストールされた場合、自動的にインストールされたというマークがついています。これは以下のようにして修正してください。

    # aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1)
    
  • 項4.10. 「時代遅れ (Obsolete) のパッケージ」 で説明するように、時代遅れ (obsolete) のパッケージや、使用していないパッケージを削除してください。それらのパッケージが使用する設定ファイルを確認し、パッケージの完全削除 (purge) によって、設定ファイルも含めて削除することを検討してください。

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

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

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

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

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

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

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

The list of obsolete packages includes:

  • apache (1.x): 後継となるパッケージは apache2

  • bind (8), successor is bind9

  • php4, successor is php5

  • postgresql-7.4, successor is postgresql-8.1

  • exim (3), successor is exim4

4.10.1. ダミーパッケージ

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

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



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

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

[4] このルールは、ネットワークインターフェースに固有名をつけるため、/etc/udev/rules.d/75-persistent-net-generator.rules スクリプトで自動生成しています。このシンボリックリンクを削除すれば、udevNIC に固有名をつけるのを無効にできます。

[5] lilo の起動エラーコードについてさらに詳しく知りたい場合は、The Linux Bootdisk HOWTO (日本語訳) を参照してください。

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