initramfs und dracut: Wie Linux beim Booten das Root Dateisystem findet

1. Warum der Kernel ein initramfs braucht

Der Linux Kernel selbst enthält beim Booten nur eine begrenzte Auswahl fest eingebauter Treiber und kennt das eigentliche Root Dateisystem zunächst überhaupt nicht. Liegt Root auf einem LVM Volume, hinter LUKS Verschlüsselung, auf einem Software RAID oder gar auf einem entfernten iSCSI Target, fehlt dem Kernel ohne Zusatzschritt schlicht das Wissen, wie er dorthin gelangt.

Das initramfs, ein initiales RAM Dateisystem, löst genau dieses Henne Ei Problem: Es ist ein komprimiertes cpio Archiv, das der Bootloader zusammen mit dem Kernel in den Arbeitsspeicher lädt und das alle Kernel Module sowie Userspace Werkzeuge enthält, die nötig sind, um das echte Root Dateisystem zu finden, zu entschlüsseln und einzuhängen, bevor der Kernel per switch_root dorthin wechselt.

Ohne initramfs müsste jeder benötigte Treiber fest in den Kernel einkompiliert sein, was Distributionen zu einem einzigen, riesigen Kernel für alle denkbaren Hardware und Storage Kombinationen zwingen würde. Das initramfs erlaubt stattdessen einen schlanken Standardkernel, der die tatsächlich benötigten Module erst zur Laufzeit aus dem initramfs nachlädt.

2. Aufbau eines initramfs Images

Ein initramfs Image ist im Kern ein gzip oder zstd komprimiertes cpio Archiv mit einem eigenen, minimalen Wurzeldateisystem: einer kleinen Auswahl an Binärdateien wie busybox oder systemd Komponenten, den relevanten Kernel Modulen für Storage und Dateisysteme, sowie Konfigurationsdateien und Skripten, die den eigentlichen Boot Ablauf steuern.

Beim modernen dracut basierten initramfs übernimmt tatsächlich systemd selbst als PID 1 innerhalb des initramfs die Steuerung, mit spezialisierten Units für Aufgaben wie das Warten auf ein LVM Volume oder das Abfragen einer LUKS Passphrase, statt eines einfachen Shell Skripts wie bei älteren initramfs Generatoren.

# Inhalt eines initramfs Images ohne Entpacken auflisten
lsinitrd /boot/initramfs-$(uname -r).img | head -40

# Enthaltene Kernel Module gezielt anzeigen
lsinitrd /boot/initramfs-$(uname -r).img -m

# Enthaltene dracut Module (Funktionsblöcke) anzeigen
lsinitrd /boot/initramfs-$(uname -r).img | grep dracut-

3. dracut: Modulares Werkzeug zum Bau des initramfs

dracut ersetzt auf RHEL, Fedora, SUSE und mittlerweile auch auf vielen Debian Derivaten die älteren initramfs Generatoren und arbeitet modular: Jedes dracut Modul in /usr/lib/dracut/modules.d kapselt Unterstützung für ein bestimmtes Feature, etwa lvm, crypt, network oder nfs, und wird nur dann eingebunden, wenn es entweder automatisch erkannt oder explizit angefordert wird.

Die Konfiguration erfolgt über /etc/dracut.conf sowie Fragmente in /etc/dracut.conf.d, in denen sich zusätzliche Module, Treiber oder Kernel Befehlszeilen Optionen dauerhaft festlegen lassen, ohne bei jedem Aufruf lange Kommandozeilen Parameter angeben zu müssen.

# /etc/dracut.conf.d/10-storage.conf: zusätzliche Module und Treiber erzwingen
cat <<'EOF' | sudo tee /etc/dracut.conf.d/10-storage.conf
add_dracutmodules+=" lvm crypt "
force_drivers+=" nvme megaraid_sas "
compress="zstd"
EOF

4. initramfs mit dracut neu bauen

Nach Änderungen an der Storage Konfiguration, etwa einem neuen LVM Volume, einer geänderten LUKS Passphrase Datei oder einem zusätzlichen Kernel Modul, muss das initramfs für den betroffenen Kernel neu gebaut werden, sonst greifen die Änderungen erst nach einem manuellen Eingriff beim nächsten Boot. Der Befehl dracut -f überschreibt das Image für den aktuell laufenden Kernel, während sich mit einem expliziten Kernel Namen auch für einen anderen installierten Kernel neu bauen lässt.

Für Umgebungen mit mehreren installierten Kernel Versionen, etwa nach einem größeren Distributions Update, baut dracut --regenerate-all die initramfs Images für sämtliche installierten Kernel in einem Durchgang neu, was sich besonders nach Änderungen anbietet, die alle Kernel betreffen, wie ein neuer force_drivers Eintrag in der dracut Konfiguration.

# initramfs für den aktuell laufenden Kernel neu bauen
sudo dracut -f

# initramfs für einen bestimmten, bereits installierten Kernel neu bauen
sudo dracut -f /boot/initramfs-5.14.0-570.el9.x86_64.img 5.14.0-570.el9.x86_64

# initramfs für alle installierten Kernel Versionen neu bauen
sudo dracut --regenerate-all -f

5. Debugging bei unable to mount root

Die Meldung dracut Warning: Could not boot beziehungsweise unable to mount root filesystem landet meist in einer minimalen dracut Notfall Shell. Der erste Blick gilt journalctl innerhalb dieser Shell sowie der Ausgabe von lvm vgscan oder cryptsetup status, um festzustellen, ob das erwartete Volume Group oder das verschlüsselte Gerät überhaupt sichtbar ist, bevor der eigentliche Root Mount versucht wird.

Häufige Ursachen sind ein initramfs, das noch die alte UUID nach einer Neuformatierung referenziert, ein fehlendes Storage Treiber Modul nach einem Hardware Wechsel, etwa von virtio auf einen physischen RAID Controller, oder ein LVM Volume, das wegen falscher Filter Konfiguration in lvm.conf innerhalb des initramfs nicht erkannt wird.

# In der dracut Notfall Shell: Volume Groups und Devices prüfen
dracut:/# vgscan
dracut:/# lvm lvs
dracut:/# cryptsetup status luks-root
dracut:/# blkid | grep -i uuid

# Root Filesystem manuell einhängen und Boot fortsetzen
dracut:/# mount /dev/mapper/vg-root /sysroot
dracut:/# exit

6. Debug Optionen über rd Kernel Parameter

dracut bringt eine eigene Familie an Kernel Parametern mit, die mit rd. beginnen und ausschließlich innerhalb der frühen Boot Phase ausgewertet werden. rd.debug schreibt eine ausführliche Log Datei nach /run/initramfs/rdsosreport.txt, rd.break hält den Boot Vorgang an einer bestimmten Stelle an und übergibt eine interaktive Shell, und rd.shell erzwingt bei jedem Fehler automatisch eine Notfall Shell statt eines sofortigen Kernel Panic.

Diese Parameter werden über das GRUB Menü mit der Taste e nur für den aktuellen Boot ergänzt, sollten also nicht dauerhaft in GRUB_CMDLINE_LINUX_DEFAULT landen, weil sie den Boot Vorgang bewusst verlangsamen und in einer Produktionsumgebung ohne aktive Fehlersuche keinen Mehrwert bieten.

# Kernel Zeile im GRUB Menü temporär um Debug Parameter erweitern
rd.debug rd.break=pre-mount

# Nach dem Boot: gesammeltes dracut Debug Log auswerten
less /run/initramfs/rdsosreport.txt

7. Anpassung für benutzerdefinierte Storage Setups

Bei ungewöhnlichen Storage Kombinationen, etwa Root über iSCSI, Root auf einem Software RAID mit mdadm oder Root über Multipath auf einem SAN, reicht die automatische Erkennung von dracut oft nicht aus und benötigt zusätzliche Kernel Parameter sowie explizit aktivierte Module wie network, iscsi, mdraid oder multipath.

Für solche Umgebungen lohnt sich ein dediziertes Konfigurationsfragment, das die benötigten Module dauerhaft festschreibt, statt sich bei jedem Kernel Update erneut auf die automatische Erkennung von dracut zu verlassen, die insbesondere bei Netzwerk Storage nicht immer zuverlässig alle Abhängigkeiten findet.

# /etc/dracut.conf.d/20-iscsi-root.conf: Root über iSCSI dauerhaft unterstützen
cat <<'EOF' | sudo tee /etc/dracut.conf.d/20-iscsi-root.conf
add_dracutmodules+=" network iscsi "
EOF

sudo dracut -f --kver $(uname -r)

8. dracut im Vergleich zu initramfs-tools

Debian und Ubuntu setzen historisch auf initramfs-tools statt dracut, mit einem eigenen Satz an Befehlen: update-initramfs -u zum Neubau des aktuellen Images und /etc/initramfs-tools/modules zum expliziten Ergänzen von Kernel Modulen. Funktional decken beide Werkzeuge dieselbe Aufgabe ab, unterscheiden sich aber deutlich in Architektur, Konfigurationssyntax und der Frage, ob systemd innerhalb des initramfs läuft.

Wer zwischen Debian und RHEL basierten Servern wechselt, sollte die unterschiedliche Kommandozeile im Kopf behalten: dracut -f entspricht in etwa update-initramfs -u, während lsinitrd kein direktes Gegenstück bei initramfs-tools hat und dort stattdessen ein manuelles Entpacken des cpio Archivs nötig ist.

9. Best Practices für den produktiven Einsatz

Nach jedem Kernel Update lohnt sich eine kurze Kontrolle, ob tatsächlich ein neues initramfs für den neuen Kernel existiert, denn ein fehlendes oder veraltetes Image führt beim nächsten Boot zuverlässig zu einem unable to mount root Fehler. Die meisten Paketmanager rufen dracut automatisch über einen Kernel Post Install Hook auf, ein manueller Kontrollblick schadet trotzdem nicht.

Vor größeren Storage Änderungen, etwa dem Wechsel von einem einzelnen Datenträger auf ein LVM Setup, sollte ein aktuelles initramfs gebaut und im Idealfall über eine Rescue Konsole getestet werden, bevor der produktive Server neu gestartet wird. Ein Backup des vorherigen initramfs Images unter einem anderen Dateinamen ist dabei eine günstige Absicherung gegen einen fehlgeschlagenen Neubau.

10. Zusammenfassung

11. FAQ: initramfs und dracut