GRUB Bootloader konfigurieren und reparieren: Von der Kernel Zeile bis zur Rescue Shell

1. Die Rolle von GRUB im Boot Prozess

GRUB, ausgeschrieben Grand Unified Bootloader, übernimmt auf einem klassischen BIOS System oder einem UEFI System jeweils den Schritt zwischen Firmware und Kernel. Nach dem Power On Self Test lädt die Firmware entweder den Master Boot Record mit dem GRUB Stage 1 Code oder, im UEFI Fall, direkt die Datei grubx64.efi aus der EFI System Partition, und übergibt die Kontrolle an GRUB.

GRUB lädt dann seine eigene Konfiguration, stellt bei Bedarf ein Menü mit mehreren Kernel Versionen und Boot Optionen dar, und übergibt am Ende die Kontrolle an den ausgewählten Kernel samt initramfs. Auf einem Server ohne physischen Monitor läuft dieser Schritt meist unsichtbar ab, ist aber genauso kritisch: Ein defektes GRUB Setup verhindert jeden Boot, unabhängig davon, wie fehlerfrei Kernel und Root Dateisystem selbst sind.

Wichtig für das Verständnis ist die Trennung zwischen der GRUB Konfigurationsquelle und der tatsächlich beim Boot gelesenen Datei. Administratoren bearbeiten fast nie direkt grub.cfg, sondern die Vorlagen unter /etc/default/grub und /etc/grub.d, aus denen grub2-mkconfig die eigentliche Konfigurationsdatei generiert.

2. /etc/default/grub: Die zentrale Konfigurationsdatei

Die Datei /etc/default/grub enthält Shell Variablen, die von den Skripten in /etc/grub.d ausgewertet werden. Die wichtigsten Variablen sind GRUB_DEFAULT für den Standardeintrag, GRUB_TIMEOUT für die Wartezeit im Menü, GRUB_CMDLINE_LINUX_DEFAULT für Kernel Parameter im Normalbetrieb und GRUB_CMDLINE_LINUX für Parameter, die auch im Recovery Modus gelten sollen.

Auf Produktionsservern ist ein niedriger GRUB_TIMEOUT sinnvoll, weil das Menü ohnehin selten manuell bedient wird, während GRUB_TIMEOUT_STYLE=hidden das Menü nur bei gedrückter Umschalttaste einblendet und den Boot Vorgang optisch aufräumt. GRUB_DISABLE_OS_PROBER=true verhindert, dass GRUB bei jedem Update fremde Betriebssysteme auf anderen Partitionen scannt, was auf reinen Linux Servern nur unnötige Zeit kostet und in seltenen Fällen falsche Einträge erzeugt.

# /etc/default/grub, typische Server Konfiguration
GRUB_DEFAULT=0
GRUB_TIMEOUT=3
GRUB_TIMEOUT_STYLE=menu
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release 2>/dev/null || echo Debian)"
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
GRUB_DISABLE_OS_PROBER=true

3. Kernel Parameter dauerhaft über den Bootloader setzen

Kernel Parameter, die nur für den aktuellen Boot gelten sollen, lassen sich im GRUB Menü direkt mit der Taste e bearbeiten, sind nach einem Neustart aber wieder verschwunden. Für dauerhafte Änderungen, etwa cgroup Parameter für Container Hosts, transparent_hugepage=never für Datenbankserver oder ein bestimmtes IOMMU Setting für PCI Passthrough, gehört die Änderung in GRUB_CMDLINE_LINUX_DEFAULT beziehungsweise GRUB_CMDLINE_LINUX.

Nach jeder Änderung an /etc/default/grub muss die Konfiguration neu generiert werden, bevor sie beim nächsten Boot wirksam wird. Debian und Ubuntu nutzen dafür den Wrapper update-grub, RHEL basierte Systeme das Kommando grub2-mkconfig mit explizitem Zielpfad. Wer den Aufruf vergisst, wundert sich später, warum die neuen Parameter trotz korrekter Datei nicht ankommen.

# Debian/Ubuntu: Konfiguration neu generieren
sudo update-grub

# RHEL/Alma/Rocky, BIOS System
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# RHEL/Alma/Rocky, UEFI System
sudo grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg

# Aktive Kernel Parameter des laufenden Systems prüfen
cat /proc/cmdline

4. Boot Menü anpassen: Reihenfolge, Timeout und versteckte Einträge

Die Reihenfolge der Menüeinträge ergibt sich aus der Verarbeitung der Skripte in /etc/grub.d in numerischer Sortierung. Das Skript 10_linux erzeugt die Einträge für installierte Kernel, wobei standardmäßig der neueste Kernel zuoberst und damit als Vorauswahl erscheint. Über GRUB_DEFAULT=saved in Kombination mit grub-set-default lässt sich stattdessen ein fester Eintrag dauerhaft als Standard festlegen, unabhängig von neu installierten Kernel Versionen.

Für Server ist ein aufgeräumtes Menü wichtiger als optische Extras: GRUB_TIMEOUT_STYLE=countdown zeigt nur einen Countdown ohne vollständiges Menü, GRUB_TERMINAL=console verzichtet auf grafische Elemente und reduziert die Abhängigkeit von einer funktionierenden Framebuffer Konfiguration, was besonders bei seriellen Konsolen und Remote Management über IPMI oder iLO hilfreich ist.

5. Multi Kernel Umgebungen sauber verwalten

Auf Produktionssystemen bleibt der vorherige Kernel nach einem Update meist installiert, damit im Fehlerfall ein Rollback über das Advanced Options Untermenü im GRUB Menü möglich ist. Debian und RHEL basierte Distributionen begrenzen die Anzahl vorgehaltener Kernel Versionen über die Variablen GRUB_DEFAULT in Kombination mit dem jeweiligen Paketmanager, etwa installonly_limit in dnf.conf auf RHEL Systemen.

Wer bewusst einen bestimmten, älteren Kernel als Standard setzen möchte, etwa weil ein neuerer Kernel Treiberprobleme mit einem RAID Controller verursacht, findet den passenden Menüeintrag über grep gegen grub.cfg und setzt ihn dann mit grub-set-default dauerhaft, statt bei jedem Boot manuell im Menü auszuwählen.

# Verfügbare Menüeinträge inklusive Advanced Options auflisten
grep -E "^menuentry|^submenu" /boot/grub2/grub.cfg

# Bestimmten Eintrag als dauerhaften Standard setzen (Index oder Titelstring)
sudo grub2-set-default "Advanced options for AlmaLinux (10.0.99-original.el9.x86_64)"

# Aktuell gespeicherten Standardeintrag prüfen
sudo grub2-editenv list

6. Eigene Menüeinträge über 40_custom

Manuelle Einträge, etwa für ein Rescue Image, ein Memtest oder einen alternativen Kernel Boot mit speziellen Parametern für die Fehlersuche, gehören in /etc/grub.d/40_custom oder eine eigene Datei mit ausführbarem Bit in /etc/grub.d. Direkte Änderungen an grub.cfg werden dagegen bei jedem Lauf von grub2-mkconfig kommentarlos überschrieben und gehen damit verloren.

Ein eigenes Skript in /etc/grub.d sollte mit einer dreistelligen Zahl beginnen, um seine Position in der Menüreihenfolge zu steuern, und muss ausführbar sein, sonst überspringt grub2-mkconfig es stillschweigend. Das ist eine häufige Fehlerquelle, wenn ein neuer Eintrag nach der Bearbeitung nicht im Menü erscheint.

# /etc/grub.d/45_rescue_debug, eigener Eintrag mit zusätzlichem Debug Parameter
cat <<'EOF' | sudo tee /etc/grub.d/45_rescue_debug
#!/bin/sh
exec tail -n +3 $0
menuentry 'Kernel Debug Boot (systemd.log_level=debug)' {
    insmod gzio
    insmod part_gpt
    insmod xfs
    set root='hd0,gpt2'
    linux /vmlinuz root=/dev/mapper/vg-root ro systemd.log_level=debug
    initrd /initramfs.img
}
EOF
sudo chmod +x /etc/grub.d/45_rescue_debug
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

7. Recovery über die GRUB Rescue Shell

Landet der Server statt im Menü in einer Zeile mit dem Prompt grub> oder grub rescue>, konnte GRUB seine Konfiguration oder Module nicht laden, meist weil der Verweis auf die Boot Partition fehlerhaft ist oder core.img beschädigt wurde. In dieser minimalen Shell lässt sich mit ls die verfügbare Partitionsstruktur ansehen und mit set root sowie einem manuellen linux und initrd Aufruf trotzdem ein einmaliger Boot erzwingen.

Dieser manuelle Boot ist nur eine Überbrückung für die aktuelle Sitzung und überlebt keinen Neustart. Er verschafft aber die nötige Zeit, um sich am laufenden System anzumelden und die eigentliche GRUB Installation über grub2-install und grub2-mkconfig dauerhaft zu reparieren, statt bei jedem Boot erneut manuell einzugreifen.

# In der grub rescue Shell: verfügbare Geräte und Partitionen auflisten
grub rescue> ls
(hd0) (hd0,gpt2) (hd0,gpt1)

# Root Partition und Kernel Pfad prüfen und manuell setzen
grub rescue> ls (hd0,gpt2)/boot
grub rescue> set root=(hd0,gpt2)
grub rescue> set prefix=(hd0,gpt2)/boot/grub2
grub rescue> insmod normal
grub rescue> normal

8. grub-install und Chroot Reparatur vom Live System

Reicht die manuelle Rescue Shell nicht aus, etwa weil core.img oder die gesamte EFI System Partition beschädigt ist, führt der zuverlässigste Weg über ein Live System oder ein Rescue Image des Hosting Providers. Dort werden die Root Partition und bei UEFI Systemen zusätzlich die EFI System Partition eingehängt, wichtige virtuelle Dateisysteme gebunden und anschließend per chroot in das eigentliche System gewechselt.

Innerhalb des Chroots verhält sich grub2-install wie auf dem laufenden System selbst und schreibt den Bootcode entweder in den MBR oder erzeugt eine neue grubx64.efi in der EFI System Partition inklusive Boot Eintrag in der NVRAM Firmware Tabelle. Ein abschließender grub2-mkconfig Lauf stellt sicher, dass die Konfiguration wieder zum tatsächlich installierten Kernel passt.

# Vom Live System aus: Root Partition und Systempfade einhängen
sudo mount /dev/mapper/vg-root /mnt
sudo mount /dev/sda1 /mnt/boot/efi
for fs in dev proc sys run; do sudo mount --bind /$fs /mnt/$fs; done
sudo chroot /mnt /bin/bash

# Innerhalb des Chroots: Bootloader neu installieren
grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=almalinux
grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg
exit

9. Best Practices und typische Fallstricke

Vor jeder Änderung an Kernel Parametern oder dem Boot Menü lohnt sich ein Test über die IPMI oder Rescue Konsole des Providers, denn eine falsche Root Angabe oder ein fehlendes Kernel Modul führt auf einem entfernten Server sofort zu einem nicht erreichbaren System ohne physischen Zugriff. Ein Snapshot oder Backup vor größeren GRUB Eingriffen ist auf virtualisierten Servern die günstigste Absicherung.

Secure Boot erschwert manuelle grub-install Aufrufe zusätzlich, weil die erzeugte EFI Binärdatei signiert sein muss, sonst verweigert die Firmware den Start. Auf Systemen mit aktivem Secure Boot sollte grub2-install möglichst über die Distributionspakete shim und grub2-efi erfolgen, statt eine unsignierte Binärdatei manuell zu kopieren.

Nach jedem Kernel Update lohnt sich eine kurze Kontrolle des Menüs mit grep gegen grub.cfg, ob der neue Kernel tatsächlich als Eintrag erscheint und die gewünschten Parameter aus GRUB_CMDLINE_LINUX_DEFAULT übernommen wurden, statt sich blind auf den automatischen Ablauf des Paketmanagers zu verlassen.

10. Zusammenfassung

11. FAQ: GRUB Bootloader