ガイド

著者 Matt Connor 2026-08-13 ・更新日 2026-10-02

do-release-upgradeでNo new release foundと出る原因と対処法

Q: Ubuntu 24.04 で do-release-upgrade を実行しても新しいリリースが見つからないのはなぜですか？

Prompt=lts のデフォルト設定が /etc/update-manager/release-upgrades にあるため、ツールは 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日時点で確認したところ、フラグは依然として 0 であり、Ubuntu 26.04.1 は 2026年8月27日に予定されていました。

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

これは開発ビルドではなく、リリース済みの 26.04 へアップグレードされます。なぜなら Prompt=normal が meta-release を読み込み、そこでは 26.04 がすでに Supported: 1 となっているからです。リスクはタイミングにあります。早期アップグレードユーザーによって発見された問題が修正される前に実行することになるためです。スナップショットから復元可能で、再起動に失敗してもプロバイダーのコンソールにアクセスできるサーバーで実行してください。実行後は値を lts に戻してください。

Q: -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 を使用してください。

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

そのリリースはサポート終了（EOL）を迎えたため、パッケージが 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 つずつリリースを更新できます。

UbuntuのアップグレードでNo new release foundと表示される原因を解説します。Prompt設定やLTSの制限、サードパーティ製リポジトリ、保留パッケージなど、エラーを解決するための確認手順をコマンド付きで具体的に紹介します。

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

do-release-upgrade が No new release found. で終了する場合、ツールが壊れていることはほとんどありません。指定したパスがその時点で閉じられているため、ツールが可能な限り簡潔に報告している状態です。これを閉ざす要因は5つあります。/etc/update-manager/release-upgrades 内の Prompt 設定、LTS（長期サポート）アップグレードにおけるポイントリリースの制限、サードパーティ製リポジトリ、保留中または設定が不完全なパッケージ、そしてサポート期間が終了したリリースです。

この順序で確認してください。各項目には、それがサーバーに該当するかを証明するコマンドがあるため、どれが原因かを推測する必要はありません。

check-only フラグが実際に報告する内容

sudo do-release-upgrade -c
echo $?

-c はチェック専用のフラグです。HTTPS (hypertext transfer protocol secure) 経由で Canonical のリリース用メタデータを読み取り、結果を表示します。アップグレードツールのダウンロードやソースファイルの書き換えは一切行いません。以下の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 となります。これは一般的なシェル規約とは逆の挙動であるため、チェック処理を構築する際は注意してください。

ログインバナーに古い結果が表示される場合は、キャッシュが原因です。その行は sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd を実行した際に保存された結果を表示する /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 のマシンでは両方の値は同一の挙動を示しますが、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日に予定されていますが、リリーススケジュールは変更される可能性があるため、カレンダーではなくメタデータを確認してください。ポイントリリースは Ubuntu の新しいバージョンではなく、リリース以降のすべてのアップデートを統合したインストールメディアに過ぎません。そのため、稼働中のサーバーにとって重要なのはメディアそのものではなく、それが開くゲートです。この遅延は意図的なものです。早期にアップグレードを行うユーザーが障害を見つけ、より多くの LTS サーバーが追随する前にそれらが修正されるためです。もしこれを読んでいる時点でその日付を過ぎている場合は、26.04.1 の内容と 24.04 サーバーへの影響で詳細を確認してください。

選択肢は2つあります。1つはポイントリリースを待つことで、監視の手間をかけたくないサーバーにはこれが適切な判断です。もう1つは Prompt=normal を設定することです。これにより、同じツールが meta-release を参照するようになり、そこでは 26.04 がサポート対象としてマークされています。後者の手順では開発ビルドではなく正式リリース版の 26.04 へアップグレードされるため、スナップショットから復元可能なマシンであれば許容できる選択肢です。作業終了後は、値を lts に戻してください。具体的な手順は 24.04 から 26.04 へのサーバーアップグレード完全ガイドを参照してください。22.04 で稼働中のサーバーは、Prompt=lts が常に次の LTS リリースしか提示しないという制約があるため、追加のステップが必要です。そのため、22.04 から 26.04 への経路は 24.04 を経由します。

アップグレードを阻害するサードパーティ製リポジトリと PPA

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

noble 用に構築された PPA（Personal Package Archive）には、サーバー上に 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 以降では、ほとんどのソースが /etc/apt/sources.list.d/ubuntu.sources 内に deb822 形式で配置されています。同一リポジトリが旧形式と新形式の両方で記述されている場合は別のエラーとなり、個別のメッセージが表示されます。詳細は deb822 形式における重複ソースエントリのエラーを参照してください。

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

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

apt-mark showhold
sudo dpkg --audit

apt-mark showhold は、保留中のパッケージを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

段階的アップデート（phased updates）のオプションは、見た目以上に重要です。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

同時にアーカイブも移動します。サポート終了（EOL）を迎えたリリースのパッケージは 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 を含むシステムの大半を置き換えます。openssh-server の処理中に SSH セッションが切断されると、パッケージが展開されたまま設定が完了しない状態でプロセスが強制終了され、次回の試行が妨げられます。すでにこの状態に陥っている場合は、途中で停止したアップグレードの復旧を先に行う必要があります。アップグレードは毎回、ターミナルマルチプレクサ内で開始してください。

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

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

マルチプレクサを使用しないユーザーのために、アップグレーダーには独自の安全策が備わっています。SSH 経由での実行を検知すると、ポート 1022 で 2 つ目の sshd を起動するよう提案します。これにより、メインセッションが切断されてもアクセス経路が確保されます。この判断は、親プロセスを遡り sshd という名前のプロセスを探すことで行われます。tmux や screen 内ではマルチプレクサのサーバーが見つかるため、この提案は表示されません。また、pid ファイル /var/run/release-upgrader-sshd.pid は、追加のデーモンが実際に起動したときのみ作成されます。プロンプトが表示されなくても問題はありません。すでにそれ以上の保護が適用されているためです。

提案を受け入れる場合でも、ポートは自動的に開放されません。ポートの開放はセキュリティに関わる判断であり、ツールが代行すべきではないため、明示的に通知されます。アップグレードの間だけポートを開放し、終了後に閉じてください。

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

多くの VPS プロバイダーは、OS とは別にコントロールパネル側でファイアウォールを提供しています。ポート 1022 はそこでも開放する必要があります。開放されていない場合、フォールバック用のリスナーが起動していても到達できず、最悪の状況となります。

コマンドを実行する前に、以下の 4 点を確認してください。

スナップショットまたはフルバックアップを取得する。インプレースのリリースアップグレードには取り消し機能がないため、これが唯一の手段です。
プロバイダーのコンソールにアクセスできることを確認する。再起動後にサーバーが復帰しない場合、SSH は使用できません。カーネルの起動失敗は別の問題であり、カーネル更新後に起動しない VPS で解説されている復旧手順が必要です。
df -h / /boot で空き容量を確認する。アップグレードではパッケージ一式をダウンロードするため、古いカーネルが蓄積された /boot パーティションで容量不足になることがよくあります。
運用しているサービスのリリースノートを確認する。PostgreSQL や PHP のメジャーバージョンアップは、予定の有無にかかわらずリリースに含まれます。

FAQ

Ubuntu 24.04 で do-release-upgrade を実行しても新しいリリースが見つからないのはなぜですか？

Prompt=lts のデフォルト設定が /etc/update-manager/release-upgrades にあるため、ツールは 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日時点で確認したところ、フラグは依然として 0 であり、Ubuntu 26.04.1 は 2026年8月27日に予定されていました。

ポイントリリースを待たずに 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 エラーになります。どうすればアップグレードできますか？

そのリリースはサポート終了（EOL）を迎えたため、パッケージが 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 版のバージョンが新しいリリースに含まれるものより新しい場合は、アーカイブから再インストールしてください。

#ubuntu #do-release-upgrade #apt #lts #troubleshooting