Linux booten verstehen (LPIC-1 101.2): Von BIOS/UEFI über GRUB bis systemd – der komplette Startpfad

Ein Linux-System startet nicht „magisch“. Firmware lädt den Bootloader, dieser den Kernel, der wiederum initramfs nutzt, um das echte Root-Dateisystem zu erreichen und die Systeminitialisierung zu übergeben. Wer diesen Pfad versteht, kann Boot-Fehler zielgerichtet beheben, Kernelparameter für Diagnosen einsetzen und Logs effektiv auswerten. Dieser Beitrag bereitet die LPI-Lektion didaktisch auf und enthält alle prüfungsrelevanten Inhalte.

Warum wichtig für Sysadmin

Fehler vor oder während des Bootens sind geschäftskritisch. Bei Dual-Boot, Kernel-Updates, Storage-Umbauten oder Hypervisor-Gästen entscheidet der sichere Umgang mit Firmware-Einträgen (NVRAM/ESP), GRUB-Konfiguration, Kernelparametern, initramfs und Log-Werkzeugen (dmesg, journalctl) darüber, wie schnell ein System wieder verfügbar ist.

Boot-Grundlagen: Firmware lädt Bootloader lädt Kernel

Beim Einschalten übernimmt die Firmware – klassisch BIOS, heute meist UEFI. Sie führt POST aus, initialisiert Basishardware (Grafik, Tastatur, Storage) und startet den Bootloader. Der Bootloader lädt den Kernel und übergibt optional Kernelparameter (z. B. Root-Partition, Ziel/Runlevel/Target, Debug-Flags). Danach erkennt der Kernel Hardware, mountet zunächst initramfs (temporäres Root-FS) und schaltet dann auf das echte Root-Dateisystem um; schließlich startet der Systeminitiator (z. B. systemd).

BIOS-Boot (MBR-basiert)

BIOS sucht auf dem ersten Boot-Gerät den MBR (erste 512 Bytes; Boot-Code + Partitionstabelle). Der MBR enthält eine minimalistische Stage 1 des Bootloaders, welche die umfangreichere Stage 2 lädt (Menü, Kernelwahl, Parameter).

UEFI-Boot (ESP-/Dateisystem-basiert)

UEFI liest NVRAM-Einträge und führt eine EFI-Anwendung von der ESP (EFI System Partition) aus. UEFI kann FAT12/16/32 und ISO-9660 lesen. Secure Boot erlaubt nur signierte EFI-Anwendungen (erhöht Sicherheit, kann alternative OS-Installationen erschweren).

Merksatz: UEFI nutzt NVRAM + ESP, nicht den MBR. Deshalb überschreibt ein weiteres OS nicht automatisch deinen Bootloader im MBR.

GRUB im Überblick und Kernelparameter gezielt nutzen

Der verbreitetste Bootloader auf x86 ist GRUB. Er zeigt ein Menü für Kernel/OS-Auswahl; bei BIOS erscheint es ggf. per Shift, bei UEFI per Esc. Kernelparameter folgen dem Schema option=value und sind nützlich für Diagnose und Sonderfälle.

• acpi=off – ACPI-Unterstützung deaktivieren (Diagnose).
• init=/bin/bash – alternative Init-Binary; startet direkt eine Bash (Recovery).
• systemd.unit=graphical.target – bestimmtes systemd-Target booten; 1/S für Single-User-Modus.
• mem=512M – verfügbaren RAM begrenzen (z. B. Test in VMs).
• maxcpus=2 / nosmp – sichtbare CPU-Kerne begrenzen/deaktivieren.
• quiet – Bootmeldungen ausblenden.
• vga=ask – Videomodus wählen (klassisch/BIOS-bezogen).
• root=/dev/sda3 – abweichende Root-Partition setzen.
• rootflags=…, ro, rw – Einhängeoptionen/Modus fürs Root-FS.

# Persistente Kernelparameter setzen (Beispiel)

andy@fedora:~$ sudo sed -i 's/^GRUB_CMDLINE_LINUX=.*/GRUB_CMDLINE_LINUX="quiet rootflags=subvol=@"/' /etc/default/grub

andy@fedora:~$ sudo grub-mkconfig -o /boot/grub/grub.cfg

# Kommentar: Aktualisiert die GRUB-Konfiguration nach Parameteränderungen

# Laufzeit-Kernelparameter prüfen

andy@fedora:~$ cat /proc/cmdline

BOOT_IMAGE=(hd0,msdos1)/vmlinuz-6.8.0 ... root=/dev/sda3 ro quiet

# Kommentar: /proc/cmdline spiegelt die Parameter des aktiven Kernels

initramfs verstehen: Brücke zum echten Root-Dateisystem

initramfs ist ein komprimiertes Archiv mit minimalem Userspace (Treiber, Hooks, Tools). Es wird als temporäres Root-FS gemountet, damit der Kernel z. B. Storage-/RAID-/Verschlüsselungs-Module laden kann, bevor das finale Root-FS erreichbar ist. Fehlt ein passendes initramfs, kann der Zugriff auf / scheitern – besonders bei modularen Treibern.

Systeminitialisierung: Von init zu systemd

Nach dem Pivot vom initramfs auf das echte Root-FS startet der Kernel das Init-Programm (PID 1). Klassische und moderne Varianten:

SysV-init (Runlevel-basiert)

Startet Dienste pro Runlevel (0–6). Einheitliche Bedeutung: 0=halt, 1=single, 6=reboot. Skriptlastig und sequentiell.

systemd (ziel-/abhängigkeitsbasiert)

De-facto-Standard. Nutzt Units, Targets, Socket-/D-Bus-Aktivierung, cgroups für Prozessüberwachung, Snapshots, Wiederherstellung, Mount-Kontrolle und abhängigkeitsbasierte Starts.

Upstart (historisch)

Ereignisbasierter Ersatz für init, ehemals in Ubuntu verbreitet, heute praktisch von systemd abgelöst.

# Aktuelles Boot-Target prüfen und wechseln (systemd)

andy@fedora:~$ systemctl get-default
graphical.target

andy@fedora:~$ sudo systemctl isolate multi-user.target

# Kommentar: Wechselt live in ein anderes Ziel (ähnlich Runlevel 3)

# Dienste verwalten

andy@fedora:~$ sudo systemctl restart sshd

# Kommentar: Änderungen an Konfigs erfordern oft Neustarts

Boot-Logs lesen: Kernel-Ringpuffer und Journal

Während des Bootens entstehende Meldungen landen im Kernel-Ringpuffer (flüchtig) und – bei systemd – im Journal (persistierbar). Diese sind essenziell für Diagnose.

# Aktuelle Kernelmeldungen anzeigen (flüchtig)

andy@fedora:~$ dmesg | head -n 10

[    0.000000] Linux version 6.8.0 ...
[    5.262389] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

# Kommentar: Zeitstempel relativ zum Kernelstart

# Boot-spezifische Journal-Ansichten (systemd)

andy@fedora:~$ journalctl --list-boots

  -1 55c0d9439bfb4e85 ... 
   0 08fbbebd9f964a74 ...

andy@fedora:~$ journalctl -b 0

# Kommentar: -b 0 = aktueller Boot; -b -1 = vorheriger Boot

# Journal anderer Systeme/Mountpunkte lesen (Recovery/Forensik)

andy@fedora:~$ sudo journalctl -D /mnt/hd/var/log/journal

# Kommentar: -D/--directory liest Journal-Dateien außerhalb des Standardpfads

Hinweis: dmesg -H/--human aktiviert einen Pager/formatierte Ausgabe, was das Lesen langer Logs erleichtert.

Geführte Übungen (didaktisch beantwortet)

1. Wo liegt unter BIOS das Bootstrap-Binary? – Im MBR (erste 512 Bytes) des im BIOS konfigurierten ersten Geräts.
2. Wo liegen UEFI-EFI-Anwendungen? – In der ESP (FAT32), referenziert durch NVRAM-Einträge.
3. Falsche Root-Partition, korrekt ist /dev/sda3: Wie Kernel mitteilen? – Mit root=/dev/sda3 als Kernelparameter.
4. Boot bricht ab: „ALERT! /dev/sda3 does not exist. Dropping to a shell!“ Ursache? – Kernel/initramfs findet das angegebene Gerät nicht (falscher Parameter, fehlender Treiber, abweichende Bezeichnung/UUID).

Offene Übungen (didaktisch beantwortet)

1. Warum überschreibt ein neues OS auf UEFI den anderen Boot nicht wie beim MBR? – UEFI verwendet keinen MBR für Stage 1; Einträge zeigen auf EFI-Programme in der ESP.
2. Folge eines angepassten Kernels ohne passendes initramfs? – Zugriff auf / kann scheitern, wenn benötigte Treiber modular sind.
3. Wie dmesg ohne eigenen Pager auflisten? – Mit dmesg -H bzw. --human.
4. Journal einer ausgebauten Platte unter /mnt/hd lesen? – journalctl -D /mnt/hd/var/log/journal.

Zusammenfassung

• Firmware → Bootloader → Kernel → initramfs → Init: Der lineare Pfad des Bootens.
• BIOS vs. UEFI: BIOS lädt MBR-Stage 1; UEFI nutzt NVRAM und ESP (FAT). Secure Boot nur signierte EFI-Apps.
• GRUB & Kernelparameter: Diagnose und Sonderfälle über root=, systemd.unit=, init=, mem=, maxcpus=, quiet, ro/rw.
• initramfs: Liefert frühe Treiber/Tools; ohne passendes Image bleibt / u. U. unerreichbar.
• Init-Systeme: SysV-Runlevel vs. systemd (Units, Targets, Abhängigkeiten, cgroups).
• Logs: dmesg (Ringpuffer) und journalctl (persistente Boots) sind Ersthelfer.

Wissensprüfung mit Multiple-Choice-Fragen

1. Wo befindet sich auf BIOS-Systemen der erste Bootloader-Code?
   • A) /boot/grub/grub.cfg
   • B) In der ESP
   • C) Im MBR des ersten Geräts
   • D) /etc/default/grub
2. Was speichert UEFI, um eine EFI-Anwendung zu starten?
   • A) Einen MBR-Zeiger
   • B) NVRAM-Einträge
   • C) Einen GPT-Backupsektor
   • D) Eine /etc/efi.conf
3. Welcher Kernelparameter setzt die Root-Partition?
   • A) root=
   • B) systemd.unit=
   • C) init=
   • D) rw=
4. Wozu dient init=/bin/bash?
   • A) Startet Bash statt Kernel
   • B) Startet Bash als PID 1 für Recovery
   • C) Setzt Root-FS read-only
   • D) Aktiviert Debug-Logs
5. Wofür ist initramfs primär notwendig?
   • A) GUI laden
   • B) Frühe Treiber/Mount-Pfad zum echten Root-FS
   • C) Bootmenüs zeichnen
   • D) Secure-Boot-Schlüsselspeicher
6. Welcher Befehl regeneriert die GRUB-Konfiguration?
   • A) update-initramfs
   • B) grub-install
   • C) grub-mkconfig -o /boot/grub/grub.cfg
   • D) dracut -f
7. Welche Aussage zu systemd ist korrekt?
   • A) Nutzt ausschließlich Runlevel
   • B) Nutzt Units/Targets und Abhängigkeiten
   • C) Lädt nur Shell-Skripte
   • D) Ersetzt den Kernel-Ringpuffer
8. Welcher Befehl zeigt das Journal des vorherigen Boots?
   • A) journalctl -b 0
   • B) journalctl -b -1
   • C) dmesg --previous
   • D) journalctl --list
9. Womit liest du ein Journal von einem gemounteten Fremdsystem?
   • A) journalctl --root=/mnt/hd
   • B) journalctl -D /mnt/hd/var/log/journal
   • C) dmesg -D /mnt/hd
   • D) less /mnt/hd/var/log/journal/*
10. Welche Meldung weist typischerweise auf fehlenden Root-Zugriff beim Boot hin?
    • A) Kernel panic: out of memory
    • B) ALERT! /dev/sda3 does not exist. Dropping to a shell!
    • C) Segmentation fault
    • D) Permission denied

Antworten mit Begründung

1. C – BIOS lädt Stage 1 aus dem MBR.
2. B – NVRAM hält Einträge, die auf EFI-Programme in der ESP zeigen.
3. A – root=/dev/… definiert die Root-Partition.
4. B – Bash läuft als PID 1; nützlich für Recovery/Debug.
5. B – initramfs bringt frühe Treiber/Tools, damit / erreichbar wird.
6. C – grub-mkconfig erzeugt die Menükonfiguration neu.
7. B – systemd arbeitet mit Units/Targets, Abhängigkeiten, cgroups.
8. B – -b -1 wählt den vorherigen Boot.
9. B – -D/--directory liest Journale außerhalb des Standardpfads.
10. B – Deutet auf falschen Device-Pfad/fehlende Treiber hin.