システムをアップグレードする前に、完全なバックアップを取っておくよう強くお勧めします。少なくとも、失いたくないデータや設定情報だけでもバックアップしておきましょう。アップグレードのツールや処理はきわめて信頼性の高いものですが、アップグレードの最中にハードウェア障害が起こると、システムに大きなダメージを与えることがありえます。
バックアップしたくなるであろう主な対象としては、/etc や
/var/lib/dpkg の中身、dpkg --get-selections
"*" (引用符を忘れてはいけません) の出力などでしょう。
アップグレードの過程では、/home
ディレクトリ以下は一切変更されません。とはいえ、(Mozilla スイートの一部や GNOME
や KDE のデスクトップ環境などのように)
ユーザが初めて新しいバージョンのアプリケーションを起動するときに、既存のユーザ設定を新たなデフォルト値で上書きしてしまうものがあるのも事実です。万一に備えて、ユーザのホームディレクトリにある隠しファイルと隠しディレクトリ
(いわゆる「ドットファイル」)
をバックアップしておくのがよいでしょう。古い状態に戻したり、再度設定する場合に役立つはずです。ユーザにもこのことについて知らせておいてください。
アップグレードの前には、その予定をすべてのユーザに知らせるとよいでしょう。しかしシステムに
ssh
接続などでアクセスしてきているユーザは、アップグレードの最中にそうと気付くことはほとんどないはずですし、作業を続行できるはずです。万一の用心をしたければ、アップグレードの前にユーザのパーティション
(/home)
をバックアップして、アンマウントしてしまいましょう。同時にカーネルもアップグレードする場合を除いて、通常は再起動は必要ないでしょう。
ディストリビューションのアップグレードは、ローカルのテキストモードの仮想コンソール
(あるいは直接接続されたシリアル端末) から行うか、リモートなら ssh
接続経由で行いましょう。
重要!
telnet、rlogin、rsh
を用いてアップグレードをしてはいけません。アップグレードマシンの
xdm、gdm、kdm などが管理している X
セッションからのアップグレードも行うべきではありません。これらのサービスはアップグレードの最中に切断されてしまう可能性が高く、するとアップグレード途中のシステムへの接続が不可能になってしまうからです。
あらゆるパッケージのインストール処理はスーパーユーザ特権で実行されなければならないため、必要なアクセス権を得るために
root としてログインするか su や sudo
を使ってください。
アップグレードに必要となる前提条件がいくつかあります。実際にアップグレードを実行する前にそれらを確認してください。
システムアップグレードの前には、残りのシステムのアップグレード, 第 4.4.4 節
で説明するシステム全体のアップグレードを開始するときに十分なハードディスク領域があるかどうかを確認しなければいけません。まず、システムにインストールされるパッケージを一時的にダウンロードするのに、/var/
を置いているファイルシステムパーティションに十分なハードディスクが必要になります。ダウンロード後にはおそらく、アップグレードされるパッケージ
(これらには、より大きなバイナリやより多くのデータが含まれている可能性があります。)
と、アップグレードに伴って引きずり込まれる新しいパッケージの両方のインストールのために、他のファイルシステムパーティションにさらに領域が必要になるでしょう。システムに十分な空き領域がない場合、アップグレードが不完全な状態で終わり、復旧が困難になる可能性があります。
aptitude と apt
のどちらを使っても、インストールに必要なディスク領域の詳細な情報を表示できます。次のように実行すると、実際にアップグレードを実行する前に、必要なディスク領域の推定値を見ることができます。
# aptitude -y -s -f --with-recommends dist-upgrade
[ ... ]
更新: XXX 個、新規インストール: XXX 個、削除: XXX 個、保留: XXX 個。
yyyMB 中 xx.xMB のアーカイブを取得する必要があります。展開後に追加で AAAMB のディスク容量が消費されます。
パッケージのインストールまたは削除。
アップグレードをするのに十分な領域がない場合、事前に領域を解放するのを忘れないようにしてください。以下のことを実行するとよいでしょう。
apt-get clean
を実行してパッケージキャッシュを掃除し、インストールするために以前
(/var/cache/apt/archive に) ダウンロードしたパッケージを削除する。
popularity-contest
をインストールしていれば、popcon-largest-unused
を使って、システムで使用していなく最も大きな領域を占めているパッケージをリストアップできます。deborphan
や debfoster を使って時代遅れのパッケージを見つけることも可能です
(時代遅れ (Obsolete) なパッケージ, 第 4.7 節
を参照してください)。
dpigs
(debian-goodies パッケージに含まれています。) や
wajig (wajig size を実行してください。)
を用いると、ディスク領域の大部分を占めているパッケージをリストアップできます。
/var/log/
の下にあるシステムログを一時的に他のシステムに移動するか、永久に削除する。
2.4.1 より前のカーネルを使用している場合、glibc
をアップグレードする前、つまりできればアップグレードを開始する前に、(最低でも)
2.4 系にアップグレードする必要があります。推奨されているのは 2.6
系のカーネルにアップグレードすることです。
[FIXME: Needs decision/documentation whether to upgrade userland or kernel first.]
この章で述べられているアップグレード手順は、サードパーティ製のパッケージを使っていない、「純粋な」sarge システムからのアップグレード用です。サードパーティ製のパッケージは先に削除しておくとよいかもしれません。
またこの手順は、システムが sarge の最新リリースにアップデート済であるものと想定しています。そうではなかったり、アップグレード済みかどうか不明なら、sarge システムのアップグレード, 第 A.1 節内の指示に従ってください。
特定のパッケージを安定版以外 (テスト版など)
のディストリビューションからインストールするように 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 状態にしておかなければなりません。
パッケージの "hold" 状態を aptitude
で変更するには、以下のように実行してください ("hold"
状態を解除するには hold を unhold で置き換えます):
# aptitude hold package_name
修正が必要なことがあるなら、ソースリストのチェック, 第 A.2
節で説明されているように sources.list が sarge
を指定したままにしておくべきです。
自分のシステムに非 Debian
パッケージがあるなら、依存関係の衝突のためアップグレード中に削除されるかもしれないことに注意すべきです。当該パッケージが
/etc/apt/sources.list
に特別なパッケージアーカイブを追加することでインストールされたのなら、そのアーカイブが
etch 用にコンパイルされたパッケージも提供しているかをチェックし、Debian
パッケージ用のソース行と一緒にそのソース行も適切に修正すべきです。
自分の sarge システムに、Debian に存在するパッケージの 非公式にバックポートされた "新" バージョンをインストールしているユーザもいるでしょう。そのようなパッケージはファイルの衝突を引き起こすことにより、アップグレード中に問題を引き起こす場合がほとんどでしょう[1]。ファイル衝突が発生したときの対処方法については、アップグレード中の注意点, 第 4.4.5 節にいくつかの情報があります。
アップグレードを始める前に、apt の設定ファイル
/etc/apt/sources.list
を編集して、パッケージの取得先を決める必要があります。
apt は、"deb"
行にあるすべてのパッケージを見比べ、最も大きなバージョン番号のパッケージをインストールします。同じパッケージが取得可能な場合は、先に現れた行を優先します
(つまり、複数のミラーを指定している場合は、最初にローカルのハードディスクを、次に
CD-ROM を、最後に HTTP/FTP ミラーを指定するといいでしょう)。
一つのリリースを指定するのに、コードネーム (sarge や etch) と状態名 (旧安定版、安定版、テスト版、不安定版) の両方ともがよく使われています。コードネームによる指定は、新しいリリースが出た時にびっくりせずに済むという利点があるため、ここではコードネームを使っています。もちろんこれは、自分でリリースアナウンスを注視する必要があることを意味してはいません。代わりに状態名を使っているなら、リリースされた直後に利用可能なパッケージの更新が急に増えたことに気づくでしょう。
デフォルトの設定では、メインの 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 程度を考慮しておきましょう。
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" 行の先頭にシャープ記号 (#)
を置き、それらを無効にしてください。
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 /mountpoint
次に、(/etc/apt/sources.list 内の) APT ソース記述が
"etch" か "stable"
のいずれかを指定していることを念入りにチェックすべきです。注意: CD-ROM
のソース行は "unstable";
を指定していることがよくあります。これは混乱の元ですが、変更してはいけません。
ここで強くお勧めしたいのですが、/usr/bin/script
プログラムを使って、このアップグレード作業の記録を取るようにしましょう。こうすれば何らかの問題が生じたときに、何が起こったかを記録しておくことができ、バグ報告の必要が生じた場合に、その正確な情報を提供できます。記録を開始するには次のように入力します。
# script -a ~/upgrade-to-etch.typescript
typescript ファイルは /tmp や /var/tmp
のような一時ディレクトリには置かないでください
(これらのディレクトリのファイルはアップグレードや再起動の際に削除されることがありますから)。
typescript はまた、スクロールしてスクリーンから消えた情報を見ることができるようにもしてくれるでしょう。(Alt-F2 を使って) 2 番の仮想コンソールに切り替えて、ログインしてから less ~root/upgrade-to-etch.typescript と実行すれば当該ファイルを見ることができます。
アップグレード完了後に script を停止するには、プロンプトから
exit と入力してください。
まず、新規リリース用として入手可能なパッケージの一覧を取得する必要があります。次のように実行してください[2]:
# apt-get update
アップグレード中の複雑な依存関係の解決には、apt-get や sarge の
aptitude よりも、etch 版の aptitude
のほうが優れていることがアップグレードのテスト中に判明しました。したがって、次のように実行してまずアップグレードすべきです:
# aptitude install aptitude
発生した変更点の一覧が表示され、承認を求めてくるでしょう。承認する前に提示された変更点、特にアップグレードによって削除されるであろうパッケージに注意を払ってください。
非常に多くのパッケージが削除対象としてリストアップされてしまう場合があります。この場合、aptitude
とともに事前にアップグレードするパッケージを選択しておくと、リストアップされるパッケージを減らせるかもしれません。わかりやすい例を挙げてみましょう
- すでに KDE がインストールされたシステムのアップグレードテスト中に、大量の KDE
パッケージや perl が削除対象になることがありました。ここでは install
aptitude ではなく install aptitude perl
とすると、うまくいくことがわかりました。
doc-base
をインストールしているなら、残りのシステムに先立ってアップグレードしなければなりません。この理由は、同時に
perl
がアップグレードされると失敗する可能性があるからです。同パッケージがインストールされているかどうかを知るには、次のように実行してください:
# dpkg -l doc-base
"i" で始まる行が出力されればインストールされているので、以降の作業を行う前にアップグレードしなければなりません。
# aptitude install doc-base
さて、アップグレードの主要部分を続行する準備が整いました。以下のコマンドを実行してください:
# 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
は、壊れたパッケージ依存関係がシステムに存在するのを許しません。
etch で知っておくべき問題点, 第 5 章で明示的に述べられている問題もありますので、そちらも参照してください。
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 package_name
として、目ざわりなパッケージを消す作業になります。または次の作業でもよいかもしれません。
# aptitude --fix-broken install
# dpkg --configure --pending
極端な場合には、コマンドラインから次のように入力して、再インストールしなければならないかもしれません。
# dpkg --install /path/to/package_name.deb
「純粋な」sarge システムからのアップグレードでは、ファイルの競合は起こらないはずですが、非公式なバックポートパッケージをインストールしているなら起こるかもしれません。ファイルの競合が起こると、次のようなエラーになります:
Unpacking replacement <package-foo> ...
dpkg: error processing <package-name-for-foo> (--unpack):
trying to overwrite `<some-file-name>',
which is also in package `<package-bar>
ファイルの競合を解消するには、エラーメッセージの最後の行に表示されたパッケージを強制的に削除します:
# dpkg -r --force-depends package_name
問題が修正できたら、先に示したように aptitude コマンドを繰り返し入力すれば、アップグレードを再開できます。
アップグレードの最中に、いくつかのパッケージの設定・再設定に関する質問が表示されます。/etc/init.d
と /etc/terminfo ディレクトリに置かれるファイルと
/etc/manpath.config
に関しては、パッケージメンテナのバージョンに置き換えるようにしてください。システムの整合性を保つためには
`yes' と答えることが必要になります。古いバージョンも .dpkg-old
という拡張子で保存されていますので、戻すのはいつでもできます。
どうすればよいかわからなくなったら、そのパッケージやファイルの名前を書き留めておいて、その問題解決は後回しにしましょう。typescript ファイルを検索すれば、アップグレードの最中に画面に表示された情報を見直すこともできます。
Linux
カーネルは、残りのパッケージとは別にアップグレードすべきです。そのようにしたい場合は、linux-image-*
パッケージのどれか一つをインストールするか、カスタマイズしたカーネルをソースからコンパイルするかします。カーネルのアップグレードに伴って生じうる問題に関しては、本セクションの情報を参照してください。
名前空間を整理するため、Linux カーネルパッケージは (kernel-* から) linux-* に名前が変わりました。
If you are currently using a kernel from the 2.4 series, the older stable Linux kernel series, you should upgrade to a 2.6 series kernel, as 2.4 is no longer supported in Etch. If you are currently using a kernel from the 2.2 series, you must upgrade to (at least the 2.4 series, better to a 2.6 series kernel prior to upgrading your packages. Some issues associated with an upgrade to 2.6 are documented in (FIXME - the link is partly broken)
initrd-tools is no longer supported and has been superseded by
initramfs-tools and yaird. Upgrading to an etch
kernel will cause initramfs-tools to be installed by default. If
you are upgrading from a 2.4 kernel to a 2.6 kernel for the first time, you
must use initramfs-tools. yaird will cause
linux-image-2.6 installations to fail when running on a 2.2 or 2.4 kernel.
Etch no longer provides support for devfs. It is recommended that
users transition to udev for dynamic /dev management. Debian
kernels not longer include support for devfs, so
devfs users will need to manually convert their systems before
upgrading to an etch kernel.
If you see the string 'devfs' in /proc/mounts, you are likely
using devfs. Any config files that reference devfs style names will need to be
adjusted to use udev style names. Files that are most likely to refer to devfs
style device names include /etc/fstab,
/etc/lilo.conf, /boot/grub/menu.lst, etc.
More information about possible issues are in the bug report #351152.
Multiprocessor systems no longer require a *-smp flavour of the Linux kernel. linux-image packages without the -smp suffix have gained support for multiprocessor systems on amd64, i386 and ia64 since Etch.
Support for the 80386 sub-archicture for i386 has been dropped in etch. The 386 kernel flavor is no longer supported and has been replaced by the new 486 flavour.
Etch features a more robust mechanism for hardware discovery than previous releases. However, this may cause changes in the order devices are discovered on your system affecting the order in which device names are assigned. For example, if you have two network adapters that are associated with two different drivers, the devices eth0 and eth1 refer to maybe swapped. Please note that the new mechanism means that if you e.g. exchange ethernet adapters in a running etch system, the new adapter will also get a new interface name.
For network devices, you can avoid this reordering by using the
ifrename utility to bind physical devices to specific names at
boot time. See ifrename(8) and iftab(5) for more
information.
For storage devices, you can avoid this reordering by using
initramfs-tools and configuring initramfs-tools to
load storage device driver modules in the same order they are currently loaded.
To do this, identify the order the storage modules on your system were loaded
by looking at the output of lsmod. lsmod lists modules in the reverse order
that they were loaded in, i.e., the first module in the list was the last one
loaded.
However, removing and reloading modules after initial boot will affect this
order. Also, your kernel may have some drivers linked statically, and these
names will not appear in the output of lsmod. You may be able to
decipher these driver names and load order from looking at
/var/log/kern.log, or the output of dmesg.
Add these module names to /etc/initramfs-tools/modules in the
order they should be loaded at boottime. Some module names may have changed
between sarge and etch. For example, sym53c8xx_2 has become sym53c8xx.
You will then need to regenerate your initramfs image(s) by executing
update-initramfs -k all.
Once you are running an etch kernel and udev, you may reconfigure your system
to access disks by an alias that is not dependent upon driver load order.
These aliases reside in the /dev/disk/ hierarchy.
When you dist-upgrade from sarge to etch, it is strongly recommended that you install a new linux-image-2.6-* metapackage. This package may automatically be installed by the dist-upgrade process. You can verify this by running:
# dpkg -l | grep '^ii linux-image'
If you do not see any output, then you will need to install a new linux-image package by hand. To see a list of available linux-image-2.6 metapackages, run:
# apt-cache search linux-image-2.6- | grep -v transition
If you are unsure about which package to select, run uname -r and
look for a package with a similar name. For example, if you see
'2.4.27-3-686', it is recommended that you install linux-image-2.6-686. You
may also use apt-cache to see a long description of each package in order to
help choose the best one available. For example:
# apt-cache show linux-image-2.6-686
インストールするカーネルイメージが決まったら、aptitude install でインストールします。新しいカーネルがインストールされたら、それを有効にするためにリブートしてください。
もうちょっと冒険したい人には、自分のカスタムカーネルをコンパイルする方法も
Debian GNU/Linux は提供しています。kernel-package
をインストールして、/usr/share/doc/kernel-package
の文書を読んでみてください。
aptitude dist-upgrade が終了したら、「公式」にはアップグレードは終了したことになります。しかし次にリブートする前に、面倒を見てやらなければならないことがいくつかあります。
X Window System
関連のパッケージのアップグレードに関する詳しい情報は、/usr/share/doc/xfree86-common/README.Debian-upgrade.gz
を読んでください。これは以前の Debian
リリースすべてのユーザに当てはまります。要するに、読め、ということです。
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
から入手可能です。問題が生じた場合は参考にしてください。
数千個の新規パッケージが導入された一方で、etch では sarge にはあった 2000 個以上の古いパッケージが破棄されたり削除されてもいます。これら時代遅れのパッケージをアップグレードする手段は提供されていません。時代遅れのパッケージを使い続けても構いませんが、Debian プロジェクトは通常 etch がリリースされてから 1 年後に[3]そのようなパッケージへのセキュリティサポートを打ち切り、その後は他のサポートも提供されないのが常です。もし存在するのなら、利用可能な代替品に置き換えることを推奨します。
あるパッケージが本ディストリビューションから削除された理由は、数多くあります - 上流ではもはや保守されていないため、そのパッケージを保守することに興味を抱く Debian 開発者がもはやいないため、提供していた機能が別のソフトウェア (あるいは新バージョン) に取って代わられたため、バグのために etch にはもはや適さないとみなされたため、などです。最後の場合では、当該パッケージが "不安定版" ディストリビューション内には存在していることがあります。
更新されたシステム内のどのパッケージが "時代遅れ"
なのかを検出するのは、パッケージ管理用フロントエンドが当該パッケージにその旨のマークを付けてくれるので簡単です。aptitude
を使っているのなら、当該パッケージが "Obsolete and Locally Created
Packages" 欄に列記されているのに気づくでしょう。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') リリースノート (Intel x86 用)
$Id: release-notes.en.sgml,v 1.103 2006/11/20 09:34:13 aba Exp $debian-doc@lists.debian.org