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


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


4.1 アップグレードの準備

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


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

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

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

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

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

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


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

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

万一の用心をしたければ、アップグレードの前にユーザのパーティション (/home) をバックアップして、アンマウントしてしまいましょう。

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


4.1.3 復旧の準備

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

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

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

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

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

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


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

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

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

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


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

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


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

この章で述べられているアップグレード手順は、サードパーティ製のパッケージが無い "純粋" な sarge システムからのアップグレード用です。特に、/usr/X11R6/bin/ 内にプログラムをインストールするサードパーティ製パッケージには、X.Org への移行 (XFree86 から X.Org への移行, 第 5.3 節) によってアップグレード時に問題が発生することが知られています。アップグレードプロセスにおいて最大限の信頼性を確保するために、アップグレード開始前にシステムからサードパーティ製パッケージを削除しておいた方が良いでしょう。

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


4.2.1 パッケージマネージャ内の中断中のアクションを確認

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

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

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


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

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


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

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

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


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

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

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


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

依存関係に引きずられてインストールされたいくつかのパッケージが 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 <パッケージ名>'

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

     deb file:/var/ftp/debian etch 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 よりも安全に行います。

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

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

次に、(/etc/apt/sources.list 内の) APT ソースのエントリが "etch" と "stable" のいずれか一方を指定していることを念入りにチェックしてください。sarge を指し示すソースエントリが含まれないようにすべきです。注意: CD-ROM のソース行は "unstable" を指定していることがよくあります。これは混乱の元かもしれませんが、変更すべきではありません


4.5.1 セッションの記録

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

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

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

     # aptitude update

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


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

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

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

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

[7]

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

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


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

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

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

     # aptitude upgrade

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

最小アップグレードが完了したら、以下のコマンドを実行してください。

     # aptitude install initrd-tools

このステップによって、libc6locales が自動的にアップグレードされ、SELinux サポート用のライブラリ群 (libselinux1) が引きずられてインストールされます。この時点で、xdmgdmkdm などといった実行中のいくつかのサービスが再起動されます。その結果、ローカルの X11 セッションは切断されます。

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

どの場合でも削除されるだろうと予想されるパッケージには、base-confighotplugxlibsnetkit-inetdpython2.3xfree86-commonxserver-common があります。etch で時代遅れとなるパッケージのさらに完全な一覧については、時代遅れ (Obsolete) なパッケージ, 第 4.10 節を参照してください。


4.5.4.1 デスクトップシステムのアップグレード

このアップグレード手順は、sarge の「デスクトップ」タスクがインストールされているシステムで正しく機能することが確認されています。「デスクトップ」タスクがインストールされているか gnome パッケージまたは kde パッケージがインストールされているシステムでは、この手順に沿ってアップグレードすれば、おそらく最もよい結果になるでしょう。

次のようにして libfam0c102 パッケージや xlibmesa-glu パッケージがシステムにインストールされているかを調べたときにまだインストールされていないという結果になった場合は、おそらく、この方法は適用する方法としてふさわしくありません

     # dpkg -l libfam0c102 | grep ^ii
     # dpkg -l xlibmesa-glu | grep ^ii

完全なデスクトップシステムがインストールされている場合、以下のコマンドを実行してください。

     # aptitude install libfam0 xlibmesa-glu

4.5.4.2 X のパッケージがいくつかインストールされているシステムのアップグレード

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) がまだシステムで利用可能になっていない場合はそれらもインストールされる、ということです。どちらのパッケージも、(内部である) ループバックネットワークデバイスにバインドするように設定できはしますが、システムで新たなネットワークサービスを有効にすることになります。


4.5.4.3 X のサポートがインストールされていないシステムでのアップグレード

X のないシステムでは aptitude install コマンドを追加実行する必要はないはずなので、次のステップへとそのまま進めます。


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

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 節を参照してください。


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

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

     # aptitude dist-upgrade

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

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

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


4.5.7 パッケージの署名の取得

アップグレードを終えたら、新しいバージョンの apt を使用してシステムのパッケージ情報を更新できます。新しいバージョンの apt には、パッケージの署名を確認するための仕組みが新たに含まれています。

     # aptitude update

アップグレードによって、Debian パッケージアーカイブの署名用の鍵を取得して有効にする作業は終わっているでしょう。パッケージソースとして他の (非公式の) ものを追加すると、apt は、そのパッケージソースからダウンロードされるパッケージが正規のものかどうかや改竄されていないかどうかを確認できないことについて、警告を表示します。さらに詳しく知りたい場合は、パッケージ管理, 第 2.2.1 節を参照してください。

新しいバージョンの apt を使用し始めたユーザは、apt が、パッケージインデックス一覧全体をダウンロードするのではなくパッケージ差分ファイル (pdiff) をダウンロードするようになったことに気付くでしょう。この機能についてさらに詳しく知りたい場合は、APT のパッケージインデックスファイルの更新が遅くなります, 第 5.1.4 節を参照してください。


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

「純粋な」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 ファイルを検索すれば、アップグレードの最中に画面に表示された情報を見直すこともできます。


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

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

このセクションには、initramfs-toolsudev の使い方に関する情報が多く含まれている、ということに注意してください。mips 用の Debian のカーネルではシステムの起動に initrd を使用していないので、これらの情報のうち一部は適切ではないかもしれません。それにも関わらずこのセクションの情報を含めているのは、別の理由で udev がシステムにインストールされているかもしれないからです。

また、udev がシステムにインストールされていない場合には、ハードウェアの検出に hotplug を使い続けられることにも注意してください。

2.4 系のカーネルを現在使用中の場合は、2.6 系カーネルへのアップグレード, 第 5.2 節も熟読してください。


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

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 の文書を読んでみてください。


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

現在 sarge で 2.6 系カーネルを使用している場合、システムパッケージを完全にアップグレードした後で、このアップグレードを実行します (パッケージのアップグレード, 第 4.5 節を参照してください)。

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

自分のカスタムカーネルを使用していて、etch で提供されているカーネルを使いたい場合も、この手順で行えます。カーネルのバージョンが udev でサポートされていない場合、最小アップグレードの後でアップグレードするのをお勧めします。udev でサポートされている場合は、安全にシステム全体のアップグレードを待っていれば OK です。


4.6.3 2.4 系カーネルからのアップグレード

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-<フレーバー>

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

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

udev のルールを使用すると、ネットワークデバイスが並び替えられないようできます。もっと正確に言うと、/etc/udev/rules.d/z25_persistent-net.rules で定義できます[10]。その他には、起動時に物理デバイスに特定の名前を割り当てる、ifrename ユーティリティを使用できます。詳細は ifrename(8)iftab(5) をご覧ください。この 2 つ (udevifrename) は同時に使用できません。

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

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

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

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

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


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

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


4.7.1 devfs からのコンバート

Debian のカーネルは、もう devfs をサポートしません。そのため devfs のユーザは、etch のカーネルで起動する前に手作業でシステムを切り替える必要があります。

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

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


4.7.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.8 次期リリースへの準備

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


4.9 廃止予定のパッケージ

Lenny のリリースからは、さらに多くのサーバパッケージが廃止されます。したがって、これらのパッケージを今のうちに新しいバージョンに更新しておくと、システムを Lenny へと更新する際の手間が省けます。

廃止予定のパッケージには以下のものがあります。


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

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

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

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

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

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


4.10.1 ダミーパッケージ

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

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


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


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

$Id: release-notes.en.sgml,v 1.312 2007-08-16 22:24:38 jseidel Exp $

Josip Rodin, Bob Hilliard, Adam Di Carlo, Anne Bezemer, Rob Bradford, Frans Pop (現在のメンテナ), Andreas Barth (現在のメンテナ), Javier Fernández-Sanguino Peña (現在のメンテナ), Steve Langasek (現在のメンテナ)
debian-doc@lists.debian.org