Ubuntu 24.04 と 26.04 の違い：サーバー視点

Ubuntu 24.04 と 26.04 の違いは、どこに出るのか

Ubuntu 24.04 と 26.04 の違いのうち、VPS を借りている側に実際に届くのはカーネル、systemd、OpenSSH、OpenSSL、言語ランタイム、そして apt と sudo の中身の入れ替わりです。デスクトップ側の話題はサーバーには関係ありません。先に結論を書きます。動いている本番サーバーを今日移す理由は薄いです。移る理由があるのは、新しい言語ランタイムか新しいカーネルの機能が必要な場合、そして OpenSSH 10.2 の既定になった耐量子鍵交換や sudo-rs を早めに踏んでおきたい場合です。

この記事は手順書ではありません。実際に上げる作業は 24.04 から 26.04 へのアップグレード手順 のほうに書いてあります。ここで扱うのは、上げる前に知っておくべき「何が変わるか」だけです。

バージョン番号をどこから取ったか

この記事に出てくる版数は、2026年9月25日に Ubuntu 公式リリースノート と packages.ubuntu.com を読んだ時点の値です。セキュリティ更新でリビジョン部分は日々動きます。アーキテクチャや HWE の選択で変わるものは、その都度そう書きます。手元の値は apt policy <パッケージ名> で確認してください。

カーネル：6.8 と 7.0、そこに HWE がどう絡むか

24.04 の GA カーネルは 6.8 系、26.04 の GA カーネルは 7.0 系です。ただしこの比較は不正確です。24.04 に留まったままカーネルだけを新しくできるからです。ポイントリリースごとに HWE（ハードウェアイネーブルメント）スタックが更新され、24.04.4 の時点で HWE カーネルは 6.17 系になっています。

つまり「新しいハードウェアに対応していない」「新しいカーネル機能が欲しい」という理由の大半は、26.04 に移らなくても HWE で届きます。ここを取り違えると、必要のない全面アップグレードをすることになります。GA と HWE のどちらを選ぶべきかは HWE カーネルと GA カーネルの選び分け に書きました。ポイントリリースが何を運んでくるのかは ポイントリリースの中身の説明 のほうです。

HWE で新しくなるのはカーネルと一部のグラフィックススタックだけです。glibc も systemd も OpenSSL も 24.04 のままです。これが HWE の限界で、同時に安全さの理由でもあります。

26.04 側は出たばかりなので GA と HWE が同じ 7.0 です。慣例では最初の HWE スタックは 26.04.2 から来ます。

リリースノートは 7.0 でクラッシュダンプが既定で有効になったと書いています。メモリの小さい VPS では、ダンプ用に予約される分だけ使える RAM が減ります。移行後に確認してください。

cat /proc/cmdline
free -h

crashkernel= が cmdline に入っていて free -h の total が以前より小さければ、それが理由です。古いカーネルが溜まって /boot を埋めるのは 24.04 でも 26.04 でも同じなので、古いカーネルの掃除 は移行とは別に済ませておきます。

systemd 255 と 259：cgroup v1 と SysV スクリプトが消える

24.04 の systemd は 255.4、26.04 は 259 です。サーバー管理者に効く変更は二つあります。

一つ目は cgroup v1 のサポートが完全に削除されたことです。24.04 でも既定は cgroup v2 でしたが、カーネルパラメータ systemd.unified_cgroup_hierarchy=0 を付ければ v1 に戻せました。26.04 ではその逃げ道がありません。v1 のパスを直接読む古い監視エージェントや、v1 前提で設定された古いコンテナランタイムは、そこで止まります。

二つ目は、リリースノートが 259 を「System V 形式のサービススクリプトを解釈する最後のリリース」と明記していることです。26.04 ではまだ動きますが、次の LTS では動きません。/etc/init.d/ にしか起動方法を持たないベンダー製品を抱えているなら、unit ファイルへの書き直しが宿題として確定します。手元にそれがあるかは次で分かります。

systemctl list-units --type=service | grep 'LSB:'

LSB: で始まる説明が付いた unit は、systemd が init スクリプトから自動生成したものです。一行も出なければ、この宿題はありません。

OpenSSH と OpenSSL：接続そのものが変わる

24.04 は OpenSSH 1:9.6p1 と OpenSSL 3.0.13、26.04 は OpenSSH 1:10.2p1 と OpenSSL 3.5.6 です。OpenSSH の差は 4 年分あり、内容が濃いです。

既定の鍵交換に mlkem768x25519-sha256 が入りました。ML-KEM（格子ベースの鍵カプセル化機構）と X25519 を組み合わせたハイブリッドで、通信を記録しておいて将来の量子計算機で解く攻撃に備えるものです。24.04 側でこれが有効にならない理由と対処は 耐量子鍵交換が使われていないという警告の読み方 にまとめてあります。

DSA（ssh-dss）のサポートは削除されました。古いネットワーク機器やアプライアンスから DSA ホスト鍵で入っていた場合、26.04 のクライアントは接続を断ります。出るメッセージはこれです。

Unable to negotiate with 203.0.113.10 port 22: no matching host key type found. Their offer: ssh-dss

PerSourcePenalties という設定も入りました。認証に失敗し続ける送信元を sshd 自身が一定時間はじきます。fail2ban を入れている場合は二重に効くので、締め出しの閾値を見直してください。

OpenSSL は 3.0 から 3.5 への移行です。共有ライブラリの名前は libssl.so.3 のままなので、普通にリンクしたバイナリはそのまま動きます。低レベル API や ENGINE に触っている自前のコードは再ビルドが要ります。26.04 の Apache は 2.4.65 で、TLS 1.0 と 1.1 が既定で無効です。古い決済端末や社内クライアントを相手にしているなら、ここは移行前に確認する項目です。

言語ランタイム：既存のデプロイに一番効く差

ここが移行の痛点です。数字だけ並べます。

• Python：24.04 は 3.12、26.04 は 3.14
• PHP：24.04 は 8.3.6、26.04 は 8.5.2
• Node.js：24.04 は 18.19、26.04 は 22.22（どちらも universe）
• glibc：24.04 は 2.39、26.04 は 2.43
• Rust ツールチェーン：24.04 は 1.75、26.04 は 1.93

Python は venv を作り直すことになります。C 拡張を含む wheel は ABI タグが cp312 と cp314 で違うので、3.12 用にビルドしたものは 3.14 から読まれません。requirements を固定したまま上げると、ビルドツールの無いサーバーで pip install が失敗します。

PHP は 8.3 から 8.5 へ二段飛びです。間に非推奨化と挙動変更が入っているので、アプリを 24.04 の上で先に 8.5 に通してから OS を上げるほうが、原因の切り分けが楽になります。二つを同時に変えると、壊れたのが OS なのかランタイムなのか分かりません。

Node.js は移行理由になりません。archive の 18 は upstream の保守がすでに終わっており、26.04 の 22 も最新系列ではないからです。どちらの OS でも結局 NodeSource か nvm を使うことになります。

glibc の差は、自前でビルドしたバイナリを配る場合に効きます。26.04 でビルドしたものを 24.04 に持っていくと動きません。新しい glibc のシンボルを参照するからです。

/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.41' not found

逆向き、つまり 24.04 でビルドして 26.04 で動かすほうは通ります。ビルド用のサーバーだけ古いままにしておく、という判断はここから出てきます。

apt の変わったところと deb822 形式

24.04 の apt は 2.8 系、26.04 は 3.1 系です。見た目から中身まで変わっています。

• 出力が色付きで列に揃うようになりました
• 依存解決に solver3 が既定で使われます
• TLS とハッシュの実装が GnuTLS から OpenSSL に移りました
• パッケージ操作の undo と redo を含む履歴管理が入りました
• apt-key は削除されました

apt-key を呼ぶ自動化スクリプトは apt-key: command not found で止まります。鍵は /etc/apt/keyrings/ に置き、ソース側の Signed-By: で指す形に書き換えます。

ソースの形式は deb822 が既定です。24.04 でもすでに /etc/apt/sources.list.d/ubuntu.sources は deb822 でしたが、26.04 では一行形式が明示的に非推奨になりました。まだ .list が残っているなら、変換コマンドがあります。

sudo apt modernize-sources
sudo apt update

元のファイルはバックアップ用の拡張子を付けて残るので、戻せます。ここでよくある失敗は、同じリポジトリを .list と .sources の両方に書いてしまうことです。apt は警告を出します。

W: Target Packages (main/binary-amd64/Packages) is configured multiple times in /etc/apt/sources.list.d/

この重複の直し方は 重複した apt ソースの直し方 のほうに、パターン別に書いてあります。

sudo-rs と、Rust で書き直された基本コマンド

26.04 では sudo の実体が sudo-rs、つまり Rust による再実装に置き換わりました。リリースノートは従来の sudo が sudo.ws という名前で archive に残ると書いています。

普通の /etc/sudoers はそのまま読まれます。問題になるのは端のほうです。sudo-rs の README が非対応として挙げているものに、LDAP ベースの sudoers、INTERCEPT によるシェル脱出の抑止、UTF-8 でない sudoers ファイル、コマンドの最終引数以外でのワイルドカードがあります。互換のために無視されるオプションもあります。env_reset は常に有効、logfile は無視されてログは常に syslog、log_denied も常に有効です。認証は必ず PAM を通るので、sudoers 側で sudo-ldap を使っていた環境は設計から変わります。

移行前後で解釈が変わっていないかは、同じユーザーで比べるのが確実です。

sudo --version
sudo -l

sudo --version が sudo-rs の版数を返せば、置き換わっています。sudo -l の出力を移行前に保存しておいて、移行後に差分を取ってください。sudo-rs 固有の挙動は sudo-rs で何が変わるか に切り出してあります。

基本コマンド側も Rust 実装が既定で入っています。ただし全部ではありません。移行の途中なので、一部のコマンドは GNU 版のまま残されています。手元で確かめるのが早いです。

cp --version | head -n 1
ls --version | head -n 1

出力に uutils と出れば Rust 実装、GNU coreutils と出れば従来のものです。実害が出るのは、コマンドのエラーメッセージや --help の文面を grep しているスクリプトです。文面が一致しなくなるので、条件分岐が黙って外れます。この移行の全体像は 基本コマンドの Rust 書き直し にまとめました。

dracut と chrony：起動と時刻の担当が替わる

26.04 の initramfs（初期 RAM ディスク）は dracut が既定になり、initramfs-tools と入れ替わりました。日々のコマンドも変わります。update-initramfs の代わりに dracut、lsinitramfs の代わりに lsinitrd、設定は /etc/dracut.conf.d/ です。initramfs-tools も archive に残っていて、必要なら戻せます。

自前の initramfs フックを持っている環境、たとえば暗号化ルートや独自のネットワークストレージからブートしている環境では、ここが 26.04 移行で一番危ない箇所です。フックが移植されていなければ、再起動した VPS は戻ってきません。その場合の手順は カーネル更新後に VPS が起動しないとき にあります。

時刻同期は、新規インストールで chrony が既定になり systemd-timesyncd と置き換わりました。アップグレードした環境は自動では替わりません。揃えたい場合はこうします。

sudo apt-mark auto systemd-timesyncd
sudo apt install chrony
chronyc tracking

chronyc tracking が参照サーバー名と Leap status : Normal を返せば同期しています。NTS（認証と暗号化つきの NTP）が既定で有効で、参照先は /etc/chrony/sources.d/ubuntu-ntp-pools.sources にあります。

サードパーティのリポジトリは codename を差し替える

24.04 の codename は noble、26.04 は resolute です。アップグレードすると Ubuntu 自身のソースは書き換えられますが、サードパーティのものは無効化されるか、noble を指したまま残ります。

ここで手が滑りやすいのは、無効化されたソースを機械的に resolute へ書き換えることです。ベンダーがまだ 26.04 向けを出していなければ、こうなります。

E: The repository 'https://download.example.com/linux/ubuntu resolute Release' does not have a Release file.

書き換える前に、その suite が実在するかを確かめます。

curl -fsSI https://download.example.com/linux/ubuntu/dists/resolute/Release

HTTP 200 が返らなければ、そのベンダーはまだ 26.04 に対応していません。確認しておくべき代表例は Docker、PostgreSQL の PGDG、NodeSource、HashiCorp、Grafana、Tailscale、nginx 公式リポジトリです。このうち一つでも止まると本番が止まります。移行を決める前に、/etc/apt/sources.list.d/ の中身を一覧にして、一つずつ上のコマンドを通してください。これが 26.04 に移れるかどうかの、最も現実的な判定になります。

24.04 に留まるべき人、26.04 に移る理由がある人

24.04 に留まってよいのは次の場合です。

• 動いている本番サーバーで、新しいランタイムを必要としていない
• PHP や Python のアプリを抱えていて、検証の時間が取れない
• cgroup v1 前提の監視エージェントや古いコンテナ基盤がある
• SysV スクリプトしか持たないベンダー製品が載っている
• 依存するサードパーティリポジトリがまだ resolute を出していない
• 欲しいのは新しいカーネルだけで、それは HWE で足りる

26.04 に移る理由があるのは次の場合です。

• 新規構築で、これから何年も使うサーバーを作る
• Python 3.14、PHP 8.5、PostgreSQL 18、MySQL 8.4 のどれかが要件になっている
• OpenSSH 10.2 の既定の耐量子鍵交換を早く入れたい
• リアルタイムカーネルを main archive から使いたい
• glibc 2.43 や新しい Rust ツールチェーンでビルドしたい

迷ったときの順番はこうです。まず HWE で足りないかを確認します。次に /etc/apt/sources.list.d/ の全ベンダーが resolute を出しているかを確認します。最後に、同じ構成のテスト用 VPS を 26.04 で一台立てて、アプリを載せてみます。この三つを通ってから本番に触ります。LTS と中間リリースのどちらを土台にするかで迷っているなら、サーバーでの LTS と中間リリースの使い分け のほうが先に読む記事です。

実際に上げる段になったら、手順と切り戻しは 24.04 から 26.04 へのアップグレード手順 に、途中で止まった場合の復旧は 失敗したリリースアップグレードからの復旧 にあります。

FAQ

Ubuntu 24.04 のまま、新しいカーネルだけ使えますか

使えます。それが HWE スタックの役割です。24.04 のポイントリリースごとに新しいカーネルが降りてきて、24.04.4 の時点で HWE は 6.17 系です。GA カーネルの 6.8 に固定したままにもできます。注意点は、HWE で新しくなるのはカーネルと一部のグラフィックススタックだけで、glibc も systemd も OpenSSL も 24.04 のまま据え置きだということです。新しいハードウェア対応が目的なら HWE で足ります。新しいランタイムやライブラリが目的なら HWE では届きません。

26.04 に上げると PHP や Python のアプリは動かなくなりますか

動かなくなる可能性は高いです。Python は 3.12 から 3.14 に上がるので、C 拡張を含む venv は ABI タグが合わず作り直しになります。PHP は 8.3 から 8.5 への二段飛びで、間に非推奨化と挙動変更が入っています。対処は、OS を上げる前に 24.04 の上でアプリを新しいランタイムに通しておくことです。OS とランタイムを同時に変えると、壊れた原因がどちらなのか切り分けられなくなります。

sudo-rs になると /etc/sudoers は書き直しになりますか

普通の書き方なら、そのまま読まれます。書き直しが必要になるのは端のほうです。sudo-rs は LDAP ベースの sudoers に対応せず、認証は必ず PAM を通ります。コマンドの最終引数以外でのワイルドカードも扱いません。env_reset や logfile のような一部のオプションは互換のために無視され、ログは常に syslog に出ます。移行前に sudo -l の出力を保存しておき、移行後の出力と比べてください。差分が出なければ、そのルールセットは通っています。

do-release-upgrade が「新しいリリースはありません」と言うのはなぜですか

LTS から LTS への案内は、新しい LTS の最初のポイントリリースが出てから開始されるためです。26.04 が公開された直後に 24.04 のサーバーで do-release-upgrade を実行しても No new release found と返ります。設定は /etc/update-manager/release-upgrades の Prompt= 行で、LTS サーバーの既定値は lts です。待たずに上げる方法と、その判断材料は 新しいリリースが見つからないと言われるときの対処 に書いてあります。