Ubuntu do-release-upgrade: geen nieuwe release gevonden

Waarom do-release-upgrade aangeeft dat er geen nieuwe release is gevonden

do-release-upgrade eindigend in No new release found. is vrijwel nooit een defecte tool. Het pad waar u om vraagt is op dat moment gesloten en de tool rapporteert dit op de kortst mogelijke manier. Vijf factoren sluiten dit pad af: de Prompt instelling in /etc/update-manager/release-upgrades, de point release-beperking bij LTS (long term support) upgrades, externe repositories, pakketten die zijn vastgezet of slechts gedeeltelijk zijn geconfigureerd, en een release waarvan de ondersteuning is verlopen.

Doorloop deze punten in die volgorde. Voor elk punt is er een commando dat aantoont of dit van toepassing is op uw server, zodat u nooit hoeft te gissen met welke van de vijf u te maken heeft.

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

Lees /etc/update-manager/release-upgrades voordat u wijzigingen aanbrengt

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

Het bestand bevat eigen documentatie in de vorm van commentaar. Er zijn drie geldige waarden:

• never: controleer nooit op een upgrade naar een nieuwe release en sta deze nooit toe.
• normal: bied de ondersteunde release aan die direct volgt op de huidige versie.
• lts: bied de eerste LTS-release aan die volgt op de huidige versie.

Prompt=never is de makkelijkste van de drie om te diagnosticeren, omdat de tool in de uitvoer zowel het bestand als de instelling benoemt:

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

Hostingproviders en configuratiebeheertools stellen never bewust in om te voorkomen dat een vloot van servers tussen releases gaat afwijken. Als u deze waarde daar aantreft, is deze door iemand gekozen. Wijzig deze naar lts voor een server die u op het Long Term Support-traject wilt houden, en zet de waarde daarna terug als uw automatisering de oude waarde verwacht.

Eén detail in die opmerkingen brengt mensen in verwarring. Wanneer Prompt=lts is ingesteld en de actieve release zelf geen LTS-release is, behandelt de upgrader de instelling als normal. Op een 25.10-machine gedragen de twee waarden zich identiek. Op een 24.04-machine is dat niet het geval, en dat verschil vormt de kern van het volgende gedeelte.

Waarom een LTS naar LTS upgrade wacht op de eerste point release

Prompt bepaalt welk metadatabestand de upgrader leest. De adressen staan 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 leest meta-release-lts. Prompt=normal leest meta-release. Beide bestanden beschrijven elke release in een klein blok met keys, en de upgrader biedt een release pas aan wanneer de Supported:-vlag op 1 staat. Lees ze zelf, vanaf dezelfde 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

Gecontroleerd op 13 augustus 2026, spreken de twee bestanden elkaar tegen over Ubuntu 26.04. Het LTS-bestand zegt:

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

Het standaardbestand zegt:

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

Die Supported: 0 in het LTS-bestand is de poortwachter. Een 24.04-server die de standaard Prompt=lts gebruikt, leest dat bestand, vindt geen nieuwere LTS-release die als beschikbaar is gemarkeerd, en toont No new release found.. Er is niets mis met uw machine. Canonical heeft het pad nog niet vrijgegeven.

De vlag verspringt naar 1 zodra de eerste point release verschijnt. Ubuntu 26.04.1 staat gepland voor 27 augustus 2026, en releasesschema's wijzigen, dus controleer de metadata in plaats van een kalender. De vertraging is bewust: de mensen die vroeg upgraden vinden de blokkerende problemen, en die worden opgelost voordat de veel grotere groep LTS-servers volgt.

Dat laat twee eerlijke opties over. Wacht op de point release, wat de juiste keuze is voor elke server die u liever niet in de gaten houdt. Of stel Prompt=normal in, wat dezelfde tool naar meta-release wijst, waar 26.04 al als ondersteund is gemarkeerd. Het tweede pad upgradet u naar de uitgebrachte 26.04, niet naar een ontwikkelingsversie, dus het is verdedigbaar op een machine die u kunt herstellen vanaf een snapshot. Zet de waarde terug naar lts wanneer u klaar bent. De procedure zelf, stap voor stap, staat in de volledige walkthrough voor de serverupgrade van 24.04 naar 26.04.

Third-party repositories en PPA's die de upgrade blokkeren

De upgrader herschrijft uw APT-bronnen zodat deze naar de nieuwe release wijzen. Dit kan alleen voor repositories die de nieuwe release ondersteunen; alle andere worden uitgeschakeld door middel van commentaar. De redenen hiervoor worden per regel weergegeven en zijn specifiek: was disabled (unknown mirror), was disabled (unknown dist) en was disabled (no Release file).

Een PPA (personal package archive) die is gebouwd voor noble heeft geen directory voor resolute op de server. De upgrader kan daarom geen Release-bestand voor de nieuwe serie ophalen en schakelt de bron uit. Dit is doorgaans een waarschuwing die u kunt accepteren. Het wordt echter een blokkade wanneer een third-party repository een pakket levert dat ook in de nieuwe release zit. De upgrade-berekening heeft dan twee kandidaten en kan niet aan beide voldoen.

Neem hierover zelf een besluit voordat u begint, in plaats van de tool dit te laten bepalen tijdens een langdurig, onbeheerd proces.

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

apt policy op een pakketnaam toont uit welke repository elke geïnstalleerde versie afkomstig is. Zo ziet u precies welke pakketten afhankelijk zijn van de bron die u op het punt staat uit te schakelen. Het verwijderen van de bron zorgt niet voor een downgrade; een pakket dat vanuit een PPA is geïnstalleerd, blijft op de PPA-versie staan en kan nieuwer zijn dan de versie in de nieuwe release. Waar dit van belang is, verwijdert u het pakket en installeert u het na de upgrade opnieuw vanuit het archief. Een repository die u wilt behouden, zoals die van Tailscale, vereist dat de codenaam wordt bijgewerkt naar de nieuwe release voordat het pakket opnieuw kan worden geïnstalleerd. Dit is de oorzaak van de meeste Tailscale-installatiefouten op Ubuntu.

Er is een vlag voor de tegenovergestelde keuze. De man-pagina beschrijft --allow-third-party als "Probeer de upgrade met third-party mirrors en repositories ingeschakeld in plaats van ze uit te schakelen." Gebruik deze optie alleen wanneer u heeft bevestigd dat de repository al publiceert voor de doelrelease. Als dat niet het geval is, vraagt u APT om een afhankelijkheidsgraaf op te lossen tegen een serie waarvoor de repository nooit heeft gebouwd.

Op Ubuntu 24.04 en later bevinden de meeste bronnen zich in /etc/apt/sources.list.d/ubuntu.sources in het deb822-formaat. Dezelfde repository die in zowel het oude als het nieuwe formaat is geschreven, levert een afzonderlijke foutmelding op, zoals beschreven in de foutmelding voor dubbele bronvermeldingen in deb822-formaat.

Vastgehouden en half geconfigureerde pakketten blokkeren de berekening

Een release-upgrade moet bijna elk pakket op het systeem verplaatsen. Als één pakket niet kan worden verplaatst, mislukt de berekening en stopt de upgrader liever voortijdig dan dat u halverwege blijft steken. Twee commando's achterhalen de oorzaak.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold toont vastgehouden pakketten, één per regel, en geeft niets weer op een schoon systeem. Een hold is een handmatige instructie om dat pakket nooit te wijzigen. Iemand heeft een kernel of een databaseversie vastgezet en is dat vervolgens vergeten. Geef de pakketten die u niet langer nodig heeft vrij met sudo apt-mark unhold gevolgd door de pakketnaam.

dpkg --audit somt pakketten op die wel zijn uitgepakt, maar nooit zijn geconfigureerd. Deze status ontstaat na een installatie die is onderbroken, meestal door een verbroken sessie. De upgrader probeert dit te herstellen en geeft dpkg interrupted, calling dpkg --configure -a weer, maar door het herstel zelf uit te voeren, leest u de foutmelding in plaats van dat deze voorbij scrollt. Een pakket dat het hulpprogramma niet kan repareren, produceert de melding Package in inconsistent state; dit vereist aandacht voordat u het opnieuw probeert.

Breng de huidige release volledig up-to-date voordat u deze upgradet.

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

De optie voor gefaseerde updates is belangrijker dan het lijkt. Ubuntu rolt sommige updates uit naar een percentage van de machines tegelijk, waardoor een standaard apt upgrade pakketten kan achterlaten en de server minder actueel is dan u denkt. Die optie haalt ze allemaal binnen. Start daarna opnieuw op als er een kernel bij zat, zodat u upgradet vanaf de kernel die u daadwerkelijk gebruikt. Een server die zichzelf al up-to-date houdt via onbeheerde beveiligingsupdates heeft hier minder werk, hoewel dat mechanisme uit veiligheidsoverwegingen nooit een releasegrens overschrijdt.

Wanneer de release het einde van de standaardondersteuning heeft bereikt

Een interim-release van Ubuntu wordt negen maanden ondersteund. Wanneer die ondersteuning eindigt, verandert de Supported:-vlag naar 0 en biedt het normale pad geen upgrade-mogelijkheid meer. Gecontroleerd op 13 augustus 2026, meldt meta-release het volgende over 25.10:

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

Het archief verplaatst zich op hetzelfde moment. Pakketten voor een release die het einde van zijn levensduur heeft bereikt, worden verwijderd van archive.ubuntu.com en bewaard op old-releases.ubuntu.com. Hierdoor begint apt update de melding 404 Not Found terug te geven, kan het systeem niet langer worden bijgewerkt, en omdat de upgrader een actueel systeem vereist, loopt het proces vast. Herstel eerst de bronbestanden.

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

Wijs zowel archive.ubuntu.com als security.ubuntu.com naar old-releases.ubuntu.com en laat de codenaam ongewijzigd. Alleen de hostnaam verandert.

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

Voer hetzelfde commando uit tegen /etc/apt/sources.list als uw server de bronbestanden nog in dat ene bestand bewaart. De optie -i.bak schrijft een back-up naast het origineel, zodat u deze kunt terugzetten als de wijziging op het verkeerde bestand was gericht. Een schone apt update daarna betekent dat het archief weer bereikbaar is en do-release-upgrade weer met u zal communiceren.

Wees realistisch over hoe ver dit u brengt. Ubuntu ondersteunt telkens één release-stap tegelijk, dus een server die twee of drie verouderde releases achterloopt, heeft elke stap afzonderlijk nodig. Elke stap kan falen door een eigen externe repository of een vastgezet pakket. Op een VPS is het vaak sneller om een nieuwe server op de huidige LTS-versie op te bouwen, de service te verplaatsen en de oude server te behouden totdat u zeker bent van de werking. Dat biedt u ook een rollback-mogelijkheid, wat bij een in-place upgrade nooit het geval is. Als u kiest op welk release-traject u daarna wilt zitten, is het verschil tussen LTS- en interim-releases op een server de moeite waard om te lezen voordat u beslist.

Wat de development release-vlag daadwerkelijk doet

-d, of --devel-release, zorgt ervoor dat de upgrader meta-release-development leest in plaats van het bestand dat Prompt heeft geselecteerd. De man-page beschrijft dit als: "Indien de laatst ondersteunde release wordt gebruikt, upgrade dan naar de development release."

Gecontroleerd op 13 augustus 2026; de nieuwste vermelding in dat bestand is niet 26.04:

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

Dus -d levert een 24.04-server niet de uitgebrachte 26.04-versie. Het richt zich op 26.10, een release die nog in ontwikkeling is. Ouder advies om "gewoon -d toe te voegen" werd geschreven voor de periode voordat een LTS werd uitgebracht. Dit nu herhalen, stuurt uw server naar een locatie waar u niet naartoe wilt. Met Prompt=lts nog steeds actief, stopt de vlag met een eigen melding:

There is no development version of an LTS available.

De serverdocumentatie van Ubuntu is duidelijk over deze vlag: "het gebruik van de development release (of de -d-vlag) wordt niet aanbevolen voor productieomgevingen". Een development release verandert dagelijks en biedt geen garantie op beveiligingsondersteuning; een pakket dat 's ochtends werkt, kan 's middags een service onklaar maken. Gebruik dit op een test-virtuele machine die u heeft opgezet om uw eigen configuratie te testen. Gebruik het niet op een server waar anderen afhankelijk van zijn. Wanneer u een uitgebrachte 26.04 wilt voordat de LTS-poort opengaat, is Prompt=normal de juiste route.

Voer de upgrade uit zonder dat een verbroken SSH-sessie deze onderbreekt

Een release-upgrade vervangt het grootste deel van het systeem, inclusief openssh-server en systemd. Als uw SSH-sessie (secure shell) wordt verbroken terwijl dpkg actief is, wordt het proces beëindigd terwijl pakketten uitgepakt en ongeconfigureerd achterblijven. Dit is precies de status die een volgende poging blokkeert. Start de upgrade daarom altijd binnen een terminal multiplexer.

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

Als de verbinding wegvalt, logt u opnieuw in en voert u tmux attach -t upgrade uit. De upgrade is blijven draaien omdat deze een kindproces is van de tmux-server en niet van uw SSH-sessie. screen -S upgrade en screen -r upgrade vervullen dezelfde functie als u de voorkeur geeft aan screen.

De upgrader bevat een eigen vangnet voor gebruikers die geen multiplexer gebruiken. Wanneer het programma detecteert dat het onder SSH draait, biedt het aan om een tweede sshd op poort 1022 te starten, zodat u bij een verbroken hoofdverbinding alsnog toegang heeft. Het programma bepaalt dit door zijn eigen ouderprocessen te doorlopen op zoek naar een proces genaamd sshd. Binnen tmux of screen vindt deze zoekopdracht de multiplexer-server, waardoor het aanbod niet verschijnt en het pid-bestand /var/run/release-upgrader-sshd.pid alleen wordt geschreven wanneer de extra daemon daadwerkelijk start. Er is niets mis als u de prompt niet ziet; u beschikt dan al over de betere bescherming.

Als u het aanbod accepteert, wordt de poort niet automatisch voor u geopend. De tool meldt dit expliciet, omdat het openen van een poort een beveiligingsbeslissing is die de tool niet namens u mag nemen. Open de poort voor de duur van de upgrade en sluit deze daarna weer.

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

De meeste VPS-providers hanteren een tweede firewall in hun configuratiescherm, buiten het besturingssysteem om. Poort 1022 moet daar ook openstaan, anders draait de fallback-listener wel, maar is deze onbereikbaar; dit is de minst gunstige situatie.

Zorg dat de volgende vier zaken in orde zijn voordat u het commando invoert:

• Maak een snapshot of een volledige back-up. Een in-place release-upgrade kan niet ongedaan worden gemaakt; dit is uw enige kans.
• Controleer of u de console van uw provider kunt openen voordat u deze nodig heeft. Als de server na een reboot niet terugkeert, is SSH precies hetgeen waarover u niet meer beschikt. Een kernel die niet opstart is een afzonderlijk probleem met eigen herstelstappen, zoals beschreven in een VPS die niet opstart na een kernel-update.
• Controleer de vrije schijfruimte met df -h / /boot. De upgrade downloadt een volledige set pakketten, en een /boot-partitie die meerdere oude kernels bevat, is een veelvoorkomende plek waar het proces vastloopt.
• Lees de release notes voor de services die u draait. Een grote versie-upgrade van PostgreSQL of PHP wordt meegeleverd met de release, ongeacht of u dit had gepland.

FAQ

Waarom geeft do-release-upgrade aan dat er geen nieuwe release is gevonden op Ubuntu 24.04?

De standaard Prompt=lts in /etc/update-manager/release-upgrades zorgt ervoor dat de tool https://changelogs.ubuntu.com/meta-release-lts leest, en Ubuntu 26.04 bevat Supported: 0 in dat bestand tot de eerste point release. De upgrader vindt geen nieuwere LTS-release die als beschikbaar is gemarkeerd en stopt daarom. Controleer het bestand zelf met curl -s https://changelogs.ubuntu.com/meta-release-lts en lees het laatste blok. Op 13 augustus 2026 stond de vlag nog op 0, terwijl Ubuntu 26.04.1 gepland staat voor 27 augustus 2026.

Is het veilig om Prompt=normal in te stellen in plaats van te wachten op de point release?

Dit upgradet u naar de uitgebrachte 26.04, niet naar een ontwikkelversie, omdat Prompt=normal het bestand meta-release leest, waarin 26.04 al de status Supported: 1 heeft. De timing vormt het risico. U voert de upgrade uit voordat de blokkerende problemen die door vroege gebruikers zijn gevonden, zijn opgelost. Doe dit op een server waarvan u een snapshot kunt terugzetten en waar u via de console van de provider bij kunt als de herstart mislukt. Zet de waarde daarna weer terug op lts.

Upgradet de vlag -d mij naar 26.04?

Nee. -d leest meta-release-development, waarvan het nieuwste item op 13 augustus 2026 Ubuntu 26.10 was, een release die nog in ontwikkeling is. Op een LTS-machine met Prompt=lts print de vlag There is no development version of an LTS available. en stopt het proces. De eigen serverdocumentatie van Ubuntu stelt dat de ontwikkelversie niet wordt aanbevolen voor productieomgevingen. Gebruik daarom Prompt=normal als u vroegtijdig naar een uitgebrachte 26.04 wilt.

apt update geeft 404-fouten op een oude release. Hoe upgrade ik deze?

Die release heeft het einde van de levensduur bereikt, waardoor de pakketten zijn verplaatst van archive.ubuntu.com naar old-releases.ubuntu.com. Wijzig alleen de hostnamen in /etc/apt/sources.list.d/ubuntu.sources, of in /etc/apt/sources.list bij oudere indelingen, en behoud de codenaam zoals deze is. Voer daarna sudo apt update en sudo apt full-upgrade uit. Zodra het systeem weer up-to-date is, kan do-release-upgrade het systeem één release per keer vooruit helpen.

Moet ik mijn PPA's verwijderen voordat ik do-release-upgrade uitvoer?

Dat hoeft niet, omdat de upgrader elke bron die niet publiceert voor de nieuwe release uitcommentarieert en voor elk daarvan een regel zoals was disabled (no Release file) print. Het is beter om dit zelf vooraf te doen, omdat u dan de volgorde bepaalt en het resultaat ziet. Voer apt policy uit op de pakketten die voor u van belang zijn om te achterhalen welke uit welke PPA afkomstig zijn, en installeer deze vervolgens opnieuw vanuit het archief als de PPA-versie nieuwer is dan de versie die de nieuwe release bevat.