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

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

バックアップしておくべき主な対象として、/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 パーティションをバックアップするか、アンマウントしてしまいましょう。

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

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

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

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

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

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

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

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

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

mount -o remount,rw /

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

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

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

	重要
	telnet、rlogin、rsh を用いてアップグレードをしてはいけません。アップグレードするマシンの xdm、gdm、kdm などが管理している X セッションからのアップグレードも行うべきではありません。これらのサービスはアップグレードの最中に切断されてしまう可能性が高く、そうなるとアップグレード途中のシステムへの接続が不可能になってしまうからです。GNOME アプリケーションの update-manager の利用は、このツールはデスクトップのセッションが利用可能であるのが前提であるため、新しいリリースへのアップグレードには全く勧められません。

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

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

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

特定のパッケージを安定版以外のディストリビューション (テスト版など) からインストールするように 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-get や dselect とは異なる手法を用いることに注意してください。aptitude で hold 状態にあるパッケージを確認するには、以下のように実行します。

# aptitude search "~ahold" 

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

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

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

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

# echo パッケージ名 hold | dpkg --set-selections

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

修正が必要なことがあるなら、「ソースリストのチェック」で説明するように sources.list が jessie を指定したままにしておくべきです。

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

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

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

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

Debian ミラーのアドレスは、https://www.debian.org/distrib/ftplist にあります (「Debian ミラーサイト一覧」 のセクションを参照してください)。FTP ミラーは廃止される点に注意願います - 「ソースリストのチェック」 を参照して下さい。

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

http://mirrors.kernel.org/debian/dists/stretch/main/binary-armhf/...
http://mirrors.kernel.org/debian/dists/stretch/contrib/binary-armhf/...

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

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

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

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

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

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

/var/local/debian/dists/stretch/main/binary-armhf/...
/var/local/debian/dists/stretch/contrib/binary-armhf/...

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

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

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

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

CD (や DVD、Blu-ray Disc) だけでインストールをしたい場合は、/etc/apt/sources.list 内の 「deb」 行の先頭にハッシュ記号 (#) を置き、それらを無効にしてください。

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-stretch手順.time -a ~/upgrade-stretch手順.script

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

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

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

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

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

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

# apt-get update

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

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

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

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

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

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

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

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

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

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

# apt-get upgrade

	注記
	以前のリリースの一部では、アップグレード作業に aptitude の利用を推奨していました。このツールは jessie から stretch へのアップグレードには推奨されません。

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

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

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

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

# apt-get dist-upgrade

	注記
	以前のリリースの一部では、アップグレード作業に aptitude の利用を推奨していました。このツールは jessie から stretch へのアップグレードには推奨されません。

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

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

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

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

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

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

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

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

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

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

# dpkg --remove パッケージ名

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

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

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

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

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

(<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-get のコマンドを再度入力すれば、アップグレードを再開できます。

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

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

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

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

jessie から stretch への dist-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 を実行し、似た名前をもつパッケージを探してください。例えば、コマンドの出力が '2.6.32-5-amd64' の場合は linux-image-amd64 をインストールすることをお勧めします。利用可能なパッケージのうち最良のものを選ぶ手助けとして、次のように apt-cache を用いて各パッケージのパッケージ説明の詳細版を参照してもよいでしょう。

# apt-cache show linux-image-amd64

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

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

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

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

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

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

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

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

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

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

$ aptitude search '~c'
$ aptitude purge '~c'

jessie の一部のパッケージは stretch では複数のパッケージに分割されていますが、これは大半がシステムの保守性を改善するためです。このような場合のアップグレード手順を容易にするために、stretch はしばしば 「ダミーの」 パッケージ―― jessie での古いパッケージと同じ名前で、新規パッケージが自動的にインストールされるような依存関係を備えた空のパッケージ――を提供しています。これらの 「ダミー」 パッケージはアップグレード後は余計なパッケージ扱いとされ、安全に削除することができます。

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