do-release-upgrade: no new release found

Why do-release-upgrade says no new release found

do-release-upgrade ending in No new release found. is almost never a broken tool. The path you asked for is closed at that moment, and the tool reports that in the shortest way it can. Five things close it: the Prompt setting in /etc/update-manager/release-upgrades, the point release gate on LTS (long term support) upgrades, third party repositories, packages that are held or half configured, and a release that is past its end of support.

Work through them in that order. Each one has a command that proves whether it applies to your server, so you never have to guess which of the five you are looking at.

What the check-only flag actually reports

sudo do-release-upgrade -c
echo $?

-c is check only. It reads Canonical's release metadata over HTTPS (hypertext transfer protocol secure) and prints the answer. It downloads no upgrade tool and rewrites no source file. Two outputs matter:

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.

The exit code carries the same answer for scripts. It is 0 when a release is available and 1 when none is, which is the reverse of the usual shell convention, so read it carefully before you build a check around it.

If your login banner still shows the old answer, it is cached. That line comes from /etc/update-motd.d/91-release-upgrade, which prints a stored result instead of asking the network. Refresh it with sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd, or just trust -c. The banner only repeats the result of the last check that ran.

The check also needs to reach changelogs.ubuntu.com. On a server behind a strict outbound firewall or a proxy the tool cannot ask, so it cannot find anything.

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

A HTTP/2 200 line means the server can see the metadata. A curl: (28) Connection timed out means your egress rules are the real cause, and no amount of editing APT (advanced package tool) files will change the answer.

If the command is missing entirely, it lives in ubuntu-release-upgrader-core. Minimal cloud images sometimes leave that package out.

sudo apt install ubuntu-release-upgrader-core

Read /etc/update-manager/release-upgrades before changing anything

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

The file carries its own documentation in comments. Three values are valid:

• never: never check for, and never allow, an upgrade to a new release.
• normal: offer the supported release that immediately follows the running one.
• lts: offer the first LTS release that follows the running one.

Prompt=never is the easiest of the three to diagnose, because the tool names both the file and the setting in its output:

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

Hosting providers and configuration management tools set never deliberately, to stop a fleet drifting between releases. If you find it there, someone chose it. Change it to lts for a server you want on the long term support track, and put it back afterwards if your automation expects the old value.

One detail in those comments catches people out. When Prompt=lts is set and the running release is not itself an LTS release, the upgrader treats the setting as normal. On a 25.10 machine the two values behave identically. On a 24.04 machine they do not, and that difference is the whole of the next section.

Why an LTS to LTS upgrade waits for the first point release

Prompt decides which metadata file the upgrader reads. The addresses live in /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 reads meta-release-lts. Prompt=normal reads meta-release. Both files describe every release in a small block of keys, and the upgrader offers a release only when its Supported: flag is 1. Read them yourself, from the same server:

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

Checked on 13 August 2026, the two files disagree about Ubuntu 26.04. The LTS file says:

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

The plain file says:

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

That Supported: 0 in the LTS file is the gate. A 24.04 server using the default Prompt=lts reads that file, finds no newer LTS release marked available, and prints No new release found. Nothing on your machine is wrong. Canonical has not opened the path yet.

The flag flips to 1 when the first point release ships. Ubuntu 26.04.1 is scheduled for 27 August 2026, and release schedules move, so check the metadata rather than a calendar. The delay is deliberate: the people who upgrade early find the blockers, and those get fixed before the much larger population of LTS servers follows.

That leaves two honest options. Wait for the point release, which is the right call for any server you would rather not watch. Or set Prompt=normal, which points the same tool at meta-release, where 26.04 is already marked supported. The second path upgrades you to the released 26.04, not to a development build, so it is defensible on a machine you can restore from a snapshot. Set the value back to lts when you are finished. The procedure itself, step by step, is in the full 24.04 to 26.04 server upgrade walkthrough.

Third party repositories and PPAs that block the upgrade

The upgrader rewrites your APT sources to point at the new release. It can only do that for a repository that publishes for the new release, so anything else is commented out. The reasons are printed one line per entry, and they are specific: was disabled (unknown mirror), was disabled (unknown dist), and was disabled (no Release file).

A PPA (personal package archive) built for noble has no directory for resolute on the server, so the upgrader cannot fetch a Release file for the new series and disables the entry. That is usually a warning you can accept. It becomes a stop when a third party repository supplies a package that the new release also ships, because the upgrade calculation then has two candidates and no way to satisfy both.

Decide this yourself before you start, rather than letting the tool decide during a long unattended run.

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

apt policy on a package name prints which repository each installed version came from, so you can see exactly which packages depend on the source you are about to disable. Removing the source does not downgrade anything, so a package installed from a PPA stays at its PPA version and can be newer than the new release carries. Where that matters, remove the package as well, and reinstall it from the archive after the upgrade.

There is a flag for the opposite choice. The manual page describes --allow-third-party as "Try the upgrade with third party mirrors and repositories enabled instead of commenting them out." Use it only when you have confirmed that the repository already publishes for the target release. If it does not, you have asked APT to resolve a dependency graph against a series that repository has never built for.

On Ubuntu 24.04 and later most sources live in /etc/apt/sources.list.d/ubuntu.sources in the deb822 format. The same repository written in both the old and the new format is a separate error with its own message, covered in the duplicate source entry error in deb822 format.

Held and half configured packages stop the calculation

A release upgrade has to move almost every package on the system. If one package cannot move, the calculation fails, and the upgrader would rather stop early than leave you halfway. Two commands find the cause.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold prints held packages one per line, and prints nothing at all on a clean system. A hold is a manual instruction never to change that package. Somebody pinned a kernel, or a database version, and then forgot. Release the ones you no longer need with sudo apt-mark unhold followed by the package name.

dpkg --audit lists packages that were unpacked but never configured. That state comes from an install that was interrupted, most often by a session that dropped. The upgrader tries to repair it and prints dpkg interrupted, calling dpkg --configure -a, but running the repair yourself first means you read the error instead of watching it scroll past. A package the tool cannot repair produces the message Package in inconsistent state, and that one needs attention before you retry.

Bring the running release fully current before you upgrade it.

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

The phased updates option matters more than it looks. Ubuntu rolls some updates out to a percentage of machines at a time, so a plain apt upgrade can correctly leave packages behind, and the server is then less current than you believe. That option takes them all. Reboot afterwards if a kernel came with them, so you upgrade from the kernel you are actually running. A box that already keeps itself patched through unattended security upgrades has less to do here, though that mechanism never crosses a release boundary by design.

When the release is past end of standard support

An interim Ubuntu release is supported for nine months. When that support ends its Supported: flag goes to 0, and the normal path offers no upgrade from it. Checked on 13 August 2026, meta-release says this about 25.10:

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

The archive moves at the same time. Packages for an end of life release are removed from archive.ubuntu.com and kept at old-releases.ubuntu.com. So apt update starts returning 404 Not Found, the system can no longer be brought current, and because the upgrader insists on a current system, nothing proceeds. Fix the sources first.

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

Point both archive.ubuntu.com and security.ubuntu.com at old-releases.ubuntu.com, and leave your codename alone. Only the host name changes.

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

Run the same command against /etc/apt/sources.list instead if your server still keeps its sources in that single file. The -i.bak option writes a backup next to the original, so you can put it back if the edit was aimed at the wrong file. A clean apt update afterwards means the archive is reachable again, and do-release-upgrade will now talk to you.

Be realistic about how far this gets you. Ubuntu supports one release step at a time, so a server two or three dead releases behind needs every step in turn, and each step can fail on its own third party repository or its own held package. On a VPS it is often faster to build a new server on the current LTS, move the service across, and keep the old one until you are sure. That also gives you a rollback, which an in place upgrade never does. If you are choosing which track to sit on afterwards, the difference between LTS and interim releases on a server is worth reading before you decide.

What the development release flag really does

-d, or --devel-release, makes the upgrader read meta-release-development instead of the file that Prompt selected. The manual page describes it as "If using the latest supported release, upgrade to the development release."

Checked on 13 August 2026, the newest entry in that file is not 26.04:

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

So -d does not hand a 24.04 server the released 26.04. It aims at 26.10, a release still being assembled. Older advice to "just add -d" was written for the window before an LTS shipped, and repeating it now points your server somewhere you did not intend to go. With Prompt=lts still in place the flag stops with a message of its own:

There is no development version of an LTS available.

Ubuntu's server documentation is direct about the flag: "using the development release (or the -d flag) is not recommended for production environments". A development release changes daily and carries no security support promise, so a package that works in the morning can break a service in the afternoon. Use it on a scratch virtual machine you built to test your own configuration. Do not use it on a server anyone depends on. When you want a released 26.04 before the LTS gate opens, Prompt=normal is the correct route.

Run the upgrade where a dropped SSH session cannot break it

A release upgrade replaces most of the system, including openssh-server and systemd. If your SSH (secure shell) session dies while dpkg is working, the process is killed with packages unpacked and unconfigured, which is exactly the state that stops your next attempt. Start the upgrade inside a terminal multiplexer every time.

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

If the connection drops, log back in and run tmux attach -t upgrade. The upgrade kept running, because it is a child of the tmux server rather than of your SSH session. screen -S upgrade and screen -r upgrade do the same job if you prefer screen.

The upgrader carries its own safety net for people who do not use a multiplexer. When it detects that it is running under SSH, it offers to start a second sshd on port 1022, so a broken main session still leaves a way in. It decides by walking its own parent processes looking for one called sshd. Inside tmux or screen that walk finds the multiplexer server instead, so the offer never appears, and the pid file /var/run/release-upgrader-sshd.pid is written only when the extra daemon really starts. Nothing is wrong when you do not see the prompt. You already have the better protection.

If you do accept the offer, the port is not opened for you. The tool says so plainly, because opening a port is a security decision it is not entitled to make on your behalf. Open it for the length of the upgrade, then close it again.

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

Most VPS providers run a second firewall in their control panel, outside the operating system. Port 1022 has to be open there as well, or the fallback listener is running and unreachable, which is the worst of both.

Four things belong in place before you type the command:

• Take a snapshot or a full backup. An in place release upgrade has no undo, and this is the only one you get.
• Confirm you can open your provider's console before you need it. If the server does not come back after its reboot, SSH is exactly the thing you will not have. A kernel that fails to boot is a separate problem with its own recovery steps, covered in a VPS that will not boot after a kernel update.
• Check free space with df -h / /boot. The upgrade downloads a full set of packages, and a /boot partition holding several old kernels is a common place to stall.
• Read the release notes for the services you run. A major version jump in PostgreSQL or PHP arrives with the release, whether or not you planned for it.

FAQ

Why does do-release-upgrade say no new release found on Ubuntu 24.04?

The default Prompt=lts in /etc/update-manager/release-upgrades makes the tool read https://changelogs.ubuntu.com/meta-release-lts, and Ubuntu 26.04 carries Supported: 0 in that file until its first point release. The upgrader finds no newer LTS release marked available, so it stops. Check the file yourself with curl -s https://changelogs.ubuntu.com/meta-release-lts and read the last block. Checked on 13 August 2026 the flag was still 0, with Ubuntu 26.04.1 scheduled for 27 August 2026.

Is it safe to set Prompt=normal instead of waiting for the point release?

It upgrades you to the released 26.04, not to a development build, because Prompt=normal reads meta-release, where 26.04 already carries Supported: 1. The timing is the risk. You are going before the blockers found by early upgraders have been fixed. Do it on a server you can restore from a snapshot, and where you can reach the provider console if the reboot goes wrong. Set the value back to lts afterwards.

Does the -d flag upgrade me to 26.04?

No. -d reads meta-release-development, whose newest entry on 13 August 2026 was Ubuntu 26.10, a release still in development. On an LTS machine with Prompt=lts the flag prints There is no development version of an LTS available. and stops. Ubuntu's own server documentation says the development release is not recommended for production, so use Prompt=normal when you want a released 26.04 early.

apt update returns 404 errors on an old release. How do I upgrade it?

That release has reached end of life, so its packages were moved from archive.ubuntu.com to old-releases.ubuntu.com. Change only the host names in /etc/apt/sources.list.d/ubuntu.sources, or in /etc/apt/sources.list on older layouts, and keep your codename as it is. Then run sudo apt update and sudo apt full-upgrade. Once the system is current again, do-release-upgrade can move it forward one release at a time.

Do I need to remove my PPAs before running do-release-upgrade?

You do not have to, because the upgrader comments out any source that does not publish for the new release and prints a line such as was disabled (no Release file) for each one. Doing it yourself first is better, since you choose the order and you see the result. Run apt policy on the packages you care about to find which ones came from each PPA, then reinstall those from the archive if the PPA version is newer than the new release carries.