[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ 次のページ ]

Debian GNU/Linux 4.0 ("etch") リリースノート (Intel x86 用)
第 4 章 - 以前のリリースからアップグレードする


4.1 アップグレードの準備

アップグレードの前には、etch で知っておくべき問題点, 第 5 章 に書かれている情報も読むことをお勧めします。この章は、アップグレードの過程と直接ではなくても関連する可能性がある、生じうる問題点について書かれています。

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

バックアップしたくなるであろう主な対象としては、/etc/var/lib/dpkg の中身、dpkg --get-selections "*" (引用符を忘れてはいけません) の出力などでしょう。

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

アップグレードの前には、その予定をすべてのユーザに知らせるとよいでしょう。しかしシステムに ssh 接続などでアクセスしてきているユーザは、アップグレードの最中にそうと気付くことはほとんどないはずですし、作業を続行できるはずです。万一の用心をしたければ、アップグレードの前にユーザのパーティション (/home) をバックアップして、アンマウントしてしまいましょう。同時にカーネルもアップグレードする場合を除いて、通常は再起動は必要ないでしょう。

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

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

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

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


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

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

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

     # aptitude -y -s -f --with-recommends dist-upgrade
     [ ... ]
     更新: XXX 個、新規インストール: XXX 個、削除: XXX 個、保留: XXX 個。
     yyyMB 中 xx.xMB のアーカイブを取得する必要があります。展開後に追加で AAAMB のディスク容量が消費されます。
     パッケージのインストールまたは削除。

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


4.1.2 2.2 系カーネルはサポートされなくなりました

2.4.1 より前のカーネルを使用している場合、glibc をアップグレードする前に (最低でも) 2.4 系にアップグレードする必要があります。これは、なるべくアップグレードを開始する前に済ませておいてください。推奨されているのは、(2.4 系のカーネルにアップグレードするのではなく、sarge で利用可能な) 2.6 系のカーネルに直接アップグレードすることです。


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

この章で述べられているアップグレード手順は、サードパーティ製のパッケージを使っていない、「純粋な」sarge システムからのアップグレード用です。サードパーティ製のパッケージは先に削除しておくとよいかもしれません。

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


4.2.1 APT の pin 機能を無効にする

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


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

アップグレードに使う手段に関係なく、まず全パッケージの状態を調べ、全パッケージがアップグレード可能な状態にあることを確認するよう推奨します。次のコマンドは、インストールが中断していたり設定に失敗したパッケージや、何らかのエラー状態にあるパッケージを表示します:

     # 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 状態にしておかなければなりません。

パッケージの "hold" 状態を aptitude で変更するには、以下のように実行してください ("hold" 状態を解除するには holdunhold で置き換えます):

     # aptitude hold package_name

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


4.2.3 非公式なソースとバックポート

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

自分の sarge システムに、Debian に存在するパッケージの 非公式にバックポートされた "新" バージョンをインストールしているユーザもいるでしょう。そのようなパッケージはファイルの衝突を引き起こすことにより、アップグレード中に問題を引き起こす場合がほとんどでしょう[2]。ファイル衝突が発生したときの対処方法については、アップグレード中の注意点, 第 4.4.5 節にいくつかの情報があります。


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

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

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

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


4.3.1 APT の Internet ソースの追加

デフォルトの設定では、メインの Debian インターネットサーバを使ってインストールするようになっています。ですがここでは、/etc/apt/sources.list を編集して、他のミラー (できればネットワーク的に最も近いミラー) を使うようにするほうがよいでしょう。

Debian の HTTP/FTP ミラーのアドレスは、http://www.debian.org/distrib/ftplist を参照してください。一般には HTTP ミラーのほうが FTP ミラーよりも高速です。

例えば、一番近くにある Debian ミラーが http://mirrors.kernel.org/debian/ だったとしましょう。このミラーをウェブブラウザや FTP プログラムで見てみると、main などのディレクトリが以下のように構成されていることがわかります。

     http://mirrors.kernel.org/debian/dists/etch/main/binary-i386/...
     http://mirrors.kernel.org/debian/dists/etch/contrib/binary-i386/...

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

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

`dists' は書かなくても暗黙のうちに追加されます。そしてリリース名の後の引数がそれぞれ用いられ、複数のディレクトリの各々のパス名に展開されます。

これらの新たなソースを追加したら、それまでの sources.list 中の "deb" 行の先頭にシャープ記号 (#) を置き、それらを無効にしてください。

インストールに必要なパッケージのうち、ネットワークから取得されたものは、/var/cache/apt/archives ディレクトリ (およびダウンロード中のものは partial/ サブディレクトリ) に置かれます。したがって、インストールを行う前には、十分な領域があるかどうか確認しなければなりません。割に大きめのインストールを行う場合には、ダウンロードデータとして少なくとも 300MB 程度を考慮しておきましょう。


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

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

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

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

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

     deb file:/var/ftp/debian etch 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 からのアップグレード方法のお勧めは、パッケージ管理ツール aptitude を用いる方法です。このプログラムはパッケージに関する判断を apt-get よりも安全に行います。

まず、必要なパーティションが read-write モードでマウントされていることを忘れずに確認しましょう (特にルートと /usr の各パーティション)。以下のようなコマンドラインが使えます。

     # mount -o remount,rw /mountpoint

次に、(/etc/apt/sources.list 内の) APT ソース記述が "etch" か "stable" のいずれかを指定していることを念入りにチェックすべきです。注意: CD-ROM のソース行は "unstable"; を指定していることがよくあります。これは混乱の元ですが、変更してはいけません


4.4.1 セッションの記録

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

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

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

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

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

script-t スイッチをつけておくと、以下のようなコマンドで scriptreplay プログラムがすべてのセッションをリプレイするようになります。

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

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

まず、新規リリース用として入手可能なパッケージの一覧を取得する必要があります。次のように実行してください[3]:

     # apt-get update

4.4.3 aptitude のアップグレード

アップグレード中の複雑な依存関係の解決には、apt-get や sarge の aptitude よりも、etch 版の aptitude のほうが優れていることがアップグレードのテスト中に判明しました。したがって、次のように実行してまずアップグレードすべきです:

     # aptitude install aptitude

発生した変更点の一覧が表示され、承認を求めてくるでしょう。承認する前に提示された変更点、特にアップグレードによって削除されるであろうパッケージに注意を払ってください。

非常に多くのパッケージが削除対象としてリストアップされてしまう場合があります。この場合、aptitude とともに事前にアップグレードするパッケージを選択しておくと、リストアップされるパッケージを減らせるかもしれません。わかりやすい例を挙げてみましょう - すでに KDE がインストールされたシステムのアップグレードテスト中に、大量の KDE パッケージや perl が削除対象になることがありました。ここでは install aptitude ではなく install aptitude perl とすると、うまくいくことがわかりました。


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

さて、アップグレードの主要部分を続行する準備が整いました。以下のコマンドを実行してください:

     # aptitude -f --with-recommends dist-upgrade

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

CD-ROM のセットからアップグレードする場合には、アップグレード作業の最中に CD を交換するよう、数回指定されることになります。同じ CD を複数回入れなければならないかもしれません。これはパッケージ間の相互依存関係のせいで、これらのパッケージが別々の CD に入っていることもあるからです。

現在インストールされているパッケージの更新版が、他のパッケージのインストール状態を変更しなければならないような場合には、そのパッケージは現在のバージョンのままになります ("held back" と表示されます)。この状態は、aptitude でこれらのパッケージをインストール対象として選択するか、aptitude -f install package を試すかのどちらかで解決できます。

--fix-broken (または単に -f) オプションを与えると、apt はシステムに存在する壊れた依存関係を修復しようとします。apt は、壊れたパッケージ依存関係がシステムに存在するのを許しません。


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

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 package_name

として、目ざわりなパッケージを消す作業になります。または次の作業でもよいかもしれません。

     # aptitude --fix-broken install
     # dpkg --configure --pending

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

     # dpkg --install /path/to/package_name.deb

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

     <package-foo> を展開し、置換しています...
     dpkg: <package-name-for-foo> の処理中にエラーが発生しました
      (--unpack):
      `<some-file-name>' を上書きしようとしています。
      これはパッケージ <package-bar> にも含まれています

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

     # dpkg -r --force-depends package_name

問題が修正できたら、先に示したように aptitude コマンドを繰り返し入力すれば、アップグレードを再開できます。

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

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


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

Linux カーネルは、他のパッケージとは別にアップグレードすべきです。そのようにしたい場合は、linux-image-* パッケージのどれか一つをインストールするか、カスタマイズしたカーネルをソースからコンパイルします。カーネルのアップグレードに伴って生じる可能性がある問題に関しては、本セクションの情報を参照してください。

名前空間を整理するため、Linux カーネルパッケージはすべて kernel-* から linux-* に名前が変わりました。

Linux カーネル安定版の 1 つ前の系列である 2.4 系は etch ではもうサポートされていないので、2.4 系のカーネルを使用中の場合は 2.6 系のカーネルにアップグレードすべきです。2.2 系のカーネルを使用中の場合は、その他のパッケージをアップグレードする前に、(最低でも) 2.4 系の、できれば 2.6 系のカーネルにアップグレードしなければなりません。2.6 系へのアップグレードに伴う一般的な問題点がいくつか、2.6 系カーネルへのアップグレード, 第 5.2 節 に記載されています。


4.5.1 2.6 系カーネルからのアップグレード

現在 sarge で 2.6 系カーネルを使用している場合は、etch で利用できる 2.6 系カーネルにアップグレードする前に coreutils を最新バージョンにアップグレードしなければなりません。そのためには、まずシステムの最小限のアップグレードを実施しなければなりません。システムのパッケージを完全にアップグレードするという (パッケージのアップグレード, 第 4.4 節 で説明するような) 選択肢はありません。何故なら、etch に含まれているバージョンの udev はカーネル 2.6.8 をサポートしておらず、逆に、sarge に含まれるバージョンの udev は最新のカーネルでは正しく動作しないからです。

TODO: Describe the steps for this minimal upgrade, should take care of glibc, initrd-tools and udev + linux-image 2.6.


4.5.2 initrd-tools の廃止

initrd-tools はもうサポートされなくなり、initramfs-toolsyaird がそれにとって代わりました。etch のカーネルにアップグレードすると、デフォルトでは initramfs-tools がインストールされます。初めて 2.4 系カーネルから 2.6 系カーネルにアップグレードする場合は、initramfs-tools を使用しなければなりません。2.2 系や 2.4 系のカーネルの上で yaird を使用すると、linux-image-2.6 のインストールは失敗に終わります。


4.5.3 devfs の廃止

etch では、devfs のサポートはもう提供していません。ユーザは、動的な /dev の管理に udev を使用するよう切り換えることが推奨されています。Debian のカーネルには devfs のサポートがもう含まれていないので、devfs ユーザは、etch のカーネルにアップグレードする前に手作業でシステムを切り換える必要があります。

/proc/mounts に 'devfs' という文字列が見つかる場合、おそらく devfs が使用されています。devfs スタイルの名前を参照している設定ファイルはすべて、udev スタイルの名前を使用するよう調整する必要があります。devfs スタイルのデバイス名を参照している可能性が最も高いファイルには、/etc/fstab/etc/lilo.conf/boot/grub/menu.lst などがあります。

生じる可能性がある問題に関するさらに詳しい情報が、バグ報告 #341152 で入手可能です。


4.5.4 標準のカーネルで SMP を使用できます

マルチプロセッサシステムには、Linux カーネルの *-smp フレーバーはもう必要ありません。Intel x86 では、-smp という接尾辞のない linux-image パッケージはユニプロセッサとマルチプロセッサの両方のシステムをサポートしています。


4.5.5 386 カーネルフレーバーの廃止

etch では、Intel x86 の 80386 サブアーキテクチャのサポートがなくなりました。386 カーネルフレーバーはもうサポートされず、新しい 486 フレーバーによって置き換えられました。


4.5.6 デバイスの整列順序の変更

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

ネットワークデバイスについては、ifrename ユーティリティを用いて起動時に物理デバイスを特定の名前に結び付けることで、この順序の変更を防げます。さらに詳しくは、ifrename(8)iftab(5) を参照してください。ネットワークデバイスの順序の変更は、udev のルール、具体的には /etc/udev/rules.d/z25_persistent-net.rules 内の定義を使用しても防げます[4]。ifrenameudev は二者択一で、同時に使用すべきではありません。

ストレージデバイスについては、initramfs-tools を用いて、initramfs-tools が現在と同じ順序でストレージデバイスドライバモジュールをロードするように設定することで、この順序の変更を防げます。そうするには、lsmod の出力に目を通し、システム上のストレージモジュールがロードされた順序を特定してください。lsmod は、ロードされた順序とは逆の順序でモジュールをリストアップします。つまり、リストの最初のモジュールは最後にロードされていたものです。

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

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

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

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


4.5.7 カーネルのアップグレード

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

     # dpkg -l | grep '^ii  linux-image'

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

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

どのパッケージを選択すればよいのか心配ならば、uname -r を実行し、似た名前をもつパッケージを探してください。例えば、コマンドの結果が '2.4.27-3-686' の場合は linux-image-2.6-686 をインストールすることをお勧めします。利用可能なパッケージのうち最良のものを選ぶ手助けとして、次のように apt-cache を用いて各パッケージのパッケージ説明・詳細版を見てもよいでしょう。

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

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

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


4.6 再起動の前にすべきこと

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


4.6.1 lilo の再実行

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

     # /sbin/lilo

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

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

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

再起動する前に lilo を再実行し忘れたり、手動で再実行する前にシステムが偶発的に再起動してしまった場合、システムは起動できなくなるでしょう。その場合、システム起動時に lilo プロンプト全体は表示されず、最初の LI だけが表示されます[5]。この状態からシステムを復旧させるには、メディアインストールディスクから rescue モードでシステムを起動しなければなりません。rescue モードでの起動方法に関してさらに詳しく知りたい場合は、DebianInstaller FAQ を参照してください。


4.6.2 mdadm のアップグレード

mdadm は、MD アレイ (RAID) を initial ramdisk から再構築したりシステム初期化シーケンス中に再構築するのに設定ファイルを必要とするようになりました。パッケージのアップグレードを終えた後、再起動する前に必ず /usr/share/doc/mdadm/README.upgrading-2.5.3.gz に書かれている説明を読み、それに従ってください。このファイルの最新版は http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/debian/README.upgrading-2.5.3?op=file から入手可能です。問題が生じた場合は参考にしてください。


4.7 時代遅れ (Obsolete) なパッケージ

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

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

更新されたシステム内のどのパッケージが "時代遅れ" なのかを検出するのは、パッケージ管理用フロントエンドが当該パッケージにその旨のマークを付けてくれるので簡単です。aptitude を使っているのなら、当該パッケージが "Obsolete and Locally Created Packages" 欄に列記されているのに気づくでしょう。dselect も同じようなセクションを提供しますが、表示される一覧はわずかに異なっています。さらに、sarge で手作業でパッケージをインストールするのに aptitude を使っていたのなら、手作業でインストールされたパッケージの記録が取られており、依存元パッケージが削除されればもはや不要となる依存関係のみによって導入されたパッケージに時代遅れのマークを付けることができるでしょう。また aptitude は、deborphan とは異なり、手作業でインストールしたパッケージには時代遅れのマークを付けません (依存関係によって自動でインストールされたものにはマークを付けます)。

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

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


4.7.1 ダミーパッケージ

sarge のいくつかのパッケージは etch では複数のパッケージに分割されていますが、これは大半がシステムの保守性を改善するためです。この場合におけるアップグレードを容易にするために、etch はしばしば "ダミーの" パッケージ - sarge での古いパッケージと同じ名前で、新規パッケージを導入するための依存関係を備えた空のパッケージ - を提供しています。これらの "ダミー" パッケージはアップグレード後は Obsolete 扱いとされ、安全に削除することができます。

大半の (すべてではない) ダミーパッケージの説明文には、その目的が記されています。しかしながらダミーパッケージの説明文は統一されていないため、自分のシステム内のダミーパッケージを検出するために deborphan--guess オプション付で使うこともできます。いくつかのダミーパッケージは、アップグレード後に削除されることを意図しておらず、代わりに時間とともに変化するプログラムの利用可能な最新バージョンの記録用として使われることに注意してください。


[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ 次のページ ]

Debian GNU/Linux 4.0 ("etch") リリースノート (Intel x86 用)

$Id: release-notes.ja.po,v 1.7 2006/11/28 07:09:59 jseidel Exp $

Josip Rodin, Bob Hilliard, Adam Di Carlo, Anne Bezemer, Rob Bradford (現在のメンテナ), Frans Pop (現在のメンテナ), Andreas Barth (現在のメンテナ)
debian-doc@lists.debian.org