本文へ移動
技術を、自社の仕事に。
判断と実行を助けるメディア

記事を検索

開発・技術

Ubuntu 24.04→26.04.1の更新開始 — 上げ時と確認点

鈴木 翔公開 参考情報・出典
目次 · 6項目

会社のWebサイトや業務システムをUbuntu 24.04のサーバーで動かしていて、保守担当から「26.04に上げますか」と聞かれた。あるいは社内のUbuntuデスクトップに、新しい版への更新を促す通知が出始めた。上げるべきか、いつ上げるか、上げたら何が止まりうるのかを、公式の資料だけで決めたいという場面を想定しています。

2026年9月29日、24.04 LTSから26.04.1 LTSへのアップグレードが有効になりました。告知、26.04のリリースノート、サポート期限の公式ページを2026年10月4日に照合し、サーバーを運用する側の判断材料を整理します。

9月29日に何が始まったか

告知はUbuntuの公式フォーラム（Ubuntu Discourse）の「Upgrades from Ubuntu 24.04 LTS to Ubuntu 26.04.1 LTS now enabled」です。投稿者はCanonical所属のUtkarsh Gupta氏で、本文は「On behalf of the Ubuntu Release Team」と結ばれています。要点は次のとおりです。

  • デスクトップには、Update Manager から26.04.1への更新が案内されます。告知は「rolled out progressively over the coming days」と書いており、数日かけて順に配られます
  • Ubuntu Serverは通知を待つ仕組みではなく、管理者が do-release-upgrade を実行すれば、いつでも始められます。通知を待ちたくないデスクトップも同じコマンドで始められます
  • 更新は無償で、事前にリリースノートの注意点・既知の問題を読むよう勧めています

Ubuntu Serverの公式手順書のとおり、LTS間の更新は最初のポイントリリース（ここでは26.04.1）まで開きません。26.04は2026年4月23日、26.04.1は8月27日に出ており、その約1か月後に経路が開きました。

アップグレードツールの配布先を並べた公開ファイル（changelogs.ubuntu.com/meta-release-lts）には、10月4日時点で「Version: 26.04.1 LTS」「Supported: 1」の項目があり、最終更新は告知の約1時間半前の9月29日11時03分（UTC）でした。

急ぐ必要はあるか — サポート期限で見る

24.04のまま使える期間は、まだ長く残っています。期限はubuntu.comのリリースサイクルのページで確かめました。

版公開標準サポート終了ESM（Ubuntu Pro）終了
22.04 LTS2022年4月2027年5月2032年5月
24.04 LTS2024年4月2029年5月2034年5月
26.04 LTS2026年4月2031年5月（注）2036年5月

（注）26.04のリリースノートは「supported until April 2031」と書いており、リリースサイクルのページ（May 2031）と月が1か月ずれています。本記事ではどちらかに断定せず、「2031年春」と読んでください。24.04のリリースノートは「until 31 May 2029」で、リリースサイクルのページと一致します。

ESMはUbuntu Proの契約で受けられる延長のセキュリティ保守です。Ubuntu Serverの手順書は、Ubuntu Proが5台まで無償で使えると書いています。

Ubuntu 22.04・24.04・26.04の各LTSについて、公開から標準サポート終了までと、ESM終了までの期間を縦の時間軸に並べ、22.04から26.04へは24.04を経由する必要があることと、2026年10月4日の位置を示した図

図で見るべき点は2つです。1つは、24.04の標準サポートが2029年5月まで、2年半以上残っていることです。9月29日の有効化は「上げられるようになった」という合図で、24.04が終わるという知らせではありません。もう1つは、22.04から26.04へ直接は上げられないことです。Ubuntu Serverの手順書は「You can only upgrade from one LTS release directly to the next sequential LTS release」と書き、26.04のリリースノートも22.04や25.04からは先に24.04か25.10へ上げるよう求めています。22.04の標準サポートは2027年5月に終わるため、22.04のサーバーが残っている場合は、24.04への更新を先に計画に載せます。

ここからは編集部の提案です。24.04で動いている本番サーバーは、2029年5月を期限として、検証環境で26.04の動作を確かめてから上げる順番を組めば足ります。26.04の新機能やPHP・PostgreSQLの新しい版が必要な案件、新規に構築するサーバーは、26.04を選ぶ理由がはっきりしています。

24.04から変わる主なもの

26.04のリリースノートには、24.04からの利用者向けの要約（Summary for LTS users）があります。Webサイトや業務システムのサーバーで影響が出やすいものを抜き出しました。

対象24.04から26.04での変化（リリースノートの記載）
MySQL8.0から8.4 LTSへ。mysql_native_password で認証するアカウントは既定でロックアウトされる
PHP8.5へ。8.4・8.5の互換性を壊す変更は上流のリリースノートを参照するよう案内
PostgreSQL18へ
OpenSSH9.6p1から10.2p1へ。弱いDSA署名のサポートを削除
カーネルGAカーネルは6.8から7.0へ
sudo・coreutilssudo-rs が既定の sudo に。基本コマンドは rust-coreutils が既定（cp・mv・rm はGNU版のまま）

業務システムで最初に確かめたいのはMySQLです。リリースノートは、古い認証方式のアカウントを caching_sha2_password に切り替えるか、設定で mysql_native_password=ON を明示するかの2通りを示しています。前者はパスワードを入れ直すことになり、後者は「will no longer work in future Ubuntu releases, which will provide MySQL 9.7+」とあります。アプリケーションの接続ユーザーがどちらの方式かを、上げる前に一覧にしておきます。MySQLの版の変化で起きる挙動の差は、MySQL 9.7のDATE挙動変更の記事でも扱いました。

DSA鍵でのSSH接続は26.04では通りません。sudo-rs と rust-coreutils は元の実装に戻す方法（sudo.ws、coreutils-from-gnu）がリリースノートにあります。シェルスクリプトの定期処理は検証環境で一度通しておきます。

リリースノートの「既知の問題」

26.04のリリースノートには既知の問題（Known issues）の節があります。サーバー運用に関わるものは次の4点です。

  1. Apache2の mod-php でPHPのJITが失敗する。 Apache2のsystemdユニットが既定で MemoryDenyWriteExecute=yes になり、libapache2-mod-php ではPCREのJITメモリを確保できず警告が出ます。リリースノートは php-fpm への切り替えを推奨し、mod-php を続ける場合は sudo systemctl edit apache2 で設定を上書きする手順を示しています
  2. PostgreSQLのスループット・遅延の低下。 Linux 7.0の変更で大きく性能が落ちる場合があり、huge pagesを使う構成は影響を受けないとして、huge_pages を on にするよう求めています
  3. rust-coreutils の既知の脆弱性。 20件のCVEが列挙され、影響を確認して緩和策や更新を当てるよう書かれています
  4. Google Cloudでの初回起動の遅れ。 26.04のイメージは、cloud-initとsystemdの問題で初回起動が最大30秒遅くなることがあります

8月27日の26.04.1の変更一覧（Point-Release Changes）には、アップグレード処理（ubuntu-release-upgrader）の修正5件が並びますが、上の1〜3が解消したという記載は見当たりませんでした。WordPressなどを mod-php で動かしているサーバーと、PostgreSQLのサーバーは、検証環境で26.04.1に上げて確かめる対象の筆頭です。

上げる前の手順（公式手順と編集部の提案）

Ubuntu Serverの手順書「How to upgrade your Ubuntu release」の事前チェックを、サーバー運用の順に並べ直しました。

  1. リリースノートを読む。 上で挙げた変更と既知の問題が、自社の構成に当たるかを確認します
  2. 24.04を最新にする。 手順書は次のコマンドを示し、段階配信（phased updates）中のパッケージが更新を止めることがあると書いています。/run/reboot-required があれば先に再起動します
sudo apt update
sudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true
ls /run/reboot-required   # あれば再起動してから進める
sudo do-release-upgrade
  1. 空き容量を確保する。 数GBのダウンロードになりうるとしています
  2. 外部リポジトリとPPAを洗い出す。 更新中は無効化され、手順書は「the most common cause of upgrade issues」と書いています。削除はされないため、更新後に再有効化するか、26.04向けの版を探します
  3. バックアップを取る。 手順書も「extremely important」としています。編集部の提案としては、仮想マシンやクラウドのサーバーなら、ディスクのスナップショットを取ってから始めると戻しやすくなります
  4. 立ち会える時間を確保する。 対話式で途中に質問が出ます。手を入れた設定ファイルは新旧の差分を確認して選ぶ画面が出て、既定は現在の設定を残す側です。ダウンロードが終わると中断できない、と更新前の確認画面にも表示されます

更新は再起動して完了です。手順書は「The system is not considered upgraded until this reboot occurs」と書いています。本番の切り替え時間は、再起動とアプリケーションの確認まで含めて見積もります。

コンテナで動かしている場合は、ベースイメージを26.04に替えて作り直すのが編集部の提案です（未検証）。OSの既定値が変わる更新で止まる場所の洗い出し方は、Amazon Linux 2027のSELinux既定変更の記事も参考になります。

2026年10月4日に、Ubuntu Discourseの告知（topic 88502）と26.04.1の変更一覧（topic 86789）の本文・投稿者、26.04のリリースノート（ubuntu/ubuntu-release-notes commit 513ac76）、リリースサイクルのページ、Ubuntu Server・Desktopの更新手順書、meta-release-lts を直接開いて照合しました（資料調査）。編集部の検証環境（Ubuntu 24.04.4 LTS）では版の確認のみ行い、do-release-upgrade は入っておらず、アップグレードは実施していません。26.04上でのApache・PHP・MySQL・PostgreSQLの動作と所要時間は未確認です。

Ubuntuで動く業務システムやWebサイトのOS更新計画、更新に合わせた改修については、グリームハブの開発・AI・自動化のご相談で承っています。サーバーの構成と使っているミドルウェアによって確認の順番が変わるため、お問い合わせからご相談ください。

Sources

この記事を共有XFacebook
鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

この記事から、もう一歩先の検討へ。

この記事のテーマを、自社の次の一歩へ

自社での進め方を、具体的に。

つくりたい仕組み、既存システム、運用の条件を整理し、実現に向けた次の一歩を考えます。

  • 実現したい仕組み
  • 既存環境との接続
  • 運用の条件
開発・運用の構想を相談する

構想段階からご相談いただけます。この記事の情報を相談フォームに引き継ぎます。

最新記事をメールで受け取る