Ubuntu 26.04 auf 24.04 zurücksetzen: Geht das?

Können Sie Ubuntu 26.04 auf 24.04 zurückstufen?

Sie können Ubuntu 26.04 nicht direkt auf 24.04 zurückstufen. Kein Tool, kein do-release-upgrade-Flag und keine apt-Einstellung kann einen Server auf eine frühere Version zurücksetzen. Um zu 24.04 zurückzukehren, können Sie den Snapshot oder das Backup wiederherstellen, den bzw. das Sie vor dem Upgrade erstellt haben. Sie können auch einen neuen 24.04-Server bereitstellen und Ihre Daten darauf übertragen. Oft ist es die bessere Lösung, bei 26.04 zu bleiben und die einzelne Ursache des Problems zu beheben.

Dieser Leitfaden ordnet diese Möglichkeiten nach ihrem Aufwand. Außerdem wird erklärt, warum das Zurücksetzen der apt-Quellen auf noble, den Codenamen von 24.04, keine Zurückstufung bewirkt. Ihre Datenbank bestimmt meist, welchen Weg Sie wählen können.

Was die offiziellen Ubuntu-Seiten zum Zurücksetzen sagen

Der offizielle Ubuntu-Server-Leitfaden „How to upgrade your Ubuntu release“ enthält keinen Abschnitt zum Downgrade oder Zurücksetzen. Der einzige Sicherheitshinweis lautet, zuerst ein Backup zu erstellen: „Es ist äußerst wichtig, die Daten sicher an einen Backup-Speicherort zu kopieren, damit sie bei Problemen wiederhergestellt werden können.“ Mit der Wiederherstellung ist eine Wiederherstellung aus diesem Backup gemeint.

Im offiziellen Ubuntu-Discourse-Forum fragte ein Benutzer, wie er ohne Löschen der Festplatte von 24.04 auf 22.04 zurückkehren kann. Keine der Antworten ist als offizielle Stellungnahme von Canonical gekennzeichnet. Alle stimmen darin überein, dass es kein In-Place-Downgrade gibt. Eine Antwort weist darauf hin, dass es keine „Downgrade“-Funktion gibt, die einer „Upgrade“-Funktion entspricht, und auch keine Möglichkeit, ein Upgrade rückgängig zu machen. Eine andere Antwort sagt, dass dies „by design impossible“ sei, weil das deb-Paketsystem anhand der Paketversionsnummern nur vorwärts arbeiten könne. Eine weitere Antwort empfiehlt, ein Backup der älteren Version wiederherzustellen. Ein Kommentator schreibt außerdem: „Ich habe Systeme selbst nicht destruktiv neu installiert und bin dabei zurückgegangen.“ Gemeint ist eine Neuinstallation der älteren Version, bei der die Daten erhalten bleiben. Derselbe Kommentator warnt, dass Sie jede Anwendung und ihre Daten berücksichtigen müssen, weil neuere Software Änderungen vornehmen kann, mit denen die ältere Software nicht umgehen kann.

Das unterstützte Werkzeug arbeitet also nur vorwärts. Wenn das Upgrade fehlschlägt, verweist die Dokumentation auf Ihr Backup.

Warum ein Release-Upgrade nicht rückwärts ausgeführt werden kann

Ein Release-Upgrade besteht aus Tausenden gemeinsam ausgeführten Paket-Upgrades. Jedes davon ist ein Schritt vorwärts. Drei Fakten verhindern, dass Sie diese Schritte zurückgehen.

dpkg prüft Abhängigkeiten bei einem Downgrade nicht. dpkg ist das Werkzeug auf niedriger Ebene, das .deb-Dateien installiert. Das dpkg-Handbuch für 24.04 sagt es eindeutig: „At present dpkg does not do any dependency checking on downgrades.“ Das Downgrade selbst ist standardmäßig zulässig. Daher legt dpkg ein älteres Paket auf der Festplatte ab, auch wenn ein anderes installiertes Paket die neuere Version benötigt. Ein Release besteht aus einer großen Gruppe voneinander abhängiger Pakete. Es ist daher nicht sicher, das Upgrade Paket für Paket umzukehren.

Paket-Skripte wurden bereits ausgeführt. Ein Paket kann Maintainer-Skripte enthalten. Das sind kleine Programme, die vor und nach der Installation ausgeführt werden. Während eines Upgrades können sie Konfigurationen oder Daten umschreiben, damit die neue Version sie verwenden kann. Die spätere Installation des alten Pakets macht diese Änderungen nicht rückgängig. Das alte Programm kann dann Dateien in einem Format vorfinden, das ihm nicht bekannt ist.

Dienste können auf eine neue Hauptversion umgestellt worden sein. Das Standardpaket postgresql in 24.04 hängt von PostgreSQL 16 ab. In 26.04 hängt es von PostgreSQL 18 ab. Das Standardpaket mysql-server wechselt von MySQL 8.0 in 24.04 zu MySQL 8.4 in 26.04. Eine Hauptversion einer Datenbank kann ändern, wie sie Daten auf der Festplatte speichert. Das PostgreSQL-Handbuch sagt, dass Methoden zur Sicherung auf Dateisystemebene beim Wechsel zwischen Hauptversionen „will not work“. PostgreSQL verfügt außerdem über Prüfungen, die den Start eines Servers mit einem Datenverzeichnis aus einer inkompatiblen Version verhindern. Diese Prüfung schützt Ihre Daten. Sie bedeutet jedoch auch, dass die alten Binärdateien die neuen Daten nicht einfach lesen können.

Die gleiche Begründung gilt für einen Desktop. Ein Desktop enthält lediglich mehr Pakete, die voneinander abhängen.

Prüfen, was das Upgrade tatsächlich geändert hat

Bevor Sie sich für einen Weg entscheiden, prüfen Sie, was sich geändert hat. Führen Sie diese Befehle auf dem 26.04-Server aus:

lsb_release -ds
uname -r
ls /boot/vmlinuz-*
pg_lsclusters
mysql --version

lsb_release -ds sollte den Release-Namen von 26.04 ausgeben. ls /boot/vmlinuz-* zeigt, welche Kernel installiert sind. Das ist für Weg 3 relevant. pg_lsclusters ist vorhanden, wenn PostgreSQL aus den Ubuntu-Paketen stammt. Der Befehl listet jeden Cluster mit Version, Port und Datenverzeichnis auf. Ein Cluster der Version 18, der Ihre Daten enthält, bedeutet, dass Ihre Daten jetzt im neuen Format vorliegen. Wird weiterhin nur ein Cluster der Version 16 angezeigt, wurde dieser Cluster durch das Upgrade nicht verschoben. Prüfen Sie in diesem Fall, welche Binärdateien ihn bereitstellen, bevor Sie fortfahren.

mysql --version gibt nur die Client-Version aus. Der Befehl fragt den Server nicht ab. Ein Ergebnis mit 8.4 beweist daher nicht, dass der Server verschoben wurde. Um die Version des laufenden Servers anzuzeigen, fragen Sie ihn mit sudo mysql -e 'SELECT VERSION();' ab. Ein Ergebnis mit 8.4 aus dieser Abfrage bedeutet ebenfalls, dass der Server verschoben wurde.

Das apt-Verlaufsprotokoll erfasst jedes Paket, das vom Upgrade geändert wurde:

zgrep -h 'Upgrade:' /var/log/apt/history.log* | head

Pfad 1: Den Snapshot wiederherstellen, der vor dem Upgrade erstellt wurde

Dies ist der günstigste Weg. Außerdem erhalten Sie damit als einzige Option exakt den 24.04-Server zurück, den Sie zuvor hatten. Wenn Ihr Provider vor der Ausführung von do-release-upgrade einen Snapshot oder ein Backup erstellt hat, setzt die Wiederherstellung die Festplatte auf diesen Zeitpunkt zurück. Die Pakete, der Kernel, die Datenbankdateien und /etc stimmen wieder überein, weil diese Kopie der Festplatte nie aktualisiert wurde.

Der Preis dafür sind alle Daten, die nach dem Snapshot geschrieben wurden. Eine Wiederherstellung setzt die gesamte Festplatte auf ihren Zustand zum Zeitpunkt des Snapshots zurück. Dadurch werden auch folgende Änderungen zurückgesetzt:

• Datenbankzeilen, die seit dem Snapshot geschrieben wurden
• Dateien, die Ihre Benutzer hochgeladen haben
• E-Mails, die auf dem Server eingegangen sind
• Logs, einschließlich der Logs des Upgrades
• Zertifikate, die nach dem Snapshot erneuert wurden
• Benutzer, Cronjobs und Konfigurationen, die Sie seitdem geändert haben

Wenn der Server mehrere Stunden oder Tage unter 26.04 lief, sind einige dieser Daten möglicherweise wichtig. Kopieren Sie sie vor der Wiederherstellung an einen anderen Ort. Mit folgendem Befehl können Sie schnell alle Dateien finden, die nach dem Beginn des Upgrades geändert wurden. Ersetzen Sie die angegebene Zeit durch Ihre Zeit:

sudo find /etc /home /srv -type f -newermt '2026-10-14 09:00' > ~/changed-since-upgrade.txt
wc -l ~/changed-since-upgrade.txt

Datenbankzeilen sind der schwierige Teil. Neue Zeilen liegen im Format der neuen Datenbankversion vor. Sie können die Datenbankdateien daher nicht einfach zurückkopieren. Übertragen Sie sie als logischen Dump zurück. Bei MySQL können Sie dafür auch die Replikation verwenden, die im Handbuch ebenfalls als Rückweg beschrieben wird. Bei Pfad 2 besteht dasselbe Problem. Lesen Sie daher vor der Wiederherstellung den folgenden Abschnitt zu Dumps.

Zwei weitere Regeln gelten. Erstellen Sie erstens einen Snapshot des aktuellen 26.04-Servers, bevor Sie den alten Server wiederherstellen. Wenn bei der Wiederherstellung ein Fehler auftritt, können Sie zum aktuellen Zustand zurückkehren. Klären Sie zweitens genau, aus welcher Quelle Sie wiederherstellen. Ein Snapshot beim selben Provider wie der Server ist nicht dasselbe wie ein Backup. VPS-Snapshots im Vergleich zu Backups erläutert den Unterschied.

Pfad 2: Neuaufbau auf einem frischen 24.04-Image

Wenn Sie keinen Snapshot von vor dem Upgrade haben, erstellen Sie einen neuen Server aus einem sauberen 24.04-Image und übertragen Sie Ihre Arbeit dorthin. Das dauert länger. Dafür stammen alle Pakete auf dem neuen Server aus einem Release, was wünschenswert ist.

Sichern Sie zuerst die wichtigen Daten auf dem 26.04-Server, solange er noch läuft:

mkdir -p ~/migrate
apt-mark showmanual > ~/migrate/manual-packages.txt
sudo tar czf ~/migrate/etc.tgz -C / etc
sudo tar czf ~/migrate/crontabs.tgz -C / var/spool/cron/crontabs
getent passwd | awk -F: '$3 >= 1000 && $3 < 65534 {print $1}' > ~/migrate/users.txt
sudo chown -R "$USER": ~/migrate
chmod 700 ~/migrate

apt-mark showmanual listet die Pakete auf, die derzeit als manuell installiert markiert sind. Dabei handelt es sich größtenteils um Pakete, die jemand ausdrücklich über ihren Namen installiert hat. Die Liste ist jedoch keine Installationshistorie. Ein als Abhängigkeit installiertes Paket kann später als manuell markiert werden und erscheint dann ebenfalls in der Liste. Das etc.tgz-Archiv enthält Ihre Konfiguration. Es enthält außerdem die SSH-Hostschlüssel in /etc/ssh und die Passwort-Hashes in /etc/shadow. Behandeln Sie den Ordner daher als geheim. Deshalb entzieht die letzte Zeile anderen Benutzern den Zugriff darauf. crontabs.tgz enthält die Crontab jedes Benutzers. Die System-Cron-Dateien in /etc/cron.d befinden sich bereits im /etc-Archiv. users.txt listet die normalen Benutzerkonten auf.

Sichern Sie anschließend die Datenbanken, wie im nächsten Abschnitt beschrieben, und kopieren Sie den gesamten Ordner auf einen anderen Rechner:

rsync -a ~/migrate/ you@backup.example.com:migrate-26.04/

Kopieren Sie den Ordner auf den frischen 24.04-Server und arbeiten Sie dort darin. Lesen Sie die Paketliste, bevor Sie sie installieren. Sie enthält Namen aus 26.04, und einige davon gibt es unter 24.04 nicht.

cd ~/migrate
sudo apt update
xargs -a manual-packages.txt sudo apt install -y

Wenn ein Name im 24.04-Archiv fehlt, installiert apt nichts. Der Vorgang wird mit einer Zeile wie E: Unable to locate package postgresql-18 beendet. Löschen Sie diese Zeile aus der Datei oder benennen Sie sie um und führen Sie den Befehl erneut aus. Versionierte Namen wie dieser bezeichnen genau die Pakete, die verschoben wurden.

Entpacken Sie etc.tgz nicht über das neue /etc. Diese Dateien stammen aus neueren Programmversionen, und eine ältere Version kann eine Option ablehnen, die sie nicht kennt. Entpacken Sie das Archiv in einen separaten Ordner und kopieren Sie nur die benötigten Dateien zurück:

mkdir -p ~/etc-2604
tar xzf etc.tgz -C ~/etc-2604
sudo diff -ru /etc/nginx ~/etc-2604/etc/nginx

Testen Sie die Dateien eines Dienstes, nachdem Sie sie zurückkopiert haben, bevor Sie den Dienst neu starten. sudo nginx -t und sudo sshd -t prüfen beide die Konfiguration, ohne sie anzuwenden. Wenn Sie die alten SSH-Hostschlüssel zurückkopieren, verbinden sich Clients ohne Warnung. Wenn Sie das nicht tun, zeigt jeder Client einmal WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! an, und Sie müssen den alten Eintrag aus seiner known_hosts-Datei entfernen.

Lässt sich ein PostgreSQL- oder MySQL-Dump von 26.04 auf 24.04 wiederherstellen?

Gehen Sie nicht davon aus. PostgreSQL garantiert nicht, dass ein Dump in eine ältere Hauptversion geladen werden kann. MySQL dokumentiert zwar einen Rückweg von 8.4 zu 8.0, aber nur als Rollback und nur solange keine neuen Serverfunktionen von 8.4 auf die Daten angewendet wurden.

PostgreSQL. Das Handbuch von pg_dump weist darauf hin, dass nicht garantiert wird, dass seine Ausgabe in einen Server einer älteren Hauptversion geladen werden kann. Das gilt auch dann, wenn der Dump von einem Server dieser älteren Version stammt. Im Handbuch steht außerdem, dass das Laden in einen älteren Server „manuelle Bearbeitung der Dump-Datei erfordern kann“. Das PostgreSQL-16-Handbuch enthält denselben Hinweis, und Version 16 wird von 24.04 ausgeliefert. Zwei weitere Details sind wichtig. pg_dump verweigert den Dump eines Servers, dessen Hauptversion neuer ist als die eigene. Verwenden Sie daher die Tools des 26.04-Servers und nicht die von 24.04. Das Handbuch empfiehlt außerdem --quote-all-identifiers, wenn ein Dump in eine andere Hauptversion geladen wird, weil jede Version eine eigene Liste reservierter Wörter hat.

Auf dem 26.04-Server:

sudo -u postgres pg_dumpall --quote-all-identifiers > ~/migrate/pg-all.sql

Auf dem 24.04-Server, nachdem das Paket postgresql installiert wurde:

cd ~/migrate
sudo -u postgres psql < pg-all.sql 2>&1 | tee restore.log
grep ERROR restore.log

Eine Meldung, dass der Benutzer postgres could not change directory in Ihr Home-Verzeichnis hat, ist harmlos. Sie erscheint, weil der Benutzer postgres Ihr Home-Verzeichnis nicht lesen kann. Ihre Shell übernimmt das Lesen und Schreiben der Datei trotzdem. Lesen Sie jede ERROR-Zeile im Log. Eine Zeile mit dem Hinweis, dass eine Rolle bereits existiert, ist normalerweise harmlos, weil die 24.04-Installation die Rolle postgres bereits angelegt hat. Ein Syntaxfehler muss genauer untersucht werden. Suchen Sie die betreffende Anweisung im Dump. Sie kann etwas verwenden, das PostgreSQL 16 nicht versteht. Dann bearbeiten Sie diesen Teil des Dumps manuell. Die Ursache kann auch in normalen Parsing-Regeln liegen, etwa bei der Maskierung oder bei einer Einstellung wie standard_conforming_strings. Untersuchen Sie daher die Anweisung, bevor Sie die Versionsdifferenz verantwortlich machen. Wenn Ihre Daten Funktionen verwenden, die nur in der neuen Version vorhanden sind, gibt es möglicherweise keinen sauberen Rückweg.

MySQL. Das MySQL-8.4-Handbuch unterstützt den Weg von 8.4 LTS (Long-Term Support) zu 8.0 nur über einen logischen Dump und dessen Import oder über Replikation. Es nennt eine Bedingung: „Nur für Rollback-Zwecke unterstützt, also wenn keine neuen Serverfunktionen auf die Daten angewendet wurden“. Der dokumentierte Rückweg hängt daher davon ab, ob neue Funktionen von 8.4 Ihre Daten verändert haben. Sichern Sie die Anwendungsdatenbanken anhand ihrer Namen:

sudo mysqldump --single-transaction --routines --events --databases appdb > ~/migrate/appdb.sql

Laden Sie den Dump mit sudo mysql < appdb.sql auf 24.04. Legen Sie die Anwendungsbenutzer und ihre Berechtigungen anschließend manuell wieder an. Ein Fehler, der den Import abbricht, kann bedeuten, dass der Dump etwas enthält, das 8.0 nicht lesen kann. Er kann auch bedeuten, dass dem Konto, das den Import ausführt, eine Berechtigung fehlt, die eine Anweisung im Dump benötigt. MySQL verlangt die erforderlichen Berechtigungen zum Ausführen jeder im Dump enthaltenen Anweisung. Lesen Sie die vom Fehler genannte Anweisung, bevor Sie die Ursache festlegen.

Für beide Datenbanken gilt dieselbe Regel. Stellen Sie den Dump auf einem Testserver mit 24.04 wieder her, starten Sie die Anwendung damit und prüfen Sie echte Daten. Tun Sie dies, bevor Sie den 26.04-Server löschen.

Warum das Zurücksetzen von apt auf noble kein Downgrade ist

Eine häufige Antwort in Foren lautet, die apt-Quellen vom Codenamen 26.04 zurück auf noble zu ändern und für diese Pakete anschließend eine hohe Priorität festzulegen. Das sieht wie ein Downgrade aus, führt aber zu etwas anderem.

apt setzt ein Paket nicht selbstständig auf eine ältere Version zurück. Das Handbuch zu apt_preferences sagt für 26.04, apt werde „Never downgrade unless the priority of an available version is at least 1000.“ Eine Pin-Priorität von genau 1000 reicht aus. Um alle Pakete gleichzeitig zurückzusetzen, erzwingt die Antwort aus dem Forum diesen Vorgang mit einem Pin. Die Angabe einer älteren Version oder eines älteren Releases für ein einzelnes Paket, wie in apt install package=version oder apt install package/noble, kann dieses Paket ebenfalls downgraden. Das Handbuch zu apt-get warnt, dass beide Mechanismen „can downgrade packages and must be used with care.“ Keine dieser Methoden setzt den Server wieder auf 24.04 zurück. Mit diesem Pin beginnt apt, neuere Pakete durch ältere zu ersetzen. dpkg führt bei diesen Downgrades keine Abhängigkeitsprüfung durch. Dasselbe Handbuch zu apt_preferences warnt, dass Downgrades riskant sind und das Mischen von Distribution-Releases weitere Probleme verursacht. Pakete aus einem Release wurden nie zusammen mit Paketen aus einem anderen Release getestet.

Sie erhalten einen Server, auf dem teils 26.04 und teils 24.04 installiert ist. Wenn eine zentrale Bibliothek auf ihrer Version von 26.04 bleibt, bleiben auch alle Pakete auf dieser Version, die sie benötigen. Die apt-Dokumentation von Ubuntu nennt „combinations of packages from different releases or third party repositories“ als einen Grund dafür, dass apt Pakete zurückhält. Auch die Datenbank enthält weiterhin das neue Format. Der alte Datenbankserver startet damit möglicherweise nicht.

Wenn sich ein Server bereits in diesem Zustand befindet, setzen Sie die Quellen auf das Release zurück, mit dem er überwiegend betrieben wird. Reparieren Sie anschließend die Pakete anhand der Schritte unter beschädigte Pakete mit apt reparieren. Wählen Sie danach einen Weg ausgehend von einem sauberen Ausgangszustand.

Pfad 3: Bei 26.04 bleiben und die Regression beheben

Die meisten Anfragen zum Downgrade beginnen mit einem einzelnen defekten Bestandteil: einem Treiber, einem Kernel, einem Dienst oder einem geänderten Standardwert. Die Behebung dieses einen Problems kostet oft weniger als die Pfade 1 und 2. Für 26.04 gibt es bis Mai 2031 standardmäßige Sicherheitswartung. Die Version ist daher keine kurzfristige Zwischenlösung.

Eine Kernel-Regression. Der Server startet, aber die Netzwerkkarte oder der Speicher funktioniert nicht ordnungsgemäß. Prüfen Sie mit ls /boot/vmlinuz-*, ob der alte Kernel noch installiert ist. Falls ja, können Sie ihn starten, während Sie auf einen korrigierten Kernel warten. Unter Ubuntu bezeichnet GRUB_DEFAULT=1 ein Untermenü und nicht Ihren alten Kernel. Lesen Sie daher wie Sie festlegen, mit welchem Kernel Ihr VPS als Nächstes startet, bevor Sie GRUB ändern. Entfernen Sie den alten Kernel erst, wenn der neue funktioniert. Verschieben Sie das Aufräumen alter Kernel auf später.

Ein geänderter Dienst. Das obige apt-Verlaufsprotokoll zeigt, welche Pakete geändert wurden. Lesen Sie die Versionshinweise für dieses Paket und vergleichen Sie dessen neue Standardkonfiguration mit Ihrer alten Datei in /etc. Wenn dpkg Ihre bearbeitete Konfigurationsdatei beibehält, kann es die neue Version des Pakets mit der Endung .dpkg-dist daneben speichern. Wenn es die neue Version installiert, kann es Ihre alte Datei mit der Endung .dpkg-old speichern. Finden Sie alle diese Dateien:

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old'

Jede gefundene Datei kennzeichnet eine Stelle, an der Paket und Konfiguration während des Upgrades nicht übereinstimmten.

Ein Upgrade, das auf halbem Weg abgebrochen wurde. Ein Server, auf dem do-release-upgrade abgestürzt ist, hat ein anderes Problem als ein Server, auf dem das Upgrade abgeschlossen wurde und der anschließend fehlerhaft arbeitet. Wenn das Upgrade nicht abgeschlossen wurde, befolgen Sie die Anleitung zur Wiederherstellung eines fehlgeschlagenen Ubuntu-Release-Upgrades, bevor Sie an eine Rückkehr zur vorherigen Version denken.

Welchen Weg Sie wählen sollten

Wählen Sie Weg 1, wenn ein Snapshot aus der Zeit vor dem Upgrade vorhanden ist und die seitdem geschriebenen Datenmenge gering ist oder sich einfach exportieren und übertragen lässt. Wählen Sie Weg 2, wenn kein Snapshot vorhanden ist oder Sie ohnehin eine saubere 24.04-Installation wünschen. Wählen Sie Weg 3, wenn Sie die eine konkrete Ursache des Fehlers benennen können.

Die Rückkehr zu 24.04 ist ein sinnvoller Ausgangspunkt. Die reguläre Sicherheitswartung für 24.04 läuft bis Mai 2029. ESM (Expanded Security Maintenance) läuft bis Mai 2034. Beachten Sie beim nächsten Versuch, dass der Upgrade-Leitfaden besagt, dass direkte LTS-zu-LTS-Upgrades „erst nach dem ersten Point Release verfügbar“ sind. Die Hinweise zu den Änderungen in Ubuntu 26.04.1 und dem richtigen Upgrade-Zeitpunkt erläutern diesen Zeitplan. Erstellen Sie zuerst einen Snapshot und testen Sie den Datenbank-Dump. Folgen Sie anschließend dem Upgrade-Leitfaden für 24.04 auf 26.04, nachdem Sie bereits eine Möglichkeit zur Rückkehr eingerichtet haben.

FAQ

Kann ich Ubuntu 26.04 ohne Neuinstallation auf 24.04 zurückstufen?

Nein. Ubuntu verfügt über kein Downgrade-Tool, und die Upgrade-Dokumentation sieht für den Fehlerfall nur ein Backup vor. Bei Downgrades prüft dpkg keine Abhängigkeiten. Deshalb lässt sich ein Release nicht sicher rückgängig machen. Ihre tatsächlichen Optionen sind die Wiederherstellung eines vor dem Upgrade erstellten Snapshots oder Backups, eine Neuinstallation mit einem frischen 24.04-Image oder der Verbleib bei 26.04 mit anschließender Behebung des konkreten Problems.

Funktionieren meine PostgreSQL-Daten nach der Rückkehr zu Ubuntu 24.04?

Nicht direkt. Die Standardversion von PostgreSQL unter 26.04 ist Version 18, unter 24.04 ist es Version 16. Ein Datenverzeichnis kann nicht zwischen Major-Versionen verschoben werden. Erstellen Sie mit dem eigenen pg_dumpall --quote-all-identifiers-Programm des 26.04-Servers einen Dump. PostgreSQL garantiert nicht, dass ein Dump in eine ältere Major-Version eingelesen werden kann. Stellen Sie ihn daher auf einem Testserver mit 24.04 wieder her und prüfen Sie jede Fehlermeldung, bevor Sie sich darauf verlassen.

Warum ändern Sie die apt-Quellen nicht einfach wieder auf noble?

apt führt von sich aus niemals ein Downgrade eines Pakets durch. Dafür benötigen Sie entweder eine Pin-Priorität von mindestens 1000 oder müssen für das Paket eine ältere Version oder ein älteres Release angeben. Bei Downgrades prüft dpkg keine Abhängigkeiten. Das Erzwingen hinterlässt einen Server mit Paketen aus zwei Releases, die nie gemeinsam getestet wurden. Dieser Zustand entspricht weder 24.04 noch 26.04. Datenbankdateien im neuen Format bleiben ebenfalls neu. Der alte Datenbankserver verweigert möglicherweise den Start mit diesen Dateien.

Wie lange wird Ubuntu 24.04 unterstützt, wenn ich zurückgehe?

Die Release-Zyklus-Seite von Canonical nennt für 24.04 LTS standardmäßige Sicherheitswartung bis Mai 2029 und ESM (Expanded Security Maintenance) bis Mai 2034. Zum Vergleich: Für 26.04 LTS läuft die standardmäßige Sicherheitswartung bis Mai 2031. Die Rückkehr verschafft Ihnen Zeit. Vor dem Ende des Standardsupports für 24.04 müssen Sie jedoch erneut upgraden.