Ubuntu-Upgrade abgebrochen: So retten Sie den Server

Ubuntu-Upgrade auf halbem Weg fehlgeschlagen: Prüfen Sie zuerst das Fehlerbild

Ein fehlgeschlagenes Ubuntu-Release-Upgrade von 24.04 auf 26.04 hinterlässt den Server in einem von vier Zuständen. Für jeden Zustand gilt eine andere Lösung. Der Upgrader läuft möglicherweise noch in einer screen-Sitzung, zu der Sie den Kontakt verloren haben. Eventuell wurde dpkg beendet, während ein Paket nur teilweise konfiguriert war. apt verweigert dann alle Aktionen zum Installieren, Entfernen oder Aktualisieren von Paketen, obwohl apt update und schreibgeschützte Befehle wie apt show weiterhin funktionieren. Die apt-Quellen nennen möglicherweise bereits 26.04, während die installierten Pakete noch zu 24.04 gehören. Oder der Server startet überhaupt nicht mehr. Ermitteln Sie zuerst, welcher dieser Zustände vorliegt, bevor Sie Befehle eingeben. Die Lösung für einen Zustand kann einen anderen Zustand verschlimmern.

Für alle vier Zustände gilt eine Regel: Starten Sie den Server nicht neu, bevor Sie wissen, in welchem Zustand sich dpkg befindet. Ein Neustart während des Austauschs von Paketen kann eine behebbare Unterbrechung von dpkg in den weiter unten beschriebenen Fall verwandeln, in dem der Server nicht mehr bootet. Starten Sie außerdem keinen zweiten apt- oder dpkg-Prozess, solange der erste möglicherweise noch läuft. Zwei Prozesse, die gleichzeitig in die Paketdatenbank schreiben, können die Datenbank beschädigen.

Diese Anleitung setzt voraus, dass Sie der Upgrade-Anleitung von 24.04 auf 26.04 gefolgt sind und vor dem Start einen Snapshot erstellt haben. Falls nicht, lesen Sie den Abschnitt zum Booten unter dieser Voraussetzung. Der Snapshot ist die Lösung für den schlimmsten Fall.

Läuft das Upgrade noch?

Viele Upgrades, die als fehlgeschlagen gemeldet werden, laufen noch. Die SSH-Sitzung ist abgebrochen, das Terminal blieb leer, und das Upgrade-Programm lief ohne Sie weiter.

do-release-upgrade ist dafür ausgelegt. Wenn es mit seiner Textoberfläche läuft, wie es bei einem Server der Fall ist, startet es in einer GNU-screen-Sitzung. Dadurch läuft das Upgrade auch nach dem Verlust des Terminals weiter, von dem aus es gestartet wurde. Wenn do-release-upgrade erkennt, dass es aus einer SSH-Sitzung gestartet wurde, bietet es außerdem an, einen zweiten sshd-Dienst auf einem anderen Port zu starten, standardmäßig auf Port 1022. So können Sie sich weiterhin anmelden, falls der Haupt-SSH-Daemon während des Austauschs der Pakete ausfällt. Beide Funktionen sind jetzt wichtig.

Melden Sie sich erneut per SSH an und suchen Sie nach der screen-Sitzung. Das Upgrade-Programm lief unter sudo. Daher gehört seine screen-Sitzung root, und ein einfaches screen -ls unter Ihrem eigenen Benutzer listet sie nicht auf.

sudo screen -ls

screen -ls kennzeichnet jede Sitzung als verbunden oder getrennt. Wenn eine Sitzung aufgelistet ist, verbinden Sie sich erneut mit ihr. Ist sie noch als verbunden gekennzeichnet, weil die abgebrochene SSH-Verbindung sie nicht freigegeben hat, trennt -d zuerst diese veraltete Verbindung.

sudo screen -d -r

Wenn mehrere Sitzungen aufgelistet sind, setzen Sie den Sitzungsnamen aus screen -ls hinter -r. Verlassen Sie sich nicht darauf, dass sudo do-release-upgrade die Verbindung automatisch wiederherstellt. Der Code, der die vorhandene screen-Sitzung findet, befindet sich in dem Upgrade-Programm, das es herunterlädt. Bevor es jedoch etwas herunterlädt, beendet sich do-release-upgrade mit der Meldung "Please install all available updates for your release before upgrading", sobald es ein Paket mit ausstehendem Upgrade findet (ausgenommen schrittweise ausgerollte Updates). Genau das ist der Zustand eines Systems, das sich mitten im Paketaustausch befindet. Nach der erneuten Verbindung landen Sie wieder im laufenden Upgrade. Meist wartet es auf eine Eingabe zu einer geänderten Konfigurationsdatei oder einem Neustart eines Dienstes. Beantworten Sie die Abfrage und lassen Sie das Upgrade fertig laufen.

Wenn Sie das Upgrade wie im Upgrade-Leitfaden empfohlen innerhalb von tmux gestartet haben, verbinden Sie sich zuerst mit tmux, und zwar mit tmux attach. Die screen-Sitzung läuft innerhalb dieses tmux-Bereichs. Daher sehen Sie das Upgrade direkt. Enthält der Bereich nur eine Shell-Eingabeaufforderung, läuft das Upgrade-Programm dort nicht mehr. Prüfen Sie als Nächstes sudo screen -ls.

Wenn der Haupt-SSH-Port die Verbindung ablehnt, versuchen Sie den Fallback-Port: ssh -p 1022 user@host. Dieser Daemon existiert nur für die Dauer des Upgrades. Wenn Sie sich über keinen der beiden Ports anmelden können, verwenden Sie stattdessen die Konsole Ihres Providers. Mit sudo ss -ltnp sehen Sie in der Konsole, auf welchen Ports ein sshd-Prozess Verbindungen entgegennimmt. sudo ufw status zeigt, ob die Firewall den Fallback-Port freigibt.

Wenn keine screen-Sitzung vorhanden ist und auf der Konsole keine Eingabe erwartet wird, wurde das Upgrade tatsächlich beendet. Stellen Sie sicher, dass derzeit kein Prozess an der Paketdatenbank arbeitet, bevor Sie Änderungen vornehmen:

ps -eo pid,etime,cmd | grep -iE '[u]pgrade|[d]pkg|[a]pt'

Ein leeres Ergebnis bedeutet, dass dpkg inaktiv ist und Sie mit der Reparatur fortfahren können. Ein dpkg- oder apt-Prozess mit langer Laufzeit und ohne screen-Sitzung, mit der Sie sich erneut verbinden können, hängt fest. Warten Sie einige Minuten, prüfen Sie die Konsole auf eine unbeantwortete debconf-Abfrage, und beenden Sie den Prozess erst danach. Löschen Sie niemals die Sperrdateien unter /var/lib/dpkg/ oder /var/lib/apt/lists/, solange ein Prozess sie geöffnet hält. Die Sperre verhindert, dass zwei Schreibprozesse die Paketdatenbank beschädigen.

dpkg wurde unterbrochen und apt verweigert die Ausführung

Wenn dpkg zwischen dem Entpacken eines Pakets und dem Ausführen seines Konfigurationsskripts beendet wird, bleibt das Paket als nur teilweise verarbeitet markiert. Außerdem bleiben nicht abgeschlossene Einträge in seinem Journal unter /var/lib/dpkg/updates/ zurück. Jeder apt-Befehl, der die dpkg-Sperre übernimmt, prüft zuerst dieses Journal. Dazu gehören alle Befehle, die Pakete installieren, entfernen oder aktualisieren. Sie werden mit dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem. beendet. Befehle, die diese Sperre nie übernehmen, funktionieren weiter. Dazu gehören beispielsweise apt update, apt list, apt show und apt-cache. Sie können sich das System also weiterhin ansehen. Unabhängig davon, was apt zusätzlich ausgibt, ist der erste Schritt immer gleich.

sudo dpkg --configure -a

Damit wird die Konfiguration aller Pakete abgeschlossen, die entpackt, aber noch nicht konfiguriert wurden. Die Maintainer-Skripte werden in Abhängigkeitsreihenfolge ausgeführt. Auf einem teilweise aktualisierten System kann das lange dauern. Warten Sie, bis der Befehl beendet ist. Wenn der Vorgang bei einem Paket stoppt, gibt er den Paketnamen und das fehlgeschlagene Skript aus. Notieren Sie sich diesen Namen. Das ist das Paket, das die Aktualisierung angehalten hat. Im nächsten Abschnitt erfahren Sie, wie Sie den Fehler dieses Pakets lesen.

Lassen Sie anschließend apt die Abhängigkeiten reparieren, die durch die Unterbrechung unerfüllt geblieben sind. Einige Pakete wurden möglicherweise aktualisiert, die von ihnen benötigten Pakete jedoch nicht.

sudo apt --fix-broken install

Schließen Sie anschließend die Aktualisierung ab, die der Upgrader gerade ausgeführt hat:

sudo apt update
sudo apt full-upgrade

Verwenden Sie full-upgrade anstelle von upgrade. Ein Release-Upgrade entfernt Pakete, während upgrade das Entfernen von Paketen verweigert. Lesen Sie die von apt ausgegebene Zusammenfassung, bevor Sie bestätigen. Eine kurze Liste von Entfernungen ist normal. Eine Liste, die ubuntu-server, systemd, openssh-server oder Ihr Kernel-Paket entfernt, ist es nicht. Antworten Sie in diesem Fall mit Nein und klären Sie, warum apt diese Pakete entfernen will, bevor Sie fortfahren.

Prüfen Sie das Ergebnis, bevor Sie etwas anderes ausführen:

sudo dpkg --audit
sudo apt-get check

dpkg --audit listet alle Pakete auf, die sich noch in einem fehlerhaften Zustand befinden. apt-get check meldet unerfüllte Abhängigkeiten. Beide Befehle sollten keine Ausgabe erzeugen. Wenn sie das tun, führen Sie sudo apt autoremove aus, um automatisch installierte Abhängigkeiten zu entfernen, die von keinem Paket mehr benötigt werden. Als manuell installiert markierte Pakete bleiben dabei erhalten, auch wenn sie von keinem anderen Paket verwendet werden. Bestätigen Sie anschließend das Release mit cat /etc/os-release. Führen Sie danach sudo update-initramfs -u -k all und sudo update-grub aus. Starten Sie das System erst dann neu.

So lesen Sie /var/log/dist-upgrade, um das Paket zu finden, das die Aktualisierung angehalten hat

Der Upgrader schreibt alle Informationen nach /var/log/dist-upgrade/. Wenn Sie ihn mehr als einmal ausgeführt haben, verschiebt er die Logs des vorherigen Versuchs in ein Unterverzeichnis mit einem Zeitstempel. Prüfen Sie daher zuerst ls -la /var/log/dist-upgrade/ und lesen Sie das Verzeichnis, das zum fehlgeschlagenen Lauf gehört.

main.log ist das eigene Protokoll des Upgraders. Es hält fest, in welcher Phase sich der Lauf befand und welche Entscheidung der Upgrader zu Ihren Paketquellen getroffen hat. Wenn der Upgrader selbst abgestürzt ist, finden Sie hier auch den Python-Traceback. Lesen Sie die Datei vom Ende her. Die letzten Zeilen zeigen, in welcher Phase der Vorgang beendet wurde. Ein dort vorhandener Traceback bedeutet, dass das Tool fehlgeschlagen ist, nicht ein Paket.

apt.log enthält die Überlegungen des Abhängigkeitsauflösers. Die Datei ist ausführlich. Sie ist relevant, wenn apt die Aktualisierung überhaupt nicht berechnen konnte. Das ist ein Fehler, der auftritt, bevor ein Paket angefasst wurde. Wenn die Aktualisierung bereits mit der Paketinstallation begonnen hat, können Sie diese Datei normalerweise überspringen.

apt-term.log ist die Datei, die Sie bei einem Paketfehler benötigen. Sie enthält die Terminalausgabe von dpkg während der Aktualisierung, also denselben Text, der andernfalls an Ihnen vorbeigelaufen wäre. Das letzte Paket, das vor dem Ende erwähnt wird, ist das Paket, das beim Abbruch der Aktualisierung gerade verarbeitet wurde. Wenn ein Maintainer-Skript fehlgeschlagen ist, steht die Fehlermeldung von dpkg direkt dort. Der eigene Fehler des Skripts steht unmittelbar darüber.

sudo tail -n 60 /var/log/dist-upgrade/apt-term.log
sudo grep -in 'error' /var/log/dist-upgrade/apt-term.log | tail

Vergleichen Sie das Ergebnis mit /var/log/dpkg.log. Diese Datei protokolliert die Statusänderungen und Aktionen von dpkg jeweils mit einem Zeitstempel. tail -n 30 /var/log/dpkg.log zeigt, welches Paket dpkg zuletzt angefasst hat und was dabei ausgeführt wurde. Das ist nur dann dieselbe Information aus einer zweiten Quelle, wenn seit dem Fehler kein weiterer dpkg-Lauf stattgefunden hat. Sobald Sie dpkg --configure -a oder apt --fix-broken install ausgeführt haben, stehen deren Einträge am Ende. Scrollen Sie daher zu den Zeilen zurück, deren Zeitstempel dem Zeitpunkt des Abbruchs entspricht.

Die meisten Fehler in dieser Phase haben auf einem Server eine von wenigen Ursachen. Ein Dienst, den das Paket in seinem postinst-Skript neu startet, kann wegen einer von Ihnen angepassten Konfigurationsdatei nicht starten. systemctl status zusammen mit journalctl -xeu für diesen Dienst nennt die Zeile, die der Dienst nicht akzeptiert. Ein Dateisystem ist vollgelaufen. Am häufigsten betrifft das /boot mit alten Kerneln oder /var mit dem Paket-Cache von apt. df -h / /boot /var zeigt den Platzverbrauch. sudo apt clean leert den Cache auch dann, wenn apt ansonsten blockiert ist. Ein Dateisystem, das trotz abweichender du-Ausgabe als voll gemeldet wird, hat eine eigene Ursache. Ein Paket aus einem Drittanbieter-Repository, das der Upgrader deaktiviert hat, benötigt möglicherweise eine Bibliothek, die 26.04 nicht mehr bereitstellt. Ein zurückgehaltenes Paket (apt-mark showhold) hat möglicherweise verhindert, dass eine Abhängigkeit aktualisiert wird. Beheben Sie die Ursache und führen Sie sudo dpkg --configure -a erneut aus. Der Vorgang wird an der unterbrochenen Stelle fortgesetzt.

Wenn sich ein Paket unabhängig von Ihren Maßnahmen nicht konfigurieren lässt und keine wichtigen Pakete davon abhängen, entfernen Sie es. Installieren Sie es nach Abschluss der Aktualisierung erneut:

sudo dpkg --remove --force-remove-reinstreq package-name
sudo dpkg --configure -a

Verwenden Sie diesen Befehl nur für ein Paket, dessen Namen und Funktion Sie angeben können. Verwenden Sie ihn niemals für eine Bibliothek oder für ein Paket in der ubuntu-server-Abhängigkeitskette. Eine erzwungene Entfernung überspringt die Prüfungen, die Ihnen andernfalls zeigen würden, was zusätzlich beschädigt wird.

Die Quellen wurden umgestellt, die Pakete jedoch nicht

Der Upgrade-Vorgang schreibt die APT-Quellen früh um, bevor er Pakete herunterlädt. Wird er danach unterbrochen, nennen die Quellen 26.04, während die installierten Pakete eine Mischung bilden. Diese Mischung verwirrt die Werkzeuge. Deshalb kann do-release-upgrade jetzt darauf bestehen, dass kein neues Release verfügbar ist.

Vergleichen Sie die beiden Stellen, die angeben, welches Release installiert ist. /etc/apt/sources.list.d/ubuntu.sources ist die deb822-Quelldatei, die 24.04 eingeführt hat. Die Zeilen mit Suites: enthalten den Release-Codenamen. /etc/os-release wird vom Paket base-files geschrieben und gibt an, welches Release tatsächlich installiert ist.

grep -E '^(Suites|Components):' /etc/apt/sources.list.d/ubuntu.sources
grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release
apt-cache policy base-files

Drei Kombinationen sind relevant. Nennen die Quellen weiterhin 24.04 (Codename noble) und gibt os-release ebenfalls 24.04 an, ist der Upgrade-Vorgang nicht über seine Prüfungen hinausgekommen. Sie können sudo do-release-upgrade nach dem Lesen von main.log erneut ausführen, um herauszufinden, warum er beendet wurde. Der Vorgang startet nicht, solange ein 24.04-Update aussteht oder /var/run/reboot-required.pkgs libc6, linux-base oder ein linux-image-Paket nennt. Führen Sie daher sudo apt full-upgrade aus und starten Sie das System neu, falls diese Datei dies zuvor verlangt. Nennen die Quellen den Codenamen von 26.04, während os-release weiterhin 24.04 angibt, wurde der Paketaustausch gestartet und unterbrochen. Die im vorherigen Abschnitt beschriebene dpkg-Reparatur, die mit apt full-upgrade endet, schließt den Vorgang ab. Führen Sie den Upgrade-Vorgang in diesem Zustand nicht erneut aus. Da Pakete für 26.04 bereitstehen, beendet er sich und fordert Sie auf, zuerst alle verfügbaren Updates zu installieren. Nennen die Quellen 26.04 und gibt os-release 26.04 an, war base-files eines der Pakete, die bereits installiert wurden. Das System bezeichnet sich jetzt als 26.04, auch wenn der größte Teil noch nicht aktualisiert ist.

Diese letzte Kombination ist die Falle. do-release-upgrade ermittelt das Release anhand derselben Informationen, die os-release enthält. Wenn dort bereits 26.04 steht, sucht das Werkzeug nach einem neueren Release. Es findet keines und meldet, dass kein neues Release verfügbar ist. Das Werkzeug beantwortet eine Frage zu os-release, aber os-release ist falsch. Verwenden Sie den Upgrade-Vorgang nicht weiter, sondern schließen Sie das Upgrade mit apt ab: zuerst sudo apt update, danach sudo apt full-upgrade. Dadurch werden die Pakete aktualisiert, die noch ihre 24.04-Version haben, ausgenommen Pakete mit Hold-Status (apt-mark showhold listet diese auf). Einige Pakete werden möglicherweise stattdessen entfernt. Lesen Sie daher die Zusammenfassung und führen Sie anschließend sudo apt autoremove aus. Die anderen Gründe, aus denen do-release-upgrade kein neues Release meldet, sollten Sie ebenfalls ausschließen, falls os-release weiterhin 24.04 angibt. Dazu gehört beispielsweise eine LTS-Abfrage, die auf das erste Point-Release wartet.

Der Upgrade-Vorgang deaktiviert außerdem Drittanbieterquellen unter /etc/apt/sources.list.d/ und erstellt für jede geänderte Datei eine Sicherungskopie. An den ursprünglichen Dateinamen wird dabei ein Suffix angehängt. Führen Sie ls -la /etc/apt/sources.list.d/ und diff für jede Originaldatei und ihre Sicherungskopie aus, um genau zu sehen, welche Änderungen vorgenommen wurden. Lassen Sie die Einträge von Drittanbieterquellen deaktiviert, bis die Ubuntu-Pakete konsistent sind. Aktivieren Sie jeden Eintrag erst wieder, nachdem Sie bestätigt haben, dass der Anbieter Pakete für 26.04 veröffentlicht. Wenn apt update meldet, dass eine Quelle mehrfach konfiguriert ist, beschreiben ein alter sources.list-Eintrag und der neue ubuntu.sources-Eintrag dieselbe Suite. Der Fehler zu doppelten deb822-Quellen erklärt, welchen Eintrag Sie entfernen müssen.

Der Server startet nach dem Upgrade nicht

Nach einem Reboot zeigen sich die Folgen eines nicht abgeschlossenen Upgrades. Bei einem VPS sind die wahrscheinlichsten Ursachen ein Kernel, der ohne initramfs installiert wurde, eine GRUB-Konfiguration, die nie neu erzeugt wurde, ein nur teilweise konfiguriertes Paket, von dem eine Unit beim Booten abhängt, oder ein Datenträger, der vollgelaufen ist, während dpkg Daten geschrieben hat.

Öffnen Sie die Konsole des Providers, bevor Sie etwas anderes tun. Dort sehen Sie, an welcher Stelle der Bootvorgang stoppt: im GRUB-Menü, mit einem Kernel Panic, bei einer Dateisystemprüfung, die auf eine Antwort wartet, oder in einer systemd-Notfall-Shell, die nach dem root-Passwort fragt. Diese eine Beobachtung bestimmt den nächsten Schritt.

Wenn GRUB angezeigt wird, booten Sie den vorherigen 24.04-Kernel über das Untermenü mit den erweiterten Optionen. Der alte Kernel bleibt normalerweise installiert, bis autoremove ausgeführt wird. Sobald das System mit dem alten Kernel läuft, führen Sie sudo dpkg --configure -a und die restliche Reparatur aus dem vorherigen Abschnitt aus. Führen Sie danach sudo update-initramfs -u -k all und sudo update-grub aus, bevor Sie den neuen Kernel erneut starten. Einen VPS wiederherstellen, der nach einem Kernel-Update nicht bootet behandelt GRUB und initramfs ausführlich.

Wenn Sie in einer Notfall-Shell landen, ist das root-Dateisystem normalerweise nur lesbar eingehängt. Hängen Sie es mit Schreibzugriff erneut ein und führen Sie dieselbe Reparatur aus:

mount -o remount,rw /
dpkg --configure -a

Wenn das System überhaupt keine Shell erreicht, booten Sie das Rescue-Image des Providers, hängen Sie den Datenträger des VPS ein und führen Sie die Reparatur aus einem chroot heraus durch. Ermitteln Sie die root-Partition mit lsblk, statt ihren Namen zu erraten.

lsblk
mount /dev/<root-partition> /mnt
for d in dev proc sys run; do mount --bind /$d /mnt/$d; done
chroot /mnt /bin/bash
dpkg --configure -a
apt --fix-broken install
update-initramfs -u -k all
update-grub
exit
reboot

Bevor Sie eine Stunde in diesem chroot verbringen, vergleichen Sie diesen Aufwand mit dem Snapshot. Sie haben vor dem Start einen Snapshot erstellt, und bei den meisten Providern dauert die Wiederherstellung nur wenige Minuten. Danach führen Sie das Upgrade erneut aus. Das dauert auf einem VPS deutlich weniger als eine Stunde, und diesmal wissen Sie bereits, welches Paket Sie reparieren müssen. Die Wiederherstellung ist immer dann der schnellere Weg, wenn eine dieser Bedingungen zutrifft: Sie erhalten keinen Zugriff auf eine Konsole oder ein Rescue-Image, Sie können das Paket, das das Upgrade gestoppt hat, nicht benennen, mehr als ein Paket hängt fest oder auf dem System laufen Dienste, auf die andere Personen warten. Eine manuelle Reparatur ist nur dann schneller, wenn Sie genau wissen, was kaputtgegangen ist, und die Behebung aus einem einzigen Befehl besteht.

Kopieren Sie /var/log/dist-upgrade/ vor der Wiederherstellung vom System. Verwenden Sie dafür das Rescue-Image, falls dies der einzige Zugangsweg ist. Die Wiederherstellung löscht diese Logs. Ein zweiter Versuch schlägt genau auf dieselbe Weise fehl, wenn Sie nicht herausfinden, warum der erste Versuch fehlgeschlagen ist. Was ein Snapshot wiederherstellen kann und was nicht sollten Sie lesen, bevor Sie sich darauf verlassen. Ein Snapshot setzt den gesamten Datenträger zurück, einschließlich aller Daten, die seit seiner Erstellung geschrieben wurden. Das ist während eines Upgrades unproblematisch, eine Woche später jedoch nicht.

Drei Anzeichen dafür, dass das System stattdessen neu erstellt werden sollte

Manche Upgrades sind die Wiederherstellung nicht wert. Einen Snapshot wiederherzustellen und den Vorgang erneut auszuführen, ist kostengünstig. Wenn der Fehler jedoch durch den Zustand des Systems selbst verursacht wurde, schlägt der zweite Durchlauf ebenfalls fehl. Die saubere Lösung ist dann ein neues 26.04-Image mit einer Wiederherstellung Ihrer Daten aus dem Backup. Drei Anzeichen zeigen, dass dieser Fall eingetreten ist.

Erstens ist die eigene Datenbank von dpkg beschädigt. Wenn dpkg --audit oder apt-get check /var/lib/dpkg/status überhaupt nicht lesen kann, statt darin beschädigte Pakete zu melden, fehlen die Aufzeichnungen über die installierten Pakete. Ubuntu legt tägliche Kopien unter /var/backups/ (ls -la /var/backups/dpkg.status*) ab. Manchmal funktioniert es, die neueste intakte Kopie an diese Stelle zu setzen. Sobald diese Kopie jedoch nicht mehr mit dem tatsächlichen Inhalt des Dateisystems übereinstimmt, arbeiten Sie mit Vermutungen. Jeder spätere apt-Durchlauf baut dann auf dieser Vermutung auf.

Zweitens sind die für die Reparatur benötigten Werkzeuge selbst beschädigt. Wenn apt oder dpkg wegen einer entfernten oder nur teilweise ersetzten Shared Library nicht startet oder systemd Units nicht starten kann, weil das eigene Paket nur teilweise konfiguriert ist, steht kein funktionierender Paketmanager mehr zur Reparatur des Paketmanagers zur Verfügung. ldd /usr/bin/apt zeigt, ob alle Bibliotheken von apt vorhanden sind. Mitunter lässt sich das System aus einer chroot-Umgebung im Rescue-Image wiederherstellen. Der dafür erforderliche Zeitaufwand ist jedoch meistens größer als der für eine Neuerstellung.

Drittens wird die Liste der beschädigten Pakete nicht kürzer. Wenn Sie dpkg --configure -a und apt --fix-broken install länger als eine Stunde in einer Schleife ausgeführt haben und jeder Durchlauf ein neues Paket findet, statt das letzte Problem zu beheben, enthielt das System bereits Fehler, die nicht durch das Upgrade entstanden sind: manuell bearbeitete Dateien unter /usr, angeheftete oder zurückgehaltene Pakete, ein Drittanbieter-Repository, das zentrale Bibliotheken ersetzt hat, oder ein früheres Upgrade, das selbst nie abgeschlossen wurde. Ein neues Image enthält diese Probleme nicht. Ihre Daten darauf wiederherzustellen, dauert weniger lange, als die Ursachen zu ermitteln.

Eine Neuerstellung ist nur dann kostengünstig, wenn sich die Daten an einem anderen Ort als auf dem System befinden. Das ist der Unterschied zwischen einem Snapshot und einem Backup und der Grund, warum die Upgrade-Anleitung beides verlangt.

FAQ

Kann ich do-release-upgrade nach einer Unterbrechung einfach erneut ausführen?

Nicht als ersten Schritt. Wenn der Upgrader in seiner screen-Sitzung noch läuft, verbinden Sie sich mit sudo screen -d -r erneut damit. Ein zweites do-release-upgrade wird beendet, bevor der eigene Reattach-Code erreicht wird, weil der Start verweigert wird, solange für ein Paket noch ein Upgrade aussteht. Wenn der Upgrader beendet wurde, führen Sie zuerst sudo dpkg --configure -a und sudo apt --fix-broken install aus. Wenn die Paketquellen bereits 26.04 angeben, schließen Sie das Upgrade mit sudo apt full-upgrade statt mit dem Upgrader ab. Wenn sie weiterhin 24.04 angeben, führen Sie sudo apt full-upgrade aus. Starten Sie den Server neu, wenn /var/run/reboot-required.pkgs libc6, linux-base oder einen Kernel auflistet, und starten Sie den Upgrader anschließend erneut. Der Upgrader verweigert den Start außerdem, wenn Prompt=never in /etc/update-manager/release-upgrades gesetzt ist oder der Ubuntu-Server „Release upgrade not possible right now“ meldet.

Warum meldet do-release-upgrade, dass es nach dem fehlgeschlagenen Upgrade keine neue Version gibt?

Weil base-files, das Paket, das /etc/os-release schreibt, zu den Paketen gehörte, die vor der Unterbrechung aktualisiert wurden. Das Tool liest diese Datei jetzt ein, geht davon aus, dass Sie 26.04 verwenden, und findet keine neuere Version, die angeboten werden kann. Vergleichen Sie grep VERSION_ID /etc/os-release mit grep Suites /etc/apt/sources.list.d/ubuntu.sources und schließen Sie das Upgrade mit sudo apt update && sudo apt full-upgrade ab.

Ist es sicher, einen teilweise aktualisierten Ubuntu-Server neu zu starten?

Erst, wenn sudo dpkg --audit keine Ausgabe mehr liefert. Ein Neustart mit einem entpackten, aber nicht konfigurierten Kernel oder mit nicht neu erzeugtem GRUB ist die häufigste Ursache dafür, dass aus einem in zehn Minuten behebbaren Upgrade ein Wiederherstellungsvorgang über ein Rescue-Image wird. Schließen Sie die dpkg-Reparatur und apt full-upgrade ab, führen Sie update-initramfs -u -k all und update-grub aus und starten Sie den Server erst danach neu.

Wie finde ich heraus, welches Paket das Upgrade angehalten hat?

Lesen Sie das Ende von /var/log/dist-upgrade/apt-term.log. Dort steht die abschließende Ausgabe von dpkg. Das letzte Paket, das vor dem Ende des Logs genannt wird, war gerade in Bearbeitung. Ein fehlgeschlagenes Maintainer-Skript gibt seinen Fehler direkt über der Fehlermeldung von dpkg aus. /var/log/dpkg.log ist eine zweite Informationsquelle. Die dortigen Zeilen mit dem Zeitstempel des Upgrade-Abbruchs nennen dasselbe Paket. Alles, was Sie seitdem über dpkg ausgeführt haben, wird jedoch danach protokolliert. Deshalb müssen die letzten Zeilen nicht dasselbe Paket nennen. Wenn main.log stattdessen mit einem Python-Traceback endet, ist der Upgrader selbst abgestürzt. Dann ist kein Paket die Ursache.

Sollte ich den Snapshot wiederherstellen oder die Reparatur fortsetzen?

Stellen Sie den Snapshot wieder her, wenn Sie das fehlgeschlagene Paket nicht benennen können, mehr als ein Paket feststeckt, Sie keinen Konsolenzugriff haben oder der Server schnell wieder verfügbar sein muss. Setzen Sie die Reparatur nur fort, wenn Sie genau wissen, was fehlgeschlagen ist, und die Behebung aus einem einzelnen Befehl besteht. Kopieren Sie /var/log/dist-upgrade/ vor der Wiederherstellung vom Server. Andernfalls schlägt der zweite Versuch auf dieselbe Weise fehl.