アップグレードの前には、etch で知っておくべき問題点, 第 5 章 に書かれている情報も読むことをお勧めします。この章に書かれている問題点は、アップグレードの過程と直接は関係がないかもしれませんが、それでもアップグレードを開始する前に知っておくべき重要事項である可能性があります。
システムをアップグレードする前に、完全なバックアップを取っておくよう強くお勧めします。少なくとも、失いたくないデータや設定情報だけでもバックアップしておきましょう。アップグレードのツールや処理はきわめて信頼性の高いものですが、アップグレードの最中にハードウェア障害が起こると、システムに大きなダメージを与えることがありえます。
バックアップしたくなるであろう主な対象としては、/etc
や
/var/lib/dpkg
の中身、dpkg --get-selections
"*" (引用符を忘れてはいけません) の出力などでしょう。
アップグレードの過程自体は、/home
ディレクトリ以下は一切変更しません。とはいえ、(Mozilla スイートの一部や GNOME
や KDE のデスクトップ環境などのように)
ユーザが初めて新しいバージョンのアプリケーションを起動するときに、既存のユーザ設定を新たなデフォルト値で上書きしてしまうものがあるのも事実です。万一に備えて、ユーザのホームディレクトリにある隠しファイルと隠しディレクトリ
(いわゆる「ドットファイル」)
をバックアップしておくのがよいでしょう。古い状態に戻したり、再度設定する場合に役立つはずです。ユーザにもこのことについて知らせておいてください。
あらゆるパッケージのインストール処理はスーパーユーザ特権で実行されなければならないため、必要なアクセス権限を得るために
root としてログインするかsu
やsudo
を使ってください。
アップグレードにあたって事前に整えなければならない条件がいくつかあります。実際にアップグレードを実行する前にそれらを確認してください。
アップグレードの前には、その予定をすべてのユーザに知らせるとよいでしょう。しかしシステムに
ssh
接続などでアクセスしてきているユーザは、アップグレードの最中にそうと気付くことはほとんどないはずですし、作業を続行できるはずです。
万一の用心をしたければ、アップグレードの前にユーザのパーティション
(/home
) をバックアップして、アンマウントしてしまいましょう。
etch にアップグレードするときはおそらくカーネルをアップグレードしなければならないので、通常は再起動が必要です。通常、再起動はアップグレードが完了した後に行います。
ドライバやハードウェア検出、デバイスファイルの命名法や順序に関して sarge と etch との間ではカーネルに多くの変更が加えられたため、アップグレードのシステム再起動で問題に直面するリスクが高くなっています。既知の潜在的な問題点の多くは、このリリースノートの本章と次章で述べられています。
上述の理由により、システムが再起動に失敗したり、リモート管理されているシステムならネットワーク接続の確立に失敗した場合に備え、復旧できる手立てを整えておくことが大切です。
ssh
接続経由でリモートアップグレードを行うのなら、リモートのシリアル端末からサーバにアクセスできるよう必要な用心をしておくことを強く勧めます。カーネルをアップグレードして再起動した後、(デバイスの整列順序の変更, 第 4.6.4 節
で述べられているように)
いくつかのデバイスの名前が変更され、ローカルコンソール経由でシステム設定を修正しなければならないことがあります。また、アップグレード途中でシステムが予期せぬ再起動を行った場合にも、ローカルコンソールを使って復旧する必要に迫られることもあります。
最初に試すべきもっとも明白なことは、古いカーネルでの再起動です。しかしながら、本文書の別の場所で述べられているいくつかの理由により、これがうまくいくという保証はありません。
古いカーネルでの再起動に失敗するなら、アクセスして修復できるようシステムを起動するための代替手段が必要となるでしょう。1 つのオプションとしては、特別な復旧イメージや Linux ライブ CD を使うことがあります。これらを使って起動した後は、ルートファイルシステムをマウントしてから、問題点を調査解決するために chroot を実行できるはずです。
お勧めしたい別のオプションとしては、etch 用 Debian
インストーラのレスキューモードを使うことがあります。同インストーラを使う利点は、多くのインストール手段の中からあなたの状況に最適なものを選べることです。より詳しい情報は、インストールガイド
の第
8 章にある "壊れたシステムの復旧" セクションや、Debian Installer
FAQ
を参照してください。
initramfs-tools
パッケージには、それが生成する initrd
の中にデバッグシェル[6]が含まれています。例えば、initrd
がルートファイルシステムをマウントできなければ、デバッグシェル内に移るでしょう。同シェルは、問題点を追跡してそれを修正する手助けとなる基本的なコマンドを備えています。
チェックすべき基本的事項としては、次のようなものがあります。/dev
内に適切なデバイスファイルが存在するか、ロードされているモジュール (cat
/proc/modules)、dmesg
の出力に示されたドライバのロード失敗など。dmesg
の出力はまた、どのデバイスファイルがどのディスクに割り当てられているのかも示してくれます。ルートファイルシステムが予期した通りのデバイス上にあるかを確認するために、echo
$ROOT の出力もチェックすべきでしょう。
問題点をしっかり解決できたなら、exit とタイプすることでデバッグシェルを終了させ、起動プロセスを失敗した時点から継続できます。もちろん次回の起動時に再び失敗することが無いよう、根本的な問題を修正して initrd を再生成する必要があるでしょう。
ディストリビューションのアップグレードは、ローカルのテキストモード仮想コンソール
(あるいは直接接続されたシリアル端末) から行うか、リモートなら ssh
接続経由で行いましょう。
リモートでのアップグレード時にさらなるセーフティマージンを得るために、screen
プログラムが提供する仮想コンソール内でアップグレードプロセスを実行することを提案します。同プログラムは安全な再接続を可能にし、リモート接続プロセスが切断された場合でもアップグレードプロセスが中断しないようにしてくれます。
重要!
telnet
、rlogin
、rsh
を用いてアップグレードをしてはいけません。アップグレードマシンの
xdm
、gdm
、kdm
などが管理している X
セッションからのアップグレードも行うべきではありません。これらのサービスはアップグレードの最中に切断されてしまう可能性が高く、そうなるとアップグレード途中のシステムへの接続が不可能になってしまうからです。
2.4.1 より前のカーネルを使用している場合、glibc
をアップグレードする前に (最低でも) 2.4
系にアップグレードする必要があります。これは、アップグレードを開始する前に済ませておくべきです。お勧めは、2.4
系のカーネルにアップグレードするのではなく、sarge で提供されているカーネル
2.6.8 に直接アップグレードすることです。
この章で述べられているアップグレード手順は、サードパーティ製のパッケージが無い
"純粋" な sarge
システムからのアップグレード用です。特に、/usr/X11R6/bin/
内にプログラムをインストールするサードパーティ製パッケージには、X.org への移行
(XFree86 から X.Org への移行, 第 5.3
節)
によってアップグレード時に問題が発生することが知られています。アップグレードプロセスにおいて最大限の信頼性を確保するために、アップグレード開始前にシステムからサードパーティ製パッケージを削除しておいた方が良いでしょう。
またこの手順は、システムが sarge の最新リリースにアップデート済みであるものと想定しています。そうではなかったり、アップグレード済みかどうか不明なら、sarge システムのアップグレード, 第 A.1 節内の指示に従ってください。
パッケージをインストールするのに aptitude
の代わりに
apt-get
を使用すると、時として、aptitude
がそのパッケージを "未使用"
だとみなし、削除対象とすることがあります。一般的にはアップグレードを行う前に、システムが完全に最新の状態で
"クリーン" な状態となっているかを確認するべきです。
このため、パッケージマネージャ aptitude
内で中断しているアクションがあるかどうかを確認すべきでしょう。パッケージマネージャによってあるパッケージが削除あるいは更新の対象となっているなら、アップグレード手順に好ましくない影響を与えるかもしれません。この修正は、sources.list
に stable や etch ではなく、sarge
が指定されている段階でのみ可能なことに注意してください。ソースリストのチェック, 第 A.2 節
も参照してください。
確認するためには、aptitude
のユーザインターフェイスを起動して 'g'
("Go")
を押してください。何らかのアクションが表示されたなら、その内容を確認して修正するかあるいは提案されたアクションを実行すべきです。いかなるアクションも提案されない場合は、"インストール・削除・更新されるパッケージがありません"
というメッセージが表示されるでしょう。
特定のパッケージを安定版以外 (テスト版など)
のディストリビューションからインストールするように APT
を設定しているなら、当該パッケージが新しい安定版リリース内のバージョンにアップグレードできるように、(/etc/apt/preferences
内に保存されている) APT の pin 設定を変更する必要があるかもしれません。APT の
pin 機能に関するより詳しい情報は、apt_preferences(5)
にあります。
アップグレードに使う手段に関係なく、まず全パッケージの状態を調べ、全パッケージがアップグレード可能な状態にあることを確認することをお勧めします。次のコマンドは、インストールが中断していたり設定に失敗したパッケージや、何らかのエラー状態にあるパッケージを表示します:
# dpkg --audit
dselect
や
aptitude
、あるいは次のようなコマンドを使ってシステムの全パッケージの状態を検査することもできます:
# dpkg -l | pager
または
# dpkg --get-selections "*" > ~/curr-pkgs.txt
アップグレード前に、あらゆる hold 状態を解除しておいたほうがよいでしょう。アップグレードに不可欠なパッケージが hold 状態にあるなら、アップグレードに失敗するでしょう。
hold 状態にあるパッケージを記録するのに、aptitude
は
apt-get
や dselect
とは異なる手法を用いることに注意してください。aptitude
では、以下のように実行して hold 状態にあるパッケージを検出できます:
# aptitude search "~ahold" | grep "^.h"
apt-get
でどのパッケージが hold
状態にあるのかを調べたければ、以下のように実行してください:
# dpkg --get-selections | grep hold
パッケージをローカルで変更したり再コンパイルしており、パッケージの名前を変えたりバージョン番号に epoch フィールドを追加していないなら、アップグレードしないよう hold 状態にしておかなければなりません。
aptitude
でパッケージを "hold"
状態に変更するには、以下のように実行してください。
# aptitude hold パッケージ名
"hold" 状態を解除するには hold の代わりに unhold を使用してください。
修正が必要なことがあるなら、ソースリストのチェック, 第 A.2
節で説明するように sources.list
が sarge
を指定したままにしておくべきです。
自分のシステムに非 Debian
パッケージがあるなら、依存関係の衝突のためアップグレード中に削除されるかもしれないことに注意すべきです。当該パッケージが
/etc/apt/sources.list
に特別なパッケージアーカイブを追加することでインストールされたのなら、そのアーカイブが
etch 用にコンパイルされたパッケージも提供しているかをチェックし、Debian
パッケージ用のソース行と一緒にそのソース行も適切に修正すべきです。
自分の sarge システムに、Debian に存在するパッケージの 非公式にバックポートされた "新" バージョンをインストールしているユーザもいるでしょう。そのようなパッケージはファイルの衝突を引き起こすことにより、アップグレード中に問題を引き起こす場合がほとんどでしょう[7]。ファイル衝突が発生したときの対処方法については、アップグレード中の注意点, 第 4.5.8 節にいくつかの情報があります。
依存関係に引きずられてインストールされたいくつかのパッケージが
aptitude
によって削除されるのを防ぐために、それらが auto
パッケージであるとの指定を手作業で外す必要があるでしょう。この中には、デスクトップインストール時の
OpenOffice や Vim が含まれます。
# aptitude unmarkauto openoffice.org vim
さらにカーネルメタパッケージを使ってインストールした場合、2.6 系のカーネルイメージも対象となります。
# aptitude unmarkauto $(dpkg-query -W 'kernel-image-2.6.*' | cut -f1)
注意: 以下のように実行することで、aptitude 内でどのパッケージが auto と指定されているのかを確認できます:
# aptitude search 'i~M <パッケージ名>'
アップグレードを始める前に、apt
の設定ファイル
/etc/apt/sources.list
を編集して、パッケージの取得先を決める必要があります。
apt
は、"deb"
行にあるすべてのパッケージを見比べ、最も大きなバージョン番号のパッケージをインストールします。同じパッケージが取得可能な場合は、先に現れた行を優先します
(つまり、複数のミラーを指定している場合は、最初にローカルのハードディスクを、次に
CD-ROM を、最後に HTTP/FTP ミラーを指定するといいでしょう)。
リリースを指定するのに、コードネーム (sarge や etch) と状態名 (oldstable、stable、testing、unstable) のどちらもよく使用されます。コードネームによる指定は、新しいリリースが出たときに驚かずに済むという利点があるため、ここではコードネームを使用しています。当然ですが、コードネームを使用している場合は自分でリリースアナウンスに注意を払わなければいけません。代わりに状態名を使用している場合は、リリースの直後にパッケージの更新が大量に利用可能になったことに気づくでしょう。
デフォルトの設定では、メインの 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-powerpc/... http://mirrors.kernel.org/debian/dists/etch/contrib/binary-powerpc/...
このミラーを apt
で使うには、次の行を sources.list
ファイルに追加します。
deb http://mirrors.kernel.org/debian etch main contrib
`dists' は書かなくても暗黙のうちに追加されます。そしてリリース名の後の引数がそれぞれ用いられ、複数のディレクトリの各々のパス名に展開されます。
新しいソースを追加した後、sources.list
内の既存の
"deb" 行の先頭にシャープ記号 (#)
を追加して、それらを無効にしてください。
HTTP や FTP のパッケージミラーを使うのではなく、ローカルディスク (多分 NFS
マウントされたもの) にあるミラーを使うよう、/etc/apt/sources.list
を変更したいこともあるかもしれません。
例えばパッケージのミラーが /var/ftp/debian/
にあり、main
などのディレクトリが次のように配置されているとします。
/var/ftp/debian/dists/etch/main/binary-powerpc/... /var/ftp/debian/dists/etch/contrib/binary-powerpc/...
これを apt
から使うには、次の行を sources.list
ファイルに追加します。
deb file:/var/ftp/debian etch main contrib
`dists' は書かなくても暗黙のうちに追加されます。そしてリリース名の後の引数がそれぞれ用いられ、複数のディレクトリの各々のパス名に展開されます。
新しいソースを追加した後、sources.list
内の既存の
"deb" 行の先頭にシャープ記号 (#)
を追加して、それらを無効にしてください。
CD
だけでインストールをしたい場合は、/etc/apt/sources.list
中の "deb" 行の先頭にシャープ記号 (#)
を置き、それらを無効にしてください。
CD-ROM ドライブをマウントポイント /cdrom
にマウントすることを許可している行が /etc/fstab
にあるかどうかを確認してください (apt-cdrom
を使う場合は、マウントポイントを /cdrom
以外にはできません)。例えば /dev/hdc
が CD-ROM
ドライブなら、/etc/fstab
には次のような行が必要です。
/dev/hdc /cdrom auto defaults,noauto,ro 0 0
第 4 フィールドの defaults,noauto,ro の間にはスペースがあってはいけません。
これが正しく機能しているか調べるには、CD を挿入して以下を実行してみてください。
# mount /cdrom # マウントポイントに CD をマウントします # ls -alF /cdrom # CD のルートディレクトリを表示します # umount /cdrom # CD をアンマウントします
問題がなければ
# apt-cdrom add
を、Debian Binary CD-ROM それぞれに対して実行してください。各 CD に関するデータが APT のデータベースに追加されます。
以前の Debian GNU/Linux
からのアップグレード方法のお勧めは、パッケージ管理ツール aptitude
を用いる方法です。このプログラムはパッケージに関する判断を apt-get
よりも安全に行います。
まず、必要なパーティションが read-write
モードでマウントされていることを忘れずに確認しましょう
(特にルートパーティションと /usr
パーティション)。以下のようなコマンドラインが使えます。
# mount -o remount,rw /マウントポイント
次に、(/etc/apt/sources.list
内の) APT ソースのエントリが
"etch" と "stable"
のいずれか一方を指定していることを念入りにチェックしてください。sarge
を指し示すソースエントリが含まれないようにすべきです。注意: CD-ROM のソース行は
"unstable"
を指定していることがよくあります。これは混乱の元かもしれませんが、変更すべきではありません。
ここで強くお勧めしたいのですが、/usr/bin/script
プログラムを使って、このアップグレード作業の記録を取るようにしましょう。こうすれば何らかの問題が生じたときに、何が起こったかを記録しておくことができ、バグ報告の必要が生じた場合に、その正確な情報を提供できます。記録を開始するには次のように入力します。
# script -t 2>~/upgrade-etch.time -a ~/upgrade-etch.script
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
まず、新しいリリースで利用可能なパッケージの一覧を取得する必要があります。そのためには以下のコマンドを実行してください。
# aptitude update
このコマンドを初めて実行して新しいソースを更新する際、ソースの取得性に関する警告がいくつか表示されます。これらの警告は無害なもので、コマンドを再び実行したときには表示されません。
システムアップグレードの前には、残りのシステムのアップグレード, 第 4.5.6 節
で説明するシステム全体のアップグレードを開始するときに十分なハードディスク領域があるかどうかを確認しなければいけません。まず、ネットワーク経由で取得してインストールする必要があるどのようなパッケージも、/var/cache/apt/archives
(およびダウンロード中には partial/
サブディレクトリ)
に保存されます。したがって、システムにインストールされるパッケージをダウンロードして一時的に保存できるよう、/var/
を保持しているファイルシステムパーティションに十分な空き領域があることを確認しなければなりません。ダウンロード後にはおそらく、アップグレードされるパッケージ
(これらには、より大きなバイナリやより多くのデータが含まれている可能性があります)
と、アップグレードに伴って依存関係に引きずられて新たに導入されるパッケージの両方のインストールのために、他のファイルシステムパーティションにさらに領域が必要になるでしょう。システムに十分な空き領域がない場合、アップグレードが不完全な状態で終わり、復旧が困難になる可能性があります。
aptitude
と apt
のどちらを使っても、インストールに必要なディスク領域の詳細な情報が表示されます。アップグレードを実行する前に、次のように実行して必要な領域の推定値を見ることができます。
# aptitude -y -s -f --with-recommends dist-upgrade [ ... ] 更新: XXX 個、新規インストール: XXX 個、削除: XXX 個、保留: XXX 個。 yyyMB 中 xx.xMB のアーカイブを取得する必要があります。展開後に追加で AAAMB のディスク容量が消費されます。 パッケージのインストールまたは削除。
アップグレードをするのに十分な領域がない場合、事前に領域を解放するのを忘れないようにしてください。以下のことを実行するとよいでしょう。
/var/cache/apt/archive
に)
ダウンロードしたパッケージを削除する。apt-get clean
または
aptitude clean
を実行してパッケージキャッシュを一掃すると、以前ダウンロードしたパッケージファイルをすべて削除できます。
popularity-contest
をインストールしていれば、popcon-largest-unused
を使って、システムで使用していないパッケージのうち最も大きな領域を占めているものをリストアップできます。deborphan
や debfoster
を使って時代遅れのパッケージを見つけることも可能です
(時代遅れ (Obsolete) なパッケージ, 第 4.9 節
を参照してください)。それらのツールを使う代わりに aptitude
を「ビジュアルモード」で起動すれば、古いパッケージは、「廃止された、またはローカルで作成されたパッケージ」の下に見つかります。
dpigs
(debian-goodies
パッケージに含まれています) や wajig
(wajig size を実行してください)
を用いると、ディスク領域の大部分を占めているパッケージをリストアップできます。
/var/log/
の下にあるシステムログを一時的に他のシステムに移動するか、永久に削除する。
パッケージを安全に削除するための注意として、ソースリストのチェック, 第 A.2
節で説明するように、sources.list
が sarge
を指し示すよう設定を戻しておくことが望ましいです。
sarge で必要なパッケージの一部と etch で必要なパッケージの一部が衝突するため、直接 aptitude dist-upgrade を実行すると、多くの場合、一時的に固定しておきたいパッケージが多数削除される結果となります。そのため、まずはこれらの競合状態を打開するための最小アップグレードを行い、その上で完全な dist-upgrade を行う、という 2 段階のアップグレード過程を踏むことをお勧めします。
まず、次のコマンドを実行してください。
# aptitude upgrade
このコマンドには、アップグレードしても他のパッケージをインストール・削除する必要がないパッケージだけをアップグレードする、という効果があります。
最小アップグレードが完了したら、以下のコマンドを実行してください。
# aptitude install initrd-tools
このステップによって、libc6
と locales
が自動的にアップグレードされ、SELinux サポート用のライブラリ群
(libselinux1
)
が引きずられてインストールされます。この時点で、xdm
や
gdm
、kdm
などといった実行中のいくつかのサービスが再起動されます。その結果、ローカルの
X11 セッションは切断されます。
次のステップは、どのようなパッケージ群がシステムにインストールされているかによって変化します。このリリースノートでは、どのような方法をとるべきかに関する一般的なアドバイスをします。しかし、確信がもてない場合は、それぞれの方法でアップグレードを先に進める前に、どのパッケージを削除するよう提案されているのかきちんと調べることをお勧めします。
どの場合でも削除されるだろうと予想されるパッケージには、base-config
、hotplug
、xlibs
、netkit-inetd
、python2.3
、xfree86-common
、xserver-common
があります。etch で時代遅れとなるパッケージのさらに完全な一覧については、時代遅れ (Obsolete) なパッケージ, 第 4.9
節を参照してください。
このアップグレード手順は、sarge の「デスクトップ」タスクがインストールされているシステムで正しく機能することが確認されています。「デスクトップ」タスクがインストールされているか gnome パッケージまたは kde パッケージがインストールされているシステムでは、この手順に沿ってアップグレードすれば、おそらく最もよい結果になるでしょう。
次のようにして libfam0c102
パッケージや xlibmesa-glu
パッケージがシステムにインストールされているかを調べたときにまだインストールされていないという結果になった場合は、おそらく、この方法は適用する方法としてふさわしくありません。
# dpkg -l libfam0c102 | grep ^ii # dpkg -l xlibmesa-glu | grep ^ii
完全なデスクトップシステムがインストールされている場合、以下のコマンドを実行してください。
# aptitude install libfam0 xlibmesa-glu
X
のパッケージがいくつかインストールされていても完全な「デスクトップ」タスクがインストールされているわけではないシステムには、異なる方法を使う必要があります。この方法は、一般に、xfree86-common
パッケージがインストールされているシステムに当てはまります。そのようなシステムとしては、tasksel
のサーバタスクがインストールされている一部のサーバシステムなどがあります。というのも、これらのタスクのうち一部には、グラフィカルな管理ツールを含むものがあるからです。X
は実行できても完全な「デスクトップ」タスクはインストールされていないようなシステムを使用するのがおそらく正しい方法でしょう。
# dpkg -l xfree86-common | grep ^ii
まず、libfam0c102
パッケージと xlibmesa-glu
パッケージがインストールされているか、次のようなコマンドで確かめてください。
# dpkg -l libfam0c102 | grep ^ii # dpkg -l xlibmesa-glu | grep ^ii
libfam0c102
パッケージがシステムにインストールされていない場合は、以下のコマンドラインに
libfam0
を含めないでください。また、xlibmesa-glu
パッケージがインストールされていない場合は、以下のコマンドラインに
xlibmesa-glu
を含めないでください[8]。
# aptitude install x11-common libfam0 xlibmesa-glu
注意しなければならないのは、libfam0
をインストールすると、File
Alteration Monitor (fam
) や RPC ポートマッパー
(portmap
)
がまだシステムで利用可能になっていない場合はそれらもインストールされる、ということです。どちらのパッケージも、(内部である)
ループバックネットワークデバイスにバインドするように設定できはしますが、システムで新たなネットワークサービスを有効にすることになります。
X のないシステムでは aptitude install コマンドを追加実行する必要はないはずなので、次のステップへとそのまま進めます。
etch に含まれているバージョンの udev
は、バージョン 2.6.15
より前のカーネル (これには sarge のカーネル 2.6.8 も含まれます)
をサポートしておらず、逆に、sarge に含まれるバージョンの udev
は最新のカーネルでは正しく動作しません。さらに、etch に含まれているバージョンの
udev
をインストールすると、2.4 系 Linux カーネルで使用されていた
hotplug
が強制的に削除されます。
その結果、このアップグレードを行うと、以前のカーネルパッケージはおそらく正しく起動しなくなります。また同様に、アップグレードの最中には、udev
がアップグレードされている一方で最新のカーネルがまだインストールされていない状況が存在します。もし、アップグレードがまだ完了していないこのような状況でシステムを再起動することになったら、ドライバの検出やロードを正しく行えないためにシステムは起動できないでしょう
(リモートからアップグレードしている場合は、発生する可能性があるこのような事態に対する心構えについては、アップグレード用の安全な環境の準備, 第 4.1.4
節の忠告を参照してください)。
したがって、「デスクトップ」タスク、あるいはそれ以外でも受け入れ難い数のパッケージ削除を伴うパッケージがシステムにインストールされているのでなければ、この段階でカーネルだけをアップグレードすることをお勧めします。
このカーネルアップグレードを実行するには、次のコマンドを実行してください。
# aptitude install linux-image-2.6-フレーバー
カーネルパッケージのどのフレーバーをインストールすべきか判断するための手助けが欲しい場合は、カーネルメタパッケージのインストール, 第 4.6.1 節を参照してください。
デスクトップの場合、残念ながら、新しいカーネルパッケージのインストールが新しい
udev
のインストールの直後に確実に行われるようにするのは不可能です。したがって、hotplug
を完全にサポートしているカーネルがシステムにインストールされていない状況が、どのくらい長くかはわかりませんが存在します。システムの起動が
hotplug に依存しないような設定に関する情報については、カーネルと関連パッケージのアップグレード, 第 4.6
節を参照してください。
さて、アップグレードの主要部分を続行する準備が整いました。以下のコマンドを実行してください:
# aptitude dist-upgrade
これによってシステムの完全なアップグレードを行います。すなわち、すべてのパッケージの最新版を入手し、リリース間でのパッケージの依存関係の変化すべてを解決します。必要に応じて、新しいパッケージ (通常は更新版のライブラリや、名前の変わったパッケージ) をインストールしたり、衝突している古いパッケージを削除したりもします。
CD-ROM のセットからアップグレードする場合には、アップグレード作業の最中に CD を交換するよう、数回指定されることになります。同じ CD を複数回入れなければならないかもしれません。これは、相互に依存しているパッケージが別々の CD に分散してこともあるからです。
現在インストールされているパッケージの更新版が、他のパッケージのインストール状態を変更しなければならないような場合には、そのパッケージは現在のバージョンのままになります
(「固定されている」と表示されます)。この状態は、aptitude
でこれらのパッケージをインストール対象として選択するか、aptitude -f
install パッケージ を試すかのどちらかで解決できます。
アップグレードを終えたら、新しいバージョンの apt
を使用してシステムのパッケージ情報を更新できます。新しいバージョンの
apt
には、パッケージの署名を確認するための仕組みが新たに含まれています。
# aptitude update
アップグレードによって、Debian
パッケージアーカイブの署名用の鍵を取得して有効にする作業は終わっているでしょう。パッケージソースとして他の
(非公式の) ものを追加すると、apt
は、そのパッケージソースからダウンロードされるパッケージが正規のものかどうかや改竄されていないかどうかを確認できないことについて、警告を表示します。さらに詳しく知りたい場合は、パッケージ管理, 第 2.2.1
節を参照してください。
新しいバージョンの apt
を使用し始めたユーザは、apt
が、パッケージインデックス一覧全体をダウンロードするのではなくパッケージ差分ファイル
(pdiff)
をダウンロードするようになったことに気付くでしょう。この機能についてさらに詳しく知りたい場合は、APT
のパッケージインデックスファイルの更新が遅くなります, 第 5.1.4
節を参照してください。
aptitude
や apt-get
、dpkg
を使用した操作が次のようなエラーで失敗に終わるかもしれません。
E: Dynamic MMap ran out of room
この場合、デフォルトのキャッシュ容量では不十分だということになります。これを解決するには、/etc/apt/sources.list
から不要な行を削除もしくはコメントアウトするか、キャッシュサイズを増やします。キャッシュサイズを増やすには、/etc/apt/apt.conf
に APT::Cache-Limit
を設定します。以下のコマンドを実行すれば、アップグレードするには十分な値が設定されます:
# echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf
ここでは、/etc/apt/apt.conf
ファイル内にまだこの値を設定していない場合を想定しています。
場合によっては衝突や事前依存のループのために、APT の
APT::Force-LoopBreak
オプションを有効にして、必須パッケージを一時的に削除しなければならないかもしれません。その場合
aptitude
はこのことを警告してアップグレードを中断します。aptitude
のコマンドラインに -o APT::Force-LoopBreak=1
を指定すれば、この状態を回避できます。
システムの依存関係の構造が非常に混乱していて、手動での介入が必要となることもあります。通常これは
aptitude
を用いるか、あるいは
# dpkg --remove パッケージ名
として、目ざわりなパッケージを消す作業になります。または次の作業でもよいかもしれません。
# aptitude --fix-broken install # dpkg --configure --pending
極端な場合には、コマンドラインから次のように入力して、再インストールしなければならないかもしれません。
# dpkg --install /path/to/パッケージ名.deb
「純粋な」sarge システムからのアップグレードでは、ファイルの衝突は起こらないはずですが、非公式なバックポートパッケージをインストールしているなら起こるかもしれません。ファイルの競合が起こると、次のようなエラーになります:
(<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 ファイルを検索すれば、アップグレードの最中に画面に表示された情報を見直すこともできます。
このセクションでは、カーネルのアップグレード方法を説明し、このアップグレードに際して生じる可能性がある問題点を確認します。Debian
で提供されている linux-image-*
パッケージのどれか一つをインストールしても、カスタマイズしたカーネルをソースからコンパイルしてもかまいません。
このセクションに書かれている多くの情報は、ユーザが Debian
のモジュール化されたカーネルのうち一つを initramfs-tools
や
udev
とともに使用しているのを前提にしている、ということに注意してください。initrd
を必要としないカスタムカーネルを使用するのを選択している場合や、initrd
生成ユーティリティとして異なるものを使用している場合は、このセクションの情報の一部は適切ではないかもしれません。
また、udev
がシステムにインストールされていない場合には、ハードウェアの検出に
hotplug
を使い続けられることにも注意してください。
2.4 系のカーネルを現在使用中の場合は、2.6 系カーネルへのアップグレード, 第 5.2 節も熟読してください。
sarge から etch への 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.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
の文書を読んでみてください。
現在 sarge で 2.6 系カーネルを使用している場合、システムパッケージを完全にアップグレードした後で、このアップグレードを実行します (パッケージのアップグレード, 第 4.5 節を参照してください)。
可能なら、カーネルパッケージのアップグレードをメインの dist-upgrade と分けることで、一時的に起動しないシステムにしてしまうことを極力避けられます。この手順の説明についてはカーネルのアップグレード, 第 4.5.5 節をご覧ください。カーネルパッケージのアップグレードは、システムの最小アップグレード, 第 4.5.4 節で説明した最小アップグレードの手順の後以外では行うべきでないことに注意してください。
自分のカスタムカーネルを使用していて、etch
で提供されているカーネルを使いたい場合も、この手順で行えます。カーネルのバージョンが
udev
でサポートされていない場合、最小アップグレードの後でアップグレードするのをお勧めします。udev
でサポートされている場合は、安全にシステム全体のアップグレードを待っていれば OK
です。
2.4系カーネルをインストールしていて、システムのハードウェア検出に
hotplug
を使用している場合、システム全体のアップグレードの前に、sarge の 2.6
系カーネルにまず最初にアップグレードすべきです。システムアップグレードを実施する前に、2.6
系カーネルでシステムが起動していることと、すべてのハードウェアが適切に認識されているかを確認してください。システム全体をアップグレードする際、hotplug
パッケージはシステムから削除され (udev
がインストールされ)
ます。この前にカーネルをアップグレードしていないと、この時点からシステムは適切に起動しません。一旦
sarge での 2.6 系カーネルにアップグレードしたら、2.6 系カーネルからのアップグレード, 第 4.6.2 節
に書かれているようにカーネルをアップグレードできます。
システムが hotplug
でハードウェア検出をしない場合[9]、残りのシステムのアップグレード, 第 4.5.6 節
にあるように、完全にシステムをアップグレードした後で、カーネルのアップグレードをしてもかまいません。システムをアップグレードしたら、以下のようにカーネルをアップグレードできます。(お使いのシステムに合わせて、カーネルパッケージ名の
<フレーバー> を置き換えてください)
# aptitude install linux-image-2.6-<フレーバー>
etch は、以前のリリースよりも強固なハードウェア検出機構を特徴としています。しかし、それによってシステム上のデバイス検出順が変わり、それがデバイス名の割り当て順に影響するかもしれません。例えば、2 つの異なるドライバと結び付いた 2 つのネットワークアダプタがある場合、eth0 と eth1 が参照するデバイスは入れ替わるかもしれません。この新しい機構によって、例えば実行中の etch システムでイーサネットアダプタを交換するなどした場合、新しいアダプタにも新しいインタフェース名が割り当てられるようになる、ということに注意してください。
udev
のルールを使用すると、ネットワークデバイスが並び替えられないようできます。もっと正確に言うと、/etc/udev/rules.d/z25_persistent-net.rules
で定義できます[10]。その他には、起動時に物理デバイスに特定の名前を割り当てる、ifrename
ユーティリティを使用できます。詳細は ifrename(8)
と
iftab(5)
をご覧ください。この 2 つ (udev
と
ifrename
) は同時に使用できません。
ストレージデバイスについては、initramfs-tools
を用いて、現在と同じ順序でストレージデバイスドライバモジュールをロードするように設定することで、この順序の変更を防げます。このためには、lsmod
の出力に目を通し、システム上のストレージモジュールがロードされた順序を特定してください。lsmod
は、ロードされた順序とは逆の順序でモジュールをリストアップします。つまり、リストの最初のモジュールは最後にロードされていたものです。以上は、カーネルが安定した順番で読み込むデバイス
(PCI デバイスなど) にしか、効果がないことに注意してください。
しかし、最初に起動した後にモジュールを削除したりロードしなおしたりすると、この順序にも影響が出ます。また、カーネルには静的にリンクされたドライバが含まれている可能性があり、そのようなドライバの名前は
lsmod
の出力に現れません。/var/log/kern.log
や
dmesg
の出力に目を通すと、これらのドライバの名前やロード順を解読できるかもしれません。
これらのモジュール名を、起動時にロードされるべき順序で
/etc/initramfs-tools/modules
に追加してください。モジュール名の一部は sarge と etch
では異なるかもしれません。例えば、sym53c8xx_2 は sym53c8xx になりました。
その上で update-initramfs -u -k all を実行し、initramfs イメージを再生成する必要があります。
一旦 etch のカーネルと udev
を使用し始めたら、ドライバのロード順に依存しないエイリアスでディスクにアクセスするよう、システムの設定を変更してもよいでしょう。これらのエイリアスは
/dev/disk/
階層にあります。
initramfs-tools
で生成した initrd
を使用してシステムを起動する場合、時として、udev
によるデバイスファイルの作成が、起動スクリプトの動作に間に合わないことがあります。
通常の症状としては、ルートファイルシステムがマウントできず起動に失敗し、デバッグシェルに落ちます。しかしその後チェックしても、必要なデバイスはすべて
/dev
により提供されているのです。このケースは、ルートファイルシステムが USB
ディスクや RAID にある場合に観察されています。
この問題に対処するには、ブートパラメータに rootdelay=9 を指定してください。タイムアウトの値 (秒) は、調整に必要な時間を指定してください。
aptitude dist-upgrade が終了したら、「公式」にはアップグレードは終了したことになります。しかし次に再起動する前に、面倒を見てやらなければならないことがいくつかあります。
Debian のカーネルは、もう devfs をサポートしません。そのため devfs のユーザは、etch のカーネルで起動する前に手作業でシステムを切り替える必要があります。
/proc/mounts
に 'devfs' という文字列がある場合、大抵
devfs を使用しています。devfs
スタイルの名前を参照している設定ファイルは、すべて udev
スタイルの名前を使うように調整する必要があります。devfs
スタイルのデバイス名を参照する可能性があるファイルには、/etc/fstab
、/etc/lilo.conf
、/boot/grub/menu.lst
、/etc/inittab
などがあります。
生じる可能性がある問題に関するさらに詳しい情報が、バグ報告 #341152
で入手可能です。
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
から入手可能です。問題が生じた場合は参考にしてください。
アップグレードの後で、次期リリースに向けてできるいくつかの準備があります。
grub
を使用している場合、/etc/kernel-img.conf
を編集し、update-grub
プログラムの位置が
/sbin/update-grub
から /usr/sbin/update-grub
に変更されたため、位置を調整してください。
# aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6-*' | cut -f1)
# aptitude purge kernel-image-2.6-<フレーバー>
/etc/network/options
にあるカーネルの設定値を、/etc/sysctl.conf
に移動してください。
数千個の新規パッケージが導入された一方で、etch では sarge にはあった 2,000 個以上の古いパッケージが破棄されたり削除されてもいます。これら時代遅れのパッケージをアップグレードする手段は提供されていません。時代遅れのパッケージを使い続けても構いませんが、Debian プロジェクトは通常 etch がリリースされてから 1 年後に[11]そのようなパッケージへのセキュリティサポートを打ち切り、その後は他のサポートも提供しないのが常です。もし存在するのなら、利用可能な代替品に置き換えることをお勧めします。
あるパッケージが本ディストリビューションから削除された理由は、数多くあります――上流ではもはや保守されていないため、そのパッケージを保守することに興味を抱く Debian 開発者がもはやいないため、提供していた機能が別のソフトウェア (あるいは新バージョン) に取って代わられたため、バグのために etch にはもはや適さないとみなされたため、などです。最後の場合では、当該パッケージが "不安定版" ディストリビューション内には存在していることがあります。
更新されたシステム内のどのパッケージが "時代遅れ"
なのかを検出するのは、パッケージ管理用フロントエンドが当該パッケージにその旨のマークをつけてくれるので簡単です。aptitude
を使っているのなら、当該パッケージが「廃止された、またはローカルで作成されたパッケージ」欄に列記されているのに気づくでしょう。dselect
も同じようなセクションを提供しますが、表示される一覧はわずかに異なっています。さらに、sarge
で手作業でパッケージをインストールするのに aptitude
を使っていたのなら、手作業でインストールされたパッケージの記録が取られており、依存元パッケージが削除されればもはや不要となる依存関係のみによって引きずられてインストールされたパッケージに時代遅れのマークをつけることができるでしょう。また
aptitude
は、deborphan
とは異なり、手作業でインストールしたパッケージには時代遅れのマークをつけません
(依存関係によって自動でインストールされたものにはマークをつけます)。
時代遅れのパッケージを見つけるのに使える追加ツールとしては、以下のものがあります――
deborphan
や
debfoster
、cruft
。deborphan
を強くお勧めしますが、同プログラムは (デフォルトモードでは)
時代遅れのライブラリ―― "libs" や "oldlibs"
セクション内にあり、他のパッケージに使われていないパッケージ――しか報告しません。これらのプログラムが表示したパッケージをやみくもに削除しないでください。特に、誤報しやすい非デフォルトのオプションを積極的に使っている場合はなおさらです。実際に削除する前に、削除を提案されたパッケージを手作業で調査
(その中身やサイズ、説明文など) することを強くお勧めします。
Debian
バグ追跡システム
は、パッケージが削除された理由についての情報を提供してくれることがよくあります。あるパッケージ自体についてのアーカイブ化されたバグ報告と、ftp.debian.org
pseudo-package
のアーカイブ化されたバグ報告の両方を調査すべきです。
sarge のいくつかのパッケージは etch では複数のパッケージに分割されていますが、これは大半がシステムの保守性を改善するためです。この場合におけるアップグレードを容易にするために、etch はしばしば "ダミーの" パッケージ―― sarge での古いパッケージと同じ名前で、新規パッケージを導入するための依存関係を備えた空のパッケージ――を提供しています。これらの "ダミー" パッケージはアップグレード後は Obsolete 扱いとされ、安全に削除することができます。
大半の (すべてではない)
ダミーパッケージの説明文には、その目的が記されています。しかしながらダミーパッケージの説明文は統一されていないため、自分のシステム内のダミーパッケージを検出するために
deborphan
を --guess
オプションつきで使うこともできます。いくつかのダミーパッケージは、アップグレード後に削除されることを意図しておらず、代わりに時間とともに変化するプログラムの利用可能な最新バージョンの記録用として使われることに注意してください。
Debian GNU/Linux 4.0 ("etch") リリースノート (PowerPC 用)
$Id: release-notes.ja.po,v 1.24 2007/04/05 01:34:53 fjp Exp $debian-doc@lists.debian.org