Ubuntu 26.04 LTS が 2026-04-23 にリリースされましたね。24.04 LTS からの移行で踏みやすい地雷を、業務インフラ・サーバー運用の視点で整理してみます。後で自分が見返すための備忘録的な位置付けです。
個人ユーザー(自宅 PC、ラズパイ、ゲーミング Linux など)向けの注意点は別記事にまとめました:「Ubuntu 24.04 → 26.04 LTS【個人・ホビー編】」のほうも合わせて読んでみてください。今回は社内インフラ・クラウド・コンテナ基盤など、業務利用にフォーカスしてます。
26.04 LTS は、単なるパッケージ更新だけでなく、cgroup、initramfs、sudo/coreutils、APT、認証基盤、Web サーバー hardening など、運用上の前提に触れる変更が複数入っている LTS なんですよね。「とりあえず上げてみる」より、自分の環境のどの前提に触れるかを先に見ておくほうが安全かなと思います。
今回のスタンス Ubuntu 26.04 LTS の release notes と各パッケージの公式情報をもとに整理してみます。一部、断定的に書ける根拠がまだ弱い項目は「要確認」「方向性として」といった表現に留めています。本番投入前は自分の環境の release notes と各ベンダー文書で再確認するのをおすすめします。
- まず全体像:24.04 と 26.04 の性格の違い
- 自分の環境にどれくらい影響するか(影響度マップ)
- 🔴 コンテナ基盤:cgroup v1 削除と Docker/Podman の世代交代
- 🔴 Web サーバー:Apache + mod_php + PHP JIT の組み合わせに注意
- 🔴 カーネル/ドライバ:カーネル世代の更新と外部モジュール
- 🔴 リモートアクセス:業務 Linux への xrdp が動かない
- 🟡 認証基盤:Samba AD/DC のパッケージ構成を事前確認
- 🟡 TLS / SSH:古い相手先との接続が切れる可能性
- 🟡 /tmp が tmpfs(RAM ベース)になる
- 🟡 initramfs:Dracut が既定に
- 🟡 APT 3:apt-key が削除された
- 🟡 sudo-rs / rust-coreutils
- 🟡 業務デスクトップ:GDM スクリプトの廃止
- 🟡 クラウド/初期化:cloud-init と時刻同期の既定変更
- アップグレード戦略
- おわりに
まず全体像:24.04 と 26.04 の性格の違い
24.04 と 26.04 を一言で対比すると、こうです。
- 24.04 LTS … 既存の作法を守って中身を底上げした LTS。Linux kernel 6.8、Python 3.12、OpenJDK 21、PHP 8.3 など、順当な更新が中心
- 26.04 LTS … systemd 259 による cgroup v1 削除、initramfs の Dracut 既定化、sudo-rs / rust-coreutils 採用、APT 3 化、Apache の hardening など、運用前提に触れる変更が複数入る LTS
しかも 26.04 は LTS から LTS へのジャンプなので、24.10 / 25.04 / 25.10 の 2 年分の累積差分が一気に入る点も忘れがちなんですよね。「1 リリース分」と思って計画すると、後で痛い目を見そうです😅
逆に言えば、新規構築するなら 26.04 のメリットは大きい(RT kernel の提供強化、ARM64 Livepatch、最新ツールチェーン、AI/ML 向け GPU スタックなど)ので、悩ましいのは「既存システムを上げるかどうか」の判断です。
自分の環境にどれくらい影響するか(影響度マップ)
詳細に入る前に、自分の環境のどこが効くのかだけ先に当たりを付けておくと読みやすくなると思います。下のマップで赤丸が多いところから読むのが効率がいいです。
| 領域 | 影響度 | 主な変更 | 該当しやすい環境 |
|---|---|---|---|
| コンテナ基盤 | 🔴 高 | cgroup v1 削除、Docker / containerd の世代交代 | Docker 利用者全般、CI runner |
| Web サーバー | 🔴 高 | Apache の hardening と PHP JIT の相性問題 | LAMP 系、社内 Web |
| カーネルモジュール | 🔴 高 | カーネル世代の更新、glibc 更新による ABI 影響 | 商用ドライバ、EDR、DKMS 利用 |
| リモートアクセス | 🔴 高 | xrdp が動作しない(Wayland-only 化) | 業務 Linux への RDP 接続 |
| 認証/ファイル基盤 | 🟡 中 | Samba AD/DC のパッケージ構成・前提を要確認 | 社内 Samba AD/DC |
| TLS / SSH | 🟡 中 | OpenSSH の DSA 廃止、TLS まわりの方針更新 | 古い機器・古いクライアント残存 |
| /tmp の挙動 | 🟡 中 | /tmp が tmpfs(RAM ベース)に |
バッチ処理、ビルドサーバー |
| initramfs | 🟡 中 | Dracut が既定に | 暗号化、独自 module、ネットブート |
| APT / パッケージ管理 | 🟡 中 | APT 3 化、apt-key 削除 |
社内 Ansible、Dockerfile |
| sudo / coreutils | 🟡 中 | sudo-rs / rust-coreutils が既定 | 運用スクリプト、CI |
| 業務デスクトップ | 🟡 中 | GDM PreLogin/PostSession 廃止 | 配布管理されたデスクトップ |
| クラウド初期化 | 🟡 中 | cloud-init 更新、Chrony が新規インストール時の既定 | golden image 運用、IaC |
| 開発者環境 | 🟢 低〜中 | Python / OpenJDK / PHP の世代更新 | アプリ依存次第 |
🔴 が 1 つでも当てはまるなら事前検証フェーズを必ず入れることになりそうです。以下、影響度の高い順に見ていきます。
🔴 コンテナ基盤:cgroup v1 削除と Docker/Podman の世代交代
26.04 で 個人的に最も影響範囲が広いと感じた変更がここなんですよね。2 つの変化が同時にやってきます。
そもそも cgroup とは
cgroup(control groups)は、Linux カーネルが提供するプロセスをグループ化して CPU・メモリ・I/O などのリソースを制限・監視する仕組みです。Docker、Kubernetes、systemd、LXC などコンテナ・サービス管理系はすべてこの上に載っています。コンテナ技術はざっくり「namespace(分離)+ cgroup(制限)+ capabilities(権限)」の 3 点セットで、cgroup はそのうち「メーター」部分にあたります。
v1(2008年〜)はリソースごとに階層が分かれた設計で、後付けの機能追加により整合性に難がありました。v2(2016年、kernel 4.5〜)で単一階層に再設計され、Ubuntu も 21.10 から v2 が既定です。systemd・Docker・Kubernetes はすべて v2 へ移行済みなので、今あえて v1 で動かしている環境のほうが少数派になっています。
1) cgroup v1 が完全削除された(systemd 259)
- ホストが cgroup v1 で起動していると 26.04 へのアップグレードがそもそも通らない
- 26.04 ホスト上で cgroup v1 前提のコンテナワークロードは動かない
- 逆に、cgroup v1 ホスト上で 26.04 のコンテナイメージも動かない
Kubernetes 本体は数年前から v2 対応済みなので影響は小さいですが、古い Docker-in-Docker 環境、自作の cgroup 監視スクリプト、レガシー JVM チューニング、古い CI runner、LXC/LXD 混在環境でやられます。事前に必ず確認しておきたいところです。
$ stat -fc %T /sys/fs/cgroup/ # 期待される結果: cgroup2fs
2) Docker / containerd / runc / Podman が世代交代
24.04 初期と 26.04 では世代差が大きいですが、24.04 側にもアップデートが入っているので、本番環境では実機で確認するのが確実です。
# 実環境のバージョン確認 $ apt policy docker.io containerd runc
参考までに、24.04 初期と 26.04 の差分の方向性は以下です。
| コンポーネント | 24.04 初期 | 26.04 | 主な注意点 |
|---|---|---|---|
| Docker | 24.0.7(updates で 27 系も配信) | 29.1 系 | fresh install で containerd image store が既定 |
| containerd | 1.7.12 | 2.2.2 | breaking changes ありと公式明言 |
| runc | 1.1.12 | 1.4.0 | pids.limit=0 の意味が変わる |
| Podman | 4.9.3 | 5.7.0 | netavark 前提が強くなる |
CLI の見た目が同じでも、image store、firewall backend、PID 制限、rootless networking の挙動が変わっています。「動いたから OK」ではなく「期待通りの挙動か」を確認するフェーズが必要になります。
🔴 Web サーバー:Apache + mod_php + PHP JIT の組み合わせに注意
サーバー運用で「アップグレード後に静かに動かなくなる」典型がこれです。
「mod_php が全面的に動かない」というより、Apache の systemd unit に追加された hardening 設定(MemoryDenyWriteExecute=yes)と PHP JIT の組み合わせで、JIT 用メモリの確保に失敗する問題です。Ubuntu の bug report でも報告されており、PHP 側の issue でも Apache mod_php と systemd のより制限的な設定との相互作用として説明されています。
対応方針は次のいずれかです。
- php-fpm へ移行する(新規・更新のタイミングならこちらが安全)
- mod_php を継続するなら、PHP JIT を無効化するか、unit 設定の override で hardening を緩める
CMS や独自 PHP 拡張を使っている環境は、composer.lock の固定状況も含めて先に PHP 8.5 対応を済ませておきたいところです。
🔴 カーネル/ドライバ:カーネル世代の更新と外部モジュール
カーネルが世代更新されます。RT kernel の提供強化、ARM64 Livepatch、EtherCAT 統合といった機能面の進化は魅力的ですが、問題は out-of-tree のモジュール側です。
- NVIDIA proprietary driver
- Mellanox / DOCA 系
- 各種 EDR・セキュリティ製品の LKM
- バックアップエージェント
- 独自 NIC/HBA driver
- DKMS でビルドしている自前モジュール
- eBPF を使う監視ツール
このあたりはベンダーが「26.04 対応」を明言するまで本番投入を待つのが安全です。glibc の更新も含めて、prebuilt のネイティブバイナリは原則再ビルド推奨と考えておくと、事故が減るんじゃないかなと思います。
🔴 リモートアクセス:業務 Linux への xrdp が動かない
業務でディスプレイレスの Linux サーバーや Linux ワークステーションに Windows から RDP で入る運用をしている場合は要注意です。
26.04 では GNOME の X11 セッションパッケージが完全に削除され、Wayland-only になりました。xrdp は X11 依存のため、Wayland-only 環境では動作しません。「24.04 から 26.04 にアップグレードしたら xrdp が壊れた」という報告も出ています。
業務での回避策
A. GNOME Remote Desktop に切り替える
GNOME Remote Desktop は RDP プロトコルをサポートしており、【設定】 → 【共有】 → 【リモートデスクトップ】 から有効化できます。Windows の標準 RDP クライアントから接続可能です。ただし、xrdp と挙動が違うので以下の点を検証する必要があります。
- 複数ユーザー同時接続の挙動
- セッションの永続化(切断後の再接続時の挙動)
- 既存の
.xsession系の起動カスタマイズが反映されない
B. デスクトップ環境を Xfce / KDE に切り替える
Xfce は引き続き X11 中心で、xrdp との組み合わせでは現時点で最も安定しています。Linux ワークステーションの用途が「Windows からのリモート操作前提」なら、Xubuntu ベースに統一するのが運用負荷が低い選択です。KDE は Plasma 6.8(2026年後期予定)で X11 完全削除予定なので、長期運用には向きません。
C. SSH + X フォワーディング への切り替え
GUI を頻繁に使わない業務なら、SSH + X11 フォワーディング(ssh -X / ssh -Y)で必要な GUI アプリだけ転送する運用に変える選択肢もあります。
🟡 認証基盤:Samba AD/DC のパッケージ構成を事前確認
社内ファイルサーバーや簡易 AD として Samba を使っている環境は、アップグレード前にパッケージ構成と AD/DC 関連サービス定義を必ず確認します。Samba 側のパッケージ構成変更や transitional 化に巻き込まれて、想定外の挙動になる可能性があるためです。
具体的には、samba-ad-dc 関連パッケージが意図したとおり入っているか、関連する systemd サービス定義に変更が必要ないか、を release notes や Samba 公式の 26.04 向け案内と突き合わせて確認していきます。本番アップグレード前にステージング環境で AD/DC 機能の起動確認をしておくのが安全かなと思います。
# 関連パッケージの状態確認 $ dpkg -l | grep samba
🟡 TLS / SSH:古い相手先との接続が切れる可能性
OpenSSH 側では DSA 署名アルゴリズムのサポートが削除され、SHA1 SSHFP DNS レコードへの警告、非ポスト量子 KEX 交渉時の警告など、古い方式への依存を減らす変更が入っています。
# 自分が使えるアルゴリズムの確認 $ ssh -Q kex $ ssh -Q key
TLS については、OpenSSL / Apache / 各アプリケーションの更新により、古い機器や古い Java クライアントとの接続は事前確認しておくのが安全です。具体的には次のような相手先がまだ残っているかの棚卸しです。
- 古いロードバランサ・WAF
- 古い SAN/NAS の管理画面
- 業務系の組み込み機器(複合機・産業用機器)
- 古いオンプレ業務アプリの API クライアント
- 一部 Java 8 系の古いクライアント
🟡 /tmp が tmpfs(RAM ベース)になる
26.04 では upstream の tmp.mount unit が既定で入り、/tmp が tmpfs(RAM ベース) になります。再起動で消えること自体は従来から前提ですが、RAM/swap を使うようになるため、サーバー運用に効く変更です。
特に注意したいのはこういうサーバーです。
- 大きな一時ファイルを
/tmpに置くバッチ処理サーバー - C/C++ や TypeScript の中間ファイルが大量に出るビルドサーバー
- 画像・動画変換、機械学習の中間データを
/tmpで扱う処理ノード
これらが /tmp を前提にしていると、メモリを圧迫したり swap を激しく使ったりします。/var/tmp や専用の作業ディレクトリへ逃がす設計を確認しておくと安全です。
🟡 initramfs:Dracut が既定に
26.04 では、初期 RAM ディスク基盤が initramfs-tools から Dracut 既定に変わっています。initramfs-tools も引き続きサポートされ、切り替え可能です。
通常利用では意識しませんが、以下のような環境では従来の initramfs-tools 前提の処理がそのまま動くかを確認したほうがよいです。
- 独自 kernel module を initramfs に組み込んでいる
- LUKS / TPM 連携の暗号化ストレージ
- iSCSI、Multipath、特定の RAID コントローラ
- ネットワークブート / PXE
- 独自の initramfs フックスクリプト
なお、TPM ベース FDE を使う場合、特定の kernel snap が必要になり、NVMe RAID 用の vmd モジュールなど一部のハードウェア機能が利用できなくなるケースがあります。NVIDIA ドライバ以外の DKMS モジュールも TPM/FDE 環境では使えないので、ストレージ要件の厳しい環境では事前確認が必要です。
🟡 APT 3:apt-key が削除された
APT は 3.1 系に更新され、apt-key コマンドが削除されました。古い手順書や社内スクリプトで apt-key add を使っている場合は、signed-by を使う方式へ更新が必要です。
# 古い書き方(動かない) $ curl -fsSL https://example.com/key.gpg | sudo apt-key add - # 新しい書き方 $ curl -fsSL https://example.com/key.gpg \ | sudo gpg --dearmor -o /etc/apt/keyrings/example.gpg $ echo "deb [signed-by=/etc/apt/keyrings/example.gpg] https://example.com/repo stable main" \ | sudo tee /etc/apt/sources.list.d/example.list
業務インフラだと、社内 Ansible、Cloud-init の user-data、Dockerfile、Packer テンプレート、CI のセットアップスクリプトなど、apt-key を含む箇所が広く散らばっているはずなんですよね。Grep して一気に書き換えるのが効率的だと思います。
# リポジトリ内の apt-key 利用箇所を一気に確認 $ grep -rn "apt-key" .
🟡 sudo-rs / rust-coreutils
26.04 では sudo-rs が既定の sudo provider になり、coreutils も rust-coreutils(uutils) ベースになります。ただし cp mv rm は未解決バグのため GNU 版が継続利用されます。
基本的な互換性は意識されていますが、運用スクリプトで GNU coreutils 特有の挙動(細かいエラーメッセージのフォーマット、GNU 拡張オプションなど)に依存している場合は確認しておくと安全です。必要に応じて GNU 版へ切り替える手段も用意されています。
CI で set -e のスクリプトが暗黙の挙動差分で落ちる、といったじわっと効く罠になりやすいので、本番投入前にステージングで一通り回しておくのが無難です。
🟡 業務デスクトップ:GDM スクリプトの廃止
業務用デスクトップを Ubuntu で配っている組織は、GDM の PreLogin / PostSession スクリプトが削除されたことに注意してください。これに依存していた以下のような処理は壊れます。
- ログオン時のホームディレクトリ同期
- ログアウト時のキャッシュ・一時データの自動削除
- 独自の監査ログ取得
回避策は PAM の session module(pam_exec など)に移植することです。あと、26.04 Desktop は「快適利用」の推奨 RAM が 6 GB に引き上げられたので、旧端末の延命用途には向きません。
🟡 クラウド/初期化:cloud-init と時刻同期の既定変更
- Chrony が新規インストール時の既定になりました。systemd-timesyncd と Chrony が共存している既存環境は設定の重複に注意
- cloud-init の世代更新でネットワーク機能が拡張された一方、いくつかの既知問題も報告されている(Google Cloud で初回起動が遅くなる事象など)。利用するイメージ・クラウド側の既知問題は個別に確認したい項目
- 未接続 NIC があると boot が数分待たされることがある。
/etc/netplan/50-cloud-init.confから削除するかoptional: trueを付ける
クラウド利用の場合、Canonical 側で 26.04 対応イメージは用意されていても、各クラウドの個別サービス(GPU image、DR、managed K8s、confidential VM、専用 guest agent)はまだ 24.04 のほうが成熟している可能性が高いので、サービス単位の対応表を別途確認する運用が無難です。
なお、Google Cloud については 26.04 の GCP イメージが AMD64v3 前提になっており、N1 系の古い CPU(Ivy Bridge / Sandy Bridge)が非対応となるなど、ハードウェア要件にも注意が必要です。
アップグレード戦略
22.04 から直接 26.04 には行けません。22.04 → 24.04 → 26.04 の二段階が必要です(または 25.10 経由)。
ロールバック戦略はノード単位での巻き戻しを前提にしておきます。kernel・systemd・OpenSSL・各ランタイムが同時に動くため、パッケージ単位で戻すと整合性が崩れます。VM スナップショット、AMI、golden image の再デプロイ、blue-green、canary の前提で設計するのが安全です。
検証順序のおすすめは以下です。
- 基盤テスト ⋯ boot、network、NTP、storage、kernel module、backup/監視 agent、
/tmp利用量 - 管理プレーン ⋯ SSH、sudo(sudo-rs)、PAM、SSO、Samba AD/DC、APT 経路
- アプリ実行基盤 ⋯ Java/PHP/Python/.NET のビルドと起動、TLS 通信
- コンテナ ⋯ Docker/Podman、古い image、rootless、GPU
- クラウド初期化 ⋯ cloud-init、multi-NIC、guest agent
- 業務デスクトップ・リモート ⋯ GDM フック、xrdp / GNOME Remote Desktop、印刷、ファイル共有
おわりに
移行前チェックリストをまとめると、こんな感じになります。
| # | 確認項目 | 影響度 | 確認コマンド/方法 |
|---|---|---|---|
| 1 | cgroup v2 で起動しているか | 🔴 | stat -fc %T /sys/fs/cgroup/ が cgroup2fs |
| 2 | Apache + mod_php + PHP JIT の組み合わせ | 🔴 | php-fpm 移行 or JIT 無効化 or unit override |
| 3 | 外部 kernel module / DKMS のベンダー対応 | 🔴 | dkms status とベンダー文書 |
| 4 | Docker / Podman / OCI runtime の挙動回帰試験 | 🔴 | image store、rootless、GPU、compose |
| 5 | xrdp 利用環境の代替策 | 🔴 | GNOME Remote Desktop または Xubuntu 化 |
| 6 | Samba AD/DC のパッケージ構成と前提条件 | 🟡 | dpkg -l | grep samba、ステージング検証 |
| 7 | OpenSSH の DSA / SHA1 SSHFP / 古い KEX | 🟡 | ssh -Q kex、機器側の KEX 確認 |
| 8 | 古い TLS / 古い Java クライアントの相手先 | 🟡 | openssl s_client で対向確認 |
| 9 | /tmp を大量利用するバッチ・ビルド・変換処理 |
🟡 | /var/tmp への退避設計 |
| 10 | initramfs:独自 module / 暗号化 / netboot | 🟡 | Dracut 配下での再生成テスト |
| 11 | 社内 Ansible / Dockerfile の apt-key 利用 |
🟡 | grep -rn "apt-key" で全置換 |
| 12 | 運用スクリプトの GNU coreutils 依存 | 🟡 | ステージングで一通り実行 |
| 13 | GDM PreLogin / PostSession 依存スクリプト | 🟡 | PAM session module へ移植 |
| 14 | cloud-init / golden image / multi-NIC | 🟡 | クラウド別に再検証 |
| 15 | クラウドベンダー側の 26.04 サポート行列 | 🟡 | サービス別に確認 |
| 16 | 22.04 → 26.04 の段階アップグレード設計 | 🟢 | 24.04 を経由する前提で計画 |
一行結論
新規構築なら 26.04 は有力な選択肢。一方、既存基幹システムの一斉置換は、26.04.1 以降の安定状況やベンダー対応を見ながら段階移行するのが無難。とくに既存サーバーは「アップグレード可否」より「特定機能だけ静かに壊れる箇所」のほうが厄介。
参考は Ubuntu 26.04 LTS の release notes と "summary for LTS users" を一次情報として読むのが最速です。今回まとめた内容も、自分の環境で適用する前には必ず一次情報で裏取りしてください😊
個人ユーザー視点での変更点は別記事「【ホビー向け】Ubuntu 26.04 LTS、上げてみる前に確認したいこと」のほうにまとめてあるので、よければ合わせて読んでみてください。検証が進んだら別記事で続きを書こうと思います。
