Ubuntu 24.04から26.04へ安全にアップグレードする方法

Ubuntu 24.04 はいつ 26.04 にアップグレードできますか？

VPS 上の Ubuntu 24.04 は、2026 年 8 月 27 日に予定されている 26.04.1 のポイントリリースが公開されると、26.04 にアップグレードできます。それまでは、24.04 のサーバーに新しいリリースが表示されません。これは意図された動作です。Ubuntu 26.04 LTS (Resolute Raccoon) は 2026 年 4 月 23 日にリリースされましたが、Canonical が LTS から LTS へのアップグレード経路を提供するのは最初のポイントリリースからです。最初の数か月に見つかったインストールやアップグレードの不具合が、そのリリースにまとめて修正されるためです。番号の付け方に慣れていない場合は、26.04.1 は別の Ubuntu ではなく、26.04 に 4 か月分の修正をメディアへ統合したものです。そのため、Canonical が既存のサーバーに提供する最初のバージョンになります。

2026 年 8 月上旬に 24.04 のサーバーで確認コマンドを実行すると、次のように表示されます。

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

これはサーバーの障害ではありません。Ubuntu Server では /etc/update-manager/release-upgrades に Prompt=lts が含まれています。つまり、このツールが提示するのは次の long term support リリースだけであり、その .1 ポイントリリースが公開された後に限られます。Prompt=normal に設定すると、24.10、25.04、25.10 の順に進むことになりますが、これらの interim リリースはすべてサポート終了を迎えています。lts のままにして待ってください。Canonical の予定は変更される場合があるため、予定日を過ぎても案内が表示されない場合は、もう一度確認してください。

以下の各コマンドは、指定された順序で、自分のサーバー上から自分で実行します。アップグレード対象のマシン上で、リリースアップグレードを事前に試すことはできません。カーネルと C library が置き換えられ、完了には再起動が必要です。

アップグレードすべきか

Ubuntu 24.04 は 2029 まで標準セキュリティ更新を受けられるため、正常に稼働している本番サーバーに期限があるわけではありません。26.04 に含まれる PHP 8.5、PostgreSQL 18、MySQL 8.4 LTS、OpenSSH 10.2、または 7.0 kernel が必要ならアップグレードします。「番号が上がったから」という理由だけで、顧客向けサービスを提供しているマシンに変更を加えるべきではありません。

次のいずれかに該当する場合は、インプレースアップグレードを行わないでください。

• プロバイダーのコンソール（VNC または serial）を開き、そこからログインしたことが一度もない。SSH が使えなくなった場合、そのコンソールだけがサーバーへ戻る手段です。アクセスできなくなってからコンソールが動作しないと判明しても手遅れです。
• 1 時間の停止時間を許容できず、ロールバック手段もない。
• resolute 用のパッケージをまだ公開していない third-party repository にスタックが依存している。
• 2 年以上前に手作業で構築され、何が入っているのか誰も把握していない。

多くの場合、代替策のほうが適切です。新しい 26.04 VPS を構築し、スタックをインストールしてデータを復元します。その後、正常に応答することを確認してから DNS を切り替えます。新しいサーバーの動作を確認するまで古いサーバーを稼働させられるため、ロールバックは復元ではなく DNS の変更で済みます。この方法を選ぶ場合は、新しい VPS で最初の 10 分間に行う作業から始め、新しいサーバーを適切に構築してください。

手順 1: 復元できるバックアップを取得する

障害の発生の仕方が異なるため、2 層構成にします。プロバイダーのスナップショットはディスク全体を対象とし、数分で復元できます。ただし、データベースが書き込み中に取得されるため、アプリケーション整合性ではなくクラッシュ整合性の状態です。サーバー外部に保存した restic によるファイルレベルのバックアップなら、個別のファイルを取得でき、アカウントがロックされても残るコピーを確保できます。

まず、データベースを手動でダンプします。データベースを停止せずに信頼できるバックアップを取得するには、ダンプが唯一の方法です。

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction は InnoDB テーブルに対してのみ整合性のあるダンプを作成します。MyISAM テーブルではデータベースを停止する必要があります。/etc の tarball は、アップグレードで確認を求められるすべての設定ファイルが含まれているため、実際に使用することになります。

復元したことのないバックアップは、推測にすぎません。必要に迫られる前に、今のうちにその中からファイルを 1 つ取り出してください。

Step 2: 24.04 を最初に完全更新する

do-release-upgrade はパッケージ状態が壊れているシステムでは実行できません。また、24.04 の更新が途中までしか適用されていないと、その後に発生する失敗の原因を特定しにくくなります。

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

dpkg --audit の出力が空なら、設定途中のパッケージはありません。apt-mark showhold の出力が空なら、アップグレードを妨げるバージョン固定もありません。出力されたパッケージは、パッケージ名を指定して sudo apt-mark unhold で固定を解除してください。ただし、その固定に理由がある場合は解除せず、ここで作業を中止してください。

カーネルが変更された場合は再起動してください。実行中だと認識されているコードを実際に実行している状態でアップグレードします。

[ -f /var/run/reboot-required ] && sudo reboot

次に、ディスク容量を確認します。アップグレーダーは、インストールを開始する前に新しいパッケージ一式をすべてダウンロードします。空き容量が不足すると、対象のファイルシステム名を示すメッセージを出して中止します。

df -h / /boot

/ の空き容量が約 5 GB 未満になると、この問題が発生しやすくなります。/boot が 300 MB 未満の場合は、カーネルのインストール中に No space left on device が発生して失敗します。通常は古いカーネルが原因で、sudo apt --purge autoremove で削除できます。

開始前に、もう 1 つ停止するものがあります。自動セキュリティ更新が実行中に開始すると、dpkg のロックを保持します。その場合、リリースアップグレーダーは Could not get lock /var/lib/dpkg/lock-frontend で停止します。先に sudo systemctl stop unattended-upgrades を実行し、完了してから再度開始してください。

ステップ 3: サードパーティーリポジトリと固定されたパッケージを確認する

do-release-upgradeは、Ubuntu のものではないすべての apt ソースを無効にします。noble向けにビルドされたパッケージは、resoluteのシステムで問題を起こす可能性があるためです。認識したソースは後で再び有効にし、それ以外はコメントアウトしたままにします。ツールに任せる前に、現在組み込まれているものを把握してください。

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04では、そのディレクトリに2種類の形式があります。従来の1行形式の.listファイルと、Types:フィールドおよびSuites:フィールドを持つ deb822 形式の.sourcesファイルです。アップグレードでは、どちらも無効になります。ubuntu-security-status --thirdpartyには、Ubuntu のアーカイブが提供していないインストール済みパッケージが一覧表示されます。これは、追加したパッケージの実数を把握するための正確な一覧です。/etc/apt/preferences.d/に含まれるものはすべて pin です。noble向けに記述された pin は、新しいリリースでも古いパッケージを選び続けます。

各サードパーティーリポジトリについて、作業を開始する前に、ベンダーが新しいコードネーム向けのリポジトリを公開していることを確認してください。Docker の suite はhttps://download.docker.com/linux/ubuntu/dists/に一覧表示されています。他のベンダーも同じディレクトリを公開しています。存在しない suite を指すソースは、アップグレード後に最初のapt updateを実行した際、次のエラーを出します。

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

ベンダーが公開するまで、そのソースは無効にしておきます。ベンダーがビルドしていないコードネームに書き換えると、誤ったシステムライブラリにリンクされたパッケージをインストールすることになります。

手順 4: 通常の SSH シェルではなく tmux でアップグレードを実行する

通常のログインシェルで do-release-upgrade の実行中に接続が切れると、プロセスは SIGHUP を受け取り、展開の途中で終了します。その結果、dpkg が不完全な状態になり、再接続に必要なネットワークスタックが動作しなくなる場合があります。代わりにターミナルマルチプレクサ内で実行してください。クライアントとの接続が切れても、プロセスはサーバー上で実行を続けます。

sudo apt install -y tmux
tmux new -s upgrade

そのセッション内で、次を実行します。

sudo ufw allow 1022/tcp
sudo do-release-upgrade

アップグレードプログラムは、変更を加える前に port 1022 で 2 つ目の SSH デーモンを起動し、そのことを表示します。

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

ファイアウォールでその port を開くことはありません。許可なくファイアウォールに穴を開けると、予期しない問題になるためです。開始前に自分で 1022 を開き、sudo ufw delete allow 1022/tcp が完了したら閉じてください。プロバイダーが、サーバーの外部にあるコントロールパネルでもう 1 つのファイアウォールを運用している場合があることにも注意してください。

接続がそれでも切れた場合は、再度ログインして tmux attach -t upgrade を実行します。離れている間もアップグレードは実行されていました。アップグレードが続行されず、dpkg の設定が中途半端な状態になっていたり、apt の sources が noble と resolute の混在状態になっていたりした場合は、失敗したリリースアップグレードから復旧する方法でパッケージの状態を修復する手順と、修復を中止して代わりにスナップショットを復元すべきタイミングを説明しています。

手順 5: 設定ファイルのプロンプトには慎重に回答する

dpkg がプロンプトを表示するのは、ユーザーまたはスクリプトが変更したファイルだけです。したがって、各プロンプトは意図的に編集したファイルを示しています。プロンプトを消すために Enter を押すと、強化済みのサーバーが気付かないうちにデフォルト構成へ戻ります。

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

毎回、最初に D を押します。変更内容を確認してから、N で自分のバージョンを保持します。デフォルトはすでに N であり、安全な選択です。現在のファイルは実際に動作しており、パッケージ側のファイルはこのマシンで実行されたことがないためです。

自分のファイルを保持すると、新しいデフォルト設定は適用されません。サーバーが起動し、時間に追われていない状態になってから、後で差分を統合します。

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

一覧に表示される各ファイルは、メンテナー側のバージョンです。これは自分のファイルの隣に保存されています。1 つずつ差分を確認し、必要な設定を取り込みます。特に注意すべきものは 2 つあります。/etc/ssh/sshd_config は、誤った選択をするとセッションが終了するためです。Web サーバーの設定は、誤った選択をするとサイトが停止するためです。

アップグレードでは、needrestart を使用して再起動するサービスも尋ねられます。すべてのサービスを再起動する選択を受け入れます。ディスクから削除された共有ライブラリファイルを使い続けているデーモンは、後で監視していないタイミングに別のリクエストを処理した際、クラッシュする可能性があります。

手順 6: 再起動してマシンを確認する

sudo reboot

再起動して戻ってきたら、次を確認します。

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a は Release: 26.04 と Codename: resolute を報告するはずです。uname -r には 7.0 カーネルが表示されるはずです。systemctl --failed にはユニットが 0 件と表示されるはずです。何か表示された場合は、それが次に対応すべき作業です。最後の apt update で、リリースイメージの作成後に公開された更新を取得します。

PostgreSQL 16 から 18 へ: ひっそり取り残されるクラスター

Ubuntu 24.04 には PostgreSQL 16 が付属し、26.04 には PostgreSQL 18 が付属します。アップグレードでは 18 が 16 と並行してインストールされますが、データは移行されません。Debian の postgresql-common 層は、新しいメジャーバージョン用に空のクラスターを次に空いているポートで作成します。そのため、16 はすべてのデータを保持したまま 5432 番ポートを使い、18 は 5433 番ポートで空の状態になります。アプリケーションは引き続き 5432 番ポートへ接続するため、問題がないように見えます。数か月後にこの問題に気付く人が多いのはそのためです。

pg_lsclusters

クラスターが 2 つ表示される場合、移行は完了していません。アプリケーションを停止できるタイミングで移行してください。

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

まず空の 18 クラスターを削除します。pg_upgradecluster は、移行先クラスターがすでに存在するとそこへ書き込めないためです。デフォルトの方式では、16 のデータをダンプして 18 に再読み込みします。そのため、データベースとほぼ同じ容量の空きディスク領域が必要です。-m upgrade は代わりに pg_upgrade を使用するため、大規模なデータベースでははるかに高速です。完了したら Port 列を確認します。新しいクラスターが 5432 番ポートを引き継ぎ、古いクラスターは停止した状態になります。新しく読み込んだクラスターには統計情報がないため、最初のクエリが遅くなります。自分で analyze 処理を実行してください。

数日間、新しいクラスターに対してアプリケーションをテストします。その後で古いクラスターを削除します。

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

古いクラスターのデータディレクトリは、最も迅速にロールバックできる手段です。アップグレード当日に削除しないでください。

MySQL 8.0 から 8.4 へ: 削除されたオプションでサーバーが停止する場合

26.04 では MySQL が 8.0 から 8.4 LTS に更新されます。このとき、2 つの変更によってサーバーが起動しなくなることがあります。

1 つ目は、設定に新しいバージョンで削除されたオプションが含まれていると、mysqld が起動を拒否することです。古いガイドの多くで設定が推奨されているため、default_authentication_plugin がよくある原因です。サービスは失敗し、journalctl -u mysql -n 50 に未知の変数が直接示されます。/etc/mysql/mysql.conf.d/ 配下のファイルからその行を削除し、その後 sudo systemctl start mysql を実行します。

2 つ目は、mysql_native_password プラグインが 8.4 ではデフォルトで有効にならないことです。このプラグインを引き続き使用しているアカウントは、まったくログインできません。8.0 のまま、次のコマンドで確認します。

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

mysql_native_password と表示されたアカウントをすべてアップグレード前に移行し、アプリケーション設定のパスワードを更新します。

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

クライアントライブラリが古すぎて caching_sha2_password に対応できない場合は、[mysqld] 配下に mysql_native_password=ON を追加すると、8.4 で古いプラグインを再度有効にできます。ただし、これは期限を定めた暫定措置として扱ってください。このプラグインは完全に廃止される予定です。

PHP 8.3 から 8.5 へ: vhost が消えたソケットを参照しています

24.04 には PHP 8.3 が含まれ、26.04 には PHP 8.5 が含まれます。パッケージはバージョン付きのパスにインストールされ、Web サーバーの設定は書き換えられません。fastcgi_pass unix:/run/php/php8.3-fpm.sock; を保持する nginx の vhost は、どのプロセスも作成しないソケットを参照するため、すべての PHP リクエストが 502 を返し、nginx のエラーログには次のように記録されます。

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

新しいソケットを参照するように変更し、設定をテストしてから reload します。

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

mod_php を使用する Apache では症状が異なります。Apache 自体が起動せず、sudo apache2ctl -t はファイルが存在しないため libphp8.3.so を読み込めないと報告します。有効化されたモジュールは、すでに削除されたパッケージへのシンボリックリンクです。

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Ubuntu 24.04 で LAMP スタックを構築してサーバーをセットアップした場合は、これら 2 つのパスを確認してください。このガイドでは、バージョン付きのモジュール名とバージョン付きのソケットが設定されるためです。

php.ini のチューニングも引き継がれません。memory_limit、upload_max_filesize、その他に設定した項目は /etc/php/8.3/ に保存され、新しいツリーはデフォルト値から始まります。2 つのファイルを diff で比較し、値を手動で移行してください。古いファイル全体を新しいファイルに上書きすると、8.3 のデフォルト値が 8.5 のインストールに持ち込まれます。続いて php -m を実行して比較します。php8.3-redis としてインストールされた拡張機能には php8.5- パッケージが必要です。PPA から導入した拡張機能の場合、アップグレーダーがそのソースを無効化しているため、拡張機能自体が不足していることがあります。

証明書については、別途 1 つ確認してください。アップグレード後に sudo certbot renew --dry-run を実行します。これは有効な証明書に変更を加えず、Web サーバーの reload hook を含む更新処理全体を実行します。サービス名や変更されたバイナリを呼び出す hook に問題があれば、60 日後に静かに失敗するのではなく、この場で確認できます。nginx で Certbot と Let's Encrypt を使用するでは、これらの hook の設定例を説明しています。

SSH: 作業中のセッションを終了させる障害

sshd_config プロンプトは、SSH から締め出される原因になります。Y と答えると、メンテナーが用意したファイルがインストールされ、既存の PermitRootLogin、PasswordAuthentication、AllowUsers、Port と、追加した他のすべての行が破棄されます。ファイアウォールがカスタムポートだけを許可し、パッケージの設定が 22 で待ち受ける場合、次の接続は拒否されます。現在使用しているセッションが、最後に残った接続になります。

アップグレードの前に対策してください。24.04 の /etc/ssh/sshd_config は Include /etc/ssh/sshd_config.d/*.conf から始まります。OpenSSH は各設定について、最初に読み込んだ値を使用します。そのため、先頭で読み込まれる drop-in に設定を置くと、後続の設定より優先されます。dpkg が所有しないファイルに設定を移します。

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

/etc/ssh/sshd_config に自分の設定が残っていなければ、このプロンプトは問題になりません。どちらを選んでも設定は維持されます。設定が別のファイルに保存されているためです。

カスタムポートを使用する場合は、想定した場所に設定されていない可能性があるため、もう 1 つ確認が必要です。

systemctl is-enabled ssh.socket

これが enabled と表示された場合、待ち受けポートは systemd が管理しています。そのため、sshd_config 内の Port 行は無視されます。Ubuntu は 22.10 以降、sshd で socket activation を使用しています。Port 2222 を編集しても何も変わらないのは、このためです。sudo systemctl edit ssh.socket を使って、socket unit 側に設定します。

[Socket]
ListenStream=
ListenStream=2222

空の ListenStream= は必須です。継承した値を消去します。これがないと、socket は 2222 だけでなく 22 でも待ち受けます。sudo systemctl daemon-reload && sudo systemctl restart ssh.socket で設定を適用します。

アップグレード後、現在のセッションを閉じる前に、次を実行します。

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

次に、自分のマシンで 2 つ目の端末を開き、再度ログインします。2 つ目の端末でシェルを使用できることだけが、接続が正常であることの証明になります。確認できるまで、最初のセッションを開いたままにしてください。VPS 上の SSH を強化するでは、この drop-in に残す価値のある設定を説明しています。

すでに手遅れの場合は、プロバイダーの Web コンソールを使用してください。SSH を使わずにログインできます。そこでログインし、設定を修正して sudo sshd -t を実行し、サービスを再起動します。アップグレード中ではなく、アップグレード前にコンソールへアクセスできることを確認するのは、このコンソールがあるためです。

FAQ

Ubuntu 24.04 で do-release-upgrade が「新しいリリースが見つかりません」と表示するのはなぜですか？

Ubuntu Server では /etc/update-manager/release-upgrades に Prompt=lts が設定されているためです。この設定では、次の長期サポートリリースが最初のポイントリリースとして公開された後にのみ提示されます。Ubuntu 26.04 LTS は 23 April 2026 にリリースされ、26.04.1 は 27 August 2026 に予定されています。その日までは、24.04 サーバーに新しいリリースは表示されません。設定は変更せず、Prompt=normal には切り替えないでください。切り替えると、代わりに中間リリースを経由することになります。

アップグレードを完了するには、サーバーを再起動する必要がありますか？

はい。アップグレードでは新しい kernel、新しい C library、新しい init system がインストールされますが、稼働中のシステムは再起動するまで古いものを使い続けます。do-release-upgrade は最後に再起動を求めます。「後で」と考えて稼働を続けると、2 つのリリースが混在した状態になります。再起動後は、uname -r で新しい kernel を確認し、systemctl --failed で起動しなかったサービスを確認してください。

インプレースでアップグレードすべきですか。それとも新しい 26.04 サーバーを構築すべきですか？

可能であれば、新しいサーバーを構築してください。新しい VPS なら、古いサーバーが引き続きネットワークトラフィックを処理している間に、ソフトウェア構成をインストールし、データを復元して、すべてをテストできます。そのため、ロールバックはバックアップからの復元ではなく DNS の変更で済みます。サーバーに移行が難しい状態を保持している場合、プロバイダーがマシン単位で課金する場合、または snapshot と実績のある console access がある場合は、インプレースアップグレードを選択します。インプレースの手順は確立されていますが、実行中の 1 時間は後戻りできません。

アップグレード中に SSH 接続が切れた場合はどうなりますか？

通常の login shell では、プロセスが SIGHUP を受け取って途中で終了し、dpkg が未設定の状態で残ります。tmux または screen の内部で開始すればプロセスが存続するため、再接続して tmux attach -t upgrade を実行すれば処理を再開できます。アップグレーダーは、別の接続経路として port 1022 で予備の SSH daemon も起動します。ただし、この port に対して firewall の許可は設定しないため、先に 1022 を自分で許可し、終了後に閉じてください。

アップグレード後に PHP サイトが 502 を返します。何が壊れたのでしょうか？

バージョン変更に伴い、PHP FPM の socket path が変わりました。Ubuntu 24.04 は PHP 8.3、26.04 は PHP 8.5 を使用するため、/run/php/php8.3-fpm.sock は存在しなくなりましたが、nginx の vhost では引き続きその path が指定されています。nginx の error log には connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) と表示されます。fastcgi_pass を 8.5 の socket に更新し、sudo nginx -t を実行してから nginx を reload してください。mod_php を使用する Apache では、同等の修正として sudo a2dismod php8.3 を実行し、その後 sudo a2enmod php8.5 と restart を実行します。