/ Artikel

/boot — Bootloader & Kernel

Vollständiger Überblick zu /boot unter Linux: Welche Dateien dort liegen (vmlinuz, initramfs, System.map, config), wie GRUB2 und systemd-boot den Start steuern, was die EFI-System-Partition macht und wie man alte Kernel sicher entfernt.

/boot enthält alle Artefakte, die der Bootloader (meist GRUB2 oder systemd-boot) zum Start des Systems lädt: Kernel-Images (vmlinuz-*), Initial-RAM-Disks (initramfs-*), Bootloader-Konfiguration und ergänzende Dateien. Auf modernen Systemen mit UEFI mountet zusätzlich eine EFI System Partition (ESP) unter /boot/efi — die ist FAT-formatiert und enthält die EFI-Bootloader-Programme. Wer den Boot-Vorgang versteht, weiß auch, warum Kernel-Updates und Dual-Boot-Setups manchmal in /boot schiefgehen.

01 · Abschnitt

Was steckt in /boot?

Das Verzeichnis hält pro installiertem Kernel vier Dateien plus die Bootloader-Konfiguration. Alte Kernel-Versionen bleiben standardmäßig als Fallback im Menü, sodass du beim Boot eine ältere Version wählen kannst, falls ein Update Probleme macht.

Datei	Inhalt
`vmlinuz-<version>`	Komprimiertes, ausführbares Kernel-Image (das eigentliche Linux)
`initrd.img-<version>` (Debian/Ubuntu) bzw. `initramfs-<version>.img` (Fedora)	Initial-RAM-Disk: Mini-Userspace mit Treibern, der vor dem eigentlichen Boot läuft
`System.map-<version>`	Tabelle der Kernel-Symbole und ihrer Speicheradressen — Debug-/Crash-Analyse
`config-<version>`	Konfiguration, mit der dieser Kernel kompiliert wurde
`grub/` (Debian/Ubuntu) bzw. `grub2/` (Fedora)	GRUB-Bootloader-Konfiguration und Module
`efi/` (auf UEFI-Systemen)	Mountpoint der EFI System Partition mit Bootloader-Binaries
`loader/` (bei systemd-boot)	systemd-boot-Konfiguration und Entry-Files

Bash Inhalt von /boot anschauen

ls -la /boot
# vmlinuz-6.8.0-generic
# vmlinuz-6.10.0-generic
# initrd.img-6.8.0-generic
# initrd.img-6.10.0-generic
# config-6.10.0-generic
# System.map-6.10.0-generic
# grub/

# Welcher Kernel läuft gerade?
uname -r
# 6.10.0-generic

# Symlinks für aktuelles und vorheriges Kernel-Image
ls -la /vmlinuz /initrd.img 2>/dev/null
# /vmlinuz -> boot/vmlinuz-6.10.0-generic
# /initrd.img -> boot/initrd.img-6.10.0-generic

02 · Abschnitt

Der Boot-Prozess in Kürze

Damit klar wird, wozu jede Datei da ist, hier der Ablauf vom Einschalten bis zum Login-Prompt:

Firmware-Phase: BIOS oder UEFI liest die Boot-Reihenfolge aus dem NVRAM und sucht den ersten verfügbaren Bootloader.
Bootloader-Phase: GRUB2 oder systemd-boot wird geladen, zeigt das Boot-Menü und lädt den gewählten Kernel (vmlinuz) und seine initramfs aus /boot in den RAM.
Kernel-Frühphase: Der Kernel dekomprimiert sich, initialisiert CPU, MMU und grundlegende Treiber.
initramfs-Phase: Der Kernel hängt die initramfs als Root-Filesystem ein. Skripte darin laden weitere Treiber (Disk, RAID, LUKS, LVM, Dateisystem-Module), entschlüsseln ggf. das echte Root-Filesystem und mounten es.
Pivot Root: Das echte Root-Filesystem ersetzt die initramfs als /. Die initramfs wird verworfen.
Init-Phase: PID 1 startet — auf modernen Systemen systemd. Es liest die Targets, startet alle Units und bringt das System schließlich in multi-user.target oder graphical.target.

Die Trennung zwischen Kernel und initramfs hat zwei Gründe:

Modularität: Der Kernel wird universal kompiliert, ohne fest eingebaute Treiber für jedes denkbare Setup. Treiber für die konkrete Hardware kommen aus der initramfs.
Verschlüsselung: Das echte Root-Filesystem kann verschlüsselt sein. Die initramfs enthält die Tools, um es zur Boot-Zeit zu öffnen — danach übernimmt das System selbst.

03 · Abschnitt

GRUB2 vs. systemd-boot vs. Direct-EFI

Auf x86-Linux sind heute drei Bootloader verbreitet. Welcher wo zum Einsatz kommt, hängt von Distribution, Boot-Mode (BIOS vs. UEFI) und Setup ab:

Bootloader	Wo verbreitet	Wo liegt die Konfig
GRUB2	Standard auf Debian, Ubuntu, Fedora, RHEL, openSUSE	`/boot/grub/grub.cfg` (auto-generiert) und `/etc/default/grub`
systemd-boot	Arch, ClearLinux, optional auf Fedora; nur UEFI	`/boot/loader/loader.conf` und `/boot/loader/entries/*.conf`
Direct EFI Boot	Minimal-Setups, EFI Stub direkt	EFI-NVRAM-Variablen via `efibootmgr`
rEFInd	Multi-OS-Boot, optisch ansprechend	`/boot/efi/EFI/refind/refind.conf`

GRUB2 ist mächtiger (BIOS und UEFI, Multi-OS, Themes), systemd-boot ist deutlich schlanker und reiner UEFI. Beide schreiben ihre eigentliche Konfiguration nicht in eine handgepflegte Datei, sondern werden indirekt aus Vorlagen erzeugt.

Bash GRUB-Konfiguration regenerieren

# Defaults anpassen — z. B. Boot-Timeout oder Kernel-Parameter
sudo $EDITOR /etc/default/grub
# GRUB_TIMEOUT=5
# GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

# Generierte grub.cfg neu bauen (Debian/Ubuntu)
sudo update-grub

# Alternativ direkt:
sudo grub-mkconfig -o /boot/grub/grub.cfg

# Auf Fedora/RHEL:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Bash systemd-boot-Einträge anschauen

# Globale Konfig
cat /boot/loader/loader.conf
# default arch.conf
# timeout 3
# console-mode max

# Pro-Kernel-Eintrag
ls /boot/loader/entries/
# arch.conf  arch-fallback.conf

cat /boot/loader/entries/arch.conf
# title   Arch Linux
# linux   /vmlinuz-linux
# initrd  /initramfs-linux.img
# options root=UUID=... rw quiet

04 · Abschnitt

EFI System Partition und /boot/efi

Auf UEFI-Systemen gibt es eine spezielle Partition: die EFI System Partition (ESP). Sie ist mit FAT32 formatiert (damit jede UEFI-Firmware sie lesen kann), trägt typ EF00 (GPT) und wird unter /boot/efi (Debian/Ubuntu) oder /efi (Arch, manche Setups) gemountet.

Die ESP enthält:

Pfad	Inhalt
`/boot/efi/EFI/BOOT/BOOTX64.EFI`	Fallback-Bootloader (Default-Pfad jeder UEFI-Firmware)
`/boot/efi/EFI/<distro>/grubx64.efi`	GRUB2 für UEFI
`/boot/efi/EFI/systemd/systemd-bootx64.efi`	systemd-boot
`/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi`	Windows-Bootloader (Dual-Boot)
`/boot/efi/loader/`	Wird bei systemd-boot von der ESP verlinkt — kein separates `/boot/loader`

Mit efibootmgr lassen sich die in der UEFI-NVRAM gespeicherten Boot-Einträge anschauen und manipulieren — das ist die Tabelle, die die Firmware nach einem Druck auf den Power-Button durchläuft:

Bash EFI-Boot-Einträge prüfen

sudo efibootmgr -v
# BootCurrent: 0001
# Timeout: 3 seconds
# BootOrder: 0001,0002,0003
# Boot0001* ubuntu  HD(1,GPT,...)/File(\EFI\ubuntu\shimx64.efi)
# Boot0002* Windows Boot Manager  ...
# Boot0003* UEFI: USB Drive       ...

# Default-Boot ändern
sudo efibootmgr -o 0002,0001,0003

# Einen Eintrag entfernen (Vorsicht!)
sudo efibootmgr -b 0003 -B

05 · Abschnitt

Kernel- und initramfs-Updates

Wer ein Kernel-Paket installiert, bekommt automatisch neue vmlinuz-* und initrd.img-* in /boot. Distributionen führen dabei pro Update meist auch ein Bootloader-Update durch — die grub.cfg wird neu erstellt, damit der neue Kernel im Menü auftaucht.

Aktion	Debian/Ubuntu	Fedora/RHEL	Arch
Neuer Kernel	`apt install linux-image-...`	`dnf install kernel`	`pacman -S linux`
initramfs neu bauen	`update-initramfs -u -k <ver>`	`dracut --force /boot/initramfs-<ver>.img <ver>`	`mkinitcpio -P`
GRUB neu generieren	`update-grub`	`grub2-mkconfig -o /boot/grub2/grub.cfg`	`grub-mkconfig -o /boot/grub/grub.cfg`
Kernel entfernen	`apt purge linux-image-<ver>`	`dnf remove kernel-<ver>`	`pacman -R linux`

Der wichtigste Punkt: niemals manuell Dateien aus /boot löschen, ohne das Paket-Tool zu fragen. Dadurch bleiben Kernel-Pakete in der Datenbank zurück, und das System ist beim nächsten Update inkonsistent.

Bash initramfs aufbauen — typische Anlässe

# Nach Treiber-Installation, die schon beim Boot da sein muss
sudo update-initramfs -u

# Für einen bestimmten Kernel
sudo update-initramfs -u -k 6.10.0-generic

# Was steckt in einer initramfs?
sudo lsinitramfs /boot/initrd.img-$(uname -r) | head -30
# bin/
# bin/busybox
# conf/
# ...

# initramfs entpacken (read-only Inspektion)
mkdir /tmp/initrd-inspect && cd /tmp/initrd-inspect
zstd -d < /boot/initrd.img-$(uname -r) | cpio -id 2>/dev/null

06 · Abschnitt

/boot voll? Alte Kernel sicher entfernen

Auf Systemen mit eigener /boot-Partition (oft 500 MB oder 1 GB) können sich nach mehreren Kernel-Updates die alten Versionen anstauen, bis kein neues Update mehr durchgeht. Typischer Fehler: apt upgrade schlägt fehl mit „No space left on device" auf /boot.

Bash Alte Kernel sicher entfernen — pro Distro

# ─── Debian/Ubuntu ─────────────────────────────────────────────
# Aktuell genutzten Kernel anzeigen
uname -r

# Nicht mehr benötigte Kernel-Pakete
sudo apt autoremove --purge

# Manuell prüfen, was alles installiert ist
dpkg -l 'linux-image-*' | grep '^ii'

# ─── Fedora/RHEL ───────────────────────────────────────────────
# Standardmäßig behält dnf 3 Kernel. Ältere entfernen:
sudo dnf remove --oldinstallonly --setopt=installonly_limit=2

# ─── Arch ──────────────────────────────────────────────────────
# Arch behält nur das aktuelle Kernel-Paket. Cache leeren:
sudo paccache -r

Der laufende Kernel (uname -r) wird durch apt autoremove und dnf remove --oldinstallonly automatisch geschützt — kein Risiko, das System unbootbar zu machen.

07 · Abschnitt

Interessantes

/boot ist auf BIOS-Systemen oft 500 MB — heute zu klein

Distributionen wie Ubuntu LTS allokieren bei Standard-Installation manchmal nur 500 MB für /boot. Drei Kernel mit modernen initramfs (60–80 MB pro Stück) plus GRUB-Daten füllen das schnell. Bei Neuinstallationen lohnt sich 1–2 GB für /boot einzuplanen, vor allem wenn man Custom-Kernel oder mehrere Distributionen parallel halten will.

EFI System Partition ist FAT32 — Vorsicht mit Symlinks und Permissions

Die ESP liegt auf einem FAT32-Filesystem, das keine Unix-Permissions oder Symlinks unterstützt. Tools, die dort hin schreiben, dürfen das nicht voraussetzen. Auch: Dateinamen sind case-insensitive. Das ist alles geplant, kann aber bei manuellen Eingriffen zu Verwirrung führen.

Secure Boot kompliziert die Sache

Auf Systemen mit aktivem Secure Boot muss der Bootloader (und auf manchen Setups auch der Kernel und Treiber) signiert sein. Distributionen liefern eigene Signaturen, eigene Kernel-Module brauchen MOK-Signaturen (Machine Owner Key). mokutil --sb-state zeigt den Secure-Boot-Status. Wer Secure Boot aktiv hat und merkwürdige „Verification failed"-Fehler beim Boot sieht, sollte zuerst hier prüfen.

Unified Kernel Image (UKI) ist die kommende Lösung

Aktuell sind Kernel, Cmdline und initramfs in /boot getrennt — Updates müssen alle drei aktuell halten. Ein Unified Kernel Image (UKI) kombiniert sie zu einem einzigen, signierten EFI-Binary. systemd ≥ 250 unterstützt das, Fedora und Arch experimentieren damit. Der Vorteil: simpler Boot ohne separaten Bootloader.

vmlinuz ist komprimiert — vmlinux nicht

vmlinuz ist die komprimierte (zlib oder zstd) Variante des Kernels, die der Bootloader lädt. Die unkomprimierte Variante heißt vmlinux und liegt nicht in /boot, sondern in den Debug-Symbolen-Paketen — wird für gdb und perf gebraucht.

System.map ist nicht mehr zwingend nötig

Früher las klogd die System.map, um Kernel-Stack-Traces aufzulösen. Auf modernen Kernels mit kallsyms ist das eingebaut — Stack-Traces in dmesg zeigen die Symbol-Namen direkt. System.map bleibt aber nützlich für Debugger und Tools wie crash.

08 · Abschnitt

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Verzeichnisstruktur

Zur Übersicht