do-release-upgradeで新しいリリースが見つからない場合

「do-release-upgrade が新しいリリースを見つけられない」と表示される理由

do-release-upgradeで終わるNo new release found.は、ほとんどの場合、ツール自体の故障ではありません。その時点で要求した移行経路が閉じており、ツールがそれを可能な限り簡潔に報告しています。移行経路を閉じる原因は、/etc/update-manager/release-upgradesにあるPrompt設定、LTS（長期サポート）アップグレードにおけるポイントリリースの制限、サードパーティーリポジトリ、hold されたパッケージまたは設定が完了していないパッケージ、そしてサポート終了後のリリースの5つです。

この順番で確認してください。それぞれについて、サーバーに該当するかどうかを確認できるコマンドがあります。5つのうちどれが原因かを推測する必要はありません。

チェック専用フラグが実際に報告する内容

sudo do-release-upgrade -c
echo $?

-c はチェック専用です。HTTPS（hypertext transfer protocol secure）経由で Canonical のリリースメタデータを読み取り、結果を表示します。アップグレードツールはダウンロードせず、source ファイルも書き換えません。重要な出力は2つあります。

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

終了コードにも、スクリプトで利用できる同じ結果が含まれます。リリースが利用可能な場合は 0、利用できない場合は 1 です。通常の shell の規約とは逆なので、この結果を使ってチェック処理を作成する前に注意して読み取ってください。

ログインバナーに古い結果が表示される場合、その結果はキャッシュされています。この行は /etc/update-motd.d/91-release-upgrade によるもので、ネットワークに問い合わせず、保存済みの結果を表示します。sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd で更新するか、単に -c の結果を信頼してください。バナーに表示されるのは、最後に実行されたチェックの結果だけです。

このチェックでは changelogs.ubuntu.com に到達できる必要もあります。厳格な送信方向ファイアウォールの背後にあるサーバーや、ツールが問い合わせできないプロキシ環境では、リリースを検出できません。

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

HTTP/2 200 の行は、サーバーがメタデータを参照できることを示します。curl: (28) Connection timed out は、実際の原因が送信方向のルールにあることを示します。APT（advanced package tool）のファイルをいくら編集しても、結果は変わりません。

コマンド自体が存在しない場合は、ubuntu-release-upgrader-core に含まれています。最小構成のクラウドイメージでは、このパッケージが省かれていることがあります。

sudo apt install ubuntu-release-upgrader-core

/etc/update-manager/release-upgrades を変更する前に確認する

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

このファイルには、コメントとして説明が記載されています。有効な値は3つです。

• never: 新しいリリースへのアップグレードを確認せず、許可もしません。
• normal: 実行中のリリースの直後にある、サポート対象のリリースを提示します。
• lts: 実行中のリリースの後にある、最初の LTS リリースを提示します。

Prompt=never は、3つの中で最も簡単に原因を特定できます。ツールの出力に、ファイルと設定の両方が明示されるためです。

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

ホスティングプロバイダーや構成管理ツールは、リリース間でサーバー群の状態がばらつかないように、never を意図的に設定します。そこにこの値があるなら、誰かが選択した設定です。長期サポート対象のリリースを使用するサーバーでは lts に変更してください。自動化処理が元の値を想定している場合は、作業後に元へ戻してください。

コメントにある注意点の1つが、問題を引き起こしやすい箇所です。Prompt=lts が設定されていて、実行中のリリース自体が LTS リリースでない場合、アップグレードツールはその設定を normal として扱います。25.10 のマシンでは、この2つの値は同じ動作になります。24.04 のマシンでは異なり、その違いが次のセクションの主題です。

LTS から LTS へのアップグレードが最初のポイントリリースまで待機する理由

Prompt により、アップグレードツールが読み取るメタデータファイルが決まります。アドレスは /etc/update-manager/meta-release にあります。

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts は meta-release-lts を読み取ります。Prompt=normal は meta-release を読み取ります。どちらのファイルも、各リリースを少数のキーからなるブロックで記述しています。アップグレードツールは、Supported: フラグが 1 の場合にだけ、そのリリースを提示します。同じサーバーから、実際に確認できます。

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

2026 年 8 月 13 日に確認したところ、2 つのファイルでは Ubuntu 26.04 の扱いが異なっていました。LTS ファイルには次のように記載されています。

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

通常のファイルには次のように記載されています。

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

LTS ファイルの Supported: 0 が判定条件です。デフォルトの Prompt=lts を使用している 24.04 サーバーは、そのファイルを読み取り、新しい LTS リリースのうち利用可能とマークされたものがないため、No new release found. と表示します。マシンに問題があるわけではありません。Canonical がまだアップグレード経路を開いていないだけです。

最初のポイントリリースがリリースされると、フラグは 1 に変わります。Ubuntu 26.04.1 は 2026 年 8 月 27 日に予定されていますが、リリーススケジュールは変更される可能性があります。そのため、カレンダーではなくメタデータを確認してください。この遅延は意図的なものです。早期にアップグレードする利用者が問題を見つけ、それらを修正してから、はるかに多くの LTS サーバーが追随します。

選択肢は2つです。ポイントリリースを待つ方法があり、停止や監視を避けたいサーバーではこれが適切です。もう1つは Prompt=normal を設定する方法です。これにより、同じツールが meta-release を参照し、そこでは 26.04 がすでにサポート対象としてマークされています。この方法でアップグレードされるのはリリース済みの 26.04 であり、開発版ではありません。そのため、スナップショットから復元できるマシンであれば、合理的な選択肢になります。完了したら、値を lts に戻してください。手順の詳細は、24.04 から 26.04 へのサーバーアップグレード完全ガイド に記載されています。

アップグレードを妨げるサードパーティリポジトリと PPA

アップグレーダーは、APT のソースを新しいリリース用に書き換えます。新しいリリース向けに公開されているリポジトリだけが対象になるため、それ以外のエントリはコメントアウトされます。理由はエントリごとに 1 行ずつ表示され、was disabled (unknown mirror)、was disabled (unknown dist)、was disabled (no Release file) のように具体的に示されます。

noble 用に作成された PPA（個人パッケージアーカイブ）には、サーバー上に resolute 用のディレクトリがありません。そのため、アップグレーダーは新しいシリーズ用の Release ファイルを取得できず、エントリを無効にします。通常は、これを警告として受け入れられます。新しいリリースにも含まれるパッケージをサードパーティリポジトリが提供している場合は、処理が停止します。アップグレードの計算時に候補が 2 つ存在し、両方を満たす方法がなくなるためです。

長時間の無人実行中にツールへ判断させるのではなく、開始前に自分で判断してください。

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

パッケージ名に対して apt policy を実行すると、インストール済みの各バージョンがどのリポジトリ由来かを表示できます。これにより、無効にしようとしているソースに依存するパッケージを正確に確認できます。ソースを削除しても、パッケージはダウングレードされません。そのため、PPA からインストールしたパッケージは PPA のバージョンのままになり、新しいリリースに含まれるバージョンより新しい場合もあります。必要に応じて、そのパッケージも削除し、アップグレード後にアーカイブから再インストールしてください。Tailscale のように再度有効にする予定のリポジトリでは、パッケージを再びインストールできるように、新しいリリースのコードネームへ更新する必要があります。Ubuntu で発生する Tailscale のインストールエラーの多くは、これが原因です。

逆の選択をするためのフラグもあります。マニュアルページでは --allow-third-party を「コメントアウトせず、サードパーティミラーとリポジトリを有効にしたままアップグレードを試行する」と説明しています。このフラグは、対象のリリース向けにリポジトリがすでに公開されていることを確認した場合だけ使用してください。公開されていない場合、リポジトリが一度もビルドしていないシリーズを対象に、APT へ依存関係グラフの解決を要求することになります。

Ubuntu 24.04 以降では、ほとんどのソースが deb822 形式の /etc/apt/sources.list.d/ubuntu.sources にあります。同じリポジトリを旧形式と新形式の両方で記述すると、固有のメッセージが表示される別のエラーになります。詳しくは、deb822 形式で発生する重複ソースエントリのエラーを参照してください。

保留中および未設定のパッケージが計算を停止させます

リリースアップグレードでは、システム上のほぼすべてのパッケージを移行する必要があります。1 つでも移行できないパッケージがあると計算に失敗します。アップグレーダーは、途中まで進めて不完全な状態を残すよりも、早い段階で停止します。原因を特定するには、2 つのコマンドを使用します。

apt-mark showhold
sudo dpkg --audit

apt-mark showhold は、保留中のパッケージを 1 行に 1 つずつ表示します。問題のないシステムでは何も表示しません。保留は、そのパッケージを変更しないよう手動で指定する設定です。誰かがカーネルやデータベースのバージョンを固定し、そのまま忘れている可能性があります。不要になった保留は、パッケージ名に続けて sudo apt-mark unhold を実行して解除します。

dpkg --audit は、展開されたものの設定されていないパッケージを一覧表示します。この状態は、インストールが中断された場合に発生します。多くの場合、セッションの切断が原因です。アップグレーダーは修復を試み、dpkg interrupted, calling dpkg --configure -a を表示します。ただし、先に自分で修復を実行すれば、流れていくメッセージを追うのではなく、エラーを確認できます。ツールで修復できないパッケージがあると Package in inconsistent state というメッセージが表示されます。この場合は、再試行する前に対処が必要です。

アップグレードする前に、実行中のリリースを完全に最新の状態にしてください。

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

段階的更新のオプションは、見た目以上に重要です。Ubuntu では、一部の更新を一度に全マシンへ配布せず、一定割合のマシンへ段階的に展開します。そのため、通常の apt upgrade ではパッケージが残ることがあり、サーバーが実際には想定より古い状態になります。このオプションを指定すると、すべての更新を適用します。更新にカーネルが含まれていた場合は、その後に再起動してください。実際に実行中のカーネルからアップグレードできるためです。unattended security upgrades によって常にパッチが適用されているサーバーでは、ここでの作業は少なくて済みます。ただし、この仕組みは設計上、リリース境界を越えて更新することはありません。

標準サポート期間を過ぎたリリースの場合

Ubuntu の中間リリースは 9 か月間サポートされます。サポートが終了すると、その Supported: フラグは 0 になり、通常の手順ではアップグレードできません。2026 年 8 月 13 日に確認したところ、meta-release には 25.10 について次のように記載されています。

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

この時点でアーカイブも移動します。サポート終了済みリリースのパッケージは archive.ubuntu.com から削除され、old-releases.ubuntu.com に保存されます。そのため apt update は 404 Not Found を返すようになり、システムを最新の状態に更新できなくなります。アップグレーダーはシステムが最新であることを要求するため、処理は先に進みません。まずパッケージソースを修正してください。

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

archive.ubuntu.com と security.ubuntu.com の両方を old-releases.ubuntu.com に変更し、コードネームはそのままにします。変更するのはホスト名だけです。

sudo sed -i.bak -e 's/archive.ubuntu.com/old-releases.ubuntu.com/g' \
                -e 's/security.ubuntu.com/old-releases.ubuntu.com/g' \
                /etc/apt/sources.list.d/ubuntu.sources
sudo apt update

サーバーがまだ単一のファイルにパッケージソースを保持している場合は、代わりに /etc/apt/sources.list に対して同じコマンドを実行します。-i.bak オプションを指定すると、元のファイルと同じ場所にバックアップが作成されるため、誤ったファイルを編集した場合に元へ戻せます。その後に apt update が正常に完了すれば、アーカイブへ再びアクセスできます。do-release-upgrade も応答するようになります。

この方法でどこまで復旧できるかは、現実的に判断してください。Ubuntu は一度に 1 リリースずつしかアップグレードできません。そのため、2 つまたは 3 つ前のサポート終了済みリリースを使っているサーバーでは、各リリースを順番に経由する必要があります。また、各段階で個別のサードパーティーリポジトリや保留パッケージが原因となり、失敗する可能性があります。VPS では、現在の LTS で新しいサーバーを構築し、サービスを移行して、問題がないことを確認するまで古いサーバーを残すほうが速い場合があります。この方法ならロールバックもできます。インプレースアップグレードではロールバックできません。移行後にどのリリース系列を使うか決める場合は、サーバーにおける LTS リリースと中間リリースの違いを読んでから判断するとよいでしょう。

開発リリースフラグの実際の動作

-d または --devel-release を指定すると、アップグレーダーは Prompt が選択したファイルではなく、meta-release-development を読み取ります。マニュアルページでは、「サポート対象の最新リリースを使用している場合は、開発リリースにアップグレードする」と説明されています。

2026 年 8 月 13 日に確認した時点で、そのファイルの最新エントリは 26.04 ではありません。

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

したがって、-d は 24.04 サーバーをリリース済みの 26.04 に移行しません。まだ開発中の 26.10 を目指します。「-d を追加するだけでよい」という以前の案内は、LTS のリリース前の期間を前提に書かれたものです。現在その方法を繰り返すと、意図しないリリースをサーバーに指定することになります。Prompt=lts が残っている場合、このフラグは専用のメッセージを表示して停止します。

There is no development version of an LTS available.

Ubuntu のサーバー向けドキュメントは、このフラグについて明確に説明しています。「開発リリース（または -d フラグ）の使用は、本番環境では推奨されません」。開発リリースは毎日変更され、セキュリティサポートも保証されません。そのため、朝に動作していたパッケージが午後にはサービスを停止させる可能性があります。自分の構成をテストするために用意した使い捨ての仮想マシンで使用してください。誰かが依存するサーバーでは使用しないでください。LTS のゲートが開く前にリリース済みの 26.04 を使用したい場合は、Prompt=normal が正しい方法です。

SSH セッションの切断で中断されない状態でアップグレードを実行する

リリースアップグレードでは、openssh-server や systemd など、システムの大部分が置き換えられます。dpkg の処理中に SSH（secure shell）セッションが切断されると、パッケージが展開済みで未設定の状態のままプロセスが強制終了されます。この状態になると、次の実行も停止します。アップグレードは必ずターミナルマルチプレクサー内で開始してください。

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

接続が切断された場合は、再度ログインして tmux attach -t upgrade を実行します。アップグレードは実行を継続しています。これは SSH セッションではなく、tmux サーバーの子プロセスとして動作しているためです。screen を使用する場合は、screen -S upgrade と screen -r upgrade でも同じことができます。

マルチプレクサーを使用しない場合に備えて、アップグレーダーには独自の安全策があります。SSH 上で実行されていることを検出すると、2 つ目の sshd をポート 1022 で起動するか確認します。メインセッションが切断されても、別の接続経路を残すためです。検出では、親プロセスをたどり、sshd という名前のプロセスを探します。tmux または screen 内では、代わりにマルチプレクサーのサーバーが見つかります。そのため、この確認は表示されず、PID ファイル /var/run/release-upgrader-sshd.pid も追加のデーモンが実際に起動した場合にだけ作成されます。確認が表示されなくても問題ありません。すでに、より適切な保護が有効になっています。

確認を受け入れても、ポートは自動的に開かれません。ポートを開くことはセキュリティ上の判断であり、ツールが代わりに決めることはできないためです。アップグレード中だけポートを開き、完了後に再び閉じてください。

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

多くの VPS プロバイダーは、オペレーティングシステムの外側にある管理パネルでもファイアウォールを実行しています。そこでもポート 1022 を開く必要があります。開いていない場合、フォールバックリスナーは動作していても到達できません。これは最も避けるべき状態です。

コマンドを入力する前に、次の 4 つを準備してください。

• スナップショットまたは完全バックアップを取得します。インプレースのリリースアップグレードには元に戻す操作がなく、取得したバックアップだけが復旧手段になります。
• 必要になる前に、プロバイダーのコンソールを開けることを確認します。再起動後にサーバーが復帰しなければ、SSH は利用できません。起動に失敗するカーネルの問題は別の問題であり、専用の復旧手順があります。カーネル更新後に起動しない VPS
• df -h / /boot で空き容量を確認します。アップグレードではパッケージ一式をダウンロードするため、複数の古いカーネルを保持する /boot パーティションは、処理が停止しやすい場所です。
• 使用しているサービスのリリースノートを確認します。PostgreSQL や PHP のメジャーバージョン更新は、計画していなくてもリリースに含まれて適用されます。

FAQ

Ubuntu 24.04 で do-release-upgrade を実行すると「新しいリリースが見つからない」と表示されるのはなぜですか？

/etc/update-manager/release-upgrades のデフォルトの Prompt=lts により、ツールは https://changelogs.ubuntu.com/meta-release-lts を読み込みます。Ubuntu 26.04 は、最初のポイントリリースが公開されるまで、そのファイルで Supported: 0 を使用します。そのため、アップグレーダーは利用可能とマークされた新しい LTS リリースを見つけられず、停止します。curl -s https://changelogs.ubuntu.com/meta-release-lts でファイルを自分で確認し、最後のブロックを読みます。2026 年 8 月 13 日に確認した時点では、Ubuntu 26.04.1 が 2026 年 8 月 27 日に予定されている状況でも、このフラグは 0 のままでした。

ポイントリリースを待たずに Prompt=normal に設定しても安全ですか？

リリース済みの 26.04 にアップグレードされます。開発版にはなりません。Prompt=normal は meta-release を読み込み、その中で 26.04 にはすでに Supported: 1 が設定されているためです。リスクは実行する時期にあります。初期のアップグレード利用者が見つけた問題が修正される前に実行することになります。スナップショットから復元でき、再起動に失敗した場合もプロバイダーのコンソールへ接続できるサーバーで実行してください。完了後に値を lts に戻します。

-d フラグを使うと 26.04 にアップグレードされますか？

いいえ。-d は meta-release-development を読み込みます。2026 年 8 月 13 日時点での最新エントリは Ubuntu 26.10 で、まだ開発中のリリースでした。Prompt=lts が設定された LTS マシンでは、このフラグにより There is no development version of an LTS available. が表示されて停止します。Ubuntu 公式のサーバー向けドキュメントでも、本番環境には開発版を推奨していません。リリース済みの 26.04 へ早期に移行したい場合は Prompt=normal を使用してください。

古いリリースで apt update を実行すると 404 エラーが返ります。どうアップグレードすればよいですか？

そのリリースはサポート終了を迎えているため、パッケージが archive.ubuntu.com から old-releases.ubuntu.com へ移動されています。/etc/apt/sources.list.d/ubuntu.sources、または古い構成では /etc/apt/sources.list にあるホスト名だけを変更し、コードネームはそのままにします。その後、sudo apt update と sudo apt full-upgrade を実行します。システムが最新の状態に戻ったら、do-release-upgrade でリリースを 1 つずつ進められます。

do-release-upgrade を実行する前に PPA を削除する必要がありますか？

必須ではありません。アップグレーダーは、新しいリリース向けに公開されていないソースをコメントアウトし、それぞれについて was disabled (no Release file) のような行を表示します。ただし、先に自分で無効化するほうが適切です。無効化する順序を選べ、結果も確認できるためです。対象のパッケージについて apt policy を実行すると、それぞれの PPA から導入されたパッケージを確認できます。PPA のバージョンが新しいリリースに含まれるバージョンより新しい場合は、アーカイブから再インストールしてください。