do-release-upgrade: Keine neue Version gefunden

Warum do-release-upgrade keine neue Version findet

do-release-upgrade mit dem Ende No new release found. ist fast nie ein defektes Tool. Der angeforderte Upgrade-Pfad ist zu diesem Zeitpunkt geschlossen, und das Tool meldet dies auf möglichst kurze Weise. Fünf Dinge können ihn schließen: die Einstellung Prompt in /etc/update-manager/release-upgrades, die Point-Release-Sperre bei Upgrades zwischen LTS-Versionen (Long Term Support), Drittanbieter-Repositorys, zurückgehaltene oder nur teilweise konfigurierte Pakete sowie eine Version, deren Supportzeitraum abgelaufen ist.

Prüfen Sie diese Ursachen in dieser Reihenfolge. Für jede Ursache gibt es einen Befehl, mit dem Sie feststellen können, ob sie auf Ihren Server zutrifft. Sie müssen daher nicht raten, welche der fünf Ursachen vorliegt.

Was das Check-only-Flag tatsächlich meldet

sudo do-release-upgrade -c
echo $?

-c führt ausschließlich eine Prüfung durch. Der Befehl liest die Release-Metadaten von Canonical über HTTPS (hypertext transfer protocol secure) ein und gibt das Ergebnis aus. Es wird kein Upgrade-Tool heruntergeladen und keine Quelldatei geändert. Zwei Ausgaben sind relevant:

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.

Der Exit-Code enthält dieselbe Information für Skripte. Er lautet 0, wenn ein Release verfügbar ist, und 1, wenn kein Release verfügbar ist. Das ist das Gegenteil der üblichen Shell-Konvention. Prüfen Sie den Wert daher sorgfältig, bevor Sie darauf eine Prüfung aufbauen.

Wenn Ihr Login-Banner weiterhin das alte Ergebnis anzeigt, ist es zwischengespeichert. Diese Zeile stammt von /etc/update-motd.d/91-release-upgrade. Der Befehl gibt ein gespeichertes Ergebnis aus, statt das Netzwerk abzufragen. Aktualisieren Sie es mit sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd, oder verlassen Sie sich einfach auf -c. Das Banner wiederholt nur das Ergebnis der letzten ausgeführten Prüfung.

Die Prüfung muss außerdem changelogs.ubuntu.com erreichen können. Auf einem Server hinter einer restriktiven Firewall für ausgehenden Datenverkehr oder hinter einem Proxy kann das Tool die Abfrage nicht durchführen. Es kann dann keine verfügbaren Releases ermitteln.

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

Eine Zeile mit HTTP/2 200 bedeutet, dass der Server die Metadaten erreichen kann. Ein curl: (28) Connection timed out bedeutet, dass Ihre Regeln für ausgehenden Datenverkehr die tatsächliche Ursache sind. Auch Änderungen an APT-Dateien (advanced package tool) ändern daran nichts.

Wenn der Befehl vollständig fehlt, befindet er sich in ubuntu-release-upgrader-core. Bei minimalen Cloud-Images fehlt dieses Paket manchmal.

sudo apt install ubuntu-release-upgrader-core

Lesen Sie /etc/update-manager/release-upgrades, bevor Sie Änderungen vornehmen

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

Die Datei enthält eine eigene Dokumentation in Form von Kommentaren. Drei Werte sind gültig:

• never: Nie nach einem Upgrade auf eine neue Version suchen und ein solches Upgrade nie zulassen.
• normal: Die unterstützte Version anbieten, die unmittelbar auf die laufende Version folgt.
• lts: Die erste LTS-Version anbieten, die auf die laufende Version folgt.

Prompt=never lässt sich am einfachsten von den drei Werten diagnostizieren, weil das Tool in seiner Ausgabe sowohl die Datei als auch die Einstellung nennt:

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

Hosting-Provider und Configuration-Management-Tools setzen never absichtlich, damit eine Serverflotte nicht unkontrolliert zwischen Versionen abweicht. Wenn Sie diesen Wert dort finden, wurde er bewusst gesetzt. Ändern Sie ihn auf lts, wenn der Server dem Long-Term-Support-Zweig folgen soll. Setzen Sie ihn anschließend zurück, wenn Ihre Automatisierung den alten Wert erwartet.

Ein Detail in diesen Kommentaren führt häufig zu Problemen. Wenn Prompt=lts gesetzt ist und die laufende Version selbst keine LTS-Version ist, behandelt das Upgrade-Programm die Einstellung als normal. Auf einem Rechner mit 25.10 verhalten sich die beiden Werte identisch. Auf einem Rechner mit 24.04 tun sie das nicht. Dieser Unterschied ist der gesamte Inhalt des nächsten Abschnitts.

Warum ein LTS-zu-LTS-Upgrade auf die erste Point-Release wartet

Prompt legt fest, welche Metadatendatei der Upgrader liest. Die Adressen stehen 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 liest meta-release-lts. Prompt=normal liest meta-release. Beide Dateien beschreiben jede Version in einem kleinen Block aus Schlüsseln. Der Upgrader bietet eine Version nur an, wenn ihr Supported:-Flag auf 1 gesetzt ist. Lesen Sie die Dateien selbst vom selben 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

Bei einer Prüfung am 13. August 2026 enthielten die beiden Dateien unterschiedliche Angaben zu Ubuntu 26.04. Die LTS-Datei enthält:

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

Die allgemeine Datei enthält:

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

Dieses Supported: 0 in der LTS-Datei ist die Freigabesperre. Ein Server mit 24.04, der das standardmäßige Prompt=lts verwendet, liest diese Datei, findet keine neuere LTS-Version, die als verfügbar markiert ist, und gibt No new release found. aus. Mit Ihrem System ist nichts falsch. Canonical hat den Upgrade-Pfad noch nicht freigegeben.

Das Flag wechselt zu 1, sobald das erste Point Release erscheint. Ubuntu 26.04.1 ist für den 27. August 2026 geplant. Release-Zeitpläne können sich ändern. Prüfen Sie daher die Metadaten statt eines Kalenders. Ein Point Release ist keine neue Ubuntu-Version. Es ist dieselbe Version mit allen seit dem Start veröffentlichten Updates in einem neuen Installationsmedium. Für einen laufenden Server ist daher nicht das Medium selbst entscheidend, sondern die dadurch geöffnete Möglichkeit. Die Verzögerung ist beabsichtigt: Wer früh aktualisiert, findet die Blocker. Diese werden behoben, bevor die deutlich größere Zahl an LTS-Servern folgt. Wenn dieses Datum beim Lesen bereits verstrichen ist, führt der Inhalt von 26.04.1 und seine Bedeutung für einen 24.04-Server die Erläuterung dort weiter.

Damit bleiben zwei vertretbare Optionen. Warten Sie auf das Point Release. Das ist die richtige Entscheidung für jeden Server, den Sie nicht laufend überwachen möchten. Oder setzen Sie Prompt=normal. Dadurch verwendet dasselbe Tool meta-release als Ziel, wo 26.04 bereits als unterstützt markiert ist. Der zweite Weg aktualisiert das System auf die veröffentlichte Version 26.04 und nicht auf einen Entwicklungsstand. Er ist daher auf einem Rechner vertretbar, den Sie aus einem Snapshot wiederherstellen können. Setzen Sie den Wert nach Abschluss wieder auf lts zurück. Die Vorgehensweise ist Schritt für Schritt in der vollständigen Anleitung zum Server-Upgrade von 24.04 auf 26.04 beschrieben. Ein Server mit 22.04 muss einen zusätzlichen Zwischenschritt durchführen, weil Prompt=lts immer nur das nächste LTS-Release anbietet. Daher führt der Weg von 22.04 zu 26.04 zunächst über 24.04.

Drittanbieter-Repositorys und PPAs, die das Upgrade blockieren

Das Upgrade-Programm schreibt Ihre APT-Quellen so um, dass sie auf das neue Release verweisen. Das ist nur für ein Repository möglich, das Pakete für das neue Release veröffentlicht. Alle anderen Einträge werden auskommentiert. Die Gründe werden für jeden Eintrag in einer eigenen Zeile ausgegeben und sind eindeutig: was disabled (unknown mirror), was disabled (unknown dist) und was disabled (no Release file).

Ein PPA (Personal Package Archive), das für noble erstellt wurde, hat auf dem Server kein Verzeichnis für resolute. Das Upgrade-Programm kann daher für die neue Serie keine Release-Datei abrufen und deaktiviert den Eintrag. Das ist normalerweise eine Warnung, die Sie akzeptieren können. Zum Abbruch kommt es, wenn ein Drittanbieter-Repository ein Paket bereitstellt, das auch im neuen Release enthalten ist. Die Upgrade-Berechnung hat dann zwei Kandidaten und kann nicht beide Abhängigkeiten erfüllen.

Entscheiden Sie das selbst, bevor Sie beginnen. Überlassen Sie diese Entscheidung nicht dem Tool während eines langen unbeaufsichtigten Laufs.

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

apt policy mit einem Paketnamen zeigt, aus welchem Repository die einzelnen installierten Versionen stammen. So sehen Sie genau, welche Pakete von der Quelle abhängen, die Sie deaktivieren möchten. Durch das Entfernen der Quelle wird kein Paket zurückgestuft. Ein aus einem PPA installiertes Paket bleibt daher auf seiner PPA-Version und kann neuer sein als die Version im neuen Release. Wenn das relevant ist, entfernen Sie das Paket ebenfalls und installieren Sie es nach dem Upgrade erneut aus dem Archiv. Wenn Sie ein Repository später wieder aktivieren möchten, beispielsweise das Repository von Tailscale, müssen Sie dessen Codename vor der erneuten Paketinstallation auf das neue Release aktualisieren. Daher entstehen die meisten Tailscale-Installationsfehler unter Ubuntu.

Für die entgegengesetzte Entscheidung gibt es ein Flag. Die Handbuchseite beschreibt --allow-third-party als „Das Upgrade mit aktivierten Drittanbieter-Mirrors und -Repositorys versuchen, anstatt diese auszukommentieren.“ Verwenden Sie es nur, wenn Sie bestätigt haben, dass das Repository bereits Pakete für das Ziel-Release veröffentlicht. Andernfalls weisen Sie APT an, einen Abhängigkeitsgraphen für eine Serie aufzulösen, für die dieses Repository noch nie Pakete erstellt hat.

Unter Ubuntu 24.04 und höher befinden sich die meisten Quellen im deb822-Format in /etc/apt/sources.list.d/ubuntu.sources. Dasselbe Repository, das sowohl im alten als auch im neuen Format eingetragen ist, verursacht einen separaten Fehler mit einer eigenen Meldung. Dieser Fall wird unter dem Fehler zu doppelten Quelleinträgen im deb822-Format behandelt.

Zurückgehaltene und halb konfigurierte Pakete verhindern die Berechnung

Ein Release-Upgrade muss fast jedes Paket auf dem System aktualisieren. Wenn ein Paket nicht aktualisiert werden kann, schlägt die Berechnung fehl. Das Upgrade-Programm beendet den Vorgang lieber frühzeitig, als das System in einem Zwischenzustand zu hinterlassen. Zwei Befehle ermitteln die Ursache.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold gibt zurückgehaltene Pakete jeweils in einer eigenen Zeile aus. Auf einem fehlerfreien System gibt der Befehl überhaupt nichts aus. Eine Zurückhaltung ist eine manuelle Anweisung, ein Paket niemals zu ändern. Jemand hat möglicherweise einen Kernel oder eine Datenbankversion festgelegt und dies anschließend vergessen. Heben Sie die Zurückhaltung nicht mehr benötigter Pakete mit sudo apt-mark unhold gefolgt vom Paketnamen auf.

dpkg --audit listet Pakete auf, die entpackt, aber noch nicht konfiguriert wurden. Dieser Zustand entsteht durch eine unterbrochene Installation, meistens durch eine abgebrochene Sitzung. Das Upgrade-Programm versucht, diesen Zustand zu reparieren, und gibt dpkg interrupted, calling dpkg --configure -a aus. Wenn Sie die Reparatur vorher selbst ausführen, können Sie die Fehlermeldung direkt lesen, anstatt sie beim Durchlaufen der Ausgabe zu übersehen. Ein Paket, das das Werkzeug nicht reparieren kann, erzeugt die Meldung Package in inconsistent state. Dieses Problem müssen Sie beheben, bevor Sie den Vorgang erneut versuchen.

Bringen Sie das laufende Release vollständig auf den aktuellen Stand, bevor Sie es aktualisieren.

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

Die Option für gestaffelte Updates ist wichtiger, als es zunächst scheint. Ubuntu verteilt einige Updates nach und nach an einen bestimmten Prozentsatz der Systeme. Daher kann apt upgrade Pakete korrekt zurücklassen. Der Server ist dann weniger aktuell, als Sie annehmen. Diese Option installiert alle verfügbaren Updates. Starten Sie das System anschließend neu, wenn ein Kernel installiert wurde. So führen Sie das Upgrade mit dem Kernel durch, der tatsächlich ausgeführt wird. Ein System, das sich bereits über unbeaufsichtigte Sicherheitsupdates selbst aktualisiert, hat hier weniger zu tun. Dieser Mechanismus überschreitet jedoch absichtlich keine Release-Grenze.

Wenn das Release das Ende des regulären Supports überschritten hat

Ein Interim-Ubuntu-Release wird neun Monate lang unterstützt. Nach Ablauf dieses Supports wechselt sein Supported:-Flag auf 0, und der normale Upgrade-Pfad bietet dafür kein Upgrade an. Am 13. August 2026 geprüft, sagt meta-release Folgendes über 25.10:

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

Gleichzeitig ändert sich das Archiv. Pakete für ein End-of-Life-Release werden aus archive.ubuntu.com entfernt und unter old-releases.ubuntu.com aufbewahrt. Deshalb liefert apt update jetzt 404 Not Found zurück, das System kann nicht mehr auf den aktuellen Stand gebracht werden, und da der Upgrader auf einem aktuellen System besteht, wird der Vorgang nicht fortgesetzt. Korrigieren Sie zuerst die Paketquellen.

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

Setzen Sie sowohl archive.ubuntu.com als auch security.ubuntu.com auf old-releases.ubuntu.com, und lassen Sie den Codename unverändert. Nur der Hostname ändert sich.

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

Führen Sie stattdessen denselben Befehl für /etc/apt/sources.list aus, wenn Ihr Server seine Paketquellen noch in dieser einzelnen Datei verwaltet. Die Option -i.bak legt neben der Originaldatei eine Sicherung an. So können Sie sie wiederherstellen, falls die Änderung auf die falsche Datei angewendet wurde. Ein sauberes apt update danach bedeutet, dass das Archiv wieder erreichbar ist, und do-release-upgrade kann nun mit dem Upgrade beginnen.

Seien Sie realistisch, wie weit Sie damit kommen. Ubuntu unterstützt jeweils nur einen Release-Schritt. Ein Server, der zwei oder drei veraltete Releases zurückliegt, benötigt daher jeden Schritt nacheinander. Jeder dieser Schritte kann an einem eigenen Drittanbieter-Repository oder an einem eigenen zurückgehaltenen Paket scheitern. Auf einem VPS ist es häufig schneller, einen neuen Server mit dem aktuellen LTS zu erstellen, den Dienst zu verschieben und den alten Server zu behalten, bis Sie sicher sind. Dadurch erhalten Sie außerdem eine Rollback-Möglichkeit, die ein Upgrade an Ort und Stelle niemals bietet. Wenn Sie anschließend entscheiden, welchen Release-Zweig Sie verwenden möchten, sollten Sie den Unterschied zwischen LTS- und Interim-Releases auf einem Server lesen, bevor Sie sich entscheiden.

Was der Flag für das Development-Release tatsächlich bewirkt

-d oder --devel-release veranlasst den Upgrader, meta-release-development statt der von Prompt ausgewählten Datei zu lesen. Die Manualpage beschreibt dies so: „Wenn das neueste unterstützte Release verwendet wird, auf das Development-Release aktualisieren.“

Am 13. August 2026 geprüft, lautet der neueste Eintrag in dieser Datei nicht 26.04:

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

-d installiert auf einem 24.04-Server daher nicht das veröffentlichte 26.04. Der Befehl zielt auf 26.10, ein Release, das noch zusammengestellt wird. Die ältere Empfehlung, einfach „-d hinzuzufügen“, bezog sich auf den Zeitraum vor der Veröffentlichung eines LTS-Releases. Wenn Sie diese Empfehlung jetzt wiederholen, verweist sie Ihren Server auf ein Release, das Sie nicht beabsichtigt haben. Wenn Prompt=lts weiterhin gesetzt ist, beendet sich der Flag mit einer eigenen Meldung:

There is no development version of an LTS available.

Die Ubuntu-Serverdokumentation formuliert die Warnung zu diesem Flag eindeutig: „Die Verwendung des Development-Releases (oder des Flags -d) wird für Produktionsumgebungen nicht empfohlen.“ Ein Development-Release ändert sich täglich und bietet keine Zusage für Security-Support. Daher kann ein Paket, das morgens funktioniert, nachmittags einen Dienst ausfallen lassen. Verwenden Sie es auf einer temporären virtuellen Maschine, die Sie zum Testen Ihrer eigenen Konfiguration eingerichtet haben. Verwenden Sie es nicht auf einem Server, auf den andere angewiesen sind. Wenn Sie ein veröffentlichtes 26.04 verwenden möchten, bevor das LTS-Gate geöffnet wird, ist Prompt=normal der richtige Weg.

Führen Sie das Upgrade in einer Umgebung aus, in der eine getrennte SSH-Sitzung es nicht abbrechen kann

Ein Release-Upgrade ersetzt den größten Teil des Systems, einschließlich openssh-server und systemd. Wenn Ihre SSH-Sitzung (Secure Shell) während der Arbeit von dpkg abbricht, wird der Prozess beendet, während Pakete entpackt und nicht konfiguriert sind. Genau dieser Zustand verhindert den nächsten Versuch. Wenn das bereits geschehen ist, ist die Wiederherstellung eines Upgrades, das auf halbem Weg abgebrochen wurde eine separate Aufgabe. Sie muss vor jedem zweiten Versuch erledigt werden. Starten Sie das Upgrade immer innerhalb eines Terminal-Multiplexers.

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

Wenn die Verbindung abbricht, melden Sie sich erneut an und führen Sie tmux attach -t upgrade aus. Das Upgrade lief weiter, weil es ein Kindprozess des tmux-Servers und nicht Ihrer SSH-Sitzung ist. screen -S upgrade und screen -r upgrade erfüllen dieselbe Aufgabe, wenn Sie screen bevorzugen.

Das Upgrade-Programm verfügt auch für Benutzer ohne Multiplexer über eine eigene Absicherung. Wenn es erkennt, dass es unter SSH ausgeführt wird, bietet es an, einen zweiten sshd auf Port 1022 zu starten. Dadurch bleibt bei einem Abbruch der Hauptsitzung weiterhin ein Zugangsweg verfügbar. Die Entscheidung basiert auf der Untersuchung der eigenen übergeordneten Prozesse nach einem Prozess mit dem Namen sshd. Innerhalb von tmux oder screen findet diese Untersuchung stattdessen den Multiplexer-Server. Das Angebot wird daher nicht angezeigt, und die PID-Datei /var/run/release-upgrader-sshd.pid wird nur geschrieben, wenn der zusätzliche Daemon tatsächlich gestartet wird. Wenn die Abfrage nicht angezeigt wird, liegt kein Problem vor. Sie verfügen bereits über den besseren Schutz.

Wenn Sie das Angebot annehmen, wird der Port nicht automatisch geöffnet. Das Programm weist ausdrücklich darauf hin, weil das Öffnen eines Ports eine Sicherheitsentscheidung ist, die es nicht in Ihrem Namen treffen darf. Öffnen Sie den Port für die Dauer des Upgrades und schließen Sie ihn anschließend wieder.

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

Die meisten VPS-Anbieter betreiben zusätzlich eine Firewall in ihrem Control Panel außerhalb des Betriebssystems. Port 1022 muss auch dort geöffnet sein. Andernfalls läuft der Fallback-Listener, ist aber nicht erreichbar. Das ist die ungünstigste Kombination.

Vor der Eingabe des Befehls müssen vier Voraussetzungen erfüllt sein:

• Erstellen Sie einen Snapshot oder ein vollständiges Backup. Ein In-Place-Release-Upgrade kann nicht rückgängig gemacht werden. Dies ist die einzige Rückfallmöglichkeit.
• Stellen Sie sicher, dass Sie die Konsole Ihres Anbieters öffnen können, bevor Sie sie benötigen. Wenn der Server nach dem Reboot nicht wieder startet, steht Ihnen ausgerechnet SSH nicht zur Verfügung. Ein Kernel, der nicht bootet, ist ein separates Problem mit eigenen Wiederherstellungsschritten. Diese werden unter ein VPS, der nach einem Kernel-Update nicht bootet beschrieben.
• Prüfen Sie den freien Speicherplatz mit df -h / /boot. Das Upgrade lädt einen vollständigen Paketsatz herunter. Eine /boot-Partition mit mehreren alten Kernels ist ein häufiger Grund, warum der Vorgang stecken bleibt.
• Lesen Sie die Release Notes für die von Ihnen betriebenen Dienste. Ein Sprung auf eine neue Hauptversion von PostgreSQL oder PHP wird zusammen mit dem Release eingespielt, unabhängig davon, ob Sie dafür geplant haben.

FAQ

Warum meldet do-release-upgrade auf Ubuntu 24.04, dass keine neue Version gefunden wurde?

Der Standardwert Prompt=lts in /etc/update-manager/release-upgrades veranlasst das Tool, https://changelogs.ubuntu.com/meta-release-lts zu lesen. Ubuntu 26.04 enthält in dieser Datei bis zur ersten Point Release den Wert Supported: 0. Der Upgrader findet keine neuere verfügbare LTS-Version und beendet sich daher. Prüfen Sie die Datei mit curl -s https://changelogs.ubuntu.com/meta-release-lts selbst und lesen Sie den letzten Block. Bei einer Prüfung am 13. August 2026 war der Wert weiterhin 0. Ubuntu 26.04.1 war für den 27. August 2026 geplant.

Ist es sicher, statt auf die Point Release zu warten, Prompt=normal zu setzen?

Damit aktualisieren Sie auf die veröffentlichte Version 26.04 und nicht auf einen Entwicklungsstand, weil Prompt=normal meta-release liest und 26.04 dort bereits Supported: 1 enthält. Das Risiko liegt im Zeitpunkt. Sie führen das Upgrade durch, bevor die von frühen Upgrades gefundenen Probleme behoben wurden. Tun Sie dies auf einem Server, den Sie aus einem Snapshot wiederherstellen können und bei dem Sie die Provider-Konsole erreichen können, falls der Reboot fehlschlägt. Setzen Sie den Wert anschließend wieder auf lts zurück.

Aktualisiert mich das Flag -d auf 26.04?

Nein. -d liest meta-release-development. Der neueste Eintrag dort war am 13. August 2026 Ubuntu 26.10, also eine noch in Entwicklung befindliche Version. Auf einem LTS-System mit Prompt=lts gibt das Flag There is no development version of an LTS available. aus und beendet sich. Die Ubuntu-Serverdokumentation empfiehlt die Entwicklungsversion nicht für den Produktivbetrieb. Verwenden Sie daher Prompt=normal, wenn Sie 26.04 frühzeitig als veröffentlichte Version installieren möchten.

apt update gibt bei einer alten Version 404-Fehler zurück. Wie führe ich das Upgrade durch?

Diese Version hat das Ende ihrer Lebensdauer erreicht. Deshalb wurden ihre Pakete von archive.ubuntu.com nach old-releases.ubuntu.com verschoben. Ändern Sie nur die Hostnamen in /etc/apt/sources.list.d/ubuntu.sources oder bei älteren Layouts in /etc/apt/sources.list. Lassen Sie den Codenamen unverändert. Führen Sie anschließend sudo apt update und sudo apt full-upgrade aus. Sobald das System wieder aktuell ist, kann do-release-upgrade es jeweils um eine Version weiter aktualisieren.

Muss ich meine PPAs vor dem Ausführen von do-release-upgrade entfernen?

Nein. Der Upgrader kommentiert jede Quelle aus, die keine Pakete für die neue Version veröffentlicht, und gibt für jede Quelle eine Zeile wie was disabled (no Release file) aus. Besser ist es, dies vorher selbst zu erledigen. So bestimmen Sie die Reihenfolge und sehen das Ergebnis unmittelbar. Führen Sie apt policy für die relevanten Pakete aus, um festzustellen, welche davon aus den einzelnen PPAs stammen. Installieren Sie diese anschließend aus dem Archiv neu, wenn die PPA-Version neuer ist als die Version, die in der neuen Version enthalten ist.