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. betekent bijna nooit dat de tool defect is. Het pad waar u om vraagt is op dat moment gesloten en de tool rapporteert dit op de meest beknopte wijze. Vijf factoren sluiten dit pad af: de Prompt-instelling in /etc/update-manager/release-upgrades, de point release-beperking bij LTS-upgrades (long term support), externe repositories, pakketten die zijn vastgezet (held) of slechts gedeeltelijk zijn geconfigureerd, en een release waarvan de ondersteuning is beëindigd.

Doorloop deze punten in de aangegeven 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.

Wat de check-only vlag daadwerkelijk rapporteert

sudo do-release-upgrade -c
echo $?

-c is check only. Het leest de release-metadata van Canonical via HTTPS (hypertext transfer protocol secure) en toont het resultaat. Het downloadt geen upgrade-tool en overschrijft geen bronbestanden. Twee uitvoerwaarden zijn van belang:

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.

De exit-code bevat hetzelfde antwoord voor scripts. Het is 0 wanneer er een release beschikbaar is en 1 wanneer dit niet het geval is. Dit is het omgekeerde van de gebruikelijke shell-conventie; lees dit dus zorgvuldig voordat u hier een controle omheen bouwt.

Als uw login-banner nog steeds het oude antwoord toont, is dit gecachet. Die regel is afkomstig van /etc/update-motd.d/91-release-upgrade, die een opgeslagen resultaat toont in plaats van het netwerk te raadplegen. Ververs dit met sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd, of vertrouw simpelweg op -c. De banner herhaalt slechts het resultaat van de laatst uitgevoerde controle.

De controle moet ook changelogs.ubuntu.com kunnen bereiken. Op een server achter een strikte uitgaande firewall of een proxy kan de tool geen verzoek doen, waardoor deze niets kan vinden.

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

Een HTTP/2 200-regel betekent dat de server de metadata kan zien. Een curl: (28) Connection timed out betekent dat uw egress-regels de werkelijke oorzaak zijn; het bewerken van APT (advanced package tool)-bestanden zal het antwoord niet veranderen.

Als het commando volledig ontbreekt, bevindt het zich in ubuntu-release-upgrader-core. Minimale cloud-images laten dat pakket soms weg.

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 eenvoudigste 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 de volgende sectie.

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 geopend.

De vlag verandert in 1 wanneer de eerste point release uitkomt. Ubuntu 26.04.1 staat gepland voor 27 August 2026, maar releaseschema's kunnen wijzigen. Controleer daarom de metadata en niet een kalender. Een point release is geen nieuwe versie van Ubuntu, maar alleen dezelfde release met alle updates sinds de oorspronkelijke release verwerkt in nieuwe installatiemedia. Voor een actieve server is daarom niet de media zelf van belang, maar de toegang die daarmee beschikbaar komt. De vertraging is bewust: gebruikers die vroeg upgraden, vinden de blokkerende problemen. Die worden opgelost voordat de veel grotere groep LTS-servers volgt. Als die datum is verstreken wanneer u dit leest, gaat wat met 26.04.1 is uitgebracht en wat dit betekent voor een 24.04-server daar verder.

Dan blijven er twee verantwoorde opties over. Wacht op de point release. Dat is de juiste keuze voor elke server die u liever niet voortdurend controleert. Of stel Prompt=normal in. Daarmee laat u dezelfde tool verwijzen naar meta-release, waar 26.04 al als ondersteund is gemarkeerd. Met de tweede optie voert u een upgrade uit naar de uitgebrachte versie 26.04, niet naar een ontwikkelbuild. Dat is verdedigbaar op een machine die u vanaf een snapshot kunt herstellen. Zet de waarde terug naar lts wanneer u klaar bent. De procedure zelf staat stap voor stap in de volledige walkthrough voor de serverupgrade van 24.04 naar 26.04. Een server die nog op 22.04 draait, moet eerst een extra tussenstap uitvoeren. Prompt=lts biedt namelijk alleen de volgende LTS-release aan. Daarom verloopt de route van 22.04 naar 26.04 eerst via 24.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 publicaties voor de nieuwe release aanbieden; alle andere bronnen worden uitgeschakeld (gecommentarieerd). 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 meestal een waarschuwing die u kunt accepteren. Het wordt een blokkade wanneer een third-party repository een pakket levert dat ook in de nieuwe release zit, omdat de upgrade-berekening dan twee kandidaten heeft en geen manier om aan beide te 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 relevant 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 flag voor de tegenovergestelde keuze. De man-page beschrijft --allow-third-party als "Probeer de upgrade met third-party mirrors en repositories ingeschakeld in plaats van ze uit te schakelen." Gebruik dit 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 die 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, is een afzonderlijke fout met een eigen melding, behandeld in de foutmelding voor dubbele bronvermeldingen in deb822-formaat.

Vastgehouden en half geconfigureerde pakketten blokkeren de berekening

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

apt-mark showhold
sudo dpkg --audit

apt-mark showhold toont vastgehouden pakketten, één per regel, en geeft op een schoon systeem niets weer. Een 'hold' is een handmatige instructie om dat pakket nooit te wijzigen. Iemand heeft wellicht een kernel of een databaseversie vastgezet en is dat 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 geconfigureerd. Deze status ontstaat na een installatie die is onderbroken, meestal door een verbroken sessie. De upgrader probeert dit te herstellen en toont dpkg interrupted, calling dpkg --configure -a, maar door het herstel zelf uit te voeren, kunt u de foutmelding lezen in plaats van deze voorbij te zien scrollen. Een pakket dat de tool niet kan herstellen, 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. De server is dan minder actueel dan u denkt. Die optie haalt ze allemaal op. Start daarna opnieuw op als er een kernel bij zat, zodat u upgradet vanaf de kernel die u daadwerkelijk draait. Een systeem dat 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 met het teruggeven van 404 Not Found, kan het systeem niet langer worden bijgewerkt, en omdat de upgrader een actueel systeem vereist, wordt het proces afgebroken. 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 -i.bak-optie 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 zal nu weer met u communiceren.

Wees realistisch over hoe ver u hiermee komt. Ubuntu ondersteunt slechts één release-stap tegelijk, dus een server die twee of drie verouderde releases achterloopt, moet elke stap afzonderlijk doorlopen. Elke stap kan falen door een repository van derden of een vastgehouden 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 ook een rollback-mogelijkheid, wat een in-place upgrade nooit doet. Als u kiest op welk release-traject u daarna wilt zitten, is het verschil tussen LTS- en interim-releases op een server het lezen waard voordat u beslist.

Wat de development release-vlag werkelijk 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 onbruikbaar maken. Gebruik dit op een test-virtuele machine die u heeft opgezet om uw eigen configuratie te valideren. 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 risico op onderbreking door een verbroken SSH-sessie

Een release-upgrade vervangt het grootste deel van het systeem, waaronder openssh-server en systemd. Als uw SSH-sessie (secure shell) wordt verbroken terwijl dpkg actief is, wordt het proces beëindigd terwijl pakketten zijn uitgepakt en nog niet geconfigureerd. Precies die toestand voorkomt dat uw volgende poging slaagt. Als dit al is gebeurd, is een halverwege gestopte upgrade herstellen een afzonderlijke taak. Voer die taak uit voordat u het opnieuw probeert. Start de upgrade altijd binnen een terminalmultiplexer.

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 child-proces 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 de tool detecteert dat deze onder SSH draait, biedt deze aan om een tweede sshd op poort 1022 te starten. Zo blijft er een toegangsweg beschikbaar als de hoofdverbinding wegvalt. De tool bepaalt dit door de eigen parent-processen 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 als 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, wat de minst gunstige situatie is.

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

• 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 wat u niet meer heeft. 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 komt mee met de release, ongeacht of u dit had gepland.

FAQ

Waarom meldt do-release-upgrade 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 was de vlag nog steeds 0, terwijl Ubuntu 26.04.1 gepland stond 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 ontwikkelingsversie, omdat Prompt=normal het bestand meta-release leest, waar 26.04 al de waarde Supported: 1 bevat. De timing is het risico. U voert de upgrade uit voordat de blokkerende problemen die door vroege upgraders zijn gevonden, zijn opgelost. Doe dit op een server waarvan u een snapshot kunt terugzetten en waar u toegang heeft tot de console van de provider als de reboot mislukt. Zet de waarde daarna weer terug op lts.

Upgrade de -d vlag 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. De eigen serverdocumentatie van Ubuntu stelt dat de ontwikkelingsrelease niet wordt aanbevolen voor productieomgevingen, dus gebruik 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, dus 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 afkomstig zijn uit welke PPA, en installeer deze vervolgens opnieuw vanuit het archief als de PPA-versie nieuwer is dan de versie die de nieuwe release bevat.