Ubuntu VPS: Kernel für den nächsten Start festlegen

Was entscheidet, mit welchem Kernel Ihre VPS startet

Welcher Kernel beim nächsten Start Ihrer VPS gebootet wird, entscheidet eine generierte Datei: /boot/grub/grub.cfg. Diese Datei bearbeiten Sie nie direkt. Sie ändern ihre Eingaben und generieren sie anschließend neu. Bei einem Ubuntu-Cloud-Image stammt eine dieser Eingaben vom Image-Anbieter. Sie kann die Auswahl im Bootmenü unwirksam machen. Deshalb ändern GRUB_DEFAULT=1 und anschließend update-grub auf einem gemieteten Server nichts, während dieselben beiden Schritte bei einer Laptop-Installation funktionieren.

Gehen Sie in dieser Reihenfolge vor. Prüfen Sie, ob Sie den Kernel selbst auswählen können. Lesen Sie jede Eingabedatei, einschließlich der vom Anbieter hinzugefügten Dateien. Lesen Sie die generierte Ausgabe und zählen Sie die Einträge, die sie tatsächlich enthält. Wählen Sie erst danach eine Methode zum Festlegen des Kernels. Wenn Sie dies auf einem Rechner falsch machen, den Sie nur über SSH erreichen, benötigen Sie eine Rettungskonsole. Deshalb stehen die sichersten Antworten am Ende dieser Seite. Sie sind häufig die richtigen.

Prüfen Sie zuerst, ob der Kernel Ihnen gehört und angeheftet werden kann

uname -r
systemd-detect-virt
ls -1 /boot/vmlinuz-*

systemd-detect-virt, kvm, qemu oder xen bedeutet, dass Sie Ihren eigenen Kernel ausführen und alle folgenden Schritte gelten. lxc oder openvz bedeutet, dass Ihr Server den Kernel des Hosts verwendet. Sie haben daher keinen eigenen Bootloader und können keinen Kernel anheften. In diesem Fall zeigt uname -r eine Version an, die in /boot/vmlinuz-* überhaupt nicht erscheint. Der laufende Kernel gehört dem Host, und keine Einstellung auf Ihrer Festplatte kann ihn ändern.

ls -1 /boot/vmlinuz-* ist die tatsächliche Liste der Kernel, zwischen denen Sie wählen können. Enthält sie nur eine Zeile, wurde der vorherige Kernel bereits gelöscht. Keine Bootloader-Einstellung kann ihn zurückbringen. Das geschieht normalerweise während eines autoremove-Vorgangs. Sie sollten diesen Vorgang verstehen, bevor Sie auf einem wichtigen System alte Kernel unter Ubuntu bereinigen.

Die bearbeitete Datei ist nicht die Datei, die GRUB einliest

/etc/default/grub enthält einfache Zuweisungen von Shell-Variablen. Sie dient als Eingabe. /boot/grub/grub.cfg ist die Ausgabe. Sie beginnt mit # DO NOT EDIT THIS FILE und dem entsprechenden Grund. Alles, was Sie in die Ausgabedatei schreiben, ist verloren, sobald ein Kernel-Paket installiert oder entfernt wird, weil die Paketskripte die Datei dann neu erzeugen.

cat /usr/sbin/update-grub

update-grub ist ein Wrapper. Er führt grub-mkconfig -o /boot/grub/grub.cfg aus. Dieses liest die Variablen ein, führt jedes Skript in /etc/grub.d/ aus und schreibt das Ergebnis. Zwei Befehle, eine Richtung: Die Eingaben fließen hinein, grub.cfg kommt heraus.

Was Ihre Einstellung überschreibt: /etc/default/grub.d

grep -rn '^[^#]' /etc/default/grub /etc/default/grub.d/

Der zweite Pfad ist der Teil, der häufig übersehen wird. grub-mkconfig lädt zuerst /etc/default/grub und anschließend jede *.cfg-Datei in /etc/default/grub.d/ in der Reihenfolge der Dateinamen. Lesen Sie den Code, der dies ausführt:

grep -n 'default/grub' /usr/sbin/grub-mkconfig

Das Einlesen erfolgt in einer normalen Shell. Daher gilt die letzte Zuweisung. Ubuntu-Cloud-Images liefern Dateien in diesem Verzeichnis aus. Diese setzen beispielsweise das Timeout und die Kernel-Befehlszeile, nachdem Ihre Datei bereits eingelesen wurde. Ihre Einstellung GRUB_TIMEOUT=10 in /etc/default/grub wird kurz darauf von einer Herstellerdatei überschrieben, die den Wert auf 0 setzt. Der obige grep-Befehl gibt die tatsächlichen Zuweisungen auf Ihrem Image aus. Orientieren Sie sich daher an dieser Ausgabe und nicht an diesem Satz.

Daraus folgt die praktische Regel: Legen Sie Ihre eigenen Einstellungen in einer Datei ab, die in der Sortierreihenfolge zuletzt kommt, beispielsweise /etc/default/grub.d/99-local.cfg. Bearbeiten Sie stattdessen nicht /etc/default/grub. Dann kann keine vom Image ausgelieferte Datei nach Ihrer Datei eingelesen werden.

Warum GRUB_FORCE_PARTUUID die Menüauswahl irrelevant macht

grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/
grep -n GRUB_FORCE_PARTUUID /etc/grub.d/10_linux
sudo grep -n 'root=PARTUUID' /boot/grub/grub.cfg

GRUB_FORCE_PARTUUID weist den Generator an, das Root-Dateisystem anhand der Partitions-UUID zu finden. Der Wert wird direkt als root=PARTUUID=... in die Kernel-Befehlszeile geschrieben. Beim Booten wird dadurch nicht nach einer Dateisystem-UUID gesucht. Der Image-Anbieter setzt diese Variable, weil ein einziges Disk-Image dadurch zuverlässig auf Hardware bootet, auf der es nicht erstellt wurde. Der zweite grep-Befehl zeigt Ihnen den Code, der die Variable in /etc/grub.d/10_linux verarbeitet. Dieses Script liegt auf Ihrer eigenen Festplatte. Es ist maßgeblich dafür, wie sich Ihr Image verhält.

Entscheidend ist die Folge davon: Auf diesem Pfad schreibt der Generator einen direkten Boot-Eintrag statt einer vollständigen Liste der installierten Kernel. Zählen Sie, wie viele Einträge tatsächlich vorhanden sind.

sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg
sudo grep -nE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg

Wenn die Anzahl 1 ist, gibt es keinen zweiten Eintrag zur Auswahl. GRUB_DEFAULT=1 verweist dann auf einen Eintrag, der nicht existiert. GRUB kann ihn nicht auflösen und bootet deshalb den ersten Eintrag. Das ist der neue Kernel, den Sie eigentlich vermeiden wollten. grub-set-default hilft ebenfalls nicht, weil nicht der Standardwert das Problem ist. Das Menü, aus dem Sie auswählen möchten, wurde nie erzeugt.

Um wieder ein vollständiges Menü zu erhalten, verschieben Sie die Datei des Anbieters vorübergehend und prüfen Sie das Ergebnis, bevor Sie die Änderung übernehmen. grub-mkconfig schreibt ohne -o in die Standardausgabe und ändert nichts auf der Festplatte.

sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '
sudo mkdir -p /root/grub-backup
sudo mv /etc/default/grub.d/<the file your grep named> /root/grub-backup/
sudo grub-mkconfig 2>/dev/null | grep -cE '^\s*(menuentry|submenu) '

Wenn die Anzahl von 1 auf mehrere Einträge steigt, erscheinen die Einträge, sobald die Erzwingung entfernt wurde. Bis dahin wurde noch nichts geschrieben. Legen Sie die Datei zurück, wenn die zweite Zählung nicht richtig aussieht. Die erzwungene PARTUUID wird vom Image Ihres Providers verwendet, um das Root-Dateisystem zu finden. Wenn Sie sie entfernen, wechselt der Rechner stattdessen zum Suchpfad. Erstellen Sie einen Snapshot, bevor Sie update-grub tatsächlich ausführen.

Wenn Sie nur einen fehlerhaften Kernel überstehen möchten, beenden Sie den Vorgang hier und verwenden Sie die weiter unten beschriebenen sichereren Optionen. Das Boot-Menü auf einem Remote-Server neu zu erstellen, um einem einzelnen Upgrade zu entgehen, ist ein größeres Risiko, als das Problem rechtfertigt.

Warum Eintragsnummern die falsche Wahl zum Fixieren sind

GRUB_DEFAULT akzeptiert eine Nummer, einen Titel oder einen Bezeichner. Nummern zählen Einträge der obersten Ebene ab 0. Ein verschachtelter Eintrag verwendet > als Trennzeichen. GRUB_DEFAULT="1>2" bezeichnet also den Eintrag am Index 2 im Untermenü am Index 1.

Indizes ändern sich. 10_linux listet Kernel in absteigender Reihenfolge auf. Wenn Sie einen Kernel installieren, wird jeder ältere Eintrag um eine Position nach unten verschoben. Wenn Sie einen Kernel entfernen, rücken die Einträge nach oben. Ihr sorgfältig gewähltes 1>2 wird danach weiterhin aufgelöst. Es bezeichnet nun jedoch einen anderen Kernel. Es tritt kein Fehler auf und es wird keine Warnung ausgegeben. Sie bemerken das Problem erst nach einem Reboot.

Bezeichner ändern sich nicht, weil jeder die Kernelversion enthält. Lesen Sie Ihre Bezeichner aus:

sudo awk -F"'" '/menuentry_id_option/ {print $2, "==>", $4}' /boot/grub/grub.cfg

Ignorieren Sie die ersten Zeilen der Ausgabe. Sie enthalten die Variable, die im Header definiert wird. Danach steht auf der linken Seite der Titel, den der Benutzer sieht, und auf der rechten Seite der Bezeichner, den Sie an die Tools übergeben. Bei einem Eintrag in einem Untermenü verbinden Sie den Bezeichner des Untermenüs und den Bezeichner des Eintrags mit >, und zwar in dieser Reihenfolge, genau wie bei der numerischen Form.

Einmalig den vorherigen Kernel mit grub-reboot starten

Eine einmalige Auswahl ist auf einem Remote-Server die richtige Vorgehensweise, weil sie sich selbst zurücksetzt. grub-reboot schreibt next_entry in /boot/grub/grubenv. GRUB liest diese Variable, löscht sie und speichert den gelöschten Wert, bevor es etwas startet. Ein Kernel, bei dem ein Panic auftritt, wird daher beim nächsten Start nicht erneut verwendet. Sie haben einen Versuch. Danach verwendet das System selbstständig wieder den normalen Standard.

Prüfen Sie zuerst, ob Ihre generierte Konfiguration diese Variable überhaupt liest:

sudo grep -n -B2 -A5 'next_entry' /boot/grub/grub.cfg

Sie benötigen eine Zeile mit load_env und einen Block, der default aus next_entry setzt. Gibt grep nichts aus, liest Ihr Image grubenv beim Start nicht. grub-reboot wird dann zwar in der Shell akzeptiert, aber vom Bootloader ignoriert. Das ist derselbe erzwungene direkte Bootpfad aus dem vorherigen Abschnitt, der an einer zweiten Stelle auftritt.

sudo grub-reboot '<the identifier you copied>'
sudo grub-editenv list

grub-editenv list sollte nun eine Zeile mit next_entry= ausgeben, die exakt den von Ihnen übergebenen Wert enthält. Öffnen Sie die Konsole Ihres Providers in einem Browser-Tab. Starten Sie das System anschließend neu und prüfen Sie das Ergebnis.

sudo reboot

uname -r

Wenn uname -r die ältere Version meldet, war die Auswahl erfolgreich. Wird die neue Version gemeldet, konnte entweder die Kennung nicht aufgelöst werden oder grubenv wird nicht gelesen. Das System ist in beiden Fällen gestartet. Genau deshalb wird die einmalige Auswahl verwendet.

Mit GRUB_DEFAULT=saved eine dauerhafte Auswahl treffen

GRUB_DEFAULT=saved bezieht den Standardwert aus saved_entry in grubenv. Diesen Wert setzen Sie mit grub-set-default. Die Einstellung bleibt bei Kernelinstallationen erhalten, weil update-grub grub.cfg neu schreibt und grubenv nicht verändert.

echo 'GRUB_DEFAULT=saved' | sudo tee /etc/default/grub.d/99-local.cfg
sudo update-grub
sudo grub-set-default '<the identifier you copied>'
sudo grub-editenv list
sudo grep -n 'set default' /boot/grub/grub.cfg

Der letzte Befehl muss set default="${saved_entry}" ausgeben. Gibt er set default="0" aus, hat eine nach Ihrer Datei geladene Konfiguration GRUB_DEFAULT wieder auf einen Literalwert gesetzt. Führen Sie daher /etc/default/grub.d/ erneut auf und prüfen Sie, dass 99-local.cfg tatsächlich an letzter Stelle sortiert wird.

GRUB_SAVEDEFAULT=true ist eine andere Einstellung und wird leicht mit dieser verwechselt. Sie speichert den gerade gestarteten Eintrag als neuen Standardwert. Dadurch folgt der Standardwert dem letzten erfolgreichen Boot. Auf einem Server kann ein unbeaufsichtigter Reboot die festgelegte Auswahl daher unbemerkt ändern. Lassen Sie diese Einstellung deaktiviert, sofern Sie genau dieses Verhalten nicht wünschen.

Eine Auswahl anhand eines Identifiers kann dennoch auf eine Weise fehlschlagen. Wenn Sie den darin genannten Kernel entfernen, lässt sich der Identifier nicht mehr auflösen. Dadurch wird wieder der erste Eintrag verwendet. Halten Sie daher auch das Paket zurück oder schließen Sie diesen Kernel von autoremove aus.

Das Menü in der Provider-Konsole anzeigen

Für eine interaktive Auswahl muss das Menü auf dem Bildschirm angezeigt werden. Bei Cloud-Images wird es ausgeblendet. Fügen Sie diese Einstellungen in die Datei ein, die zuletzt verarbeitet wird, und führen Sie anschließend sudo update-grub aus.

GRUB_TIMEOUT=10
GRUB_TIMEOUT_STYLE=menu
GRUB_RECORDFAIL_TIMEOUT=10

GRUB_TIMEOUT_STYLE=hidden zusammen mit GRUB_TIMEOUT=0 zeigt überhaupt nichts an. Wer die Konsole beobachtet, sieht daher sofort Kernelmeldungen und schließt daraus, dass der Bootloader übersprungen wurde. GRUB_RECORDFAIL_TIMEOUT ist das separate Timeout für einen Bootvorgang, der nicht abgeschlossen wurde. Auch diesen Wert setzen Cloud-Images auf 0. Deshalb hält ein Server, dessen Bootvorgang gerade fehlgeschlagen ist, ebenfalls nicht an und wartet auf Ihre Eingabe.

Wenn Ihr Provider statt einer grafischen Konsole eine serielle Konsole bereitstellt und Sie weiterhin nichts sehen, schreibt GRUB auf ein Terminal, das für Sie nicht sichtbar ist. Fügen Sie beide Zeilen gemeinsam ein. Die erste wählt die Ausgaben aus, die zweite konfiguriert den Port:

GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1"

Ab jetzt werden bei jedem Bootvorgang zehn Sekunden hinzugefügt. Setzen Sie das Timeout wieder auf 0, sobald Sie fertig sind.

Sicherere Optionen als das Bearbeiten des Bootloaders

Die Eingabe für den Bootloader auf einem Rechner zu ändern, den Sie ausschließlich über SSH erreichen, ist die riskanteste Option auf dieser Seite. Es gibt einfachere Lösungen, die in der Regel das eigentliche Problem beheben.

Kernel-Pakete zurückhalten. Wenn das Ziel lautet: „Installieren Sie mir keinen neueren Kernel“, teilen Sie das dem Paketmanager mit und nicht dem Bootloader.

apt list --installed 2>/dev/null | grep -E '^linux-(image|headers|generic|virtual|kvm|aws|azure|gcp|oracle)'
sudo apt-mark hold linux-image-virtual linux-headers-virtual
apt-mark showhold

Verwenden Sie die Namen, die der erste Befehl ausgegeben hat, da Cloud-Images häufig die Variante virtual oder kvm statt generic installieren. Wenn der neuere Kernel im Zusammenhang mit einer Image-Aktualisierung aufgetaucht ist und Sie vermuten, dass sich das Release unter Ihrer Installation geändert hat, trifft das nicht zu: Ein Point-Release enthält die Updates, die bereits in neue Installationsmedien übernommen wurden. Ein bereits gepatchter Server erhält dadurch nichts, was ihm nicht schon Wochen zuvor angeboten wurde. Ein zurückgehaltenes Paket wird von apt upgrade übersprungen. Der Befehl weist mit The following packages have been kept back: darauf hin. Auch unattended upgrades unter Ubuntu überspringen es. Die Kosten sind real: Ein zurückgehaltener Kernel erhält keine Sicherheitsupdates mehr. Betrachten Sie dies daher als Pause mit einem festgelegten Enddatum und geben Sie das Paket mit sudo apt-mark unhold wieder frei. Wenn Sie Kernel-Aktualisierungen vermeiden, weil Reboots Ausfallzeit verursachen, und nicht weil ein bestimmter Kernel fehlerhaft ist, ist Live-Kernel-Patching auf einem VPS die passende Lösung.

Erstellen Sie vor dem Upgrade einen Snapshot. Ein Snapshot lässt sich innerhalb weniger Minuten wiederherstellen, ohne Eingaben an der Konsole und ohne das Risiko einer unvollständig angewendeten Bootloader-Änderung. Erstellen Sie den Snapshot, führen Sie das Upgrade durch, starten Sie neu und prüfen Sie das Ergebnis. Wenn der neue Kernel Probleme verursacht, führen Sie ein Rollback durch. Der Bootpfad entspricht dann genau dem vorherigen Zustand.

Verwenden Sie für einen bereits ausgefallenen Server die Konsole oder ein Rescue-Image. Sobald der Server nicht mehr bootet, beheben Sie das Problem nicht in der Bootloader-Konfiguration. Dieser Wiederherstellungspfad ist ein eigenes Verfahren: Was Sie tun sollten, wenn ein VPS nach einer Kernel-Aktualisierung nicht mehr bootet.

Was fehlschlägt und welche Meldung Sie sehen

Ihre Änderung an /boot/grub/grub.cfg ist verschwunden. Ein Kernel-Paket wurde installiert oder entfernt, sein Maintainer-Skript wurde mit update-grub ausgeführt, und die Datei wurde aus den Eingabedateien neu erzeugt. Der Header # DO NOT EDIT THIS FILE nennt die beiden Eingabeorte. Bearbeiten Sie diese.

grub-editenv: error: environment block too small. /boot/grub/grubenv fehlt oder ist abgeschnitten. Erstellen Sie die Datei mit sudo grub-editenv /boot/grub/grubenv create neu, setzen Sie anschließend Ihren Wert erneut und prüfen Sie ihn mit sudo grub-editenv list.

Ein angehefteter Kernel führt zu einem Kernel-Panic mit VFS: Unable to mount root fs on unknown-block(0,0). Der angeheftete Eintrag verweist auf einen Kernel oder eine initrd, die nicht mehr auf der Festplatte vorhanden ist. Ursache ist meist, dass das Paket entfernt wurde, während die Kennung in grubenv erhalten blieb. Starten Sie zur Wiederherstellung über die Konsole einen funktionierenden Eintrag und löschen Sie anschließend den veralteten Wert.

uname -r bleibt nach einem Reboot unverändert, obwohl Sie eine Änderung erwartet haben. Prüfen Sie drei Dinge in dieser Reihenfolge: Zeigt grub-editenv list weiterhin Ihren Wert an oder wurde er bereits verarbeitet? Erscheint die gesetzte Kennung in der aktuellen grub.cfg? Enthält grub.cfg eine set default-Zeile, die die gesetzte Variable liest? Eine dieser drei Ursachen erklärt das Verhalten in jedem Fall.

Das Menü wurde nach einem Absturz automatisch angezeigt. GRUB protokolliert einen fehlgeschlagenen Boot in grubenv als recordfail=1. Dadurch wird das Menü beim folgenden Boot erzwungen, damit ein Benutzer eingreifen kann. Löschen Sie den Wert mit sudo grub-editenv /boot/grub/grubenv unset recordfail, sobald das System wieder fehlerfrei läuft.

Der eine Satz, den Sie behalten sollten: Die Datei, die Sie bearbeiten, ist nicht die Datei, die GRUB liest. Bei einem Cloud-Image liegt genau in diesem Unterschied die Ursache für die Verwirrung. Lesen Sie zuerst die generierte Konfiguration. Jede Entscheidung auf dieser Seite ergibt sich daraus, was tatsächlich darin steht.

FAQ

Warum ändert GRUB_DEFAULT=1 nicht, mit welchem Kernel meine VPS startet?

Bei einem Ubuntu-Cloud-Image enthält der generierte /boot/grub/grub.cfg häufig nur einen einzigen Booteintrag. Der Index 1 verweist dann auf keinen Eintrag, und GRUB verwendet den ersten Eintrag. Prüfen Sie das mit sudo grep -cE '^\s*(menuentry|submenu) ' /boot/grub/grub.cfg. Eine Anzahl von 1 ist die Antwort. Ursache ist GRUB_FORCE_PARTUUID. Der Image-Anbieter setzt diese Einstellung in einer Datei unter /etc/default/grub.d/. Dadurch verwendet der Generator einen direkten Bootpfad, statt eine vollständige Liste der installierten Kernel zu erstellen. Ermitteln Sie die Datei mit grep -rn GRUB_FORCE_PARTUUID /etc/default/grub /etc/default/grub.d/.

Wie starte ich den vorherigen Kernel genau einmal?

Führen Sie sudo grub-reboot '<identifier>' mit einem Bezeichner aus, den Sie aus Ihrem eigenen grub.cfg kopiert haben. Starten Sie anschließend neu, während die Provider-Konsole bereits geöffnet ist. GRUB löscht next_entry vor dem Booten. Die Auswahl gilt daher genau für einen Versuch, und ein Kernel, der einen Panic auslöst, wird nicht erneut verwendet. Prüfen Sie mit sudo grub-editenv list, ob der Wert übernommen wurde. Führen Sie zuvor sudo grep -n next_entry /boot/grub/grub.cfg aus. Ein Image, dessen Konfiguration grubenv nie lädt, ignoriert den Befehl ohne Fehlermeldung.

Sollte ich nach der Eintragsnummer oder nach dem Bezeichner auswählen?

Nach dem Bezeichner. Eintragsnummern sind Positionen in einer Liste, die 10_linux bei jedem Aufbau mit dem neuesten Eintrag zuerst neu erstellt. Durch die Installation oder Entfernung eines beliebigen Kernels ändern sich diese Nummern. Ein veralteter 1>2 kann weiterhin einen vorhandenen, aber falschen Eintrag auswählen, ohne eine Warnung auszugeben. Bezeichner enthalten die Kernelversion. Sie verweisen daher entweder auf den gewünschten Kernel oder lassen sich nicht auflösen. Listen Sie die Bezeichner mit sudo grep -n menuentry_id_option /boot/grub/grub.cfg auf und kopieren Sie die Zeichenfolge in Anführungszeichen, die auf jede Eintragszeile folgt.

Ist es sicherer, das Kernelpaket zurückzuhalten, als den Bootloader zu ändern?

Für das übliche Ziel: ja. sudo apt-mark hold linux-image-virtual linux-headers-virtual verhindert, dass überhaupt ein neuerer Kernel installiert wird. Dadurch ändert sich der Bootpfad nicht, und eine möglicherweise nicht verfügbare Konsole kann keine Fehlkonfiguration verursachen. Prüfen Sie zunächst mit apt list --installed die auf Ihrem eigenen System installierten Variantenbezeichnungen. Verifizieren Sie die Zurückhaltung mit apt-mark showhold. Der Nachteil ist, dass ein zurückgehaltenes Kernelpaket keine Sicherheitskorrekturen erhält. Legen Sie daher fest, wann Sie sudo apt-mark unhold ausführen, bevor Sie das Paket zurückhalten.