Boot-Probleme bei NVMe-only-Setups: UEFI, initramfs und fstab prüfen

Boot-Probleme bei NVMe-only-Setups treten in produktiven Umgebungen oft nach Kernel-Updates, Storage-Änderungen oder Firmware-Updates auf. Dieses Runbook ist für Administratoren, System Engineers und Operatoren gedacht und beschreibt eine geprüfte Prüfreihenfolge: Sichtbarkeit der NVMe-Hardware, UEFI/ESP, Bootloader und Kernel-Cmdline, initramfs-Inhalt und /etc/fstab. Jede Maßnahme enthält die jeweils relevanten Risiken, praktische Kommandos und eine Rückfallstrategie.

Warum systematisch vorgehen? Das Zusammenspiel der Bootkette

Die Bootkette ist kein einzelnes Artefakt, sondern mehrere Schichten, die zusammenarbeiten: Die Firmware (UEFI) liest die EFI-Systempartition (ESP) und startet einen EFI-Loader; der Bootloader (z. B. GRUB2 oder systemd-boot) lädt Kernel und initramfs und übergibt die Kernel-Cmdline; das initramfs (ein temporäres Root-Dateisystem) initialisiert Treiber und Werkzeuge (NVMe-Treiber, LVM, mdadm, cryptsetup) und mountet das Root-Dateisystem; erst danach übernimmt /etc/fstab die weiteren Mounts. Fehler in einer Schicht sehen oft wie Hardwarefehler aus — deshalb ist die Prüfreihenfolge wichtig.

Symptome klassifizieren und Folgen abwägen

Bevor Sie Änderungen vornehmen, ordnen Sie das Symptom ein. Das spart Zeit und verhindert falsche Eingriffe:

• Firmware/UEFI meldet „No bootable device“: Fokus auf ESP, NVRAM-Einträge und Partitionstypen.
• Bootloader startet Kernel, anschließend Drop in initramfs-Shell: Fokus auf Kernel-Cmdline und initramfs-Inhalt.
• Root gemountet, später systemd-Emergency-Mode: /etc/fstab, fehlende Mounts oder Timeouts sind wahrscheinlich.

Vor dem Eingriff: Sicherheitsmaßnahmen

Risiken minimieren, Ausfallzeit begrenzen:

• Remote-Konsole (IPMI/iDRAC/iLO/VM-Konsole) bereitstellen, damit Sie Bootmeldungen sehen und steuern können.
• Ältere Kernel-Einträge behalten; löschen Sie nichts, was Sie nicht reproduzierbar sichern können.
• ESP- und initramfs-Kopie anlegen, bevor Sie schreiben.
• Sperren Sie kritische Änderungen hinter Wartungsfenstern und dokumentieren Sie Schritte.

Prüfschritt 1: NVMe-Hardware und Kernel-Sichtbarkeit

Ziel: Prüfen, ob das System und der Kernel die NVMe-Geräte sehen. Fehlen /dev/nvme*-Geräte, hilft kein Bootloader-Repair.

# Geräte und Partitionen anzeigen
lsblk -e7 -o NAME,TYPE,SIZE,MODEL,SERIAL,FSTYPE,UUID,MOUNTPOINTS

# Dateisystem-UUIDs
blkid

# Kernel-Meldungen nach NVMe/PCIe-Fehlern durchsuchen
dmesg | grep -iE 'nvme|pcie|iommu|timeout|reset' | tail -n 200

Deutung: Wenn lsblk keine NVMe-Geräte anzeigt, prüfen Sie BIOS/UEFI-Einstellungen (PCIe-Mode, ACS/ASPM, Hotplug), Firmware-Updates des Mainboards/NVMe-Controllers oder physische Verbindungen (Backplane). Manchmal fehlt im Rescue-Kernel der passende NVMe-Treiber.

Prüfschritt 2: UEFI, ESP und NVRAM-Einträge

Die ESP (EFI-Systempartition) muss eine gültige Partition mit Typ EF00 (GPT) und eine FAT32-Formatierung haben. Ist die ESP beschädigt oder enthält falsche Pfade, findet UEFI keinen Loader.

# ESP mounten und Inhalt prüfen
mkdir -p /mnt/esp
mount -t vfat /dev/nvme0n1p1 /mnt/esp
ls -la /mnt/esp

# NVRAM-Einträge anzeigen (Rescue muss im UEFI-Modus gebootet sein)
efibootmgr -v

Stolperfallen:

• Beim Klonen einer NVMe kann sich die Partitionstabelle ändern; NVRAM-Einträge zeigen dann auf nicht vorhandene PARTUUIDs.
• Secure Boot kann unsignierte Loader blockieren; prüfen Sie Signatur- und MOK-Status.
• Ein volles NVRAM verhindert neue Boot-Einträge; alte, ungültige Einträge können Prioritäten verzerren.

Prüfschritt 3: Bootloader, Kernel-Cmdline und root=

Die Kernel-Cmdline legt fest, welches Gerät als Root dient. Bei falsch gesetztem root= landet das System sofort in der initramfs-Shell. Prüfen Sie die Konfiguration des Bootloaders, nicht nur das aktuell laufende Kernel-Argument.

# Aktuelle Kernel-Cmdline prüfen
cat /proc/cmdline

# GRUB-Konfiguration im gemounteten System untersuchen
grep -R "linux .*root=" -n /mnt/sysroot/boot/grub*/grub.cfg | head -n 50

# systemd-boot Einträge lesen
find /mnt/esp/loader -maxdepth 2 -type f -name "*.conf" -exec sed -n '1,120p' {} ;

Praxis-Tipp: Verwenden Sie UUID= oder PARTUUID= im root=; /dev/nvme0n1p2 kann sich bei Hardwareänderungen verschieben. PARTUUID bezieht sich auf die Partitionstabelleeinträge und bleibt stabiler bei Repartitionierung.

Prüfschritt 4: initramfs – Inhalt prüfen, regenerieren und Fehlerquellen

Das initramfs ist ein temporäres Root, das die nötigen Treiber und Werkzeuge enthält, um das Root-Laufwerk vorzubereiten. Es gibt zwei verbreitete Tools zur Erzeugung von initramfs: update-initramfs (Debian/Ubuntu) und dracut (RHEL/Alma/Rocky). Fehlt etwa der NVMe-Treiber oder cryptsetup, kann das System nicht entsperren oder mounten.

# Beispiel: initramfs-Inhalt prüfen (Debian/Ubuntu)
lsinitramfs /mnt/sysroot/boot/initrd.img-$(ls /mnt/sysroot/lib/modules | sort -V | tail -n 1) | grep -iE 'nvme|lvm|crypt|mdadm|ext4|xfs|btrfs'

# Beispiel: initramfs-Inhalt prüfen (RHEL/Rocky/Alma)
lsinitrd /mnt/sysroot/boot/initramfs-*.img | grep -iE 'nvme|lvm|crypt|mdraid|ext4|xfs|btrfs'

Regenerieren Sie initramfs aus dem chroot des Zielsystems und sichern Sie immer die alte Datei:

# In chroot (Debian/Ubuntu)
cp -a /boot/initrd.img-$(uname -r) /boot/initrd.img-$(uname -r).bak.$(date +%F)
update-initramfs -u -k all

# In chroot (RHEL/Rocky/Alma)
KVER=$(ls /lib/modules | sort -V | tail -n 1)
cp -a /boot/initramfs-${KVER}.img /boot/initramfs-${KVER}.img.bak.$(date +%F)
dracut -f /boot/initramfs-${KVER}.img ${KVER}

Häufige Fehlerursachen beim Regenerieren:

• /etc/crypttab fehlt oder ist falsch: cryptsetup-Parameter werden nicht in das initramfs aufgenommen.
• LVM-PVG-Filters in /etc/lvm/lvm.conf verhindern das Erkennen von Volume-Groups.
• Dracut-Module wurden durch custom dracut.conf ausgeschaltet; prüfen Sie /etc/dracut.conf.d.

Prüfschritt 5: Sauber chrooten und Abhängigkeiten aktivieren

Arbeiten Sie nach Möglichkeit im chroot des Zielsystems. Das verhindert, dass Systempfade der Rescue-Umgebung die Reparatur verfälschen. Binden Sie /dev, /proc, /sys und /run.

mount /dev/nvme0n1p2 /mnt/sysroot
mount -t vfat /dev/nvme0n1p1 /mnt/sysroot/boot/efi
mount --bind /dev  /mnt/sysroot/dev
mount --bind /proc /mnt/sysroot/proc
mount --bind /sys  /mnt/sysroot/sys
mount --bind /run  /mnt/sysroot/run
chroot /mnt/sysroot /bin/bash

Wenn LUKS/LVM/RAID verwendet wird, öffnen/aktivieren Sie diese vorher:

# LUKS öffnen
cryptsetup luksOpen /dev/nvme0n1p3 cryptroot

# LVM aktivieren
pvscan
vgscan
vgchange -ay

# mdadm-RAIDs zusammenbauen
mdadm --assemble --scan

/etc/fstab prüfen: Stabilität statt fragiler Gerätedateien

/etc/fstab steuert persistente Mounts. Fehlerhafte oder blockierende Einträge sind eine häufige Ursache für spätere Boots in den Emergency-Mode, auch wenn Root korrekt gemountet wurde.

# fstab und Geräteliste prüfen
cat /etc/fstab
lsblk -f
blkid

Empfehlungen:

• Nutzen Sie UUID= oder PARTUUID= anstelle von /dev/nvme0n1pX, weil /dev-Gerätenamen sich bei Enumerationsänderungen verschieben können.
• Für nicht-kritische Mounts temporär nofail setzen, damit Boot nicht bei jedem fehlgeschlagenen Mount stoppt.
• Für Netzwerk-Mounts oder Volumes mit Spindown-Risiko x-systemd.automount verwenden.
• Resume- und Swap-Einträge prüfen: falsche Resume-Devices führen zu langen Timeouts.

# Beispiel fstab-Eintrag mit UUID und nofail
UUID=1111-2222  /data   ext4  defaults,nofail,x-systemd.device-timeout=10  0 2

Timing- und Initialisierungsprobleme

Einige NVMe-Controller oder Backplanes benötigen länger zum Initialisieren. Das initramfs versucht standardmäßig eine bestimmte Zeit, Geräte zu finden. Bei langsamer Initialisierung können Sie temporär rootdelay=30 oder spezifische Retry-Parameter setzen, bis Firmware-/BIOS-Lösungen implementiert sind. Dauerhafte Maßnahmen sind Firmware-Updates, BIOS-Settings (z. B. Fast Boot deaktivieren) oder physische Änderungen an der Hardware.

Spezialfälle: Secure Boot, signierte Kernel/Loader und MOK

Secure Boot überprüft Signaturen von EFI-Loaders und Kernen. Wenn Sie eigene Kernel oder unsignierte Loader nutzen, schlägt der Boot fehl, ohne dass das System in die initramfs-Shell springt. Prüfen Sie:

• Ob der Loader in der ESP signiert ist.
• Ob der Kernel eine gültige Signatur hat (bei Verwendung von Shim/MOK).
• Ob MOK (Machine Owner Key) gebootet und akzeptiert wurde.

Bei Bedarf können Sie Secure Boot temporär deaktivieren, um eine Reparatur durchzuführen — beachten Sie Sicherheitsrichtlinien und protokollieren Sie die Maßnahme.

Bootloader-Reparatur: GRUB vs. systemd-boot

Je nach Bootloader ist die Reparatur unterschiedlich. Beispiele:

# GRUB UEFI neu installieren (im chroot, ESP gemountet)
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
update-grub

# systemd-boot installieren
bootctl --path=/boot/efi install

Wichtig: Dokumentieren Sie efibootmgr -v vor Änderungen und legen Sie Backups der ESP an. Ein falscher grub-install kann NVRAM-Einträge überschreiben.

Docker-Hosts: Warum NVMe-Bootprobleme besonders kritisch sind

Container-Hosts sind oft minimal gehalten und laufen mit vielen statischen Volumes. Bootausfälle betreffen nicht nur einzelne Dienste, sondern Container-Orchestrierung, Volume-Verfügbarkeit und Logging. Zusätzliche Aspekte:

• Docker (oder containerd) benutzt das Host-Root-Filesystem für container-storage (z. B. /var/lib/docker). Probleme beim Root-Mount führen zu readonly- oder fehlenden Volumes.
• Overlay2 und device-mapper sind anfällig bei inkonsistenten Dateisystemzuständen; ein beschädigtes initramfs, das Root verspätet mountet, kann Container-Engpässe beim Start verursachen.
• Bei Clustered Setups synchronisieren Orchestratoren Status und sollten über Health-Checks verfügen, um Failover auszulösen.

Praktische Prüfungen auf einem Docker-Host (nach erfolgreichem Chroot):

# Docker-Status prüfen
systemctl status docker
docker info | sed -n '1,120p'

# Storage-Pfade überprüfen
ls -la /var/lib/docker
df -h /var/lib/docker

Best Practices vor Kernel-/Boot-Änderungen:

• Sichern Sie Container-Volumes (Snapshots, rsync, Registry-Push für Images).
• Testen Sie Bootänderungen zuerst auf einem Replikat oder Canaries.
• Behandeln Sie Boot-Artefakte wie Konfigurationsobjekte: Versionieren, Review und Change-Record.

Wiederherstellungs- und Rückfallstrategie

Wenn die Ursache unklar bleibt, handeln Sie minimal und reversibel:

1. Versuchen Sie, mit einem älteren Kernel zu booten, statt neu zu bauen.
2. Setzen Sie kritische fstab-Einträge auf nofail, anstatt sie zu löschen.
3. Sichern Sie ESP und initramfs, exportieren Sie efibootmgr-Ausgabe.
4. Arbeiten Sie schrittweise: Erst Sichtbarkeit der NVMe, dann Bootloader/Kmdline, danach initramfs und fstab.
5. In Notfällen: Replikat aus Backup/Imaging bereitstellen und Migration der IP/Services planen.

Praxis-Checkliste (Kurzreferenz)

1. Symptomklasse bestimmen: UEFI / initramfs / fstab.
2. NVMe sichtbar? (lsblk, dmesg)
3. Chroot vorbereiten und LUKS/LVM/RAID aktivieren.
4. ESP mounten, efibootmgr -v sichern.
5. Kernel-Cmdline prüfen: root=UUID/PARTUUID.
6. Initramfs-Inhalt prüfen und aus chroot regenerieren (Backup).
7. /etc/fstab vs. blkid abgleichen, nofail verwenden.
8. Bootloader neu installieren wenn nötig (grub-install / bootctl).
9. Testboot, Logging prüfen, Postmortem und Change-Record schreiben.

Fazit

Bei Boot-Problemen bei NVMe-only-Setups ist die erfolgreiche Diagnose eine Kombination aus methodischem Vorgehen, Kenntnis der Bootkette und konservativem Handeln. NVMe ist selten der alleinige Schuldige; meistens spielen UEFI/NVRAM, Kernel-Cmdline, fehlende initramfs-Module oder fehlerhafte fstab-Einträge zusammen. Arbeiten Sie chroot-basiert, sichern Sie Boot-Artefakte, regenerieren Sie initramfs mit Bedacht und planen Sie Rückfallmaßnahmen. Für Docker-Hosts gelten zusätzlich strenge Anforderungen an Volumes und Orchestrator-Resilienz — testen Sie Änderungen zuerst auf Replikaten oder Canary-Hosts.

Mit der hier beschriebenen Prüfreihenfolge und den konkreten Kommandos reduzieren Sie Ausfallzeiten und vermeiden unnötige Neuinstallationen. Dokumentation und Change-Control sind dabei ebenso wichtig wie die technische Reparatur.

Boot-Probleme bei NVMe-only-Setups: Betrieb, Monitoring und Automatisierung

Neben der klassischen Reparatur ist es entscheidend, den Betrieb so zu gestalten, dass Boot‑Fehler früh erkannt, reproduzierbar getestet und sicher zurückgerollt werden können. Drei Bereiche zahlen sich praktisch immer aus: Artefakt‑Backup (ESP, NVRAM, GPT), beobachtbare Boot‑Telemetry und automatisierte Validierung in der CI/CD‑Pipeline.

Artefakt‑Backup und Metadaten sichern

Sichern Sie vor Änderungen immer die EFI‑Partition, die NVRAM‑Einträge und die GPT‑Tabelle. Diese Metadaten sind oft der schnellste Weg, um einen funktionierenden Zustand wiederherzustellen.

# GPT-Backup
sgdisk --backup=gpt-backup-$(date +%F).bin /dev/nvme0n1

# NVRAM/efibootmgr sichern
efibootmgr -v > /root/efibootmgr-$(date +%F).txt

# ESP snapshot
mount /dev/nvme0n1p1 /mnt/esp
tar -c -C /mnt/esp . | gzip -c > /root/esp-backup-$(date +%F).tar.gz

Beobachtbarkeit: Early‑Logging und Remote‑Zugriff

• Aktivieren Sie eine serielle Konsole oder Netconsole für frühe Kernel‑Meldungen. So sehen Sie, ob NVMe‑Controller initialisiert werden.
• Konfigurieren Sie systemd‑journal persistent, damit Logs über Boots hinweg erhalten bleiben.
• Für verschlüsselte Root‑Volumes planen Sie einen Remote‑Unlock‑Weg (z. B. SSH‑Dropbear im initramfs oder zentraler Key‑Escrow) und regeln Zugriff und Auditierung strikt.

CI/CD und Canary‑Strategie für Kernel/initramfs

Bauen Sie initramfs und Bootloader‑Artefakte reproduzierbar in Ihrer Pipeline und prüfen Sie automatisiert, ob notwendige Module (nvme, nvme_core, lvm, dm‑crypt etc.) enthalten sind. Verteilen Sie Kernel‑ und Firmware‑Updates zunächst an Canary‑Hosts mit Monitoring von Boot‑Zeit, dmesg‑Fehlern und Container‑Health (bei Docker‑Hosts).

Sonderelement: LUKS‑Header und Schlüsselmanagement

# LUKS-Header sichern
cryptsetup luksHeaderBackup /dev/nvme0n1p3 --header-backup-file /root/luks-header-$(date +%F).bin

Ohne Header‑Backup sind LUKS‑Volumes nach unglücklichen Schreiboperationen oft nicht mehr wiederherstellbar. Dokumentieren Sie Prozesse und halten Sie Schlüssel/Backups in einem gesicherten Vault mit Zugriffskontrolle.

Diese operationalen Maßnahmen reduzieren Ausfallrisiken erheblich: Metadaten sichern, frühe Telemetrie aktivieren, reproduzierbare Artefakte bauen und schrittweise ausrollen sind oft wirksamer als ad‑hoc Reparaturen im Notfall.

Für dieses Thema sind auch Uefi Boot und Initramfs Regenerieren wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.