4. Debian 12 (bookworm) からのアップグレード
4.1. アップグレードの準備
アップグレードの前には、trixie で注意すべき点 に書かれている情報も読むことをお勧めします。この章に書かれている問題点は、アップグレードの過程と直接は関係がないかもしれませんが、それでもアップグレードを開始する前に知っておくべき重要事項である可能性があります。
4.1.1. あらゆるデータや設定情報をバックアップする
システムをアップグレードする前に、完全なバックアップを取っておくよう強くお勧めします。少なくとも、失いたくないデータや設定情報だけでもバックアップしておきましょう。アップグレードのツールや処理はきわめて信頼性の高いものですが、アップグレードの最中にハードウェア障害が起こると、システムに大きなダメージを与えることがありえます。
The main things you'll want to back up are the contents of /etc
,
/var/lib/dpkg
, /var/lib/apt/extended_states
and the output of:
$ dpkg --get-selections '*' # (the quotes are important)
If you use aptitude
to manage packages on your system, you will also
want to back up /var/lib/aptitude/pkgstates
.
The upgrade process itself does not modify anything in the /home
directory. However, some applications (e.g. parts of the Mozilla suite,
and the GNOME and KDE desktop environments) are known to overwrite
existing user settings with new defaults when a new version of the
application is first started by a user. As a precaution, you may want to
make a backup of the hidden files and directories ("dotfiles") in users'
home directories. This backup may help to restore or recreate the old
settings. You may also want to inform users about this.
あらゆるパッケージのインストール処理はスーパーユーザ特権で実行されなければならないため、root
としてログインするか su
や sudo
を使って、必要なアクセス権限を得てください。
アップグレードにあたって事前に整えなければならない条件がいくつかあります。実際にアップグレードを実行する前にそれらを確認してください。
4.1.2. 事前にユーザに通知する
アップグレードの前には、その予定をすべてのユーザに知らせるとよいでしょう。ただ、システムに ssh
接続などでアクセスしてきているユーザが、アップグレードの最中にそうと気付くことはほとんどないはずで、また、作業を続行できるはずです。
万一の対策をしたければ、アップグレードの前に /home
パーティションをバックアップするか、アンマウントしておきましょう。
trixie にアップグレードするときはおそらくカーネルをアップグレードしなければならないので、通常は再起動が必要です。通常、これはアップグレード完了後に実施します。
4.1.3. サービスのダウン期間の準備
システムが提供しているサービスで、アップグレードに含まれるパッケージが関連するサービスがあるかもしれません。この場合、注意して欲しいのですが、アップグレード作業中に関連パッケージが置換・設定される際、これらのサービスが停止します。この間、サービスは利用できなくなります。
これらのサービスに対する実際のダウン期間は、システム中でアップグレードされるパッケージ数に応じて違いますし、このダウン期間には (もしあれば) システム管理者が各パッケージのアップグレードに対する設定の質問への回答に費やす時間も含まれます。アップグレード作業が放置されたままでいて、システムがアップグレード中に入力を必要とした場合、非常に長期間サービスが利用ができなくなる可能性が非常に高いでしょう [1]
If the system being upgraded provides critical services for your users or the network [2], you can reduce the downtime if you do a minimal system upgrade, as described in Minimal system upgrade, followed by a kernel upgrade and reboot, and then upgrade the packages associated with your critical services. Upgrade these packages prior to doing the full upgrade described in Upgrading the system. This way you can ensure that these critical services are running and available through the full upgrade process, and their downtime is reduced.
4.1.4. 復旧の準備
Debian はシステムがブートできる状態を常に確保するように努めていますが、アップグレード後のシステム再起動で問題に遭遇する可能性は常にあります。既知の潜在的な問題点の多くは、このリリースノートの本章と次章で述べられています。
上述の理由により、システムが再起動に失敗したり、リモート管理されているシステムならネットワーク接続の確立に失敗した場合に備え、復旧できる手立てを整えておくことが大切です。
ssh
接続経由でリモートからアップグレードを行うのなら、リモートのシリアル端末からサーバにアクセスできるよう、必要な事前準備をしておくことをお勧めします。カーネルをアップグレードして再起動した後、ローカルコンソール経由でシステム設定を修正しなければならないことがあります。また、アップグレード中に誤ってシステムが再起動された場合にも、ローカルコンソールを使って復旧する必要に迫られることがあります。
For emergency recovery we generally recommend using the rescue mode of the trixie Debian Installer. The advantage of using the installer is that you can choose between its many methods to find one that best suits your situation. For more information, please consult the section "Recovering a Broken System" in chapter 8 of the Installation Guide (at https://www.debian.org/releases/trixie/installmanual) and the Debian Installer FAQ.
If that fails, you will need an alternative way to boot your system so
you can access and repair it. One option is to use a special rescue or
live install image. After booting
from that, you should be able to mount your root file system and
chroot
into it to investigate and fix the problem.
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 /
もう一つのアプローチは debug-shell.service
経由で systemd の "早い段階でのデバッグシェル" を有効にすることです。次の起動時にこのサービスは起動プロセスの初期段階で tty9 にて root のログインシェルを立ち上げます。カーネルの起動パラメーターで systemd.debug-shell=1
と指定して有効にするか、あるいは systemctl enable debug-shell
で設定を永続的にします (この場合、デバッグが完了した際には再度無効にできます)。
systemd 環境下で起動がおかしいのをデバッグする詳細な情報については、Freedesktop.org の Diagnosing Boot Problems という記事で参照できます。
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 Prepare for downtime on services.
リモートでのアップグレード時にさらなる安全マージンを得るため、screen
プログラムが提供する仮想コンソール内でアップグレード作業を行うことを提案します。このプログラムは安全な再接続を可能にし、リモート接続プロセスが一時的に切断された場合でもアップグレード作業が中断しないようにしてくれます。
micro-evtd パッケージにより提供される watchdog デーモンのユーザは、アップグレードの前にデーモンを止めて watchdog タイマーを無効化し、アップグレード作業の途中で誤ってリブートが起きないようにすべきです:
# service micro-evtd stop
# /usr/sbin/microapl -a system_set_watchdog off
4.2. "純粋"な Debian からの作業開始
この章で説明しているアップグレードのプロセスは、"純粋"な安定版の Debian システムを想定して書かれています。もし、APT の設定が bookworm 以外で追加のソースを指定している、あるいは他のリリースやサードパーティからパッケージをインストール している場合、確実にアップグレード作業を遂行するため、事態をややこしくするこれらの要因を取り除くことから始めると良いでしょう。
APT がどのソースからパッケージをダウンロードするべきかを判断するのに使っている主要設定ファイルは /etc/apt/sources.list
ですが、/etc/apt/sources.list.d/
ディレクトリ内のファイルを使用することもできます。詳細は sources.list(5) を参照してください。もしシステムで複数の source-list ファイルを使用しているのであれば、設定に一貫性があることを確認する必要があるでしょう。
4.2.1. Debian 12 (bookworm) からのアップグレード
12 (bookworm) からのアップグレードのみがサポートされています。Debian のバージョンを表示するには以下を実行します:
$ cat /etc/debian_version
Please follow the instructions in the Release Notes for Debian 12 at https://www.debian.org/releases/bookworm/releasenotes to upgrade to Debian 12 first if needed.
4.2.2. 最新のポイントリリースへのアップグレード
This procedure assumes your system has been updated to the latest point release of bookworm. If you have not done this or are unsure, follow the instructions in bookworm システムのアップグレード.
4.2.3. Debian Backports
Debian Backports allows users of Debian stable to run more up-to-date versions of packages (with some tradeoffs in testing and security support). The Debian Backports Team maintains a subset of packages from the next Debian release, adjusted and recompiled for usage on the current Debian stable release.
bookworm-backports から取得したパッケージは trixie にあるバージョンよりも小さいバージョン番号なので、ディストリビューションのアップグレードの作業中、"純粋な" bookworm パッケージと同じやり方で trixie へと問題なくアップグレードできるはずです。今の所は潜在的な問題は特定されてないものの backports 経由のアップグレードはテストが少なく、それに応じてよりリスクがあります。
注意
While regular Debian Backports are supported, there is no clean upgrade path from sloppy backports (which use APT source-list entries referencing bookworm-backports-sloppy).
As with Unofficial sources, users are advised to remove "bookworm-backports" entries from their APT source-list files before the upgrade. After it is completed, they may consider adding "trixie-backports" (see https://backports.debian.org/Instructions/).
For more information, consult the Backports Wiki page.
4.2.4. パッケージデータベースの準備
You should 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 "bookworm" and not to "stable" or "trixie"; see APT source-list ファイルのチェック.
4.2.5. 利用されなくなったパッケージ
It is a good idea to remove obsolete packages from your system before upgrading. They may introduce complications during the upgrade process, and can present security risks as they are no longer maintained.
4.2.6. Debian 由来でないパッケージを削除する
Debian 由来でないパッケージを見つけるには、以下の apt
または apt-forktracer
を使った 2 つの手法があります。どちらも 100% 正確ではない点を留意して下さい (例: apt の例では、古いカーネルパッケージのように一度は Debian によって提供されていたが今は提供されていないパッケージを表示します)。
$ apt list '?narrow(?installed, ?not(?origin(Debian)))'
$ apt-forktracer | sort
4.2.7. 残っている設定ファイルを取り除く
A previous upgrade may have left unused copies of configuration files; old versions of configuration files, versions supplied by the package maintainers, etc. Removing leftover files from previous upgrades can avoid confusion. Find such leftover files with:
# find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'
4.2.8. non-free コンポーネントと non-free-firmware コンポーネント
If you have non-free firmware installed it is recommended to add
non-free-firmware
to your APT sources-list. For details see
アーカイブエリア and non-free なファームウェアがアーカイブの独自コンポーネントへ移動しました.
4.2.9. proposed-updates セクション
APT source-list ファイルに proposed-updates
セクションを含めている場合は、システムのアップグレードを試みる前に、それらのセクションをファイルから削除してください。これは衝突の可能性を減らすための予防策です。
4.2.10. 非公式なソース
システムに Debian 以外のパッケージがインストールされている場合、依存関係の衝突のためアップグレード中に削除されるかもしれないことに注意してください。当該パッケージが APT source-list ファイルに Debian 以外のパッケージアーカイブを追加することでインストールされたのなら、そのアーカイブが trixie 用にコンパイルされたパッケージも提供しているかをチェックし、Debian パッケージ用のソース項目と同時にそれも適切に修正してください。
Some users may have unofficial backported "newer" versions of packages that are in Debian installed on their bookworm system. Such packages are most likely to cause problems during an upgrade as they may result in file conflicts [4]. Possible issues during upgrade has some information on how to deal with file conflicts if they should occur.
4.2.11. APT の pin 機能を無効にする
特定のパッケージを安定版以外のディストリビューション (テスト版など) からインストールするように APT を設定している場合、そのパッケージが新しい安定版リリース内のバージョンにアップグレードできるように、(/etc/apt/preferences
および /etc/apt/preferences.d/
内に保存されている) APT の pin 設定を変更しなければならないかもしれません。APT の pin 機能に関する、より詳しい情報は、apt_preferences(5) にあります。
4.2.12. gpgv がインストールされているのを確認する
APT は trixie のリリース署名に使われている鍵を照合するのに gpgv バージョン 2 以降を必要とします。gpgv1 でも技術的には依存関係を満たしますが、これは特定の状況下でのみ有用なため、ユーザーは正しいバージョンがインストールされているのを保証したくなることでしょう。以下のコマンドを実施ください:
# apt install gpgv
4.2.13. パッケージの状態をチェックする
アップグレードの方法に関係なく、まず全パッケージの状態を調べ、全パッケージがアップグレード可能な状態にあるのを確認することをお勧めします。次のコマンドは、インストールが未完了のパッケージ (Half-Installed) や設定に失敗したパッケージ (Failed-Config)、何らかのエラー状態にあるパッケージを表示します:
$ dpkg --audit
aptitude
や次のようなコマンドを使ってシステムの全パッケージの状態を検査することもできます。
$ dpkg -l | pager
または
# dpkg --get-selections '*' > ~/curr-pkgs.txt
別の方法としては apt
を使うこともできます。
# apt list --installed > ~/curr-pkgs.txt
アップグレード前に、あらゆる hold 状態を解除しておいたほうがよいでしょう。アップグレードに不可欠なパッケージが hold 状態にある場合、アップグレードに失敗します。
$ apt-mark showhold
パッケージをローカルで変更・再コンパイルしており、パッケージの名前を変えたりバージョン番号に epoch フィールドを追加していないなら、アップグレードしないよう hold 状態にしておかなければなりません。
apt
でパッケージを "hold" 状態に変更するには、以下のように実行してください。
# apt-mark hold package_name
Replace hold
with unhold
to unset the "hold" state.
If there is anything you need to fix, it is best to make sure your APT source-list files still refer to bookworm as explained in APT source-list ファイルのチェック.
4.3. APT source-list ファイルの準備
アップグレードを始める前に、APT の source-list ファイル (/etc/apt/sources.list
および /etc/apt/sources.list.d/
以下のファイル) に |RELEASENAME|
を追加し、|OLDRELEASENAME|
を削除する必要があります。
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.
A release can often be referred to both by its codename (e.g. "bookworm", "trixie") and by its status name (i.e. "oldstable", "stable", "testing", "unstable"). Referring to a release by its codename has the advantage that you will never be surprised by a new release and for this reason is the approach taken here. It does of course mean that you will have to watch out for release announcements yourself. If you use the status name instead, you will just see loads of updates for packages available as soon as a release has happened.
Debian は、Debian のリリースに関わる関連情報について最新の状態を保つために役立つ 2 つのアナウンス用メーリングリストを提供しています:
By subscribing to the Debian announcement mailing list, you will receive a notification every time Debian makes a new release. Such as when "trixie" changes from e.g. "testing" to "stable".
By subscribing to the Debian security announcement mailing list, you will receive a notification every time Debian publishes a security announcement.
4.3.1. APT のインターネットソースの追加
新規インストールではデフォルトはネットワークの条件によってあなたに近いサーバから自動的にパッケージをダウンロードできる Debian APT CDN サービスを使うように APT を設定します。これは比較的新しいサービスのため、古いインストールでは以前としてメインの Debian インターネットサーバのひとつまたはミラーのひとつを設定しているかもしれません。もしまだ設定を行っていない場合、APT 設定において CDN サービスを使うように切り替えることを推奨します。
CDN サービスを利用するには、あなたの APT ソース設定にこのような 1 行を追加してください (main
と contrib
を使用していると仮定します):
deb https://deb.debian.org/debian trixie main contrib
新しいソースを追加した後、"deb
" 行の先頭に、ハッシュ記号 (#
) を追加して無効にしてください。
しかしながら、もしあなたのネットワークの条件から近い特定のミラーを使用して良い結果が得たいならば、このオプションはまだ利用可能です。
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/trixie/main/... http://mirrors.kernel.org/debian/dists/trixie/contrib/...
与えられたミラーを使うよう APT 設定をするには、このような 1 行を追加してください (再度、main
と contrib
を使用していると仮定します):
deb http://mirrors.kernel.org/debian trixie main contrib
"dists
" を書かなくても、暗黙のうちに追加します。リリース名の後の各引数は、パスの末尾につけて、複数のディレクトリに展開するのに用います。
再度、あなたの新しいソースを追加した後、既存のアーカイブエントリを無効にしてください。
4.3.2. APT のローカルミラーソースの追加
HTTP パッケージミラーを使うのではなく、ローカルディスク (おそらくは NFS マウントされたもの) にあるミラーを使うよう、APT source-list ファイルを変更したいことがあるかもしれません。
例えばパッケージのミラーが /var/local/debian/
にあり、主なディレクトリの配置が次のようになっているとします。
/var/local/debian/dists/trixie/main/... /var/local/debian/dists/trixie/contrib/...
これを apt で使うには、次の行を sources.list
ファイルに追加します。
deb file:/var/local/debian trixie main contrib
"dists
" を書かなくても、暗黙のうちに追加します。リリース名の後の各引数は、パスの末尾につけて、複数のディレクトリに展開するのに用います。
新しいソースを追加した後、APT source-list ファイル内の既存のアーカイブエントリの先頭にハッシュ記号 (#
) を追加して無効にしてください。
4.3.3. APT の光学メディアソースの追加
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 # 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. パッケージのアップグレード
推奨する方法はパッケージ管理ツール apt
を使って前の Debian リリースからアップグレードすることです。
注釈
apt
は対話式な用途を目的としており、スクリプトの中で使うべきではありません。スクリプトの中では字句解析に適していて安定した出力をもつ apt-get
を使うべきです。
まず、必要なすべてのパーティション (特にルートパーティションと /usr
パーティション) を read-write モードでマウントするのを忘れずに行いましょう。それには以下のようなコマンドを使います。
# mount -o remount,rw /mountpoint
次に、(/etc/apt/sources.list
や /etc/apt/sources.list.d/
以下のファイル内の) APT ソースのエントリが "trixie" と "stable" のいずれか一方を指定していることを念入りにチェックしてください。bookworm を指し示すソースエントリが含まれてはいけません。
注釈
CD-ROM のソース行は "unstable" を指定していることがよくあります。これは混乱の元かもしれませんが、変更すべきでは*ありません*。
4.4.1. セッションの記録
ここで強くお勧めしたいのですが、/usr/bin/script
プログラムを使って、このアップグレードセッションの記録を取るようにしましょう。こうすれば、何らかの問題が生じたときに何が起こったかを記録しておくことができ、必要に応じてバグ報告に正確な情報を含めることができます。記録を開始するには次のように入力します。
# script -t 2>~/upgrade-trixie-step.time -a ~/upgrade-trixie-step.script
or similar. If you have to rerun the typescript (e.g. if you have to
reboot the system) use different step values to indicate which step of
the upgrade you are logging. Do not put the typescript file in a
temporary directory such as /tmp
or /var/tmp
(files in those
directories may be deleted during the upgrade or during any restart).
The typescript will also allow you to review information that has
scrolled off-screen. If you are at the system's console, just switch to
VT2 (using Alt+F2
) and, after logging in, use
# less -R ~root/upgrade-trixie.script
to view the file.
アップグレード完了後に script
を停止するには、プロンプトから exit
と入力してください。
apt
は /var/log/apt/history.log
に変更されたパッケージの状態を、/var/log/apt/term.log
に端末の出力を記録します。
script
に -t スイッチをつけておいた場合は、以下のように scriptreplay
プログラムでセッション全体をリプレイできます。
# scriptreplay ~/upgrade-trixie-step.time ~/upgrade-trixie-step.script
4.4.2. パッケージリストの更新
まず、新しいリリースで利用可能なパッケージの一覧を取得する必要があります。そのためには以下のコマンドを実行してください。
# apt update
注釈
apt-secure のユーザは aptitude
や apt-get
を使うと問題を見つけることができるかもしれません。apt-get の場合、apt-get update --allow-releaseinfo-change
を使うことができます。
4.4.3. アップグレードするのに十分な領域があることを確認する
You have to make sure before upgrading your system that you will have
sufficient hard disk space when you start the full system upgrade
described in Upgrading the system. First, any
package needed for installation that is fetched from the network is
stored in /var/cache/apt/archives
(and the partial/
subdirectory, during download), so you must make sure you have enough
space on the file system partition that holds /var/
to temporarily
download the packages that will be installed in your system. After the
download, you will probably need more space in other file system
partitions in order to both install upgraded packages (which might
contain bigger binaries or more data) and new packages that will be
pulled in for the upgrade. If your system does not have sufficient space
you might end up with an incomplete upgrade that is difficult to recover
from.
apt
で、インストールに必要なディスク領域の詳細な情報が表示できます。アップグレードを実行する前に、次のように実行して必要な領域の推定値を見ることができます。
# 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.
注釈
Running this command at the beginning of the upgrade process may give an error, for the reasons described in the next sections. In that case you will need to wait until you've done the minimal system upgrade as in Minimal system upgrade before running this command to estimate the disk space.
アップグレードをするのに十分な領域がない場合は、apt
が以下のような警告メッセージを出します。
E: You don't have enough free space in /var/cache/apt/archives/.
この場合、事前に領域を解放するのを忘れないようにしてください。以下のことを実行するとよいでしょう。
インストールのために、以前 (
/var/cache/apt/archives
に) ダウンロードしたパッケージを削除する。apt clean
を実行してパッケージキャッシュを一掃すると、以前ダウンロードしたパッケージファイルをすべて削除できます。忘れ去られたパッケージを削除する。さらに、bookworm で手作業でパッケージをインストールするのに
aptitude
やapt
を使っていたのなら、手作業でインストールされたパッケージの記録が取られています。依存関係のみによって引きずられてインストールされたパッケージに対して、依存元パッケージが削除されたためにもう不要となった場合に、余分だというマークをつけることができるでしょう。手作業でインストールしたパッケージには削除されるマークをつけません。自動的にインストールされたがもはや使われていないパッケージを削除するには、以下を実行してください:# apt autoremove
余分なパッケージを見つけるのに、
deborphan
やdebfoster
、cruft
も使えます。これらのツールが表示したパッケージをやみくもに削除しないでください。特に、誤検出しやすい非デフォルトの凶暴なオプションを使っている場合はなおさらです。実際に削除する前に、削除を提案されたパッケージ (の内容やサイズ、説明など) を手作業で調べなおすことを強くお勧めします。Remove packages that take up too much space and are not currently needed (you can always reinstall them after the upgrade). If you have popularity-contest installed, you can use
popcon-largest-unused
to list the packages you do not use that occupy the most space. You can find the packages that just take up the most disk space withdpigs
(available in the debian-goodies package) or withwajig
(runningwajig size
). They can also be found with aptitude. Startaptitude
in full-terminal mode, selectViews > New Flat Package List
, pressl
and enter~i
, then pressS
and enter~installsize
. This will give you a handy list to work with.翻訳や地域化用ファイルが不要なら、それらをシステムから削除する。localepurge パッケージをインストールして設定すれば、選んだ少数のロケールのみがシステムに残るようにすることが可能です。これによって、
/usr/share/locale
の消費するディスク領域を減らせるでしょう。/var/log/
の下にあるシステムログを、一時的に他のシステムに移動するか、永久に削除する。仮設の
/var/cache/apt/archives
を使用する。すなわち、別のファイルシステム (USB ストレージデバイス、一時的なハードディスク、既に使用されているファイルシステムなど) を仮設のキャッシュディレクトリとして拝借することができます。注釈
アップグレード中にネットワーク接続が途切れる可能性があるので、NFS マウントは使用しないでください。
以下は、
/media/usbkey
にマウントされた USB ドライブがある場合を例とします。今までに、インストールのためにダウンロードされたパッケージを削除します。
# apt clean
ディレクトリ
/var/cache/apt/archives
を、USB ドライブにコピーします。# cp -ax /var/cache/apt/archives /media/usbkey/
現在のキャッシュディレクトリに、仮のキャッシュディレクトリをマウントします。
# mount --bind /media/usbkey/archives /var/cache/apt/archives
アップグレード後に、元々の
/var/cache/apt/archives
ディレクトリを復活させます。# umount /var/cache/apt/archives
残っている
/media/usbkey/archives
を削除します。
仮設のキャッシュディレクトリは、システムにマウントされているファイルシステムであれば何にでも作成できます。
Do a minimal upgrade of the system (see Minimal system upgrade) or partial upgrades of the system followed by a full upgrade. This will make it possible to upgrade the system partially, and allow you to clean the package cache before the full upgrade.
パッケージを安全に削除するための注意として、APT source-list ファイルのチェック で説明するように、APT source-list ファイルが bookworm を指し示すよう設定を戻しておくことが望ましいです。
4.4.4. 監視システムの停止
apt
があなたのコンピューターで動作しているサービスを一時的に停止する必要があるかもしれないため、アップグレードの最中に終了された他のサービスを再起動できるような監視用サービスを予め停止しておくのが良い考えでしょう。Debian では、monit がそのようなサービスの例です。
4.4.5. システムの最小アップグレード
In some cases, doing the full upgrade (as described below) directly might remove large numbers of packages that you will want to keep. We therefore recommend a two-part upgrade process: first a minimal upgrade to overcome these conflicts, then a full upgrade as described in Upgrading the system.
これをまず行うには、以下のコマンドを実行してください。
# apt upgrade --without-new-pkgs
このコマンドには、アップグレードしても他のパッケージをインストール・削除する必要がないパッケージだけをアップグレードする、という効果があります。
システムの容量が少なく、容量による制約のため完全アップグレードが実行できない場合にも、システムの最小アップグレードは有用です。
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.6. システムのアップグレード
これまでの手順を実行し終わったら、アップグレードの主要な部分を続ける準備ができています。以下のコマンドを実行してください。
# 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. アップグレード中の注意点
以下の章では、trixie へのアップグレードの最中に現れるかもしれない既知の問題を記述しています
4.5.1. 「即時設定は動作しません」で full-upgrade が失敗する
apt full-upgrade
の途中でパッケージをダウンロードした後に失敗となり、
E: Could not perform immediate configuration on 'package'. Please see man 5 apt.conf under APT::Immediate-Configure for details.
と表示することがあります。これが起きた場合は、代わりに apt full-upgrade -o APT::Immediate-Configure=0
を実行することでアップグレードを進められるはずです。
この問題の暫定的な別の対処の可能性として、bookworm と trixie の両方のソースを一時的に sources.list
に追加して apt update
を実行する方法があります。
4.5.2. 予期されるパッケージの削除
The upgrade process to trixie might ask for the removal of packages on the system. The precise list of packages will vary depending on the set of packages that you have installed. These release notes give general advice on these removals, but if in doubt, it is recommended that you examine the package removals proposed by each method before proceeding. For more information about packages obsoleted in trixie, see Obsolete packages.
4.5.3. 衝突 (Conflicts) あるいは事前依存 (Pre-Depends) のループ
場合によっては衝突や事前依存のループのために、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/package_name.deb
4.5.4. ファイルの衝突
"純粋" な bookworm システムからのアップグレードでは、ファイルの衝突は起こらないはずですが、非公式のバックポートパッケージをインストールしているなら起こるかもしれません。ファイルの競合が起こると、次のようなエラーになります:
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>
You can try to solve a file conflict by forcibly removing the package mentioned on the last line of the error message:
# dpkg -r --force-depends package_name
問題が修正できたら、先程説明した apt
コマンドを再度入力すれば、アップグレードを再開できます。
4.5.5. 設定の変更
アップグレードの最中に、いくつかのパッケージの設定・再設定に関する質問が表示されます。/etc/init.d
ディレクトリと /etc/manpath.config
ファイルに関しては、パッケージメンテナのバージョンに置き換えるようにしてください。システムの整合性を保つためには "yes" と答えることが必要になります。古いバージョンも .dpkg-old
という拡張子をつけられて保存されていますので、戻すのはいつでもできます。
どうすればよいかわからなくなったら、そのパッケージやファイルの名前を書き留めておいて、その問題解決は後回しにしましょう。typescript ファイルを検索すれば、アップグレードの最中に画面に表示された情報をもう一度見ることもできます。
4.5.6. コンソール接続へセッションの変更
システムのローカルコンソールを使ってアップグレードを実行している場合、アップグレードの最中に何回かコンソールが別の画面へ移動してしまい、アップグレード作業が見えなくなることに気づくかもしれません。例えば、グラフィカルインターフェイスがあるシステムではディスプレイマネージャが再起動した際に起こります。
To recover the console where the upgrade was running you will have to
use Ctrl+Alt+F1
(if in the graphical startup screen) or Alt+F1
(if in
the local text-mode console) to switch back to the virtual terminal 1.
Replace F1
with the function key with the same number as the virtual
terminal the upgrade was running in. You can also use Alt+Left Arrow
or
Alt+Right Arrow
to switch between the different text-mode terminals.
4.7. 次のリリースへの準備
アップグレードの後で、次のリリースに向けてできるいくつかの準備があります。
Remove newly redundant or obsolete packages as described in Make sure you have sufficient space for the upgrade and Obsolete packages. You should review which configuration files they use and consider purging the packages to remove their configuration files. See also Purging removed packages.
4.7.1. 削除したパッケージを完全削除する
一般的に、削除したパッケージを完全に削除 (purge) するのは賢明なことです。以前のリリースアップグレード (つまりは bookworm へのアップグレード) の際に削除されているパッケージである、あるいはパッケージがサードパーティベンダーから提供されたものである場合、尚のこととなります。特に、古い init.d スクリプトは問題を起こすことが知られています。
注意
パッケージの完全削除 (purge) は通常ログファイルについても完全に削除を行うので、まずはこのバックアップを行ったほうが良いでしょう。
以下のコマンドは、設定ファイルをシステムに残して削除されたパッケージの一覧を (もしあれば) 表示します:
$ apt list '~c'
apt purge
を実行すればパッケージを削除できます。一度でこれらのパッケージを削除したい場合は、以下のコマンドで実施できます:
# apt purge '~c'
4.8. 利用されなくなったパッケージ
trixie では大量の新規パッケージが導入された一方で、bookworm に存在していた非常の少量の古いパッケージの破棄や削除が行われています。これら時代遅れのパッケージをアップグレードする手段は提供されていません。時代遅れのパッケージを使い続けても構いませんが、Debian プロジェクトでは通常、trixie がリリースされてから 1 年後にセキュリティサポートを終了します [5]。そして、その時点から他のサポートも提供しません。利用可能な代替手段で置き換えられるのであれば、そうすることをお勧めします。
There are many reasons why packages might have been removed from the distribution: they are no longer maintained upstream; there is no longer a Debian Developer interested in maintaining the packages; the functionality they provide has been superseded by different software (or a new version); or they are no longer considered suitable for trixie due to bugs in them. In the latter case, packages might still be present in the "unstable" distribution.
"Obsolete and Locally Created Packages" can be listed and purged from the commandline with:
$ apt list '~o'
# apt purge '~o'
Debian バグ追跡システム は、パッケージが削除された理由についての追加情報を提供してくれることがよくあります。そのパッケージ自体と ftp.debian.org 擬似パッケージ の両方の、アーカイブ化されたバグ報告を調べてください。
trixie での廃止パッケージ一覧については、特記すべき廃止されたパッケージたち を参照して下さい。
4.8.1. 移行用ダミーパッケージ
bookworm からのいくつかのパッケージは trixie においてアップグレードを簡単にできるよう設計された空の代用品である移行用ダミーパッケージによって置き換えられるかもしれません。以前は 1 つのパッケージであったアプリケーションがいくつかのパッケージに分割された場合、移行用パッケージは古いパッケージと同じ名前で、新しいパッケージをインストールするための適切な依存関係をもって提供されるかもしれません。これをインストールした後は冗長なダミーパッケージを安全に削除できます。
(すべてではないのですが) 大半のダミーパッケージの説明には、その目的が記されています。しかしダミーパッケージの説明文は統一されておらず、パッケージ一式をインストールするためや、最新のバージョンを追跡するために"ダミー"パッケージがインストールされたままとなるように設計されているものもあります。自分のシステム内のダミーパッケージを検出するには、deborphan
を --guess-*
オプションつきで使うのが便利でしょう (例: --guess-dummy
)。一部のダミーパッケージは、アップグレード後に削除されることを意図したものではなく、プログラムのどのバージョンが現在利用可能な最新版かを長期にわたって追跡するのに使われる、ということに注意してください。