Ubuntu 26.04 LTS「Resolute Raccoon」は 2026 年 4 月 23 日にリリースされました。しかしサーバーが 24.04 LTS で動いている場合、この 4 か月間 do-release-upgrade は「新しいリリースはありません」と答え続けてきたはずです。これは不具合ではありません。Canonical は LTS から LTS へのアップグレード経路をリリース当日ではなく、最初のポイントリリースで開きます。公式スケジュールでは、そのポイントリリース 26.04.1 は 2026 年 8 月 27 日です。
なぜ待つのか
この 4 か月はアップグレード経路そのもののための時間です。26.04 の公開後に見つかった阻害要因——パッケージ依存の衝突、設定ファイル移行の失敗、ドライバの退行——が修正され、26.04.1 のインストールメディアとアップグレーダに取り込まれます。.1 を待つのは慎重さではなく、その経路が実際にテストされた最初の日だからです。
期限も正直に計算しておきましょう。24.04 LTS の標準セキュリティメンテナンスは 2029 年 5 月までなので、急ぐ理由はありません。26.04 LTS は標準メンテナンスが 2031 年 5 月まで、拡張セキュリティメンテナンス（ESM）は 2036 年 5 月までです。22.04 のままなら状況は逆で、標準サポートは 2027 年 4 月に終わり、しかも 26.04 へ直接は上がれません。22.04 から 24.04、次に 24.04 から 26.04 と 2 回分の時間を確保してください。
VPS で重要な 5 点
- 本当に戻せるスナップショットを取る：途中で失敗した場合、マシンごと戻すほうがパッケージを手作業で直すより圧倒的に速いです。スナップショット機能がなければ完全バックアップを取り、復元を検証してください。検証していないバックアップはバックアップではありません。
- SSH の退路を残す：
do-release-upgradeは主接続が切れた場合に備え、ポート 1022 に 2 つ目の sshd を立ち上げます。ファイアウォールとクラウドのセキュリティグループで事前に開放しておかないと、切断された時点で締め出されます。ネットワークの瞬断でプロセスが死なないよう、必ずtmuxかscreenの中で実行します。 - サードパーティのリポジトリを先に処理する：アップグレーダは大半の PPA と外部 apt ソースを無効化しますが、自分で追加した Docker、Node、PHP、データベースのリポジトリは26.04 向けのブランチがあるか事前に確認しておかないと、一部のパッケージが旧リリースに取り残されます。
- メジャーバージョンの飛躍を事前に調べる：LTS を 2 つ跨ぐと PHP、MySQL/MariaDB、Python、Node がメジャー更新される可能性があります。時間課金の使い捨てインスタンスで同じ構成を先にリハーサルし、エラー一覧を把握してから本番に触れてください。
- ピーク時間帯に実施しない：設定ファイルの衝突（ローカル版を残すか、メンテナ版を採用するか）は人間の判断が必要で、特に nginx、sshd、postfix では慎重に。完了後は再起動し、「マシンが上がった」で満足せず各サービスを個別に検証します。
-d オプションはあるが本番では使わない
管理者は do-release-upgrade -d で経路が開く前に強制アップグレードできます。これはテスト用の手段で、Canonical は本番システムには推奨していません。どのみち 8 月 27 日に通常の経路が開くのですから、危険を冒す理由はほとんどありません。
アップグレードを訓練として扱う
LTS 間のアップグレードは 2 年に 1 度で、その希少さこそが初回の失敗を招きます。合理的な方法は、まず安価な小型インスタンスで一通り実行することです。同じ構成、同じコマンド、人間の判断が必要だった箇所をすべてメモし、その後で本番に繰り返します。SharkCloud は日本、シンガポール、香港、米国にノードがあり、リハーサル用の一時インスタンスの費用は、本番機がアップグレード途中で止まる代償よりはるかに安く済みます。