VPS bootet nach Kernel-Update nicht: Lösungen

Was Sie zuerst tun sollten, wenn ein VPS nach einem Kernel-Update nicht bootet

Ein VPS, der nach einem Kernel-Update nicht bootet, lässt sich meist innerhalb weniger Minuten wiederherstellen. Das Update hat den Kernel, der gestern noch funktioniert hat, normalerweise nicht gelöscht. Ubuntu installiert einen neuen Kernel neben dem alten und ändert nur den Eintrag, den GRUB standardmäßig startet. Der erste Schritt ist daher keine Reparatur. Wählen Sie im Boot-Menü den vorherigen Kernel aus, stellen Sie eine Login-Eingabeaufforderung wieder her und führen Sie die Diagnose anschließend aus einem laufenden System heraus durch.

Die Fehlerbehebung auf einem Server unterscheidet sich von der auf einem Laptop. An den Server ist keine Tastatur angeschlossen, und kein Monitor zeigt den Kernel-Panic-Fehler an. Auch über SSH erhalten Sie keine Antwort, weil das System den Punkt, an dem sshd startet, noch nicht erreicht hat. Alle folgenden Schritte erfolgen über die Konsole Ihres Providers.

Lesen Sie zuerst die Ausgabe Ihrer eigenen Konsole, bevor Sie etwas ändern. Der Text auf diesem Bildschirm bestimmt, welcher Fehlerklasse das Problem zuzuordnen ist. Zwei Server, die beide „nicht booten“, können entgegengesetzte Maßnahmen erfordern.

Wie erreiche ich die Konsole, wenn SSH nicht funktioniert?

Öffnen Sie das Control Panel Ihres Providers und suchen Sie nach einer Konsole. Übliche Bezeichnungen sind VNC console, web console, noVNC und serial console. Wenn beide Optionen vorhanden sind, bevorzugen Sie die serial console. Sie liefert echten Text, den Sie scrollen und kopieren können, während eine VNC-Ansicht nur ein Bildschirmbild darstellt. Suchen Sie diese Funktion jetzt, solange die Maschine ordnungsgemäß läuft, und prüfen Sie, ob sie sich öffnen lässt. Wenn Sie während eines Ausfalls danach suchen müssen, fehlt Ihnen die nötige Ruhe. Diese Prüfung gehört zu den ersten zehn Minuten auf einem neuen VPS, zusammen mit den Firewall-Regeln und den SSH-Schlüsseln.

Die meisten Control Panels bieten außerdem einen rescue mode oder ein recovery image an. Dabei wird ein kleines System aus dem Netzwerk des Providers gestartet und Ihre Festplatte als zusätzliches Gerät eingebunden. Dadurch wird nichts von Ihrer Festplatte ausgeführt. Der rescue mode ist die Ausweichlösung, wenn GRUB selbst beschädigt ist. Er dient auch dazu, Daten von einem Server zu kopieren, den Sie nicht mehr retten wollen.

In der Regel benötigen Sie im Control Panel einen hard reset, um das Bootmenü zu erreichen, da Sie sudo reboot auf einer Maschine, bei der Sie sich nicht anmelden können, nicht ausführen können. Ein hard reset entspricht dem Trennen der Stromversorgung. Dateisysteme werden dabei nicht ordnungsgemäß heruntergefahren. Rechnen Sie deshalb beim nächsten Boot mit einer Dateisystemprüfung.

Wie wähle ich im GRUB-Menü einen älteren Kernel aus?

Beobachten Sie die Konsole ab dem Moment, in dem Sie den Reset auslösen. Drücken Sie in den ersten Sekunden wiederholt Esc oder halten Sie Shift gedrückt, wenn der Rechner im Legacy-BIOS-Modus startet. Das Zeitfenster ist kurz. Außerdem benötigt der Konsolen-Viewer oft eine Sekunde zum Verbinden. Beginnen Sie daher frühzeitig mit dem Drücken und setzen Sie dies fort.

Wenn das Menü erscheint, wählen Sie „Advanced options for Ubuntu“. Das Untermenü listet jeden installierten Kernel auf, beginnend mit dem neuesten. Für jeden Kernel gibt es außerdem einen Eintrag für den Recovery Mode. Wählen Sie den zweiten normalen Eintrag aus. Das ist der Kernel unterhalb des neuesten Kernels. Drücken Sie anschließend die Eingabetaste. Der Recovery Mode ist etwas anderes. Er startet ein minimales Single-User-System und dient Reparaturarbeiten, nicht dazu, Ihre Dienste wieder online zu bringen.

Wenn der ältere Kernel startet, steht Ihnen der Server wieder zur Verfügung. Prüfen Sie, mit welchem Kernel Sie arbeiten, und notieren Sie die Versionsnummern.

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

Die Ausgabe von dpkg enthält die Liste der installierten Kernel. Wenn sie nur eine Zeile enthält, gibt es überhaupt keinen Fallback. Das müssen Sie zuerst beheben.

Das GRUB-Menü wird nicht angezeigt. Was nun?

Cloud-Images enthalten eine Konfiguration, die das Menü ausblendet. Ubuntu-Images setzen das Timeout häufig auf 0 in einer Datei unter /etc/default/grub.d/. Dadurch startet der neueste Kernel sofort, und es gibt keine Eingabeaufforderung.

Es gibt auch den umgekehrten Fall: Das Menü wird angezeigt und wartet, sodass es wie ein Hänger aussieht. GRUB erkennt einen fehlgeschlagenen Bootvorgang. Beim nächsten Start kann GRUB das Menü geöffnet halten, bis jemand eine Taste drückt. Auf einem System ohne Tastatur endet diese Wartezeit nie. Wenn Ihre Konsole ein Menü anzeigt und sich nichts bewegt, ist das passiert. Wählen Sie einen Eintrag aus und setzen Sie den Startvorgang fort.

Beheben Sie beide Fälle, solange das System ordnungsgemäß läuft. Bearbeiten Sie /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

Wenden Sie die Änderung anschließend an und prüfen Sie, ob sie erhalten geblieben ist. Dateien unter /etc/default/grub.d/ werden nach /etc/default/grub gelesen und können Ihre Einstellungen überschreiben.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" sendet das Menü an die grafische Konsole und an den seriellen Port. Dadurch wird es in dem Viewer angezeigt, den Ihr Panel bereitstellt. Die Kernel-Argumente console= bewirken dasselbe für die anschließenden Bootmeldungen. Zehn Sekunden Verzögerung pro Bootvorgang sind ein geringer Preis für ein Menü, auf das Sie um 2 Uhr morgens tatsächlich zugreifen können.

Welche Fehlerklasse liegt vor?

Lesen Sie die letzten zwanzig Zeilen, bevor die Konsole keine neuen Ausgaben mehr anzeigt. Vier Muster decken die meisten Fehler nach einer Kernel-Aktualisierung ab.

GRUB findet seine eigenen Dateien nicht. Sie sehen eine grub rescue>-Eingabeaufforderung oder eine Fehlermeldung zu einer Partition oder Datei, die nicht existiert. Eine Kernelmeldung erscheint nicht. Der Kernel ist zu diesem Zeitpunkt noch nicht beteiligt. Das tritt nach einer Änderung an Datenträgern oder Partitionen oder nach dem Schreiben des Bootloaders auf das falsche Gerät auf, nicht durch ein Kernel-Paket allein.

Der Kernel startet, kann aber das Root-Dateisystem nicht einhängen. Kernelmeldungen laufen über den Bildschirm. Danach gelangen Sie in eine BusyBox-Shell mit der Eingabeaufforderung (initramfs). Alternativ endet der Bootvorgang mit einem Panic-Fehler, weil das Root-Dateisystem nicht eingehängt werden konnte. Der Kernel wurde geladen. Die initramfs, also das kleine temporäre Root-Dateisystem, das Ihr tatsächliches Root-Dateisystem findet und einhängt, hat den Datenträger nicht gefunden. Unter Ubuntu geht dieser Shell normalerweise eine Meldung voraus, dass das Warten auf das Root-Gerät abgebrochen wurde. Die Meldung nennt die erwartete UUID. Kopieren Sie diese UUID und vergleichen Sie sie später mit der Ausgabe von blkid.

Ein logisches Volume erscheint nicht. Dies ist die vorherige Fehlerklasse mit einer bestimmten Ursache. Führen Sie an der Eingabeaufforderung (initramfs) den Befehl ls /dev/mapper aus. Wenn der einzige Eintrag control lautet, wurde kein LVM-Volume (Logical Volume Manager) aktiviert. Das Root-Gerät existiert daher noch nicht. Aktivieren Sie die Volume Groups manuell:

lvm vgchange -ay
ls /dev/mapper
exit

exit übergibt die Steuerung wieder an das initramfs-Skript. Dieses versucht erneut, das Dateisystem einzuhängen. Wenn das System danach startet, fehlen der neuen initramfs die LVM-Bestandteile. Die Reparatur besteht dann darin, dieses Image neu zu erstellen, nicht den Kernel zu ändern.

Überhaupt keine Linux-Ausgabe. Die Konsole zeigt Firmware-Text, eine UEFI-Shell (Unified Extensible Firmware Interface), einen leeren Bildschirm ohne Kernel-Ausgabe oder eine Neustartschleife. Der Fehler tritt auf, bevor Linux ausgeführt wird. Prüfen Sie nach der Wiederherstellung, welchen Modus Ihr Server tatsächlich verwendet. Viele VPS-Instanzen starten im Legacy-BIOS-Modus und verwenden den EFI-Pfad nie:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

Eine während der Aktualisierung nicht eingehängte /boot/efi ist auf UEFI-Systemen eine häufige Ursache. Die Pakete zur Verwaltung der EFI-Systempartition schreiben dann stattdessen in ein gewöhnliches leeres Verzeichnis. Die Firmware startet weiterhin den alten Booteintrag, bis dieser nicht mehr mit dem Inhalt des Datenträgers übereinstimmt.

Ein weiteres Muster ist überhaupt kein Bootfehler. Wenn Sie eine Root-Shell erreichen und dort steht, dass sich das System im Notfallmodus befindet, wurde der Kernel gestartet und der Userspace angehalten. Meistens ist eine fehlerhafte Zeile in /etc/fstab oder ein Dateisystem die Ursache, dessen Prüfung fehlgeschlagen ist. Führen Sie in dieser Shell journalctl -xb aus und lesen Sie den Namen der fehlgeschlagenen Unit.

Ist das Kernelpaket beschädigt oder die initramfs?

Diese beiden Fälle sehen auf der Konsole identisch aus und erfordern unterschiedliche Reparaturen. Starten Sie den alten Kernel und vergleichen Sie anschließend die Dateien.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

Für jede installierte Version benötigen Sie jeweils eine vmlinuz- und eine passende initrd.img- mit plausibler Größe. Eine fehlende initrd oder eine Datei, die deutlich kleiner als die benachbarten Dateien ist, bedeutet, dass die initramfs-Erzeugung fehlgeschlagen ist. Der häufigste Grund ist ein volles /boot. Die entsprechenden Hinweise stehen in den Paketprotokollen:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log listet außerdem genau auf, welche Pakete bei den letzten Ausführungen wann installiert wurden. Damit lässt sich eindeutig feststellen, was geändert wurde.

Schaffen Sie zuerst freien Speicherplatz, wenn /boot voll ist. Erzeugen Sie anschließend das Image für die benötigte Version neu und aktualisieren Sie das Bootmenü. Verwenden Sie die Versionszeichenfolge aus Ihrer eigenen ls-Ausgabe, da der Platzhalter unten keine echte Version darstellt:

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

Das letzte ls dient zur Kontrolle. Eine Datei mit normaler Größe bedeutet, dass das Image jetzt vorhanden ist. Wenn stattdessen das Kernel-Image selbst beschädigt ist oder dpkg -l das Paket in einem anderen Zustand als ii anzeigt, installieren Sie das Paket neu:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

Reparatur aus dem Rescue-Modus, wenn kein Kernel startet

Wenn jeder Eintrag im Menü fehlschlägt, starten Sie das Rescue-Image des Providers und reparieren Sie die Festplatte von außen. Ihre Festplatte wird als nicht eingehängtes Gerät angezeigt. Daher läuft darauf nichts, und kein Prozess kann die Reparatur blockieren.

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

Einen neuen Kernel testen, ohne den nächsten Bootvorgang zu gefährden

GRUB kann einen Eintrag einmalig starten und danach auf den von Ihnen gewählten Standard zurückfallen. Setzen Sie den Standard auf einen Kernel, dem Sie vertrauen, und starten Sie den neuen Kernel nur für einen Bootvorgang. Falls er fehlschlägt, bringt ein Hard Reset über das Panel Sie ohne Zeitdruck bei der Konsolenbedienung zum funktionierenden Kernel zurück.

Setzen Sie GRUB_DEFAULT=saved in /etc/default/grub, führen Sie sudo update-grub aus und listen Sie anschließend die Titel der Einträge auf, damit Sie einen davon exakt angeben können:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list sollte Ihren gewählten Titel als saved_entry ausgeben. Diese Ausgabe bestätigt, dass der Mechanismus funktioniert, weil zum Speichern ein beschreibbares /boot/grub/grubenv erforderlich ist und dies bei manchen Layouts stillschweigend nicht der Fall ist. Eintrag 0 steht am Anfang des Menüs und entspricht damit dem neuesten Kernel. Titel sind hier sicherer als Nummern, weil sich die Nummern jedes Mal ändern, wenn ein Kernel installiert oder entfernt wird.

Warum autoremove auf einem headless Server riskant ist

APT verwaltet eine Liste der Kernel-Pakete, die es nicht eigenständig entfernen darf. Lesen Sie Ihre Liste:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

Diese Datei wird jedes Mal neu erzeugt, wenn sich Kernel-Pakete ändern. Sie schützt den laufenden Kernel und die zuletzt installierten Kernel. Das Problem ist der Zeitpunkt. Wenn Sie sudo apt autoremove --purge direkt nach dem Neustart mit einem neuen Kernel ausführen, wurde die geschützte Liste bereits aktualisiert. Der ältere Kernel, auf den Sie angewiesen waren, ist dann nicht mehr geschützt. Auf einem Rechner mit Tastatur ist das nur ein Ärgernis. Auf einem headless Server entscheidet es darüber, ob Sie einen Menüeintrag auswählen können oder Ihre Festplatte über ein Rescue-Image einbinden müssen.

Behalten Sie mindestens zwei Kernel. Wenn /boot genügend Speicherplatz hat, sollten es drei sein. Entfernen Sie alte Kernel nach einer Prüfung von uname -r anhand ihres Namens. So können Sie den aktuell laufenden Kernel nicht löschen:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

Führen Sie den letzten Befehl anschließend erneut aus. Wenn die Anzahl von drei auf zwei sinkt, handelt es sich um eine Bereinigung. Wenn sie auf eins sinkt, ist der nächste Neustart ein absehbarer Ausfall.

Vor dem Upgrade einen Snapshot erstellen

Ein vor apt upgrade erstellter Snapshot ist der einzige Wiederherstellungspfad, der nicht davon abhängt, dass irgendetwas bootet. Durch die Wiederherstellung wird die Festplatte in den Zustand zurückversetzt, in dem der alte Kernel der Standardkernel war. Danach können Sie das Upgrade mit bereits geöffneter Konsole erneut versuchen. Snapshots eines laufenden Systems sind crash-konsistent. Das bedeutet, dass sie die Festplatte so erfassen, als wäre die Stromversorgung unterbrochen worden. Fahren Sie den Server daher zuerst herunter, wenn Ihr Provider einen Offline-Snapshot unterstützt. Ein Snapshot ist außerdem kein Backup, weil er normalerweise auf derselben Infrastruktur wie das kopierte Volume liegt. Wenn der Fehler größer ist als ein Kernelproblem, entscheidet das Verständnis von dem Unterschied zwischen VPS-Snapshots und echten Backups, welche Option Sie rettet.

Das ist besonders bei einem Release-Upgrade wichtig. Dabei werden Kernel, initramfs-Tools, Bootloader und die GRUB-Konfiguration in einem Durchlauf geändert. Erstellen Sie den Snapshot unmittelbar vor Beginn von einem Upgrade von Ubuntu 24.04 auf 26.04, nicht am Vorabend. So entspricht der Wiederherstellungspunkt genau dem Zustand des Systems, den Sie ändern werden.

Umgang von unattended-upgrades mit Kernelpaketen

Ubuntu's unattended-upgrades installiert Sicherheitsupdates ohne Rückfrage. Kernelpakete kommen wie alle anderen Pakete über das Security-Pocket. Daraus ergeben sich zwei Folgen.

Erstens wird der neue Kernel installiert, aber nicht ausgeführt. Ein Kernel wird erst beim Booten aktiv. Die Datei /var/run/reboot-required wird angelegt. /var/run/reboot-required.pkgs nennt den Dienst, der den Reboot angefordert hat. Ohne aktiviertes Unattended-Upgrade::Automatic-Reboot in /etc/apt/apt.conf.d/50unattended-upgrades wird jedoch nichts neu gestartet.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

Zweitens kann diese Lücke die Ursache verschleiern. Ein Server kann im März einen Kernel installieren und im Juni aus einem völlig anderen Grund neu starten. Danach startet er möglicherweise nicht mehr. Die Änderung, die den Bootvorgang beschädigt hat, ist dann drei Monate alt. Nichts, was Sie an diesem Tag getan haben, erklärt den Fehler. In /var/log/apt/history.log finden Sie den Lauf, bei dem der Kernel installiert wurde, an dem der Server jetzt scheitert.

Führen Sie den Reboot bewusst an einem von Ihnen festgelegten Tag durch, und öffnen Sie vorher bereits die Konsole. Diese einfache Gewohnheit macht aus einem rätselhaften Ausfall eine Auswahl in einem zweiminütigen Menü. Wenn Sie die Automatisierung ohne die Überraschung möchten, lassen Sie automatische Installationen aktiviert und automatische Reboots deaktiviert. Die genauen Einstellungen finden Sie unter unattended-upgrades unter Ubuntu konfigurieren. Das Zurückhalten von Kernelpaketen mit sudo apt-mark hold linux-image-generic verhindert deren Installation vollständig. Dadurch werden gleichzeitig Sicherheitskorrekturen für den Kernel verhindert. Betrachten Sie das daher als bewusste Abwägung und nicht als Sicherheitsmaßnahme.

FAQ

Wie boote ich auf einem VPS ohne Tastatur einen älteren Kernel?

Öffnen Sie die Konsole des Providers (VNC oder seriell) und lösen Sie im Control Panel einen Hard Reset aus, weil Sie sich nicht anmelden können, um das System sauber neu zu starten. Drücken Sie beim Neustart wiederholt Esc oder halten Sie bei einem Bootvorgang mit Legacy-BIOS Shift gedrückt, damit das GRUB-Menü geöffnet bleibt. Wählen Sie „Advanced options for Ubuntu“ und anschließend den Eintrag unterhalb des neuesten Kernels. Sobald eine Anmeldeaufforderung angezeigt wird, führen Sie uname -r aus, um den aktuell verwendeten Kernel zu bestätigen, und dpkg -l 'linux-image-*', um die übrigen installierten Kernel anzuzeigen. Beginnen Sie erst mit der Diagnose, wenn das System wieder läuft.

Warum zeigt mein VPS überhaupt kein GRUB-Menü an?

Cloud-Images setzen das GRUB-Timeout häufig in einer Datei unter /etc/default/grub.d/ auf 0. Dadurch wird der neueste Kernel gestartet, ohne dass eine Eingabe möglich ist. Setzen Sie in /etc/default/grub GRUB_TIMEOUT=10 und GRUB_TIMEOUT_STYLE=menu und ergänzen Sie GRUB_TERMINAL="console serial", damit das Menü auch über eine serielle Konsole ausgegeben wird. Führen Sie anschließend sudo update-grub aus. Prüfen Sie das Ergebnis mit grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, weil Dateien in diesem Verzeichnis nach der Hauptdatei eingelesen werden und Ihre Änderung überschreiben können.

Sollte ich alte Kernel entfernen, um Speicherplatz in /boot freizugeben?

Entfernen Sie die ältesten Kernel und behalten Sie mindestens zwei. Ein volles /boot ist ein eigener Fehlerfall, weil die Erstellung des initramfs dann fehlschlägt und nur ein Kernel ohne funktionierendes Image verbleibt. Löschen Sie Pakete nach der Prüfung mit uname -r anhand des exakten Paketnamens, damit der aktuell laufende Kernel niemals als Kandidat ausgewählt wird. Vermeiden Sie auf einem nicht über eine Tastatur verwalteten System ein pauschales sudo apt autoremove --purge, weil die Liste der geschützten Kernel bei jeder Kerneländerung neu erzeugt wird und ein ungünstig gestarteter Vorgang dazu führen kann, dass nur ein Kernel ohne Fallback-Eintrag im Menü verbleibt.

Können unattended-upgrades den Systemstart verhindern?

Das Programm kann einen Kernel installieren, der später nicht bootet. Es startet das System jedoch nicht neu, sofern Unattended-Upgrade::Automatic-Reboot in /etc/apt/apt.conf.d/50unattended-upgrades nicht auf true gesetzt ist. Typischerweise tritt der Fehler verzögert auf: Der Kernel wird während eines automatischen Vorgangs installiert, /var/run/reboot-required erscheint, und das Problem wird erst beim nächsten Neustart Wochen später sichtbar. Starten Sie das System bewusst neu, während die Konsole bereits geöffnet ist, und lesen Sie /var/log/apt/history.log aus, um festzustellen, welcher Vorgang den Kernel installiert hat, mit dem Sie gerade booten.