Fix do-release-upgrade: no new release found

Why do-release-upgrade talk say e no see new release

do-release-upgrade wey end for No new release found. almost never mean say the tool spoil. The path wey you request close for that moment, and the tool report am for the shortest way e fit. Five things fit close am: the Prompt setting for /etc/update-manager/release-upgrades, the point release gate for LTS (long term support) upgrades, third party repositories, packages wey dem hold or configure halfway, and release wey pass im end of support.

Handle dem for that order. Each one get command wey go prove whether e apply to your server, so you no need guess which of the five you dey face.

Wetin check-only flag actually dey report

sudo do-release-upgrade -c
echo $?

-c na check only. E dey read Canonical release metadata over HTTPS (hypertext transfer protocol secure) and print the answer. E no download upgrade tool and e no rewrite any source file. Na 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.

Exit code carry the same answer for scripts. E be 0 when release dey available, and 1 when no release dey. This one reverse the normal shell convention, so read am carefully before you build check around am.

If your login banner still dey show the old answer, na cached result. That line dey come from /etc/update-motd.d/91-release-upgrade, wey dey print stored result instead of asking the network. Refresh am with sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd, or simply trust -c. The banner only dey repeat the result of the last check wey run.

The check also need reach changelogs.ubuntu.com. If server dey behind strict outbound firewall or proxy wey the tool no fit ask, e no go find anything.

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

A HTTP/2 200 line mean say server fit see the metadata. A curl: (28) Connection timed out mean say na your egress rules cause the problem, and editing APT (advanced package tool) files no go change the answer.

If command no dey at all, e dey inside ubuntu-release-upgrader-core. Some minimal cloud images no include that package.

sudo apt install ubuntu-release-upgrader-core

Read /etc/update-manager/release-upgrades before you change anything

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

The file get its own documentation inside comments. Three values dey valid:

• never: e no go ever check for, or allow, upgrade to new release.
• normal: e go offer the supported release wey follow the one wey dey run immediately.
• lts: e go offer the first LTS release wey follow the one wey dey run.

Prompt=never na the easiest one to diagnose, because the tool go name both the file and the setting for 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 dey set never deliberately, so fleet no go drift between releases. If you see am there, somebody choose am. Change am to lts for server wey you want keep for long term support track, and change am back afterwards if your automation dey expect the old value.

One detail for those comments dey catch people. When Prompt=lts dey set and the release wey dey run no be LTS release itself, the upgrader dey treat the setting as normal. For 25.10 machine, the two values dey behave the same way. For 24.04 machine, dem no dey behave the same way, and na that difference be the whole next section.

Why LTS go wait for the first point release before e upgrade

Prompt dey decide which metadata file upgrader go read. The addresses dey inside /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 dey read meta-release-lts. Prompt=normal dey read meta-release. Both files describe every release with small block of keys, and upgrader go offer release only when e Supported: flag be 1. You fit read dem 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

We check am on 13 August 2026, and the two files no agree about Ubuntu 26.04. The LTS file talk say:

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

The plain file talk say:

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

That Supported: 0 for the LTS file na the gate. A 24.04 server wey dey use default Prompt=lts go read that file, find say no newer LTS release dey marked as available, then print No new release found. Nothing dey wrong with your machine. Canonical never open that upgrade path yet.

The flag go change to 1 when the first point release ship. Ubuntu 26.04.1 dey scheduled for 27 August 2026, but release schedules fit change, so check the metadata instead of relying on calendar. The delay dey deliberate: people wey upgrade early go find the blockers, and dem go fix those blockers before the much bigger number of LTS servers follow.

That one leave two honest options. Wait for the point release; na the correct choice for any server wey you no want monitor closely. Or set Prompt=normal, wey go point the same tool to meta-release, where 26.04 don already marked as supported. The second path go upgrade you to the released 26.04, not development build, so e make sense for machine wey you fit restore from snapshot. Set the value back to lts when you finish. The procedure dey explained step by step for the complete 24.04 to 26.04 server upgrade guide.

Third party repositories and PPAs wey dey block the upgrade

The upgrader dey rewrite your APT sources make dem point to the new release. E fit only do this for repository wey publishes for the new release, so e go comment out anything else. The reasons dey print one line for each entry, and dem specific: was disabled (unknown mirror), was disabled (unknown dist), and was disabled (no Release file).

A PPA (personal package archive) wey dem build for noble no get directory for resolute for the server, so the upgrader no fit fetch Release file for the new series and e disable the entry. Normally, na warning wey you fit accept. E becomes a stop when third party repository dey provide package wey the new release also ships, because the upgrade calculation then get two candidates and no way to satisfy both.

Decide this by yourself before you start, instead make the tool decide during one long unattended run.

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

apt policy for a package name go print which repository each installed version come from, so you fit see exactly which packages depend on the source wey you wan disable. Removing the source no dey downgrade anything, so package wey you install from a PPA go remain for the PPA version and fit newer pass the version wey the new release carry. Where this matter, remove the package too, then reinstall am from the archive after the upgrade. Repository wey you plan to bring back, like Tailscale own, need make you update its codename to the new release before the package fit install again. Na from here plenty Tailscale install errors on Ubuntu dey come.

One flag dey for the opposite choice. The manual page describe --allow-third-party as "Try the upgrade with third party mirrors and repositories enabled instead of commenting them out." Use am only when you don confirm say the repository already publishes for the target release. If e no publish, you don ask APT to resolve dependency graph against a series wey that repository never build for.

For Ubuntu 24.04 and later, most sources dey for /etc/apt/sources.list.d/ubuntu.sources with deb822 format. The same repository wey dem write for both the old and new format na separate error with its own message. The duplicate source entry error for deb822 format cover am.

Held and half configured packages fit stop the calculation

A release upgrade gats move almost every package for the system. If one package no fit move, the calculation go fail, and the upgrader prefer stop early instead make e leave you halfway. Two commands go find the cause.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold dey print held packages one for each line, and e no go print anything at all for clean system. Hold na manual instruction say make system never change that package. Somebody fit pin kernel or database version, then forget about am. Release the ones wey you no need again with sudo apt-mark unhold followed by the package name.

dpkg --audit dey list packages wey system unpack but never configure. This state fit come from install wey interruption stop, most times because session disconnect. The upgrader dey try repair am and print dpkg interrupted, calling dpkg --configure -a, but if you run the repair yourself first, you go read the error instead of watching am scroll pass. Package wey the tool no fit repair go produce message Package in inconsistent state, and you need handle that one before you retry.

Make the release wey dey run fully current before you upgrade am.

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 matter pass as e look. Ubuntu dey roll out some updates to percentage of machines at a time, so plain apt upgrade fit correctly leave some packages behind, and the server go then less current than you think. That option go take all of dem. Reboot afterwards if kernel dey among dem, so you fit upgrade from the kernel wey you dey actually run. Server wey already dey keep itself patched through unattended security upgrades get less work for here, though that mechanism no dey cross release boundary by design.

When release don pass end of standard support

Ubuntu interim release dey get support for nine months. When that support end, e Supported: flag go turn to 0, and normal upgrade path no dey offer upgrade from am. As at 13 August 2026, meta-release talk this about 25.10:

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

Archive dey move for the same time. Dem remove packages for release wey don reach end of life from archive.ubuntu.com and keep dem for old-releases.ubuntu.com. So apt update go start return 404 Not Found, system no fit become current again, and because upgrader require current system, nothing go continue. 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 to old-releases.ubuntu.com, and leave your codename as e be. Na the host name only go change.

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 dey keep sources for that single file. -i.bak option go write backup beside the original, so you fit restore am if edit target the wrong file. If clean apt update come afterwards, e mean say archive dey reachable again, and do-release-upgrade go fit communicate with you now.

Make you realistic about wetin this fit achieve. Ubuntu support one release step at a time, so server wey dey two or three dead releases behind need every step one after another, and each step fit fail because of its own third party repository or held package. For VPS, e often faster to build new server on current LTS, move the service go there, and keep the old one until you confirm say everything dey okay. This one also give you rollback, something wey in place upgrade never provide. If you dey choose which track to use afterwards, difference between LTS and interim releases for server worth reading before you decide.

Development release flag really mean wetin

-d, or --devel-release, dey make the upgrader read meta-release-development instead of the file wey Prompt select. The manual page describe am as "If using the latest supported release, upgrade to the development release."

Dem check am on 13 August 2026, and the newest entry for that file no be 26.04:

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

So -d no dey give 24.04 server the released 26.04. E dey target 26.10, wey still dey under development. The old advice to "just add -d" na for the period before an LTS release come out, and if you repeat am now, e go point your server to place wey you no intend. If Prompt=lts still dey there, the flag go stop and show im own message:

There is no development version of an LTS available.

Ubuntu's server documentation talk clearly about the flag: "using the development release (or the -d flag) is not recommended for production environments". Development release dey change every day, and e no get promise of security support. So package wey work for morning fit break service for afternoon. Use am for scratch virtual machine wey you build to test your own configuration. No use am for server wey anybody depend on. When you want released 26.04 before the LTS gate open, Prompt=normal na the correct route.

Run the upgrade where dropped SSH session no fit spoil am

A release upgrade dey replace most parts of the system, including openssh-server and systemd. If your SSH (secure shell) session cut while dpkg dey work, the process go die with packages wey don unpack but never configure. Na exactly this state dey stop your next attempt. Start the upgrade inside terminal multiplexer every time.

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

If connection drop, log in again and run tmux attach -t upgrade. The upgrade continue dey run because na child of tmux server, no be your SSH session. screen -S upgrade and screen -r upgrade dey do the same work if you prefer screen.

The upgrader get safety net for people wey no dey use multiplexer. When e detect say e dey run under SSH, e go offer to start second sshd for port 1022. This one leave another way to enter if the main session break. E dey decide this by checking its own parent processes to find one wey dem call sshd. Inside tmux or screen, that check go find the multiplexer server instead. So the offer no go appear, and pid file /var/run/release-upgrader-sshd.pid go only write when the extra daemon really start. Nothing dey wrong if you no see the prompt. You already get better protection.

If you accept the offer, the port no go open by itself. The tool talk am clearly because opening port na security decision wey e no get permission to make for you. Open the port for the time wey upgrade go take, then close am again.

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

Most VPS providers dey run second firewall for their control panel, outside the operating system. Port 1022 must open there too. Otherwise fallback listener go dey run but nobody fit reach am. Na the worst situation be that.

Make these four things dey ready before you type the command:

• Take snapshot or full backup. In-place release upgrade no get undo, and na this one chance you get.
• Confirm say you fit open your provider console before you need am. If server no come back after reboot, SSH na exactly the thing wey you no go get. Kernel wey fail to boot na separate problem with its own recovery steps. You fit see am for VPS wey no go boot after kernel update.
• Check free space with df -h / /boot. The upgrade go download full set of packages, and /boot partition wey dey hold several old kernels na common place where e fit stop.
• Read release notes for the services wey you dey run. Major version jump for PostgreSQL or PHP go come with the release, whether you plan for am or not.

FAQ

Demek why do-release-upgrade dey talk say no new release dey for Ubuntu 24.04?

The default Prompt=lts wey dey for /etc/update-manager/release-upgrades make the tool read https://changelogs.ubuntu.com/meta-release-lts, and Ubuntu 26.04 get Supported: 0 for that file until the first point release. The upgrader no find any newer LTS release wey dem mark as available, so e stop. Check the file yourself with curl -s https://changelogs.ubuntu.com/meta-release-lts and read the last block. When dem check am on 13 August 2026, the flag still be 0, and dem schedule Ubuntu 26.04.1 for 27 August 2026.

E safe make I set Prompt=normal instead of waiting for the point release?

E go upgrade you to the released 26.04, no be development build, because Prompt=normal dey read meta-release, where 26.04 already get Supported: 1. The risk na the timing. You dey do am before dem fix the blockers wey early upgraders find. Do am for server wey you fit restore from snapshot, and wey you fit reach through provider console if reboot no go well. Set the value back to lts afterwards.

The -d flag go upgrade me to 26.04?

No. -d dey read meta-release-development, and the newest entry there on 13 August 2026 na Ubuntu 26.10, wey still dey development. For LTS machine wey get Prompt=lts, the flag go print There is no development version of an LTS available. and stop. Ubuntu own server documentation talk say dem no recommend development release for production, so use Prompt=normal when you want released 26.04 early.

apt update dey return 404 errors for old release. How I fit upgrade am?

That release don reach end of life, so dem move its packages from archive.ubuntu.com go old-releases.ubuntu.com. Change only the host names for /etc/apt/sources.list.d/ubuntu.sources, or for /etc/apt/sources.list on older layouts, and leave your codename as e be. Then run sudo apt update and sudo apt full-upgrade. Once the system current again, do-release-upgrade fit move am forward one release at a time.

I need remove my PPAs before I run do-release-upgrade?

You no need do am, because the upgrader dey comment out any source wey no publish for the new release and e print line like was disabled (no Release file) for each one. But e better make you do am yourself first, because you go choose the order and see the result. Run apt policy on the packages wey matter to you to find which ones come from each PPA, then reinstall dem from the archive if the PPA version newer than the one wey the new release carry.