Ubuntu 24.04から26.04へVPSを安全にアップグレード

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

Ubuntu 24.04 の VPS は、26.04.1 のポイントリリースがリリースされた後に 26.04 へアップグレードできます。リリース予定日は 27 August 2026 です。それまでは、24.04 のサーバーに新しいリリースが表示されません。これは意図された動作です。Ubuntu 26.04 LTS (Resolute Raccoon) は 23 April 2026 にリリースされましたが、Canonical が LTS から LTS へのアップグレード経路を有効にするのは、最初のポイントリリースの時点です。最初の数か月に見つかったインストールおよびアップグレードの不具合が、このリリースにまとめて修正されるためです。

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 の順に案内されますが、これらはすべてサポート終了済みの中間リリースです。lts のままにして待ってください。Canonical のスケジュールは変更される可能性があるため、予定日を過ぎても表示されない場合は再度確認してください。

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

アップグレードすべきか

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 用のパッケージをまだ公開していないサードパーティーリポジトリに、スタックが依存している場合。
• 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 つのファイルを取り出して確認してください。

ステップ 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: サードパーティーリポジトリと pin 留めされたパッケージを確認する

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 があると、新しいリリースでも古いパッケージが選択され続けます。

各サードパーティーリポジトリについて、開始前にベンダーが新しい codename 用のリポジトリを公開していることを確認してください。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.

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

手順 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 daemon を起動します。そのことも表示します。

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 が完了したら閉じてください。プロバイダーがサーバーの外部にある control panel で、別のファイアウォールも実行している場合があります。

それでも接続が切れた場合は、再度ログインして tmux attach -t upgrade を実行してください。接続が切れている間も、アップグレードは実行され続けています。

ステップ 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 stack を使ってサーバーを構築した場合は、これら 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 で Let's Encrypt を使用する Certbot では、これらの hook の適切な設定例を説明しています。

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

sshd_config プロンプトで、ログインできなくなる事故が発生します。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 でソケットアクティベーションを使用しています。Port 2222 を編集しても反映されないのはこのためです。sudo systemctl edit ssh.socket を使い、ソケットユニットに設定してください。

[Socket]
ListenStream=
ListenStream=2222

空の ListenStream= は必須です。継承された値をクリアします。これがないと、ソケットは 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 が設定されているためです。この設定では、次の long term support release が最初の point release の公開後にのみ提示されます。Ubuntu 26.04 LTS は 23 April 2026 にリリースされ、26.04.1 は 27 August 2026 に予定されています。その日までは、24.04 のサーバーに新しいリリースは表示されません。設定は変更せず、Prompt=normal には切り替えないでください。切り替えると、代わりに interim release を経由することになります。

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

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

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

可能なら、新しいサーバーを構築してください。新しい VPS なら、古いサーバーが引き続き traffic を処理している間に stack をインストールし、data を復元して、すべてをテストできます。そのため、rollback は backup からの復元ではなく DNS の変更で行えます。サーバーに移行が難しい state が保存されている場合、provider が machine 単位で課金する場合、または snapshot と実績のある console access がある場合は、その場でアップグレードします。その場でのアップグレードは一般的な手順ですが、実行中の 1 時間は一方向の変更になります。

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

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

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

PHP FPM の socket path が version によって変更されたためです。Ubuntu 24.04 は PHP 8.3、26.04 は PHP 8.5 を使用するため、nginx の vhost が指定している /run/php/php8.3-fpm.sock は存在しなくなっています。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 してください。Apache で mod_php を使用している場合は、同等の修正として sudo a2dismod php8.3 を実行し、その後 sudo a2enmod php8.5 と restart を実行します。