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 lässt den Server in einem von vier Zuständen zurück. Für jeden Zustand gibt es eine andere Lösung. Der Upgrader läuft möglicherweise noch in einer screen-Sitzung, zu der Sie die Verbindung verloren haben. dpkg wurde möglicherweise beendet, während ein Paket nur teilweise konfiguriert war. Deshalb verweigert apt jetzt jeden Befehl. In den apt-Quellen ist möglicherweise bereits 26.04 eingetragen, 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 ausführen. Die Lösung für einen Zustand kann einen anderen 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 macht aus einer behebbaren Unterbrechung von dpkg den Fall „startet nicht mehr“, der gegen Ende dieses Leitfadens beschrieben wird. 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.

Dieser Leitfaden setzt voraus, dass Sie den Upgrade-Leitfaden von 24.04 auf 26.04 befolgt und vor dem Start einen Snapshot erstellt haben. Falls nicht, berücksichtigen Sie dies beim Lesen des Abschnitts zum Bootvorgang. Der Snapshot ist die Lösung für den schwerwiegendsten 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 der Upgrader lief ohne Sie weiter.

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

Melden Sie sich erneut per SSH an und suchen Sie nach der screen-Sitzung. Der Upgrader 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 angehängt oder getrennt. Wenn eine Sitzung aufgelistet wird, hängen Sie sich wieder an diese an. Ist sie weiterhin als angehängt gekennzeichnet, weil die unterbrochene SSH-Verbindung sie nicht freigegeben hat, trennt -d zuerst diese veraltete Verbindung.

sudo screen -d -r

Wenn mehrere Sitzungen aufgelistet werden, setzen Sie den Sitzungsnamen aus screen -ls hinter -r. Sie können sudo do-release-upgrade auch erneut ausführen. Der Upgrader prüft auf seine bereits vorhandene screen-Sitzung und hängt sich wieder an, statt einen neuen Durchlauf zu starten. In beiden Fällen gelangen Sie zurück zum laufenden Upgrade. Meist wartet es an einer Eingabeaufforderung zu einer geänderten Konfigurationsdatei oder einem Dienstneustart. Beantworten Sie die Frage und lassen Sie den Vorgang abschließen.

Wenn Sie das Upgrade innerhalb von tmux gestartet haben, wie im Upgrade-Leitfaden empfohlen, hängen Sie sich zuerst mit tmux attach wieder an tmux an. Die screen-Sitzung läuft innerhalb dieses tmux-Fensters. Das Upgrade wird daher direkt angezeigt. Enthält das Fenster nur eine Shell-Eingabeaufforderung, läuft der Upgrader dort nicht mehr. Prüfen Sie als Nächstes sudo screen -ls.

Wenn der Haupt-SSH-Port die Verbindung ablehnt, versuchen Sie den Ausweichport: 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. Auf der Konsole zeigt sudo ss -ltnp, an welchen Ports ein sshd-Prozess Verbindungen annimmt. sudo ufw status zeigt, ob die Firewall den Ausweichport durchgelassen hat.

Wenn keine screen-Sitzung existiert und auf der Konsole keine Eingabe erwartet wird, wurde das Upgrade tatsächlich beendet. Stellen Sie sicher, dass kein Prozess mehr 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, für den keine screen-Sitzung zum erneuten Anhängen vorhanden ist, hängt. Warten Sie einige Minuten. Prüfen Sie die Konsole auf eine debconf-Frage, die niemand beantwortet hat. 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 hält. Die Sperre verhindert, dass zwei Schreibprozesse die Paketdatenbank beschädigen.

dpkg wurde unterbrochen und apt verweigert den Start

Wenn dpkg zwischen dem Entpacken eines Pakets und dem Ausführen seines Konfigurationsskripts beendet wird, speichert es diesen unvollständigen Zustand in /var/lib/dpkg/status. Jeder spätere apt-Befehl liest diesen Zustand und beendet sich, weil apt nicht auf einer Datenbank mit unvollständigen Vorgängen aufbauen kann. Unabhängig davon, welche Meldung apt bei der Verweigerung ausgibt, ist der erste Schritt immer gleich.

sudo dpkg --configure -a

Damit wird der Konfigurationsschritt für jedes entpackte, aber noch nicht konfigurierte Paket abgeschlossen. Die Maintainer-Skripte werden in Abhängigkeitsreihenfolge ausgeführt. Auf einem teilweise aktualisierten System kann das lange dauern. Lassen Sie den Vorgang laufen, bis er beendet ist. Wenn er bei einem Paket stoppt, gibt er den Paketnamen und das fehlgeschlagene Skript aus. Notieren Sie sich diesen Namen. Dieses Paket hat die Aktualisierung angehalten. Im nächsten Abschnitt erfahren Sie, wie Sie den Fehler lesen.

Lassen Sie anschließend apt die Abhängigkeiten reparieren, die durch die Unterbrechung unerfüllt geblieben sind. Einige Pakete wurden aktualisiert, die Pakete, von denen sie abhängen, jedoch nicht.

sudo apt --fix-broken install

Schließen Sie anschließend die Aktualisierung ab, die der Upgrader begonnen hatte:

sudo apt update
sudo apt full-upgrade

Verwenden Sie full-upgrade statt upgrade, weil eine Release-Aktualisierung Pakete entfernt und einfaches upgrade das Entfernen von Paketen verweigert. Lesen Sie die von apt ausgegebene Zusammenfassung, bevor Sie bestätigen. Eine kurze Liste zu entfernender Pakete ist normal. Wenn ubuntu-server, systemd, openssh-server oder Ihr Kernel-Paket entfernt werden sollen, ist das nicht normal. Antworten Sie in diesem Fall mit Nein und klären Sie zunächst, warum apt diese Pakete entfernen möchte.

Prüfen Sie das Ergebnis, bevor Sie etwas anderes tun:

sudo dpkg --audit
sudo apt-get check

dpkg --audit listet jedes Paket auf, das sich noch in einem fehlerhaften Zustand befindet, und apt-get check meldet unerfüllte Abhängigkeiten. Beide Befehle sollten keine Ausgabe erzeugen. Führen Sie anschließend sudo apt autoremove aus, um die 24.04-Pakete zu entfernen, von denen nichts mehr abhängt. Bestätigen Sie danach die Release mit cat /etc/os-release. Führen Sie dann sudo update-initramfs -u -k all und sudo update-grub aus und starten Sie erst danach 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 Durchlauf gehört.

main.log ist das eigene Protokoll des Upgraders. Es zeichnet auf, in welcher Phase sich der Durchlauf befand und wie der Upgrader Ihre Paketquellen bewertet hat. Wenn der Upgrader selbst abgestürzt ist, finden Sie hier auch den Python-Traceback. Lesen Sie das Protokoll vom Ende her: Die letzten Zeilen zeigen, in welcher Phase der Upgrader angehalten wurde. Ein Traceback an dieser Stelle bedeutet, dass das Tool fehlgeschlagen ist, nicht ein Paket.

apt.log enthält die Überlegungen des Abhängigkeitsauflösers. Die Datei ist ausführlich und relevant, wenn apt die Aktualisierung überhaupt nicht berechnen konnte. Das ist ein Fehler, bevor ein Paket angefasst wurde. Wenn die Aktualisierung bereits Pakete installiert hat, können Sie diese Datei in der Regel ü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 sonst am Terminal vorbeigelaufen wäre. Das letzte Paket, das vor dem Ende erwähnt wird, wurde ausgeführt, als die Aktualisierung angehalten wurde. Wenn ein Maintainer-Skript fehlgeschlagen ist, steht dpkg's Fehlermeldung 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 jede Statusänderung von dpkg mit einem Zeitstempel. tail -n 30 /var/log/dpkg.log zeigt, welches Paket dpkg zuletzt bearbeitet hat und welcher Vorgang dabei ausgeführt wurde. Das ist dieselbe Information aus einer zweiten Quelle.

Die meisten Fehler in dieser Phase haben auf einem Server eine von wenigen Ursachen. Ein Dienst, den das Paket in seinem postinst 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, meistens /boot durch alte Kernel oder /var durch den Paket-Cache von apt. df -h / /boot /var zeigt dies an. sudo apt clean leert den Cache auch dann, wenn apt ansonsten blockiert ist. Ein Dateisystem, das voll meldet, obwohl du zeigt, dass es nicht voll ist hat eine eigene Ursache. Ein Paket aus einem Drittanbieter-Repository, das der Upgrader deaktiviert hat, hängt möglicherweise von einer Bibliothek ab, die 26.04 nicht mehr bereitstellt. Ein zurückgehaltenes Paket (apt-mark showhold) hat möglicherweise verhindert, dass sich eine Abhängigkeit aktualisiert. 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 wichtige Komponente davon abhängt, 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 dies nur für ein Paket, dessen Namen und Fehlerursache Sie angeben können. Verwenden Sie es niemals für eine Bibliothek oder für etwas in der Abhängigkeitskette ubuntu-server, weil das erzwungene Entfernen die Prüfungen überspringt, die Ihnen zeigen würden, was dadurch noch beschädigt wird.

Die Quellen wurden umgestellt, die Pakete jedoch nicht

Der Upgrader schreibt die APT-Quellen frühzeitig um, bevor er Pakete herunterlädt. Wird der Vorgang danach unterbrochen, nennen die Quellen 26.04, während die installierten Pakete eine Mischung bilden. Diese Mischung verwirrt die Werkzeuge. Deshalb besteht do-release-upgrade möglicherweise darauf, dass keine neue Version verfügbar ist.

Vergleichen Sie die beiden Stellen, die angeben, welche Version installiert ist. /etc/apt/sources.list.d/ubuntu.sources ist die Deb822-Quelldatei, die mit 24.04 eingeführt wurde. Die Suites:-Zeilen enthalten den Codenamen der Version. /etc/os-release wird vom Paket base-files geschrieben und gibt an, welche Version 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. Die Quellen nennen weiterhin 24.04 (Codename noble), und os-release gibt ebenfalls 24.04 an: Das Upgrade ist nicht über seine Prüfungen hinausgekommen. Sie können sudo do-release-upgrade nach dem Lesen von main.log erneut ausführen, um den Grund für den Abbruch zu ermitteln. Die Quellen nennen den Codename von 26.04, während os-release weiterhin 24.04 angibt: Der Austausch der Pakete wurde begonnen und unterbrochen. Die dpkg-Reparatur aus dem vorherigen Abschnitt, die mit apt full-upgrade endet, stellt den Vorgang fertig. Die Quellen nennen 26.04, und os-release gibt ebenfalls 26.04 an: base-files war eines der Pakete, die erfolgreich installiert wurden. Das System bezeichnet sich nun als 26.04, auch wenn der größte Teil noch nicht aktualisiert ist.

Die letzte Kombination ist problematisch. do-release-upgrade ermittelt die installierte Version anhand derselben Informationen, die os-release enthält. Wenn dort bereits 26.04 steht, sucht das Werkzeug nach einer neueren Version. Es findet keine und meldet, dass keine neue Version verfügbar ist. Das Werkzeug beantwortet eine Frage zu os-release, aber os-release ist falsch. Verwenden Sie den Upgrader nicht weiter, sondern schließen Sie das Upgrade mit APT ab: zuerst sudo apt update, danach sudo apt full-upgrade. Dadurch werden alle Pakete aktualisiert, die noch in ihrer 24.04-Version vorliegen. Führen Sie anschließend sudo apt autoremove aus. Die anderen Gründe, aus denen do-release-upgrade keine neue Version meldet, sollten Sie ausschließen, wenn os-release weiterhin 24.04 angibt. Dazu gehört beispielsweise eine LTS-Aufforderung, die auf das erste Point-Release wartet.

Der Upgrader deaktiviert außerdem Drittanbieterquellen unter /etc/apt/sources.list.d/ und legt von jeder geänderten Datei eine Sicherungskopie an, deren ursprünglichem Namen ein Suffix hinzugefügt wird. Führen Sie ls -la /etc/apt/sources.list.d/ aus und vergleichen Sie jede ursprüngliche Datei mit ihrer Sicherung mithilfe von diff, um genau zu sehen, welche Änderungen vorgenommen wurden. Lassen Sie die Einträge der 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 mehrmals 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?

Ja. Das ist der beste erste Schritt. Wenn der Upgrader noch in seiner screen-Sitzung läuft, verbindet die erneute Ausführung wieder mit dieser Sitzung. Wenn das nicht der Fall ist, führen Sie zuerst sudo dpkg --configure -a und sudo apt --fix-broken install aus und starten Sie den Upgrader anschließend erneut. Er liest den aktuellen Zustand erneut ein und setzt das Upgrade fort. Der einzige Fall, in dem dies nicht hilft, liegt vor, wenn /etc/os-release bereits 26.04 ausgibt. Dann geht das Programm davon aus, dass das Upgrade abgeschlossen ist. Führen Sie stattdessen sudo apt full-upgrade aus.

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, vor der Unterbrechung aktualisiert wurde. Das Programm liest diese Datei nun ein, schließt daraus, dass Sie 26.04 verwenden, und bietet kein neueres Release an. Vergleichen Sie grep VERSION_ID /etc/os-release mit grep Suites /etc/apt/sources.list.d/ubuntu.sources und schließen Sie das Upgrade anschließend mit sudo apt update && sudo apt full-upgrade ab.

Ist ein Neustart eines teilweise aktualisierten Ubuntu-Servers sicher?

Erst, wenn sudo dpkg --audit keine Ausgabe mehr liefert. Ein Neustart bei entpacktem, aber noch nicht konfiguriertem Kernel oder bei nicht neu erzeugtem GRUB ist die häufigste Ursache dafür, dass aus einem in zehn Minuten behebbaren Upgrade-Problem ein Einsatz des Rescue-Images 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 befindet sich die Terminalausgabe von dpkg. Das letzte Paket, das vor dem Ende des Logs genannt wird, wurde gerade verarbeitet. Ein fehlgeschlagenes Maintainer-Skript gibt seine Fehlermeldung direkt über der Fehlermeldung von dpkg aus. tail -n 30 /var/log/dpkg.log bestätigt dies anhand einer zweiten Quelle. Wenn main.log dagegen 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, wenn mehr als ein Paket feststeckt, wenn Sie keinen Konsolenzugriff haben oder wenn 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 einzigen Befehl besteht. Kopieren Sie /var/log/dist-upgrade/ vor der Wiederherstellung vom Server. Andernfalls schlägt der zweite Versuch auf dieselbe Weise fehl.