Ubuntu 26.04.1 更新の実録｜Docker 20コンテナを止めずに2分で完了

はじめに

自宅サーバー（Ubuntu 26.04 LTS・Docker コンテナ20本が常時稼働）を 26.04.1 に上げました。26.04 LTS にとって最初のポイントリリースです。結果は次のとおりです。

「2分で終わった」という結果そのものより、その2分の中で何が起きていたかのほうが読み物として面白い作業でした。ポイントリリースの実体はパッケージ1個の changelog に全部書いてあり、コンテナが1本も止まらなかった理由は、事前に予想していたものとは違いました。

この記事では次の順で書きます。

• なぜ初回のポイントリリースだけ意味が違うのか（.2 以降との差）
• 26.04.1 の正体は何なのか（apt-get changelog base-files の5行が答え）
• do-release-upgrade を使わず apt full-upgrade を選ぶまでの判断
• コンテナ20本が生き残った本当の理由（live-restore ではなかった）
• 事後検証14項目の結果と、24.04 から移行を待っている人への位置づけ

🚩 なぜ「初回のポイントリリース」だけ意味が違うのか

ポイントリリースは .1 .2 .3 と続いていきますが、初回だけは扱いが違います。26.04.1 は Ubuntu 26.04 LTS にとって最初のポイントリリースで、ここを境に「この LTS に乗り換えていいのか」の答えが変わるからです。

公式のアップグレード案内は、初回ポイントリリースで開く

Ubuntu の更新マネージャーは、既定で /etc/update-manager/release-upgrades の Prompt=lts に従います。この設定では、新しい LTS への乗り換えが案内されるのは最初のポイントリリースが出てからです。26.04 のリリース当日に 24.04 から上げようとすると do-release-upgrade -d（development フラグ）が必要だったのは、この制限を手で外していたからでした。

今回の 26.04.1 は、その制限が外れる回にあたります。ただし Canonical は 26.04.1 のアナウンスで、24.04 ユーザーへの自動案内を始めるのはリリースから数週間後だと告知しました。26.04 で進んだ基本コマンドの Rust 化にともなう rust-coreutils のリグレッション対応バックポートを、案内より先に入れるためです。

日付は数週間ずれるとはいえ、24.04 勢に移行の号砲を鳴らすのは 26.04.1 だという関係は変わりません。

「LTS は .1 まで待つ」は、根拠のある慣行

企業や保守的な現場ほど「新しい LTS は最初のポイントリリースが出てから入れる」という運用をとります。これは公式に定められたルールではなく現場の慣行ですが、理由としてよく挙がるのは次の3点です。

• リリース直後の数か月で出た SRU とセキュリティ更新が最初から入っている（入れた直後に当てる更新の山が小さくなる）
• そもそも公式のアップグレード案内が、それより前には出ない
• クラウドの公式イメージや商用ソフトの動作確認が、この前後を目安に揃っていく

3つ目は組織や製品によって事情が違うので目安どまりですが、2つ目は Canonical 側の仕組みそのものです。この慣行は経験則だけでなく、案内が出ないという実装にも支えられているわけです。

.2 以降との違い

すでに 26.04 を動かしている環境から見れば、26.04.1 も 26.04.2 も作業内容は同じです。今回当てたのは21パッケージ、バージョン表記を書き換えたのは base-files 1個だけでした。その1個の書き換えが、エコシステムの側では「新しい LTS を勧めてよい」という判断の切り替え信号として働きます。実体の地味さと意味の大きさが、これだけ離れている更新もそうありません。

🔍 26.04.1 の正体は base-files 1パッケージ

changelog が語る「bump version to 26.04.1」

更新前に apt-cache policy を叩くと、base-files に新しい候補が来ていました。

$ apt-cache policy base-files
base-files:
  インストールされているバージョン: 14ubuntu6.1
  候補:               14ubuntu6.2
  バージョンテーブル:
     14ubuntu6.2 500
        500 http://archive.ubuntu.com/ubuntu resolute-updates/main amd64 Packages
 *** 14ubuntu6.1 100
        100 /var/lib/dpkg/status
     14ubuntu6 500
        500 http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages

そして、その changelog がこれです。

$ apt-get changelog base-files

base-files (14ubuntu6.2) resolute; urgency=medium

  * /etc/issue{,.net}, /etc/{lsb,os}-release: bump version to 26.04.1
    (LP: #2164885)

 -- Oliver Reiche <oliver.reiche@canonical.com>  Mon, 24 Aug 2026 12:33:48 +0200

1行です。「/etc/issue と /etc/issue.net と /etc/lsb-release と /etc/os-release のバージョン表記を 26.04.1 に上げる」。それが base-files 14ubuntu6.2 のやることのすべてでした。

ここから分かることは、意外と大きい話です。26.04.1 という「別の何か」は存在しません。 インストールメディアとしての 26.04.1 は確かに配布されていますが、すでに 26.04 が動いているマシンにとっての「26.04.1 にする」は、その時点の更新を全部当てて base-files を最新にすることと同義です。バージョン表記の書き換えは、その結果に付いてくるラベルにすぎません。

履歴を遡ると、Canonical のうっかりも残っている

同じ changelog をもう少し下まで読むと、このリリースの歩みがそのまま並んでいます。

base-files (14ubuntu6.1) resolute; urgency=medium

  * /etc/os-release: Fix missing LTS in VERSION (LP: #2150561)

 -- Oliver Reiche <oliver.reiche@canonical.com>  Fri, 24 Apr 2026 11:24:55 +0100

base-files (14ubuntu6) resolute; urgency=medium

  *  /etc/issue{,.net}, /etc/{lsb,os}-release: Prepare for 26.04 release

 -- Oliver Reiche <oliver.reiche@canonical.com>  Mon, 20 Apr 2026 09:46:31 +0100

base-files (14ubuntu4) resolute; urgency=medium

  - /etc/issue{,.net}, /etc/{lsb,os}-release: Welcome to Resolute Raccoon!

下から読むと、14ubuntu4 の “Welcome to Resolute Raccoon!” が開発サイクルの開始、14ubuntu6 の “Prepare for 26.04 release” がリリース準備、そして 14ubuntu6.2 が今回のポイントリリースです。

その途中に挟まっている 14ubuntu6.1 が “Fix missing LTS in VERSION”。日付は4月24日、つまり 26.04 のリリース翌日です。リリース版の /etc/os-release の VERSION から “LTS” の文字が抜けていた、という修正が残っています。数億台規模で使われる OS でも、リリース直後にこういう修正が入る。それが記録として消されずに残っているのが changelog の良いところです。

書き換わるのは3ファイルだけ

changelog が予告したとおりのことが、実行ログにそのまま現れました。

base-files (14ubuntu6.2) を設定しています ...
新バージョンの設定ファイル /etc/issue をインストールしています ...
新バージョンの設定ファイル /etc/issue.net をインストールしています ...
新バージョンの設定ファイル /etc/lsb-release をインストールしています ...

「bump version to 26.04.1」の実行形がこの3行です。/etc/os-release は /usr/lib/os-release へのシンボリックリンクなのでこのログには現れませんが、同じ base-files が更新しています。

ここで注目したいのは、設定ファイルの差分プロンプト（(Y/I/N/O/D/Z)）が1度も出なかったことです。dpkg がプロンプトを出すのは配布物と手元の両方に変更があるときで、この3ファイルは手で編集していなかったため、黙って新版に置き換わりました。/etc/issue にログインバナーを書き足していたら、ここで止まっていたことになります。

VERSION_ID は 26.04 のまま — 判定スクリプトは壊れない

更新後の /etc/os-release と /etc/lsb-release はこうなりました。

$ grep -E '^(VERSION|VERSION_ID|PRETTY_NAME)=' /etc/os-release
PRETTY_NAME="Ubuntu 26.04.1 LTS"
VERSION_ID="26.04"
VERSION="26.04.1 LTS (Resolute Raccoon)"

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=26.04
DISTRIB_CODENAME=resolute
DISTRIB_DESCRIPTION="Ubuntu 26.04.1 LTS"

26.04.1 が現れるのは PRETTY_NAME / VERSION / DISTRIB_DESCRIPTION の3つだけで、VERSION_ID も DISTRIB_RELEASE も 26.04 のままです。

実務ではここが効きます。CI やインストーラで . /etc/os-release; [ "$VERSION_ID" = "26.04" ] のような判定を書いている場合、ポイントリリースで壊れません。バージョン番号としては 26.04 のまま、表示名だけが 26.04.1 になる、という設計です。逆に言うと、PRETTY_NAME を文字列比較して判定していると壊れます。

🧭 打つコマンドを決めるまでの4つの判断

やること自体は apt full-upgrade の一行ですが、そこに至るまでに決めたことが4つあります。

1. do-release-upgrade は使わない

26.04 から 26.04.1 で do-release-upgrade を使うのは間違いです。あれは 26.04 から 26.10 のようなリリース間アップグレードのためのツールで、実行するとまったく別のことが始まります。

判断の根拠は前節の VERSION_ID です。リリース ID が変わらない以上、リリース間アップグレードではありません。 実際、更新後も VERSION_ID="26.04" のままでした。

2. upgrade ではなく full-upgrade

ドライラン（apt-get -s full-upgrade）の結果がこうでした。

アップグレード: 19 個、新規インストール: 2 個、削除: 0 個、保留: 5 個。

新規インストールが2個あるのがポイントです。gst-audio-thumbnailer と gst-video-thumbnailer で、nautilus 50系の推奨パッケージが ubuntu-desktop-minimal の依存関係経由で引かれてきたものです。

apt upgrade は新規インストールを伴う更新を保留します。つまりこの状況で apt upgrade を打つと、依存の連鎖に巻き込まれて base-files まで保留され、26.04.1 にならない可能性がありました。だから full-upgrade を選んでいます。

full-upgrade は「必要ならパッケージを削除してでも依存を解決する」ため危険視されがちですが、危険なのは削除が発生するときです。ドライランで 削除: 0 個 を確認済みなら、その懸念は消えます。

3. phased updates — 24個 upgradable なのに19個しか上がらない

apt update は「アップグレードできるパッケージが24個あります」と言うのに、full-upgrade は19個しか上げない。この差は引き算で説明できます。

24 - 5 = 19。保留の5個は phased updates（段階的配信）の待ちです。

26.04 の apt は、この保留を名前まで挙げて教えてくれます。

Not upgrading yet due to phasing:
  libnautilus-extension4  nautilus  nautilus-data  python3-software-properties  software-properties-common

対応は何もしないが正解です。apt install nautilus で個別にねじ込むこともできますが、展開率が上がれば自然に入ります。実際、前回の更新作業でも保留されていたパッケージが数時間後に適用済みになった例がありました。焦って手で入れると、以後その環境だけが通常の配信経路と食い違った状態になります。

4. reboot-required を見てから決める

更新対象のリストに linux-image-* も libc6 も systemd も含まれていませんでした。この時点で「/var/run/reboot-required は作られないはず」という見込みが立ちます。

そのうえで、判断としてはこう決めました。「バージョンが上がったから念のため再起動」はしない。 reboot-required が立っていたら再起動、立っていなければそこで終了。

無用な再起動が生むのは、ダウンタイムと監視アラートの誤発報だけです。ここを条件付きにしたことが、結果として「ダウンタイム0秒」に直結しました。

🤖 AI が段取りを作り、人間が sudo を押す

この作業は、少し変わった分担で回しました。

このサーバーは sudo にパスワードが必須で、非対話実行ができない設定です。AI エージェント側は鍵認証で SSH に入れますが、sudo が要る操作は一切実行できません。そこで役割をこう切っています。

AI に root を渡さないまま、調査と検証だけを任せる形です。おもしろいのは、sudo を外しても事前確認でやれることがほとんど減らないことでした。apt-get -s full-upgrade も apt-get changelog も apt list --upgradable も、すべて一般ユーザーで通ります。「何が起きるかを調べる」作業に root はほぼ要らないわけです。

そして結果として、事前ドライランの予測（19 / 2 / 0 / 5）は実行結果と1個の差もなく一致しました。

手順書の形式についても学びがありました。当初は PowerShell から ssh host "sudo ..." の1行形式で渡していましたが、これは事故ります。ローカルのシェルとリモートの bash で引用符が2回解釈されるため、awk の中でシングルクォートとダブルクォートと $ が混ざった瞬間に破綻します。対策は「引用しない」こと。スクリプトをファイルに書いて ssh host 'bash -s' < script.sh と標準入力で渡せば、リモート側の bash が1回だけ解釈します。手順書も同じ理由で、「SSH でログインしてからブロックを貼る」形式に統一しました。

⏱️ 2分3秒の実録

更新前の記録

$ echo "=== BEFORE $(date '+%F %T') ==="
=== BEFORE 2026-08-29 12:19:50 ===
Description:    Ubuntu 26.04 LTS
PRETTY_NAME="Ubuntu 26.04 LTS"
VERSION_ID="26.04"
VERSION="26.04 LTS (Resolute Raccoon)"
7.0.0-30-generic
base-files 14ubuntu6.1
containers running/all: 20/20
/dev/sda2       233G   48G  173G  22% /
reboot-required: NO

実行

sudo apt update から続けて sudo apt full-upgrade。サマリはこうです。

Installing dependencies:
  gst-audio-thumbnailer  gst-video-thumbnailer

Not upgrading yet due to phasing:
  libnautilus-extension4  nautilus  nautilus-data  python3-software-properties  software-properties-common

Summary:
  Upgrading: 19, Installing: 2, Removing: 0, Not Upgrading: 5
  Download size: 75.8 MB
  Space needed: 2,182 kB / 186 GB available

Continue? [Y/n] y

75.8 MB を 5秒 で取得しました (16.4 MB/s)

この Space needed: 2,182 kB が地味に効く数字です。76MB ダウンロードして、ディスク使用量の増加は 2.1MB。更新はディスクを食うという印象がありますが、既存ファイルの置き換えが大半なので、増えるのは差分だけです。

展開・設定・トリガ処理までエラー0件・確認プロンプトは Continue? [Y/n] の1回だけで完走しました。途中で紫の全画面ダイアログが出ないのは、このサーバーに needrestart が入っていないためです。

更新後の確認

$ echo "=== AFTER $(date '+%F %T') ==="
=== AFTER 2026-08-29 12:21:53 ===
Description:    Ubuntu 26.04.1 LTS
PRETTY_NAME="Ubuntu 26.04.1 LTS"
VERSION_ID="26.04"
VERSION="26.04.1 LTS (Resolute Raccoon)"
Ubuntu 26.04.1 LTS \n \l

7.0.0-30-generic
base-files 14ubuntu6.2
containerd containerd v2.3.4 db8809540e1a7a9da5d518876894933ff55692ab
containers running/all: 20/20
--- reboot check ---
reboot-required: NO

並べるとこうなります。

2分3秒。 reboot-required は立たなかったので、判定は「再起動不要」でそのまま作業終了です。

ドライランと実行結果の突き合わせ

1個の差もありません。 ダウンロード量だけ数字が違って見えますが、これは単位の違いです。URI から合計した実バイト数は 75849738 bytes。1024 で割れば 72.3 MiB、1000 で割れば 75.8 MB で、同じ値を apt が SI 単位で表示しているだけでした。

カーネルは据え置きなのに initramfs が作り直される

実行ログの終盤に、少し面食らう行が並びます。

keyboard-configuration (1.237ubuntu3.1) を設定しています ...
update-initramfs: deferring update (trigger activated)
...
console-setup (1.237ubuntu3.1) を設定しています ...
update-initramfs: deferring update (trigger activated)
...
initramfs-tools (0.151ubuntu1) のトリガを処理しています ...
update-initramfs: Generating /boot/initrd.img-7.0.0-30-generic

カーネルは1ミリも変わっていないのに /boot の initramfs が作り直されています。理由は console-setup と keyboard-configuration で、この2つはコンソールのフォントとキーマップを initramfs に埋め込むため、更新すると再生成を要求します。

deferring update (trigger activated) は dpkg のトリガ機構で、要求をいったん保留し、最後に1回だけまとめて実行するという意味です。2パッケージが別々に要求しても、initramfs の生成は1回で済みます。

そして重要なのは、これは reboot-required を立てないということ。同時に出るこの行も同様です。

Your console font configuration will be updated the next time your system boots.

「次回起動時に反映される」とは書いてありますが、これは再起動を要求しているのではなく、再起動したときに反映されると言っているだけです。SSH と GUI で使っているサーバーでは実害がありません。

🐳 コンテナ20本が生き残った本当の理由

事前の予想は live-restore の効果検証

更新対象に containerd.io 2.3.3 → 2.3.4 が入っていました。前回（1週間前）の Docker まわりの更新では16コンテナが一斉に落ちて再起動しています。その反省で、/etc/docker/daemon.json にこれを入れてありました。

{
  "live-restore": true
}

live-restore は dockerd を再起動してもコンテナを動かしたままにする設定です。今回はその効果を初めて実地で確かめる回になるはずでした。

結果はコンテナ無停止。ただし live-restore は出番なし

コンテナは20本すべて生き残りました。docker ps の Up 日数もリセットされていません。

（更新前 12:19:50）containers running/all: 20/20   cadvisor Up 6 days ... redis Up 6 days
（更新後 12:21:53）containers running/all: 20/20   cadvisor Up 6 days ... redis Up 6 days

ところが、systemd に「いつ起動したか」を聞くと、事前の予想が外れていたことが分かります。

$ systemctl show containerd -p ActiveEnterTimestamp --value
Sat 2026-08-29 12:21:31 JST      # containerd は更新中に再起動されている

$ systemctl show docker -p ActiveEnterTimestamp --value
Sat 2026-08-22 23:37:26 JST      # dockerd は1週間前から動きっぱなし

今回更新されたのは containerd.io だけで、docker-ce は対象外でした。Docker Server のバージョンが 29.7.2 のまま変わっていないのがその証拠です。dockerd はそもそも一度も再起動されていないので、「dockerd 再起動時にコンテナを生かす」設定である live-restore は、今回まったく出番がありませんでした。

生き残ったのは、shim が別プロセスだから

では何がコンテナを生かしたのか。答えは systemd のログにそのまま書いてありました。

12:21:31 systemd[1]: Stopping containerd.service - containerd container runtime...
12:21:31 dockerd[66771]: level=error msg="Failed to get event" error="rpc error: code = Unavailable desc = error reading from server: EOF" module=libcontainerd
12:21:31 dockerd[66771]: level=info  msg="Waiting for containerd to be ready to restart event processing" module=libcontainerd
12:21:31 systemd[1]: containerd.service: Deactivated successfully.
12:21:31 systemd[1]: containerd.service: Unit process 2165 (containerd-shim) remains running after unit stopped.
12:21:31 systemd[1]: containerd.service: Unit process 2213 (containerd-shim) remains running after unit stopped.
12:21:31 systemd[1]: containerd.service: Unit process 2425 (containerd-shim) remains running after unit stopped.
                     ... (20本ぶん続く) ...
12:21:31 systemd[1]: containerd.service: Found left-over process 2165 (containerd-shim) in control group while starting unit. Ignoring.
12:21:31 systemd[1]: containerd.service: This usually indicates unclean termination of a previous run, or service implementation deficiencies.

1行ずつ読むと、こうなります。

containerd-shim は、コンテナ1本につき1個ずつ起動する独立したプロセスです。実際、shim の起動時刻は前回の再起動のときのまま止まっていました。

$ ps -eo pid,lstart,comm | grep containerd-shim | head -3
   2165 土  8月 22 20:32:32 2026 containerd-shim
   2213 土  8月 22 20:32:32 2026 containerd-shim
   2425 土  8月 22 20:32:32 2026 containerd-shim
(shim count: 20)

3層のどこが再起動されるかで、影響範囲が変わる

つまり Docker の実行環境は、上から3つの層に分かれています。

コンテナのプロセスの直接の親は shim であって、containerd でも dockerd でもありません。だから containerd が止まってもコンテナは止まらない。containerd が起き直すと、残っていた shim を見つけて管理下に戻します。

この構造が分かると、更新のたびに影響範囲を先に読めるようになります。

前回16コンテナが落ちたのは、docker-ce と containerd.io が両方更新されて dockerd が再起動し、そのとき live-restore を入れていなかったためでした。live-restore の真価が問われるのは、次に docker-ce が更新される回ということになります。

✅ 事後検証 — 14項目・NG 0件

更新後、すべて読み取り専用（sudo なし）で検証しました。

NG 0件 / WARN 0件。

この中でいちばん効いた指標が uptime でした。

$ uptime
 12:25:42 up 6 days, 15:53,  4 users,  load average: 0.69, 0.50, 0.32

更新前（11:03 時点）が up 6 days, 14:30 で、更新後も同じ6日目が続いている。再起動していないことの、これ以上ない証拠です。

監視アラートについては、事前に「一時的に無効化するか」を検討して無効化しないと決めていました。再起動を伴う作業なら1〜2分の誤発報が出ますが、それは自動的に解消されます。それより無効化したまま戻し忘れて監視が死ぬほうが危険だからです。結果として再起動しなかったので、誤発報そのものが発生しませんでした。

とくに「5分以上データが途絶したら発報する」ルールが inactive のままだったことが、センサーデータの流入が1分も止まらなかったことを裏から証明しています。

🧹 autoremove 候補を消す前に、3つ調べる

apt update のとき、本題とは別にこんな通知が出ていました。

以下のパッケージが自動でインストールされましたが、もう必要とされていません:
  libslirp0  slirp4netns
これを削除するには 'sudo apt autoremove' を利用してください。

これを反射的に sudo apt autoremove してはいけません。調べたのは次の3点です。

① 本当に誰も必要としていないか

$ apt-cache rdepends --installed --no-recommends --no-suggests libslirp0
libslirp0
Reverse Depends:
  slirp4netns          # libslirp0 を必要とするのは slirp4netns だけ

$ apt-cache rdepends --installed --no-recommends --no-suggests slirp4netns
slirp4netns
Reverse Depends:
                       # 空。誰も依存していない

② なぜ孤児になったのか

$ apt-cache show docker-ce-rootless-extras | grep -E '^(Version|Depends|Recommends):'
Version: 5:29.7.2-...   Depends: dbus-user-session, libc6 (>= 2.34)     # Recommends なし
Version: 5:29.4.3-...   Recommends: slirp4netns (>= 0.4.0) | passt      # 昔はあった

slirp4netns は docker-ce-rootless-extras の Recommends として自動で入っていたものでした。Docker CE のどこかのバージョンでこの Recommends が削除され、1週間前の Docker 更新で親を失って孤児になったわけです。今回の 26.04.1 更新とは無関係でした。

③ その機能を将来使う予定があるか

rootless Docker は使っていないことを確認済みですが、2つ合わせて 259kB です。173GB 空いている環境で、削除して得られるものは実質ありません。

結論は何もしない。通知が目障りなら sudo apt-mark manual libslirp0 slirp4netns で「手動インストール」の印を付ければ、ファイルを消さずに autoremove 候補から外れます（完全に可逆です）。

「apt が消していいと言ったから消す」で処理していたら、1週間前の別の更新の置き土産という因果には気づけませんでした。

🗓️ 24.04 から来る人・26.04 で待っている人へ

いま Ubuntu の LTS まわりは、立場によって次にやることが違います。

24.04 LTS を使っている人は、Update Manager に案内が出るまで待つのが最も安全です。その案内を開くのが 26.04.1 であること、開始はリリース（2026年8月27日）から数週間後になることは前述のとおりです。急ぐなら do-release-upgrade -d で今すぐ移行できますが、rust-coreutils のリグレッション対応バックポートが入る前の状態で移行することになります。26.04 側の新機能と既知問題は Ubuntu 26.04 LTS の新機能｜sudo の Rust 化・X11 廃止・GNOME 50 と既知問題 にまとめています。

すでに 26.04 を使っている人は、待つ理由がありません。この記事の作業がそのまま「26.04.1 にする」です。

sudo apt update
apt-get -s full-upgrade          # ドライラン。「削除: 0 個」を確認する
sudo apt full-upgrade
test -f /var/run/reboot-required && echo YES || echo NO

3行目までで base-files が最新になれば、lsb_release -d が 26.04.1 を返します。4行目が NO なら、そこで終わりです。

✅ まとめ

• 26.04.1 は LTS の初回ポイントリリース。24.04 からの公式アップグレード案内が開くのはこの回で、.2 以降の定期更新とは意味が違う。ただし既存の 26.04 環境から見た作業内容は .2 以降と変わらない
• ポイントリリースの実体は base-files 1パッケージ。changelog の「bump version to 26.04.1」1行がすべてで、書き換わるのは /etc/issue /etc/issue.net /etc/lsb-release /etc/os-release だけ
• VERSION_ID と DISTRIB_RELEASE は 26.04 のまま。OS 判定スクリプトはポイントリリースで壊れない
• do-release-upgrade ではなく apt full-upgrade。新規インストールを伴うため apt upgrade では保留されうる。apt-get -s full-upgrade で「削除: 0 個」を確認してから打つ
• apt list --upgradable と実際に上がる数が食い違うのは phased updates。手でねじ込まず放置してよい
• containerd.io だけの更新ならコンテナは止まらない。containerd-shim が別プロセスで、コンテナの直接の親だから。止まるのは docker-ce が更新されて dockerd が再起動する回で、そこで効くのが live-restore
• 実測は 2分3秒・ダウンタイム0秒・再起動なし・ディスク増加 2.1MB

事前の見立て（19 / 2 / 0 / 5・再起動不要）が実行結果と完全に一致したことで、このクラスの更新は事前に全部読み切れることが確認できました。逆に言えば、読み切れないまま apt full-upgrade を打つ理由もありません。ドライランは sudo なしで打てます。

よくある質問（FAQ）

Q. 「LTS は最初のポイントリリースまで待て」とよく聞きますが、本当ですか？

A. 公式のルールではなく現場の慣行ですが、根拠はあります。Ubuntu の更新マネージャーは既定（/etc/update-manager/release-upgrades の Prompt=lts）では最初のポイントリリースが出るまで新しい LTS を案内しないため、待っていれば自然にそのタイミングになります。加えて、リリース直後の数か月分の SRU とセキュリティ更新が入った状態から始められます。急ぐ理由があるなら do-release-upgrade -d で先に上げることもできます。

Q. 26.04 を使っています。26.04.1 のインストールメディアを入れ直す必要はありますか？

A. 必要ありません。すでに動いている環境にとっての「26.04.1 にする」は、通常の更新を全部当てることと同じです。インストールメディアとしての 26.04.1 は、新規インストール時に更新の当て直しを減らすためのものです。

Q. apt upgrade ではなく apt full-upgrade を使うのは危険ではありませんか？

A. full-upgrade は依存解決のためにパッケージを削除することがあるため、削除が発生するかどうかで判断します。apt-get -s full-upgrade（sudo 不要）を先に打ち、サマリ行が「削除: 0 個」なら upgrade との違いは「新規インストールを保留しない」ことだけです。今回はこの手順で確認してから実行しました。

Q. apt list --upgradable に出ているのに更新されないパッケージがあります。壊れていますか？

A. phased updates（段階的配信）の待ちです。apt full-upgrade の出力に Not upgrading yet due to phasing: としてパッケージ名が並びます。放置すれば展開率の上昇とともに自然に入ります。 個別に apt install でねじ込む必要はありません。

Q. ポイントリリース更新のあと、再起動は必要ですか？

A. /var/run/reboot-required が存在するかどうかで決めます。 カーネル・libc6・systemd が更新対象に入っていなければ、通常このファイルは作られません。今回は作られなかったため再起動していません。「バージョン表記が上がったから念のため」は再起動の理由になりません。

Q. Docker を動かしたまま OS 更新をして大丈夫ですか？

A. 何が更新されるかによります。 containerd.io だけの更新なら、containerd-shim がコンテナの直接の親として生き残るため、コンテナは停止しません（本記事の実例）。docker-ce が更新されて dockerd が再起動する場合は停止しうるので、/etc/docker/daemon.json に "live-restore": true を入れておくと影響を抑えられます。事前に apt-get -s full-upgrade で、どちらが対象かを見ておくのが確実です。

Q. 更新中に紫の全画面ダイアログが出て止まりました。

A. needrestart が入っている環境で出るものです。dpkg -l needrestart で確認できます。今回のサーバーには入っていなかったため、確認プロンプトは Continue? [Y/n] の1回だけで完走しました。

関連記事

Ubuntu 26.04 をこれから入れる・上げる：

• Ubuntu 26.04 LTS アップグレード手順｜24.04からの移行を実機記録で解説
• Ubuntu 26.04 LTS の新機能｜sudo の Rust 化・X11 廃止・GNOME 50 と既知問題

このサーバーで動いているもの：

• 自宅MQTTサーバーをDockerで構築｜ACLでなりすましを遮断【自宅センサー基盤 #3】

参考

• Ubuntu 26.04.1 LTS released（ubuntu-announce・2026年8月27日）
• Changes in Ubuntu 26.04.1（Canonical 公式リリースノート）