第4章 Debian 10 (buster) からのアップグレード

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

バックアップしておくべき主な対象として、/etc、/var/lib/dpkg、/var/lib/apt/extended_states の中身、dpkg --get-selections "*" (引用符を忘れてはいけません) の出力などがあります。システムの管理に aptitude を使っている場合は、/var/lib/aptitude/pkgstates もバックアップしておくと良いでしょう。

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

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

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

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

万一の対策をしたければ、アップグレードの前に /home パーティションをバックアップするか、アンマウントしておきましょう。

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

システムが提供しているサービスで、アップグレードに含まれるパッケージが関連するサービスがあるかもしれません。この場合、注意して欲しいのですが、アップグレード作業中に関連パッケージが置換・設定される際、これらのサービスが停止します。この間、サービスは利用できなくなります。

これらのサービスに対する実際のダウン期間は、システム中でアップグレードされるパッケージ数に応じて違いますし、このダウン期間には (もしあれば) システム管理者が各パッケージのアップグレードに対する設定の質問への回答に費やす時間も含まれます。アップグレード作業が放置されたままでいて、システムがアップグレード中に入力を必要とした場合、非常に長期間サービスが利用ができなくなる可能性が非常に高いでしょう ^[1]

アップグレードを行うシステムが、ユーザーやネットワークにとって最も重要なサービスを提供している場合^[2]、「システムの最小アップグレード」 で記述しているように最小限のシステムアップグレードを行い、次にカーネルのアップグレードと再起動をし、そしてもっとも重要なサービスに関連するパッケージをアップグレードします。これらのパッケージのアップグレードは、「システムのアップグレード」 にある完全アップグレードより先に実施します。このようにすれば、これらの最重要サービスが動作しつづけ、そして完全アップグレード作業を行っても利用可能であることを保証し、サービスの停止時間を減らすことができます。

Debian はシステムがブートできる状態を常に確保するように努めていますが、アップグレード後のシステム再起動で問題に遭遇する可能性は常にあります。既知の潜在的な問題点の多くは、このリリースノートの本章と次章で述べられています。

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

ssh 接続経由でリモートからアップグレードを行うのなら、リモートのシリアル端末からサーバにアクセスできるよう、必要な事前準備をしておくことをお勧めします。カーネルをアップグレードして再起動した後、ローカルコンソール経由でシステム設定を修正しなければならないことがあります。また、アップグレード中に誤ってシステムが再起動された場合にも、ローカルコンソールを使って復旧する必要に迫られることがあります。

緊急時のリカバリ作業について、通常お勧めしているのは bullseye 用 Debian インストーラーのレスキューモードの利用です。インストーラーを使う利点は、多くのインストール手段の中からあなたの状況に最適なものを選べることにあります。より詳しい情報は、インストールガイドの第 8 章にある「壊れたシステムの復旧」セクションや、Debian インストーラー FAQ を参照してください。

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

# mount -o remount,rw /
      

	重要
	(tinc のような) VPN サービスを使っている場合、アップグレード作業中に使えなくなる可能性を考慮してください。「サービスのダウン期間の準備」 を参照してください。

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

10 (buster) より古い Debian のリリースからの直接のアップグレードはサポートしていません。Debian のバージョンを表示するには以下を実行します:

$ cat /etc/debian_version
      

Debian 10 へのアップグレードは、まずDebian 10 のリリースノートの指示に従ってください。

Debian 由来でないパッケージを見つけるには、以下の aptitude または apt-forktracer を使った 2 つの手法があります。どちらも 100% 正確ではない点を留意して下さい (例: aptitude の例では、古いカーネルパッケージのように、一度は Debian によって提供されていたが今は提供されていないパッケージを表示します)。

$ aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
$ apt-forktracer | sort
    

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

パッケージデータベースの準備が整っているか、アップグレードする前に確認してください。もしパッケージマネージャ aptitudeやsynapticを使っているなら、それらにおいて中断しているアクションがないか確認してください。パッケージマネージャにおいて、あるパッケージが削除あるいは更新の対象となっているなら、アップグレード手順に好ましくない影響を与える可能性があります。パッケージマネージャにおけるアクションの修正は、sources.list に stable や bullseye ではなく、buster が指定されている段階でのみ可能なことに注意してください。「APT source-list ファイルのチェック」 も参照してください。

アップグレードする前に 古いパッケージをシステムから削除する のも良いでしょう。古いパッケージはアップグレードを難しくさせ、メンテナンスされていなければセキュリティリスクが存在しうるからです。

以前のアップグレードでは使われていない設定ファイルのコピー、パッケージメンテナーによって提供された 古いバージョン の設定ファイルなどが残されているかもしれません。以前のアップグレードから取り残されたファイルを削除すると混乱を避けることができます。そのような取り残されたファイルを見つけるには:

# find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
    

セキュリティアーカイブを参照する APT ソース行では、フォーマットが buster/updates から bullseye-security へリリース名と一緒に少し変更されています。「セキュリティアーカイブの構成が変更されました」 を参照ください。

APT source-list ファイルに proposed-updates セクションを含めている場合は、システムのアップグレードを試みる前に、それらのセクションをファイルから削除してください。これは衝突の可能性を減らすための予防策です。

システムに Debian 以外のパッケージがインストールされている場合、依存関係の衝突のためアップグレード中に削除されるかもしれないことに注意してください。当該パッケージが APT source-list ファイルに Debian 以外のパッケージアーカイブを追加することでインストールされたのなら、そのアーカイブが bullseye 用にコンパイルされたパッケージも提供しているかをチェックし、Debian パッケージ用のソース項目と同時にそれも適切に修正してください。

ユーザによっては buster システムに 非公式に バックポートされた 「より新しい」 バージョンのパッケージが 存在している こともあるでしょう。そのようなパッケージはファイルが競合する可能性があるので、アップグレードの際にはおそらく問題を起こします^[4]。「アップグレード中の注意点」には、もしそのような競合が起きた場合にどうやって対処するのか、という情報があります。

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

アップグレードの方法に関係なく、まず全パッケージの状態を調べ、全パッケージがアップグレード可能な状態にあるのを確認することをお勧めします。次のコマンドは、インストールが未完了のパッケージ (Half-Installed) や設定に失敗したパッケージ (Failed-Config)、何らかのエラー状態にあるパッケージを表示します:

# dpkg --audit
    

aptitude や次のようなコマンドを使ってシステムの全パッケージの状態を検査することもできます。

# dpkg -l | pager
    

または

# dpkg --get-selections "*" > ~/curr-pkgs.txt
    

アップグレード前に、あらゆる hold 状態を解除しておいたほうがよいでしょう。アップグレードに不可欠なパッケージが hold 状態にある場合、アップグレードに失敗します。

hold 状態にあるパッケージを記録するのに、aptitude は apt や dselect とは異なる手法を用いることに注意してください。aptitude で hold 状態にあるパッケージを確認するには、以下のように実行します。

# aptitude search "~ahold" 
    

apt でどのパッケージが hold 状態にあるのかを調べたければ、以下のように実行してください。

# dpkg --get-selections | grep 'hold$'
    

パッケージをローカルで変更・再コンパイルしており、パッケージの名前を変えたりバージョン番号に epoch フィールドを追加していないなら、アップグレードしないよう hold 状態にしておかなければなりません。

apt でパッケージを 「hold」 状態に変更するには、以下のように実行してください。

# echo package_name hold | dpkg --set-selections
    

「hold」 状態を解除するには hold の代わりに install を使用してください。

修正が必要なことがあるなら、「APT source-list ファイルのチェック」で説明するように APT source-list ファイルが buster を指定したままにしておくべきです。

新規インストールではデフォルトはネットワークの条件によってあなたに近いサーバから自動的にパッケージをダウンロードできる Debian APT CDN サービスを使うように APT を設定します。これは比較的新しいサービスのため、古いインストールでは以前としてメインの Debian インターネットサーバのひとつまたはミラーのひとつを設定しているかもしれません。もしまだ設定を行っていない場合、APT 設定において CDN サービスを使うように切り替えることを推奨します。

CDN サービスを利用するには、あなたの APT ソース設定にこのような 1 行を追加してください (main と contrib を使用していると仮定します):

deb http://deb.debian.org/debian bullseye main contrib

新しいソースを追加した後、「deb」 行の先頭に、ハッシュ記号 (#) を追加して無効にしてください。

しかしながら、もしあなたのネットワークの条件から近い特定のミラーを使用して良い結果が得たいならば、このオプションはまだ利用可能です。

Debian ミラーのアドレスは、https://www.debian.org/distrib/ftplist にあります (「Debian ミラーサイト一覧」 のセクションを参照してください)。

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

http://mirrors.kernel.org/debian/dists/bullseye/main/binary-arm64/...
http://mirrors.kernel.org/debian/dists/bullseye/contrib/binary-arm64/...
    

与えられたミラーを使うよう APT 設定をするには、このような 1 行を追加してください (再度、main と contrib を使用していると仮定します):

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

「dists」 を書かなくても、暗黙のうちに追加します。リリース名の後の各引数は、パスの末尾につけて、複数のディレクトリに展開するのに用います。

再度、あなたの新しいソースを追加した後、既存のアーカイブエントリを無効にしてください。

HTTP パッケージミラーを使うのではなく、ローカルディスク (おそらくは NFS マウントされたもの) にあるミラーを使うよう、APT source-list ファイルを変更したいことがあるかもしれません。

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

/var/local/debian/dists/bullseye/main/binary-arm64/...
/var/local/debian/dists/bullseye/contrib/binary-arm64/...
    

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

deb file:/var/local/debian bullseye main contrib

「dists」 を書かなくても、暗黙のうちに追加します。リリース名の後の各引数は、パスの末尾につけて、複数のディレクトリに展開するのに用います。

新しいソースを追加した後、APT source-list ファイル内の既存のアーカイブエントリの先頭にハッシュ記号 (#) を追加して無効にしてください。

DVD (や CD、Blu-ray ディスク) だけを使いたい場合は、すべての APT source-list ファイル内の既存エントリの先頭にハッシュ記号 (#) を置き、それらを無効にしてください。

CD-ROM ドライブをマウントポイント /media/cdrom にマウントできるようにしている行が /etc/fstab にあるかどうかを確認してください。例えば /dev/sr0 が CD-ROM ドライブなら、/etc/fstab には次のような行が必要です。

/dev/sr0 /media/cdrom auto noauto,ro 0 0
    

第 4 フィールドの noauto,ro の単語の間には、スペースを入れてはいけません。

これが正しく機能しているか調べるには、CD を挿入して以下を実行してみてください。

# mount /media/cdrom    # マウントポイントに CD をマウントします
# ls -alF /media/cdrom  # CD のルートディレクトリを表示します
# umount /media/cdrom   # CD をアンマウントします
    

問題がなければ

# apt-cdrom add
    

を、Debian Binary CD-ROM それぞれに対して実行してください。各 CD に関するデータが APT のデータベースに追加されます。

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

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

typescript を再度実行する必要がある場合 (例: システムを再起動する必要がある場合) は、どのアップグレード手順のログを取っているのかを示すため、別の手順番号を使ってください。typescript ファイルは /tmp や /var/tmp のような一時ディレクトリには置かないでください (これらのディレクトリ内のファイルはアップグレードや再起動の際に削除されることがありますから)。

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

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

apt は /var/log/apt/history.log に変更されたパッケージの状態を、/var/log/apt/term.log に端末の出力を記録します。

script に -t スイッチをつけておいた場合は、以下のように scriptreplay プログラムでセッション全体をリプレイできます。

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

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

# apt update
    

	注記
	apt-secure のユーザは aptitude や apt-get を使うと問題を見つけることができるかもしれません。apt-get の場合、apt-get update --allow-releaseinfo-change を使うことができます。

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

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

# apt -o APT::Get::Trivial-Only=true full-upgrade
[ ... ]
アップグレード: XXX 個、新規インストール: XXX 個、削除: XXX 個、保留: XXX 個。
xx.x MB のアーカイブを取得する必要があります。
この操作後に追加で AAA MB のディスク容量が消費されます。
    

	注記
	アップグレード手順の初めにこのコマンドを実行すると、以降のセクションで説明するような理由でエラーが発生する可能性があります。その場合、このコマンドを実行してディスク領域の推定値を見る前に、まず「システムの最小アップグレード」で説明しているシステムの最小アップグレードを行う必要があります。

アップグレードをするのに十分な領域がない場合は、apt が以下のような警告メッセージを出します。

エラー: /var/cache/apt/archives/ に充分な空きスペースがありません。
    

この場合、事前に領域を解放するのを忘れないようにしてください。以下のことを実行するとよいでしょう。

パッケージを安全に削除するための注意として、「APT source-list ファイルのチェック」で説明するように、APT source-list ファイルが buster を指し示すよう設定を戻しておくことが望ましいです。

	重要
	アップグレードをリモートから実行している場合は、「アップグレード中に新規の SSH 接続が出来ない」で記載されている点に注意してください。

完全アップグレード (以下に記述しています) を直接行った場合、残しておきたいパッケージが大量に削除されてしまうことが時折あります。そのため、まずはこれらの競合状態を打開するための最小アップグレードを行い、その上で 「システムのアップグレード」 にあるような完全なアップグレードを行う、という 2 段階のアップグレード過程を踏むことをお勧めします。

これをまず行うには、以下のコマンドを実行してください。

# apt upgrade --without-new-pkgs
    

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

システムの容量が少なく、容量による制約のため完全アップグレードが実行できない場合にも、システムの最小アップグレードは有用です。

apt-listchanges パッケージがインストールされていれば、(デフォルト設定で) パッケージのダウンロード後にアップグレードされるパッケージについての重要な情報をページャで表示します。読み終わったら q を押してページャを終了し、アップグレードを続けてください。

これまでの手順を実行し終わったら、アップグレードの主要な部分を続ける準備ができています。以下のコマンドを実行してください。

# apt full-upgrade
    

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

CD/DVD/BD のセットからアップグレードする場合には、アップグレードの最中に、おそらく特定のディスクを入れるよう何回か指示されることになるでしょう。同じディスクを複数回入れなければならないかもしれません。これは、相互に依存しているパッケージが別々のディスクに分散しているためです。

現在インストールされているパッケージを新しいバージョンへとアップグレードする際に、他のパッケージのインストール状態を変更しなければならないような場合には、そのパッケージは現在のバージョンのままになります (「固定されている」 と表示されます)。この状態は、aptitude でこれらのパッケージをインストール対象として選択するか、または apt install パッケージ名 を実行してみると、解決できます。

apt full-upgrade の途中でパッケージをダウンロードした後に失敗となり、

「パッケージ」の即時設定は動作しません。詳細については man 5 apt.conf の APT::Immediate-Configure の項を参照してください。
      

と表示することがあります。これが起きた場合は、代わりに apt full-upgrade -o APT::Immediate-Configure=0 を実行することでアップグレードを進められるはずです。

この問題の暫定的な別の対処の可能性として、buster と bullseye の両方のソースを一時的に sources.list に追加して apt update を実行する方法があります。

bullseye へのアップグレード作業では、システム中のパッケージ削除を尋ねてくるかもしれません。実際のパッケージ一覧は、インストールしてあるパッケージの構成によって異なってくるでしょう。このリリースノートでは、どのような方法をとるべきかに関する一般的なアドバイスをします。しかし、確信がもてない場合は、それぞれの方法でアップグレードを先に進める前に、どのパッケージを削除するよう提案されているのか、きちんと調べることをお勧めします。bullseye で時代遅れ (obsoleted) となったパッケージの詳細については、「利用されなくなったパッケージ」 を参照してください

場合によっては衝突や事前依存のループのために、APT の APT::Force-LoopBreak オプションを有効にして、必須パッケージを一時的に削除しなければならないかもしれません。その場合 apt はこのことを警告してアップグレードを中断します。apt のコマンドラインにオプション -o APT::Force-LoopBreak=1 を指定すれば、この状態を回避できます。

システムの依存関係の構造があまりに問題だらけで、手動での介入が必要となることもあります。通常、手動での介入とは、apt を用いるか、あるいは

# dpkg --remove package_name
    

で問題の原因となるパッケージを消す作業になります。または次の方法を用いてもよいかもしれません。

# apt -f install
# dpkg --configure --pending
    

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

# dpkg --install /path/to/パッケージ名.deb
    

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

(<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 パッケージ名
    

問題が修正できたら、先程説明した apt コマンドを再度入力すれば、アップグレードを再開できます。

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

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

システムのローカルコンソールを使ってアップグレードを実行している場合、アップグレードの最中に何回かコンソールが別の画面へ移動してしまい、アップグレード作業が見えなくなることに気づくかもしれません。例えば、グラフィカルインターフェイスがあるシステムではディスプレイマネージャが再起動した際に起こります。

仮想ターミナル 1 に戻るには (グラフィカルの起動画面の場合は) Ctrl+Alt+F1、あるいは (ローカルのテキストモードコンソールの場合には) Alt+F1を使う必要があります。F1 は、アップグレードが実行されている仮想ターミナルの番号と同じ番号のファンクションキーと置き換えてください。異なったテキストモードのターミナル間で切り替えを行うには、Alt+左矢印 か Alt+右矢印 も使えます。

buster から bullseye への full-upgrade を実行する際、新しい linux-image-* メタパッケージを、過去にインストールしていない場合にはインストールすることを強くお勧めします。これらのメタパッケージは、アップグレードの最中に自動的に新しいバージョンのパッケージを取得します。次のように実行すると、どのパッケージがインストールされているのかを確認できます:

# dpkg -l "linux-image*" | grep ^ii | grep -i meta
    

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

# apt-cache search linux-image- | grep -i meta | grep -v transition
    

どのパッケージを選択すればよいのかわからない場合は、uname -r を実行し、似た名前をもつパッケージを探してください。例えば、コマンドの出力が '4.9.0-8-amd64' の場合は linux-image-amd64 をインストールすることをお勧めします。利用可能なパッケージのうち最良のものを選ぶ手助けとして、次のように apt を用いて各パッケージのパッケージ説明の詳細版を参照してもよいでしょう。以下は例です:

# apt show linux-image-amd64
    

インストールするカーネルイメージが決まったら、apt install でインストールします。次回、再起動可能になった際に新しいカーネルバージョンが提供するメリットを得るために再起動を実行する必要があります。ですが、アップグレード後の最初の再起動を実行する前に 「アップグレード後、再起動前にすること」 を参照してください。

少し勇気のある人には、Debian 上で簡単に自分のカスタムカーネルをコンパイルするやり方があります。linux-source パッケージで提供されるカーネルソースをインストールしてください。バイナリパッケージの構築には、ソース中の Makefile 中の deb-pkg ターゲットが使えます。さらなる情報は、Debian Linux カーネルハンドブック にあります。debian-kernel-handbook パッケージでも利用できます。

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

一般的に、削除したパッケージを完全に削除 (purge) するのは賢明なことです。以前のリリースアップグレード (つまりは buster へのアップグレード) の際に削除されているパッケージである、あるいはパッケージがサードパーティベンダーから提供されたものである場合、尚のこととなります。特に、古い init.d スクリプトは問題を起こすことが知られています。

	注意
	パッケージの完全削除 (purge) は通常ログファイルについても完全に削除を行うので、まずはこのバックアップを行ったほうが良いでしょう。

以下のコマンドは、設定ファイルをシステムに残して削除されたパッケージの一覧を (もしあれば) 表示します:

# dpkg -l | awk '/^rc/ { print $2 }'
    

apt purge を実行すればパッケージを削除できます。一度でこれらのパッケージを削除したい場合は、以下のコマンドで実施できます:

# apt purge $(dpkg -l | awk '/^rc/ { print $2 }')
    

aptitude　を利用している場合、上記のコマンドの代わりに以下を使うこともできます:

# aptitude search '~c'
# aptitude purge '~c'
    

buster からのいくつかのパッケージは bullseye においてアップグレードを簡単にできるよう設計された空の代用品である移行用ダミーパッケージによって置き換えられるかもしれません。以前は 1 つのパッケージであったアプリケーションがいくつかのパッケージに分割された場合、移行用パッケージは古いパッケージと同じ名前で、新しいパッケージをインストールするための適切な依存関係をもって提供されるかもしれません。これをインストールした後は冗長なダミーパッケージを安全に削除できます。

(すべてではないのですが) 大半のダミーパッケージの説明には、その目的が記されています。しかしダミーパッケージの説明文は統一されておらず、パッケージ一式をインストールするためや、最新のバージョンを追跡するために「ダミー」パッケージがインストールされたままとなるように設計されているものもあります。自分のシステム内のダミーパッケージを検出するには、deborphan を --guess* オプションつきで使うのが便利でしょう (例: --guess-dummy)。一部のダミーパッケージは、アップグレード後に削除されることを意図したものではなく、プログラムのどのバージョンが現在利用可能な最新版かを長期にわたって追跡するのに使われる、ということに注意してください。