インストール中の再起動が不要に

インストールは以前は 2 つの部分に分かれていました。ベースシステムをセットアップしてそれを起動可能にするステージと、その後で再起動してから、ユーザのセットアップ・パッケージ管理システムのセットアップ・(tasksel を使用した) 追加パッケージのインストールなどの面倒を見る base-config を実行するステージです。

&releasename; では、第 2 ステージが Debian Installer 本体に統合されました。この統合には多数の利点があります。例えば、セキュリティが強化されます。また、インストールの最後の再起動後には新システムが正しいタイムゾーンを既にもった状態となり、デスクトップ環境をインストールしている場合はすぐにグラフィカルユーザインタフェースが起動されます。

前のセクションで述べたとおりインストーラに多数の変更が加えられたので、インストーラによる、事前設定ファイルを使用した自動インストールのサポートにも変更がありました。つまり、&oldreleasename; のインストーラで動いた既存の事前設定ファイルがあっても、修正を加えずにそれが新しいインストーラで動くことは期待できません。

幸いなことに、事前設定の使用方法に関する豊富な文書を含んだ付録がにつけられました。

&releasename; のインストーラには、インストールをさらに、そしてより簡単に自動化できるようにする、ワクワクするような新機能がいくつか追加されました。このインストーラは RAID や LVM、暗号化 LVM を使用した高度なパーティション分割もサポートしています。詳しくは付属文書を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

initramfs-tools パッケージには、それが生成する initrd の中にデバッグシェル

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

チェックすべき基本的事項としては、次のようなものがあります。/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 系のカーネルにアップグレードするのではなく、&oldreleasename; で提供されているカーネル 2.6.8 に直接アップグレードすることです。

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

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

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

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

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

修正が必要なことがあるなら、で説明するように sources.list が &oldreleasename; を指定したままにしておくべきです。

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

自分の &oldreleasename; システムに、Debian に存在するパッケージの 非公式にバックポートされた "新" バージョンをインストールしているユーザもいるでしょう。そのようなパッケージはファイルの衝突を引き起こすことにより、アップグレード中に問題を引き起こす場合がほとんどでしょう

Debian のパッケージ管理システムは、対象パッケージを置き換えるように指定されていない限り、通常はあるパッケージが別のパッケージが所有しているファイルを削除したり置き換えることを許可しません。

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

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

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

このミラーを apt で使うには、次の行を sources.list ファイルに追加します。 deb &url-debian-mirror-eg; &releasename; main contrib

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

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

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

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

これを apt から使うには、次の行を sources.list ファイルに追加します。 deb file:/var/ftp/debian &releasename; 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 のデータベースに追加されます。

ここで強くお勧めしたいのですが、/usr/bin/script プログラムを使って、このアップグレード作業の記録を取るようにしましょう。こうすれば何らかの問題が生じたときに、何が起こったかを記録しておくことができ、バグ報告の必要が生じた場合に、その正確な情報を提供できます。記録を開始するには次のように入力します。 # script -t 2>~/upgrade-&releasename;.time -a ~/upgrade-&releasename;.script typescript ファイルは /tmp や /var/tmp のような一時ディレクトリには置かないでください (これらのディレクトリのファイルはアップグレードや再起動の際に削除されることがありますから)。

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

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

script に -t スイッチをつけておいた場合は、以下のようなコマンドを使用して scriptreplay プログラムでセッション全体をリプレイできます。 # scriptreplay ~/upgrade-&releasename;.time ~/upgrade-&releasename;.script

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

# aptitude update

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

システムアップグレードの前には、 で説明するシステム全体のアップグレードを開始するときに十分なハードディスク領域があるかどうかを確認しなければいけません。まず、ネットワーク経由で取得してインストールする必要があるどのようなパッケージも、/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 を実行してパッケージキャッシュを一掃すると、以前ダウンロードしたパッケージファイルをすべて削除できます。

パッケージを安全に削除するための注意として、で説明するように、sources.list が &oldreleasename; を指し示すよう設定を戻しておくことが望ましいです。

&oldreleasename; で必要なパッケージの一部と &releasename; で必要なパッケージの一部が衝突するため、直接 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 があります。&releasename; で時代遅れとなるパッケージのさらに完全な一覧については、を参照してください。

&releasename; に含まれているバージョンの udev は、バージョン 2.6.15 より前のカーネル (これには &oldreleasename; のカーネル 2.6.8 も含まれます) をサポートしておらず、逆に、&oldreleasename; に含まれるバージョンの udev は最新のカーネルでは正しく動作しません。さらに、&releasename; に含まれているバージョンの udev をインストールすると、2.4 系 Linux カーネルで使用されていた hotplug が強制的に削除されます。

その結果、このアップグレードを行うと、以前のカーネルパッケージはおそらく正しく起動しなくなります。また同様に、アップグレードの最中には、udev がアップグレードされている一方で最新のカーネルがまだインストールされていない状況が存在します。もし、アップグレードがまだ完了していないこのような状況でシステムを再起動することになったら、ドライバの検出やロードを正しく行えないためにシステムは起動できないでしょう (リモートからアップグレードしている場合には、発生する可能性があるこのような事態に対する心構えについて、の忠告を参照してください)。

したがって、「デスクトップ」タスク、あるいはそれ以外でも受け入れ難い数のパッケージ削除を伴うパッケージがシステムにインストールされているのでなければ、この段階でカーネルだけをアップグレードすることをお勧めします。

このカーネルアップグレードを実行するには、次のコマンドを実行してください。 # aptitude install linux-image-2.6-フレーバー カーネルパッケージのどのフレーバーをインストールすべきか判断するための手助けが欲しい場合は、を参照してください。

デスクトップの場合、残念ながら、新しいカーネルパッケージのインストールが新しい udev のインストールの直後に確実に行われるようにするのは不可能です。したがって、hotplug を完全にサポートしているカーネルがシステムにインストールされていない状況が、どのくらい長くかはわかりませんが存在します。システムの起動が hotplug に依存しないような設定に関する情報については、を参照してください。

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

# aptitude dist-upgrade

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

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

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

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

# aptitude update

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

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

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 -f install # dpkg --configure --pending

極端な場合には、コマンドラインから次のように入力して、再インストールしなければならないかもしれません。 # dpkg --install /path/to/パッケージ名.deb

「純粋な」&oldreleasename; システムからのアップグレードでは、ファイルの衝突は起こらないはずですが、非公式なバックポートパッケージをインストールしているなら起こるかもしれません。ファイルの競合が起こると、次のようなエラーになります: (<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 のカーネルは、もう devfs をサポートしません。そのため devfs のユーザは、&releasename; のカーネルで起動する前に手作業でシステムを切り替える必要があります。

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

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

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

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

udev は広範囲にわたってテストされていますが、いくつかのデバイスでは若干の修正が必要になるという問題があるかもしれません。大抵の問題は、デバイスファイルの権限や所有者が変更されるというものです。デフォルトではデバイスファイルが作成されない場合もあります (/dev/video や /dev/radio など)。

udev は、これらの問題に対処する設定の仕組みを提供しています。詳しくは、 や /etc/udev を見てください。

2.6.17 以降の Linux は、RFC 1323 で指定された TCP ウィンドウのスケーリングを積極的に使用しています。サーバによってはこれに対しておかしな挙動を示し、ウィンドウサイズを誤って認識することがあります。さらに詳しく知りたい場合は、バグ報告 や 、 を参照してください。

これらの問題を回避する方法は、通常 2 つあります。許可される TCP ウィンドウサイズの最大値を小さな値に戻す (好ましい) 方法と、TCP ウィンドウスケーリングオプションを完全に無効にする (非推奨の) 方法です。にあるコマンドの例を参照してください。

デフォルトでは、&releasename; バージョンの apt は、(/etc/apt/apt.conf 設定ファイルに Acquire::Pdiffs "false"; を追加すれば、この機能を無効にできます。