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

目次

4.1. アップグレードの準備
4.1.1. あらゆるデータや設定情報をバックアップする
4.1.2. 事前にユーザに通知する
4.1.3. サービスのダウン期間の準備
4.1.4. 復旧の準備
4.1.5. アップグレード用の安全な環境の準備
4.1.6. Verify network interface name support
4.2. Checking APT configuration status
4.2.1. proposed-updates セクション
4.2.2. 非公式なソース
4.2.3. APT の pin 機能を無効にする
4.2.4. パッケージの状態をチェックする
4.3. Preparing APT source-list files
4.3.1. APT のインターネットソースの追加
4.3.2. APT のローカルミラーソースの追加
4.3.3. APT の光学メディアソースの追加
4.4. パッケージのアップグレード
4.4.1. セッションの記録
4.4.2. パッケージリストの更新
4.4.3. アップグレードするのに十分な領域があることを確認する
4.4.4. システムの最小アップグレード
4.4.5. システムのアップグレード
4.5. アップグレード中の注意点
4.5.1. 「即時設定は動作しません」で dist-upgrade が失敗する
4.5.2. 予期されるパッケージの削除
4.5.3. 衝突 (Conflicts) あるいは事前依存 (Pre-Depends) のループ
4.5.4. ファイルの衝突
4.5.5. 設定の変更
4.5.6. コンソール接続へセッションの変更
4.6. カーネルと関連パッケージのアップグレード
4.6.1. カーネルメタパッケージのインストール
4.7. 次のリリースへの準備
4.7.1. 削除したパッケージを完全削除する
4.8. 利用されなくなったパッケージ
4.8.1. Transitional dummy packages

4.1. アップグレードの準備

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

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

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

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

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

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

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

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

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

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

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

4.1.3. サービスのダウン期間の準備

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

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

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

4.1.4. 復旧の準備

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

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

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

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

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

4.1.4.1. initrd を使った起動中のデバッグシェル

initramfs-tools パッケージは生成した initrd にデバッグシェルを収録します[3]。例えば、initrd がルートファイルシステムをマウントできなければ、デバッグシェル内に移るでしょう。このデバッグシェルは、問題の追跡、そしておそらくは修正の手助けとなる基本的なコマンドを備えています。

チェックすべき基本的事項としては、次のようなものがあります。/dev 内に適切なデバイスファイルが存在するか、どのモジュールがロードされているか (cat /proc/modules)、dmesg の出力にドライバのロード失敗のエラーが出ていないか、など。dmesg の出力はまた、どのデバイスファイルがどのディスクに割り当てられているのかも示してくれます。ルートファイルシステムが期待通りのデバイス上にあるかを確認するために、echo $ROOT の出力もチェックすべきでしょう。

問題点を何とか解決できたなら、exit とタイプすることでデバッグシェルを終了させ、起動プロセスを失敗した時点から継続できます。もちろん次回の起動時に再び失敗することが無いよう、根本的な問題を修正して initrd を再生成する必要があるでしょう。

4.1.4.2. systemd を使った起動中のデバッグシェル

起動が systemd において失敗する場合、カーネルコマンドラインを変更することでデバッグ用の root シェルを追加できます。基本的な起動は成功するがサービスが起動に失敗する場合は、カーネルパラメーターに systemd.unit=rescue.target を追加すると解決の役に立つかもしれません。

それ以外の場合、カーネルパラメーターとして systemd.unit=emergency.target を指定することによって、可能な限り早い段階で root シェルが使えるようになります。ですが、これは root ファイルシステムを読み書き可能な権限でマウントする前に実行されます。以下を手動で実行する必要があるでしょう:

# mount -o remount,rw /
      

More information on debugging a broken boot under systemd can be found in the Diagnosing Boot Problems article.

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

[重要]重要

If you are using some VPN services (such as tinc) consider that they might not be available throughout the upgrade process. Please see 「サービスのダウン期間の準備」.

In order to gain extra safety margin when upgrading remotely, we suggest that you run upgrade processes in the virtual console provided by the screen program, which enables safe reconnection and ensures the upgrade process is not interrupted even if the remote connection process temporarily fails.

4.1.6. Verify network interface name support

Systems upgraded from older releases that still use network interfaces with names like eth0 or wlan0 are at risk of losing networking once they switch to buster; see 「旧式ネットワークインターフェイス名からの移行について」 for migration instructions.

4.2. Checking APT configuration status

The upgrade process described in this chapter has been designed for pure Debian stable systems. If your APT configuration mentions additional sources besides stretch, or if you have installed packages from other releases or from third parties, then to ensure a reliable upgrade process you may wish to begin by removing these complicating factors.

The main configuration file that APT uses to decide what sources it should download packages from is /etc/apt/sources.list, but it can also use files in the /etc/apt/sources.list.d/ directory - for details see sources.list(5). If your system is using multiple source-list files then you will need to ensure they stay consistent.

Below there are two methods for finding installed packages that did not come from Debian, using either aptitude or apt-forktracer. Please note that neither of them are 100% accurate (e.g. the aptitude example will list packages that were once provided by Debian but no longer are, such as old kernel packages).

$ aptitude search '~i(!~ODebian)'
$ apt-forktracer | sort
  

Direct upgrades from Debian releases older than 9 (stretch) are not supported. Please follow the instructions in the Release Notes for Debian 9 to upgrade to Debian 9 first.

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

You should also make sure the package database is ready before proceeding with the upgrade. If you are a user of another package manager like aptitude or synaptic, review any pending actions. A package scheduled for installation or removal might interfere with the upgrade procedure. Note that correcting this is only possible if your APT source-list files still point to stretch and not to stable or buster; see 「Checking your APT source-list files」.

It is a good idea to remove obsolete packages from your system before upgrading.

4.2.1. proposed-updates セクション

If you have listed the proposed-updates section in your APT source-list files, you should remove it before attempting to upgrade your system. This is a precaution to reduce the likelihood of conflicts.

4.2.2. 非公式なソース

If you have any non-Debian packages on your system, you should be aware that these may be removed during the upgrade because of conflicting dependencies. If these packages were installed by adding an extra package archive in your APT source-list files, you should check if that archive also offers packages compiled for buster and change the source item accordingly at the same time as your source items for Debian packages.

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

4.2.3. APT の pin 機能を無効にする

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

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

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

# dpkg --audit
    

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

# dpkg -l | pager
    

または

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

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

Note that aptitude uses a different method for registering packages that are on hold than apt and dselect. You can identify packages on hold for aptitude with

# aptitude search "~ahold" 
    

If you want to check which packages you had on hold for apt, you should use

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

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

The hold package state for apt can be changed using:

# echo package_name hold | dpkg --set-selections
    

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

If there is anything you need to fix, it is best to make sure your APT source-list files still refer to stretch as explained in 「Checking your APT source-list files」.

4.3. Preparing APT source-list files

Before starting the upgrade you must reconfigure APT's source-list files (/etc/apt/sources.list and files under /etc/apt/sources.list.d/).

APT will consider all packages that can be found via any configured archive, and install the package with the highest version number, giving priority to the first entry in the files. Thus, if you have multiple mirror locations, list first the ones on local hard disks, then CD-ROMs, and then remote mirrors.

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

Debian は、Debian のリリースに関わる関連情報について最新の状態を保つために役立つ 2 つのアナウンス用メーリングリストを提供しています:

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

On new installations the default is for APT to be set up to use the Debian APT CDN service, which should ensure that packages are automatically downloaded from a server near you in network terms. As this is a relatively new service, older installations may have configuration that still points to one of the main Debian Internet servers or one of the mirrors. If you haven't done so yet, it is recommended to switch over to the use of the CDN service in your APT configuration.

To make use of the CDN service, add a line like this to your APT source configuration (assuming you are using main and contrib):

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

After adding your new sources, disable the previously existing deb lines by placing a hash sign (#) in front of them.

However, if you get better results using a specific mirror that is close to you in network terms, this option is still available.

Debian mirror addresses can be found at https://www.debian.org/distrib/ftplist (look at the list of Debian mirrors section).

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

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

To configure APT to use a given mirror, add a line like this (again, assuming you are using main and contrib):

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

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

Again, after adding your new sources, disable the previously existing archive entries.

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

Instead of using remote package mirrors, you may wish to modify the APT source-list files to use a mirror on a local disk (possibly mounted over NFS).

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

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

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

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

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

After adding your new sources, disable the previously existing archive entries in the APT source-list files by placing a hash sign (#) in front of them.

4.3.3. APT の光学メディアソースの追加

If you want to use only DVDs (or CDs or Blu-ray Discs), comment out the existing entries in all the APT source-list files by placing a hash sign (#) in front of them.

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    # this will mount the CD to the mount point
# ls -alF /media/cdrom  # this should show the CD's root directory
# umount /media/cdrom   # this will unmount the CD
    

問題がなければ

# apt-cdrom add
    

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

4.4. パッケージのアップグレード

The recommended way to upgrade from previous Debian releases is to use the package management tool apt.

[注記]注記

apt is meant for interactive use, and should not be used in scripts. In scripts one should use apt-get, which has a stable output better suitable for parsing.

まず、必要なすべてのパーティション (特にルートパーティションと /usr パーティション) を read-write モードでマウントするのを忘れずに行いましょう。それには以下のようなコマンドを使います。

# mount -o remount,rw /mountpoint
  

Next you should double-check that the APT source entries (in /etc/apt/sources.list and files under /etc/apt/sources.list.d/) refer either to buster or to stable. There should not be any sources entries pointing to stretch.

[注記]注記

CD-ROM のソース行は unstable を指定していることがよくあります。これは混乱の元かもしれませんが、変更すべきではありません

4.4.1. セッションの記録

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

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

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

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

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

apt will also log the changed package states in /var/log/apt/history.log and the terminal output in /var/log/apt/term.log. dpkg will, in addition, log all package state changes in /var/log/dpkg.log. If you use aptitude, it will also log state changes in /var/log/aptitude.

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

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

4.4.2. パッケージリストの更新

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

# apt update
    
[注記]注記

Users of apt-secure may find issues when using aptitude or apt-get. For apt-get, you can use apt-get update --allow-releaseinfo-change.

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

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

apt can show you detailed information about the disk space needed for the installation. Before executing the upgrade, you can see this estimate by running:

# apt -o APT::Get::Trivial-Only=true full-upgrade
[ ... ]
XXX upgraded, XXX newly installed, XXX to remove and XXX not upgraded.
Need to get xx.xMB of archives. 
After this operation, AAAMB of additional disk space will be used.
    
[注記]注記

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

If you do not have enough space for the upgrade, apt will warn you with a message like this:

E: You don't have enough free space in /var/cache/apt/archives/.
    

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

  • Remove packages that have been previously downloaded for installation (at /var/cache/apt/archives). Cleaning up the package cache by running apt clean will remove all previously downloaded package files.

  • Remove forgotten packages. If you have used aptitude or apt to manually install packages in stretch it will have kept track of those packages you manually installed, and will be able to mark as redundant those packages pulled in by dependencies alone which are no longer needed due to a package being removed. They will not mark for removal packages that you manually installed. To remove automatically installed packages that are no longer used, run:

    # apt autoremove
            

    余分なパッケージを見つけるのに、deborphandebfostercruft も使えます。これらのツールが表示したパッケージをやみくもに削除しないでください。特に、誤検出しやすい非デフォルトの凶暴なオプションを使っている場合はなおさらです。実際に削除する前に、削除を提案されたパッケージ (の内容やサイズ、説明など) を手作業で調べなおすことを強くお勧めします。

  • 多くの容量を占めていて現在必要のないパッケージを削除する (アップグレード後にいつでもインストールし直せます)。popularity-contest をインストールしていれば、popcon-largest-unused を使うことにより、容量の多くを占めていて使うことのないパッケージの一覧が得られます。dpigs (debian-goodies パッケージに収録) や wajig (wajig size を実行) により、ディスク容量を消費するだけのパッケージを検索することができます。こういった情報は aptitude を使って検索することもできます。aptitude を full-terminal モードで起動し、表示フラットなパッケージ一覧を新規に作成を実行し、l を押して、~i と入力します。S を押して ~installsize と入力します。すると、作業しやすい一覧が得られます。

  • 翻訳や地域化用ファイルが不要なら、それらをシステムから削除する。localepurge パッケージをインストールして設定すれば、選んだ少数のロケールのみがシステムに残るようにすることが可能です。これによって、/usr/share/locale の消費するディスク領域を減らせるでしょう。

  • /var/log/ の下にあるシステムログを、一時的に他のシステムに移動するか、永久に削除する。

  • 仮設の /var/cache/apt/archives を使用する。すなわち、別のファイルシステム (USB ストレージデバイス、一時的なハードディスク、既に使用されているファイルシステムなど) を仮設のキャッシュディレクトリとして拝借することができます。

    [注記]注記

    アップグレード中にネットワーク接続が途切れる可能性があるので、NFS マウントは使用しないでください。

    以下は、/media/usbkey にマウントされた USB ドライブがある場合を例とします。

    1. 今までに、インストールのためにダウンロードされたパッケージを削除します。

      # apt clean
                      

    2. ディレクトリ /var/cache/apt/archives を、USB ドライブにコピーします。

      # cp -ax /var/cache/apt/archives /media/usbkey/
                      

    3. 現在のキャッシュディレクトリに、仮のキャッシュディレクトリをマウントします。

      # mount --bind /media/usbkey/archives /var/cache/apt/archives
                      

    4. アップグレード後に、元々の /var/cache/apt/archives ディレクトリを復活させます。

      # umount /media/usbkey/archives
                      

    5. 残っている /media/usbkey/archives を削除します。

    仮設のキャッシュディレクトリは、システムにマウントされているファイルシステムであれば何にでも作成できます。

  • システムの最小アップグレードを行う (「システムの最小アップグレード」 参照)、あるいは完全アップグレードにしたがって、システムの部分的なアップグレードを行う。これによって、システムを部分的にアップグレードが可能になり、完全アップグレード前にパッケージキャッシュの削除ができます。

Note that in order to safely remove packages, it is advisable to switch your APT source-list files back to stretch as described in 「Checking your APT source-list files」.

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

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

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

# apt-get upgrade
    

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

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

If the apt-listchanges package is installed, it will (in its default configuration) show important information about upgraded packages in a pager after downloading the packages. Press q after reading to exit the pager and continue the upgrade.

4.4.5. システムのアップグレード

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

# apt full-upgrade
    

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

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

New versions of currently installed packages that cannot be upgraded without changing the install status of another package will be left at their current version (displayed as held back). This can be resolved by either using aptitude to choose these packages for installation or by trying apt install package.

4.5. アップグレード中の注意点

以下の章では、buster へのアップグレードの最中に現れるかもしれない既知の問題を記述しています

4.5.1. 「即時設定は動作しません」で dist-upgrade が失敗する

In some cases the apt full-upgrade step can fail after downloading packages with:

E: Could not perform immediate configuration on 'package'.  Please see man 5 apt.conf under APT::Immediate-Configure for details.
      

If that happens, running apt full-upgrade -o APT::Immediate-Configure=0 instead should allow the upgrade to proceed.

Another possible workaround for this problem is to temporarily add both stretch and buster sources to your APT source-list files and run apt update.

4.5.2. 予期されるパッケージの削除

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

4.5.3. 衝突 (Conflicts) あるいは事前依存 (Pre-Depends) のループ

Sometimes it's necessary to enable the APT::Force-LoopBreak option in APT to be able to temporarily remove an essential package due to a Conflicts/Pre-Depends loop. apt will alert you of this and abort the upgrade. You can work around this by specifying the option -o APT::Force-LoopBreak=1 on the apt command line.

It is possible that a system's dependency structure can be so corrupt as to require manual intervention. Usually this means using apt or

# dpkg --remove package_name
    

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

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

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

# dpkg --install /path/to/package_name.deb
    

4.5.4. ファイルの衝突

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

Unpacking <package-foo> (from <package-foo-file>) ...
dpkg: error processing <package-foo> (--install):
trying to overwrite `<some-file-name>',
which is also in package <package-bar>
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
<package-foo>
    

ファイルの衝突を解消するには、エラーメッセージの最後の行に表示されたパッケージを強制的に削除します:

# dpkg -r --force-depends package_name
    

After fixing things up, you should be able to resume the upgrade by repeating the previously described apt commands.

4.5.5. 設定の変更

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

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

4.5.6. コンソール接続へセッションの変更

If you are running the upgrade using the system's local console you might find that at some points during the upgrade the console is shifted over to a different view and you lose visibility of the upgrade process. For example, this may happen in systems with a graphical interface when the display manager is restarted.

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

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

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

このセクションに書かれている多くの情報は、ユーザが Debian のモジュラーカーネルのいずれかを initramfs-toolsudev とともに使用しているのを前提にしている、ということに注意してください。initrd を必要としないカスタムカーネルを使用するのを選択した場合や、initrd 生成ユーティリティとして異なるものを使用している場合は、このセクションの情報の一部は適切ではないかもしれません。

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

When you full-upgrade from stretch to buster, it is strongly recommended that you install a linux-image-* metapackage, if you have not done so before. These metapackages will automatically pull in a newer version of the kernel during upgrades. You can verify whether you have one installed by running:

# 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
    

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 4.9.0-8-amd64, it is recommended that you install linux-image-amd64. You may also use apt to see a long description of each package in order to help choose the best one available. For example:

# apt show linux-image-amd64
    

You should then use apt install to install it. Once this new kernel is installed you should reboot at the next available opportunity to get the benefits provided by the new kernel version. However, please have a look at 「アップグレード後、再起動前にすること」 before performing the first reboot after the upgrade.

For the more adventurous there is an easy way to compile your own custom kernel on Debian. Install the kernel sources, provided in the linux-source package. You can make use of the deb-pkg target available in the sources' makefile for building a binary package. More information can be found in the Debian Linux Kernel Handbook, which can also be found as the debian-kernel-handbook package.

If possible, it is to your advantage to upgrade the kernel package separately from the main full-upgrade to reduce the chances of a temporarily non-bootable system. Note that this should only be done after the minimal upgrade process described in 「システムの最小アップグレード」.

4.7. 次のリリースへの準備

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

4.7.1. 削除したパッケージを完全削除する

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

[注意]注意

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

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

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

The packages can be removed by using apt purge. Assuming you want to purge all of them in one go, you can use the following command:

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

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

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

4.8. 利用されなくなったパッケージ

buster では大量の新規パッケージが導入された一方で、stretch に存在していた非常の少量の古いパッケージの破棄や削除が行われています。これら時代遅れのパッケージをアップグレードする手段は提供されていません。時代遅れのパッケージを使い続けても構いませんが、Debian プロジェクトでは通常、buster がリリースされてから 1 年後にセキュリティサポートを終了します [5]。そして、その時点から他のサポートも提供しません。利用可能な代替手段で置き換えれるのであれば、そうすることをお勧めします。

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

Some package management front-ends provide easy ways of finding installed packages that are no longer available from any known repository. The aptitude textual user interface lists them in the category Obsolete and Locally Created Packages, and they can be listed and purged from the commandline with:

# aptitude search '~o'
# aptitude purge '~o'
  

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

Buster での廃止パッケージ一覧については、「特記すべき時代遅れとなったパッケージたち」 を参照して下さい。

4.8.1. Transitional dummy packages

Some packages from stretch may have been replaced in buster by transitional dummy packages, which are empty placeholders designed to simplify upgrades. If for instance an application that was formerly a single package has been split into several, a transitional package may be provided with the same name as the old package and with appropriate dependencies to cause the new ones to be installed. After this has happened the redundant dummy package can be safely removed.

The package descriptions for transitional dummy packages usually indicate their purpose. However, they are not uniform; in particular, some dummy packages are designed to be kept installed, in order to pull in a full software suite, or track the current latest version of some program. You might also find deborphan with the --guess-* options (e.g. --guess-dummy) useful to detect transitional dummy packages on your system.



[1] debconf の優先度を、とても高いレベルに設定していると設定プロンプトを抑制できますが、デフォルト値があなたのシステムに合わない場合、サービスはそのままでは起動に失敗することでしょう。

[2] 例: DNS や DHCP サービス、特に冗長性やフェイルオーバー機能が無い場合。DHCP の例では、リースタイムがアップグレード作業が完了する時間よりも短い場合、エンドユーザはネットワークから切り離されるでしょう。

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

[4] Debian のパッケージ管理システムにおいて、別のパッケージを置き換えるように指定されていないパッケージは、通常、別のパッケージの所有ファイルを削除したり置き換えたりすることはできません。

[5] あるいは、1 年以内でも別のリリースが出るときに。一般に、どの時点でも、サポートされる安定版リリースは 2 つだけです。