do-release-upgrade: Keine neue Version gefunden

Warum do-release-upgrade meldet, dass keine neue Version gefunden wurde

do-release-upgrade mit No new release found. am Ende ist fast nie ein defektes Tool. Der von Ihnen angeforderte Upgrade-Pfad ist zu diesem Zeitpunkt nicht verfügbar. Das Tool meldet dies in der kürzestmöglichen Form. Fünf Ursachen können ihn blockieren: die Einstellung Prompt in /etc/update-manager/release-upgrades, die Freigabe der Point-Release-Voraussetzung bei LTS-Upgrades (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 Flag für eine reine Prüfung tatsächlich meldet

sudo do-release-upgrade -c
echo $?

-c führt nur eine Prüfung durch. Es liest die Release-Metadaten von Canonical über HTTPS (hypertext transfer protocol secure) und gibt das Ergebnis aus. Es lädt kein Upgrade-Tool herunter und schreibt keine Quelldatei neu. 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 für Skripte dasselbe Ergebnis. Er lautet 0, wenn ein Release verfügbar ist, und 1, wenn kein Release verfügbar ist. Das ist die umgekehrte Belegung der üblichen Shell-Konvention. Lesen 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 strengen Firewall für ausgehenden Datenverkehr oder hinter einem Proxy kann das Tool die Abfrage nicht durchführen. Daher kann es kein verfügbares Release erkennen.

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. Keine Änderung an APT-Dateien (advanced package tool) wird das Ergebnis ändern.

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 vor Änderungen zuerst /etc/update-manager/release-upgrades

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

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

• never: Nie nach einer neuen Version suchen und kein Upgrade auf eine neue Version zulassen.
• normal: Die unterstützte Version anbieten, die unmittelbar auf die derzeit ausgeführte Version folgt.
• lts: Die erste LTS-Version anbieten, die auf die derzeit ausgeführte Version folgt.

Prompt=never lässt sich am einfachsten 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 bewusst, damit die Systeme einer Flotte nicht auf unterschiedliche Versionen abweichen. Wenn dieser Wert dort steht, wurde er absichtlich 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 den Kommentaren führt häufig zu Verwechslungen. Wenn Prompt=lts gesetzt ist und die derzeit ausgeführte Version selbst keine LTS-Version ist, behandelt das Upgrade-Tool die Einstellung als normal. Auf einem Rechner mit 25.10 verhalten sich die beiden Werte identisch. Auf einem Rechner mit 24.04 ist das nicht der Fall. Dieser Unterschied bildet den gesamten nächsten Abschnitt.

Warum ein Upgrade von LTS zu LTS auf das 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 jedes Release in einem kleinen Block aus Schlüsseln. Der Upgrader bietet ein Release nur an, wenn sein Flag Supported: auf 1 gesetzt ist. Sie können die Dateien selbst vom selben Server abrufen:

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

Am 13. August 2026 enthielten die beiden Dateien unterschiedliche Angaben zu Ubuntu 26.04. Die LTS-Datei meldete:

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

Die normale Datei meldete:

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 Sperre. Ein 24.04-Server mit dem standardmäßigen Prompt=lts liest diese Datei, findet kein neueres LTS-Release, das als verfügbar markiert ist, und gibt No new release found. aus. Auf Ihrem System liegt kein Fehler vor. Canonical hat den Upgradepfad noch nicht freigegeben.

Das Flag wird auf 1 gesetzt, sobald das erste Point-Release veröffentlicht wird. 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. Die Verzögerung ist beabsichtigt: Nutzer, die früh aktualisieren, finden die Blocker. Diese werden behoben, bevor die deutlich größere Zahl der LTS-Server folgt.

Damit bleiben zwei sinnvolle Optionen. Warten Sie auf das Point-Release. Das ist die richtige Entscheidung für jeden Server, den Sie möglichst nicht überwachen müssen. Oder setzen Sie Prompt=normal. Damit verwendet dasselbe Tool meta-release, wo 26.04 bereits als unterstützt markiert ist. Der zweite Pfad aktualisiert auf das veröffentlichte 26.04 und nicht auf einen Entwicklungs-Build. Das ist auf einem System vertretbar, das Sie aus einem Snapshot wiederherstellen können. Setzen Sie den Wert nach Abschluss auf lts zurück. Die einzelnen Schritte finden Sie in der vollständigen Anleitung für das Server-Upgrade von 24.04 auf 26.04.

Drittanbieter-Repositories 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. Sie sind konkret: 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 keine Release-Datei für die neue Serie abrufen und deaktiviert den Eintrag. Das ist normalerweise eine Warnung, die Sie akzeptieren können. Zu einem Abbruch kommt es, wenn ein Drittanbieter-Repository ein Paket bereitstellt, das auch im neuen Release enthalten ist. Die Upgrade-Berechnung hat dann zwei mögliche Versionen und kann nicht beide Abhängigkeiten erfüllen.

Entscheiden Sie das vor dem Start selbst, statt diese Entscheidung dem Programm während eines langen unbeaufsichtigten Laufs zu überlassen.

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

Mit apt policy für einen Paketnamen sehen Sie, aus welchem Repository die jeweils installierte Version stammt. So erkennen Sie genau, welche Pakete von der Quelle abhängen, die Sie deaktivieren möchten. Das Entfernen der Quelle führt zu keinem Downgrade. Ein aus einem PPA installiertes Paket bleibt daher auf seiner PPA-Version und kann neuer sein als die Version, die das neue Release enthält. Wenn das relevant ist, entfernen Sie auch das Paket und installieren Sie es nach dem Upgrade erneut aus dem Archiv. Ein Repository, das Sie später wieder aktivieren möchten, beispielsweise das Repository von Tailscale, muss vor der erneuten Installation des Pakets auf den Codenamen des neuen Release aktualisiert werden. Das ist die Ursache für die meisten Tailscale-Installationsfehler unter Ubuntu.

Für die umgekehrte Entscheidung gibt es ein Flag. Die Handbuchseite beschreibt --allow-third-party als „Upgrade mit aktivierten Drittanbieter-Mirrors und -Repositories versuchen, statt sie auszukommentieren“. Verwenden Sie es nur, wenn Sie bestätigt haben, dass das Repository bereits Pakete für das Ziel-Release veröffentlicht. Falls nicht, weisen Sie APT an, einen Abhängigkeitsgraphen gegen 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 in /etc/apt/sources.list.d/ubuntu.sources im deb822-Format. Dasselbe Repository, das sowohl im alten als auch im neuen Format eingetragen ist, verursacht einen separaten Fehler mit einer eigenen Meldung. Dieser wird unter dem Fehler bei doppelten Quelleinträgen im deb822-Format behandelt.

Unvollständige und zurückgehaltene 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. Der Upgrader beendet den Vorgang lieber frühzeitig, als das System in einem halb aktualisierten Zustand 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 sauberen System gibt der Befehl überhaupt nichts aus. Eine Zurückhaltung ist eine manuelle Anweisung, ein Paket niemals zu ändern. Jemand hat möglicherweise eine Kernel- oder Datenbankversion festgeschrieben 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 nach dem Abbruch einer Sitzung. Der Upgrader versucht, den Zustand zu reparieren, und gibt dpkg interrupted, calling dpkg --configure -a aus. Wenn Sie die Reparatur vorher selbst ausführen, lesen Sie die Fehlermeldung direkt, statt sie beim Durchlaufen der Ausgabe zu übersehen. Wenn das Tool ein Paket nicht reparieren kann, gibt es Package in inconsistent state aus. Dieses Problem müssen Sie beheben, bevor Sie den Vorgang erneut versuchen.

Aktualisieren Sie die laufende Release-Version vollständig, bevor Sie das Upgrade starten.

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 phasenweise Updates ist wichtiger, als es zunächst scheint. Ubuntu verteilt einige Updates schrittweise an einen bestimmten Prozentsatz der Systeme. Ein einfaches apt upgrade kann daher Pakete korrekt zurücklassen. Der Server ist dann weniger aktuell, als Sie annehmen. Diese Option installiert alle Updates. Starten Sie das System anschließend neu, wenn ein Kernel enthalten war. So führen Sie das Upgrade mit dem Kernel durch, der tatsächlich ausgeführt wird. Ein System, das sich bereits über unbeaufsichtigte Sicherheitsupdates aktuell hält, hat hier weniger zu tun. Dieser Mechanismus überschreitet jedoch bewusst keine Release-Grenze.

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

Ein Interim-Release von Ubuntu wird neun Monate lang unterstützt. Nach dem Ende dieses Supports wechselt sein Supported:-Flag auf 0, und der reguläre Weg 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 abgekündigtes Release werden aus archive.ubuntu.com entfernt und unter old-releases.ubuntu.com aufbewahrt. Daher liefert apt update nun 404 Not Found zurück. Das System kann nicht mehr auf den aktuellen Stand gebracht werden. Da das Upgrade-Programm ein aktuelles System voraussetzt, 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/

Verweisen Sie sowohl archive.ubuntu.com als auch security.ubuntu.com auf old-releases.ubuntu.com. Lassen Sie den Codenamen 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 die Paketquellen noch in dieser einzelnen Datei speichert. Die Option -i.bak legt eine Sicherung neben der Originaldatei an. Dadurch können Sie die Datei wiederherstellen, falls die Änderung auf die falsche Datei angewendet wurde. Ein sauberes apt update danach bedeutet, dass das Archiv wieder erreichbar ist. do-release-upgrade kann nun wieder mit dem Archiv kommunizieren.

Seien Sie realistisch, wie weit Sie damit kommen. Ubuntu unterstützt jeweils nur einen Release-Schritt. Ein Server, der zwei oder drei abgelaufene Releases zurückliegt, muss daher jeden Schritt nacheinander durchlaufen. Jeder Schritt kann an einem eigenen Drittanbieter-Repository oder einem eigenen zurückgehaltenen Paket scheitern. Auf einem VPS ist es oft schneller, einen neuen Server mit dem aktuellen LTS aufzusetzen, den Dienst zu übertragen und den alten Server beizubehalten, bis Sie sicher sind. Das bietet außerdem einen Rollback, den ein Upgrade im laufenden System nicht ermöglicht. Wenn Sie anschließend entscheiden, welchen Release-Zweig Sie verwenden möchten, sollten Sie vor der Entscheidung den Unterschied zwischen LTS- und Interim-Releases auf einem Server lesen.

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

-d oder --devel-release weist den Upgrader an, meta-release-development statt der von Prompt ausgewählten Datei einzulesen. Die Manualpage beschreibt dies als: „Wenn das aktuell unterstützte Release verwendet wird, auf das Development-Release aktualisieren.“

Am 13. August 2026 geprüft, ist 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 Schalter 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-Release. Wer sie jetzt wiederholt, verweist den Server auf ein anderes Ziel als beabsichtigt. Wenn Prompt=lts weiterhin gesetzt ist, beendet sich der Schalter mit einer eigenen Meldung:

There is no development version of an LTS available.

Die Ubuntu-Serverdokumentation weist ausdrücklich auf die Einschränkung des Schalters hin: „Die Verwendung des Development-Release (oder des Schalters -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, am Nachmittag einen Dienst außer Betrieb setzen. 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, von dem andere abhängig sind. Wenn Sie ein veröffentlichtes 26.04 vor dem Öffnen des LTS-Gateways benötigen, ist Prompt=normal der richtige Weg.

Führen Sie das Upgrade dort aus, wo eine unterbrochene 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 beendet wird, wird der Prozess mit entpackten, aber nicht konfigurierten Paketen beendet. Genau dieser Zustand verhindert meist den nächsten Versuch. 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 für Benutzer ohne Multiplexer über eine eigene Absicherung. Wenn es erkennt, dass es unter SSH läuft, bietet es an, einen zweiten sshd auf Port 1022 zu starten. Dadurch bleibt bei einem Abbruch der Hauptsitzung eine weitere Zugriffsmöglichkeit bestehen. Zur Erkennung durchsucht es seine übergeordneten Prozesse nach einem Prozess namens sshd. Innerhalb von tmux oder screen findet diese Suche stattdessen den Multiplexer-Server. Das Angebot wird daher nicht angezeigt. Die PID-Datei /var/run/release-upgrader-sshd.pid wird nur geschrieben, wenn der zusätzliche Daemon tatsächlich gestartet wird. Wenn Sie die Abfrage nicht sehen, liegt kein Fehler 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-Provider betreiben zusätzlich eine Firewall in ihrem Control Panel außerhalb des Betriebssystems. Port 1022 muss dort ebenfalls geöffnet sein. Andernfalls läuft der Fallback-Listener, ist aber nicht erreichbar. Das ist der ungünstigste Fall.

Vor der Eingabe des Befehls müssen vier Dinge vorbereitet sein:

• Erstellen Sie einen Snapshot oder ein vollständiges Backup. Ein In-Place-Release-Upgrade kann nicht rückgängig gemacht werden. Dieses Backup ist die einzige Rückfallmöglichkeit.
• Stellen Sie sicher, dass Sie die Konsole Ihres Providers ö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. Es wird in einem VPS, der nach einem Kernel-Update nicht bootet behandelt.
• 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 dafür, dass der Vorgang nicht fortgesetzt werden kann.
• Lesen Sie die Release Notes für die von Ihnen betriebenen Dienste. Ein Sprung auf eine neue Hauptversion von PostgreSQL oder PHP kommt mit dem Release, unabhängig davon, ob Sie ihn eingeplant haben.

FAQ

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

Der Standardwert Prompt=lts in /etc/update-manager/release-upgrades sorgt dafür, dass das Tool https://changelogs.ubuntu.com/meta-release-lts liest. Ubuntu 26.04 enthält in dieser Datei bis zur ersten Point Release den Wert Supported: 0. Der Upgrader findet daher keine neuere verfügbare LTS-Version und beendet sich. Prüfen Sie die Datei mit curl -s https://changelogs.ubuntu.com/meta-release-lts selbst und lesen Sie den letzten Block. Am 13. August 2026 war der Wert weiterhin 0 gesetzt. 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 Development Build, weil Prompt=normal den Wert meta-release liest. Dort ist 26.04 bereits mit Supported: 1 eingetragen. Das Risiko liegt im Zeitpunkt. Sie führen das Upgrade durch, bevor die von frühen Anwendern gefundenen Probleme behoben wurden. Tun Sie das auf einem Server, den Sie aus einem Snapshot wiederherstellen können und bei dem Sie die Provider-Konsole erreichen, 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 war dort 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 Development-Version nicht für den Produktivbetrieb. Verwenden Sie daher Prompt=normal, wenn Sie frühzeitig auf eine veröffentlichte Version 26.04 aktualisieren möchten.

apt update gibt bei einer alten Version 404-Fehler aus. Wie kann ich sie aktualisieren?

Diese Version hat das Ende ihrer Lebensdauer erreicht. Daher 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 Strukturen in /etc/apt/sources.list. Behalten Sie den Codename unverändert bei. 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, die Quellen vorher selbst zu deaktivieren. So bestimmen Sie die Reihenfolge und sehen das Ergebnis direkt. Führen Sie apt policy für die relevanten Pakete aus, um zu ermitteln, welche Pakete aus den einzelnen PPAs stammen. Installieren Sie diese anschließend aus dem Archiv neu, wenn die PPA-Version neuer ist als die Version, die die neue Version enthält.