VPS bootet nach Kernel-Update nicht: Lösungen

Was Sie zuerst tun sollten, wenn ein VPS nach einer Kernel-Aktualisierung nicht bootet

Ein VPS, der nach einer Kernel-Aktualisierung nicht bootet, lässt sich meist innerhalb weniger Minuten wiederherstellen, weil die Aktualisierung den Kernel, der am Vortag funktioniert hat, nicht gelöscht hat. Ubuntu installiert einen neuen Kernel neben dem alten und ändert nur, welcher Eintrag von GRUB standardmäßig gestartet wird. Der erste Schritt ist daher keine Reparatur. Wählen Sie im Bootmenü den vorherigen Kernel aus, stellen Sie eine Anmeldeaufforderung wieder her und führen Sie die Diagnose anschließend von einem laufenden System aus durch.

Die Behebung auf einem Server unterscheidet sich von der Behebung auf einem Laptop, weil keine Tastatur angeschlossen ist und kein Monitor den Kernel-Panic anzeigt. Auch SSH antwortet nicht, da der Rechner den Punkt, an dem sshd gestartet wird, nie erreicht hat. Alle folgenden Schritte werden über die Konsole Ihres Providers ausgeführt.

Lesen Sie die Anzeige Ihrer eigenen Konsole, bevor Sie Änderungen vornehmen. Der Text auf diesem Bildschirm bestimmt, welcher Fehlerklasse das Problem zuzuordnen ist. Zwei Server, die beide „nicht booten“, können entgegengesetzte Lösungen 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. Bevorzugen Sie die serial console, wenn beide Optionen vorhanden sind. Sie zeigt echten Text an, den Sie scrollen und kopieren können. Eine VNC-Ansicht ist dagegen nur ein Bild des Bildschirms. Suchen Sie diese Funktion jetzt, solange die Maschine ordnungsgemäß läuft, und prüfen Sie, ob sie sich öffnen lässt. Wenn Sie erst während eines Ausfalls danach suchen, 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 auch einen rescue mode oder ein recovery image an. Dabei wird ein kleines System aus dem Netzwerk des Providers gebootet und Ihre Festplatte als zusätzliches Gerät eingebunden. Auf der Festplatte läuft dadurch nichts. Der rescue mode ist die Ausweichmöglichkeit, wenn bereits GRUB beschädigt ist. Er dient außerdem dazu, Daten von einem Server zu kopieren, den Sie nicht mehr retten wollen.

In der Regel benötigen Sie einen hard reset über das Control Panel, um das Bootmenü zu erreichen. Auf einer Maschine, an der Sie sich nicht anmelden können, lässt sich sudo reboot nicht ausführen. Ein hard reset entspricht dem Trennen der Stromversorgung. Dateisysteme werden dadurch 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 auf einem Rechner, der im Legacy-BIOS-Modus startet, Shift gedrückt. Das Zeitfenster ist kurz, und der Konsolen-Viewer benötigt häufig eine Sekunde für die Verbindung. Beginnen Sie daher frühzeitig mit dem Drücken und fahren Sie damit fort.

Wenn das Menü angezeigt wird, wählen Sie „Advanced options for Ubuntu“. Dieses Untermenü listet alle installierten Kernel auf, den neuesten zuerst, jeweils mit einem Eintrag für den Recovery-Modus. Wählen Sie den zweiten normalen Eintrag, also den Kernel unterhalb des neuesten, und drücken Sie die Eingabetaste. Der Recovery-Modus 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 wieder ein laufender Server zur Verfügung. Prüfen Sie, welcher Kernel aktiv ist, und notieren Sie die Versionsnummern.

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

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

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

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

Es gibt auch den umgekehrten Fall: Das Menü wird angezeigt und wartet, sodass es wie ein Systemstillstand wirkt. GRUB registriert einen fehlgeschlagenen Bootvorgang. Beim nächsten Start kann GRUB das Menü geöffnet lassen, 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 die Ursache. 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 eingelesen 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 sich die Konsolenausgabe nicht mehr ändert. Vier Muster decken die meisten Fälle nach einem Kernel-Update ab.

GRUB findet seine eigenen Dateien nicht. Sie erhalten eine grub rescue>-Eingabeaufforderung oder eine Fehlermeldung zu einer Partition oder Datei, die nicht vorhanden ist. Eine Kernelmeldung erscheint nicht. Der Kernel ist zu diesem Zeitpunkt noch nicht beteiligt. Dies geschieht nach einer Änderung an Datenträgern oder Partitionen oder wenn der Bootloader auf das falsche Gerät geschrieben wurde. Ein Kernel-Paket allein ist dafür nicht die Ursache.

Der Kernel startet, kann das Root-Dateisystem aber nicht einhängen. Kernelmeldungen laufen über den Bildschirm. Danach landen Sie in einer 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 eigentliches Root-Dateisystem sucht und einhängt, hat den Datenträger nicht gefunden. Unter Ubuntu erscheint vor dieser Shell normalerweise eine Meldung, dass das Warten auf das Root-Gerät abgebrochen wurde. Sie nennt die erwartete UUID. Kopieren Sie diese UUID und vergleichen Sie sie später mit der Ausgabe von blkid.

Ein logisches Volume wird nicht verfügbar. 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 ist daher noch nicht vorhanden. Aktivieren Sie die Volume Groups manuell:

lvm vgchange -ay
ls /dev/mapper
exit

exit übergibt die Kontrolle wieder an das Initramfs-Skript, das den Einhängevorgang erneut versucht. Wenn das System anschließend startet, fehlen der neuen Initramfs die LVM-Bestandteile. Sie müssen dann dieses Image neu erstellen und nicht den Kernel ändern.

Von Linux ist überhaupt nichts zu sehen. 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

Ein nicht eingehängtes /boot/efi während des Upgrades ist auf UEFI-Systemen eine häufige Ursache. Die Pakete zur Pflege der EFI-Systempartition schreiben dann stattdessen in ein gewöhnliches leeres Verzeichnis. Die Firmware startet weiterhin den alten Booteintrag, bis dieser nicht mehr zum Inhalt des Datenträgers passt.

Ein weiteres Muster ist überhaupt kein Bootfehler. Wenn Sie eine Root-Shell erreichen, die meldet, dass sich das System im Emergency Mode befindet, wurde der Kernel gestartet und der Userspace beendet. In der Regel ist eine fehlerhafte Zeile in /etc/fstab oder ein Dateisystem, dessen Prüfung fehlgeschlagen ist, die Ursache. 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 Fehler sehen auf der Konsole identisch aus, erfordern aber 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, weist auf eine fehlgeschlagene initramfs-Generierung hin. Der häufigste Grund ist ein volles /boot. Die entsprechenden Hinweise finden Sie 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 führt 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. Erstellen Sie anschließend das Image für die benötigte Version neu und aktualisieren Sie das Bootmenü. Übernehmen Sie die Versionszeichenfolge aus Ihrer eigenen ls-Ausgabe, da der Platzhalter unten keine echte Version bezeichnet:

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 zeigt, dass das Image wieder vorhanden ist. Wenn stattdessen das Kernel-Image selbst beschädigt ist oder dpkg -l für das Paket einen anderen Status 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 den Datenträger von außen. Der Datenträger erscheint als nicht eingehängtes Gerät. Daher läuft nichts von ihm, 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 riskieren

GRUB kann einen Eintrag einmalig starten und anschließend auf den von Ihnen gewählten Standard zurückfallen. Legen Sie als Standard einen Kernel fest, dem Sie vertrauen, und starten Sie den neuen Kernel nur für diesen einen Bootvorgang. Falls er fehlschlägt, bringt ein Hard Reset über das Panel Sie ohne korrektes Timing an der Konsole 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 Eintragstitel 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, da zum Speichern ein beschreibbares /boot/grub/grubenv erforderlich ist und dieses bei manchen Layouts stillschweigend nicht beschreibbar ist. Eintrag 0 steht für den obersten Menüeintrag und damit für den neuesten Kernel. Titel sind hier sicherer als Nummern, da sich die Nummern bei jeder Installation oder Entfernung eines Kernels ändern.

Warum autoremove auf einem Headless-Server riskant ist

APT führt eine Liste der Kernel-Pakete, die es nicht selbst entfernen darf. Lesen Sie Ihre Liste:

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

Diese Datei wird bei jeder Änderung an Kernel-Paketen neu erzeugt. Sie schützt den laufenden Kernel und die neuesten 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 lästig. Auf einem Headless-Server entscheidet es darüber, ob Sie einen Menüeintrag auswählen können oder Ihre Festplatte von einem Rescue-Image aus einbinden müssen.

Behalten Sie mindestens zwei Kernel. Wenn /boot ausreichend Platz hat, sollten es drei sein. Entfernen Sie alte Kernel nach einer Prüfung von uname -r anhand ihres Namens. So können Sie den 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.

Erstellen Sie vor dem Upgrade einen Snapshot

Ein vor apt upgrade erstellter Snapshot ist der einzige Wiederherstellungspfad, der nicht davon abhängt, dass irgendetwas bootet. Durch die Wiederherstellung wird der Datenträger 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 den Datenträger so erfassen, als wäre die Stromversorgung unterbrochen worden. Fahren Sie den Server daher zuerst herunter, wenn Ihr Provider Offline-Snapshots unterstützt. Ein Snapshot ist außerdem kein Backup, weil er normalerweise auf derselben Infrastruktur wie das kopierte Volume liegt. Wenn Sie den Unterschied zwischen VPS-Snapshots und echten Backups verstehen, können Sie entscheiden, welche Option Sie bei einem Fehler verwenden, der über ein Kernelproblem hinausgeht.

Das ist bei einem Release-Upgrade besonders wichtig. Dabei werden der Kernel, die initramfs-Werkzeuge, der Bootloader und die GRUB-Konfiguration in einem Durchlauf geändert. Erstellen Sie den Snapshot unmittelbar vor Beginn eines Upgrades von Ubuntu 24.04 auf 26.04 und nicht am Vorabend. So entspricht der Wiederherstellungspunkt genau dem Zustand des Systems, den Sie ändern werden. Wenn dieses Upgrade auf Ihrem Server noch nicht angeboten wird, liegt das an der Zeitplanung und nicht an einer fehlerhaften Konfiguration. Ein Wechsel von LTS zu LTS wird erst mit dem ersten Point-Release, 26.04.1 freigeschaltet.

Wie unattended-upgrades Kernelpakete behandelt

Ubuntu installiert mit unattended-upgrades Sicherheitsupdates ohne Rückfrage. Kernelpakete kommen wie alle anderen Pakete aus dem 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 zeigt, welcher Prozess 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 verschleiert diese Lücke die Ursache. Ein Server kann im März einen Kernel installieren und im Juni aus einem völlig anderen Grund neu starten. Anschließend fährt er möglicherweise nicht mehr hoch. 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. Unter /var/log/apt/history.log finden Sie den Lauf, der den Kernel installiert hat, mit dem der Server jetzt nicht mehr startet.

Führen Sie den Reboot bewusst an einem von Ihnen festgelegten Tag durch. Öffnen Sie vorher bereits die Konsolensitzung. Diese einfache Vorgehensweise macht aus einem ungeklärten Ausfall eine Menüauswahl von zwei Minuten. Wenn Sie die Automatisierung ohne unerwartete Reboots nutzen 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 Kernel-Sicherheitsupdates verhindert. Betrachten Sie dies daher als eine 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 Anbieters (VNC oder seriell) und lösen Sie über das Control Panel einen Hard Reset aus, da Sie sich nicht anmelden können, um den Rechner ordnungsgemäß neu zu starten. Drücken Sie beim Neustart wiederholt Esc oder halten Sie bei einem Legacy-BIOS-Start 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 aktiven Kernel zu prüfen, und dpkg -l 'linux-image-*', um die übrigen installierten Kernel anzuzeigen. Führen Sie die Diagnose erst durch, 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 startet der neueste Kernel, 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 auf einer seriellen 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/, da 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 eine eigene Fehlerursache, weil dann die Initramfs-Erzeugung fehlschlägt und nur ein Kernel ohne funktionierendes Image verbleibt. Entfernen Sie Pakete erst nach der Prüfung mit uname -r anhand ihres exakten Paketnamens, damit der aktive Kernel niemals als Kandidat ausgewählt wird. Vermeiden Sie auf einem Rechner ohne Tastatur und Bildschirm ein pauschales sudo apt autoremove --purge. Die Liste der geschützten Kernel wird bei jeder Kerneländerung neu erzeugt. Bei einem ungünstigen Zeitpunkt kann dadurch nur ein Kernel ohne Fallback-Eintrag im Menü verbleiben.

Können unattended-upgrades den Systemstart verhindern?

Das Programm kann einen Kernel installieren, der später nicht bootet. Es startet den Rechner 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 Laufs installiert, /var/run/reboot-required wird erstellt, und das Problem zeigt sich erst beim nächsten Neustart, der Wochen später erfolgt. Starten Sie den Rechner bewusst neu, während die Konsole bereits geöffnet ist, und lesen Sie /var/log/apt/history.log aus, um festzustellen, welcher Lauf den Kernel installiert hat, mit dem Sie gerade booten.