Kap. 01 · Bootprozess, BIOS/UEFI & Bootloader

1.1

Warum musst du das verstehen?

Einstieg

Stell dir vor: Du kommst Montagmorgen ins Büro. Sandra läuft dir entgegen — der Webserver kommt nicht hoch. Bildschirm schwarz, kein Login-Prompt, nur eine kryptische Meldung. Du hast genau zwei Möglichkeiten: panisch rebooten (und hoffen) oder wissen, an welcher Stelle es klemmt.

Wer den Bootprozess versteht, kann gezielt diagnostizieren: Liegt's an der Firmware? Am Bootloader? Am Kernel? An einem Service, der nicht startet? Diese vier Stellen sind die vier Phasen jedes Linux-Boots — und du wirst sie heute kennenlernen.

🎯

Ziel dieses Kapitels

Am Ende kannst du die vier Boot-Phasen in eigenen Worten erklären, BIOS und UEFI auseinanderhalten und das GRUB-Menü interaktiv bedienen. Das ist die Basis für Troubleshooting — und Prüfungsstoff.

1.2

Die vier Phasen des Boot-Prozesses

Pflicht

Jedes Linux-System durchläuft beim Booten genau diese vier Phasen, in dieser Reihenfolge:

Phase 1 — Firmware (BIOS oder UEFI)

Du drückst den Power-Knopf. Strom fließt. Die Firmware auf dem Motherboard erwacht und macht den POST (Power-On Self-Test): RAM zählen, CPU prüfen, angeschlossene Geräte finden. Findet sie alles in Ordnung, sucht sie das Boot-Device (Festplatte, SSD, USB-Stick) und lädt dessen Bootloader.

Phase 2 — Bootloader (GRUB2)

GRUB2 ist ein kleines Programm, das die Firmware in den RAM lädt und ausführt. Seine Aufgabe: das Boot-Menü zeigen (welcher Kernel? welches Betriebssystem?) und dann den ausgewählten Linux-Kernel in den RAM laden und starten.

Phase 3 — Kernel

Jetzt übernimmt der Linux-Kernel. Er initialisiert die Hardware (CPU, RAM, Bus-Systeme), lädt die nötigen Treiber und mountet das Wurzel-Dateisystem (/). Sobald das steht, startet er das allererste Userland-Programm: systemd.

Phase 4 — init (systemd)

systemd bekommt die Prozess-ID 1 (PID 1) — es ist der Urvater aller Prozesse. Von hier startet alles andere: Netzwerk, SSH, Webserver, Login-Manager. Wenn das konfigurierte Target erreicht ist (mehr dazu in Kap. 02), siehst du den Login-Prompt. Boot fertig.

🧠

Merksatz

F-B-K-I — Firmware, Bootloader, Kernel, Init. Diese vier Phasen kommen in jeder Linux-Prüfung dran. Wer die kennt, weiß bei jedem Boot-Problem, wo er suchen muss.

▶ Tiefer einsteigen: Was ist initramfs?

Zwischen Phase 3 (Kernel) und Phase 4 (init) gibt es eine versteckte Mini-Phase: die initramfs (initial RAM filesystem). Das ist ein Mini-Linux im RAM, das der Kernel ganz früh lädt, weil er noch nicht weiß, wie er die echte Festplatte mounten soll (vielleicht braucht er erst einen Treiber für den RAID-Controller oder das LUKS-verschlüsselte Volume).

Du siehst die initramfs in /boot/initramfs-*.img. Diese Datei wird beim Kernel-Update neu generiert und enthält genau die Treiber, die zum Mounten der echten Wurzel nötig sind. Sobald das echte / da ist, wird initramfs verworfen.

1.3

BIOS vs. UEFI — die zwei Firmware-Welten

Pflicht

Es gibt zwei Firmware-Standards, und du wirst beide in der Praxis treffen:

Eigenschaft	BIOS (alt)	UEFI (modern)
Erschienen	1981 (IBM-PC)	2007 (Intel-Standard)
Festplatten-Format	MBR (max. 2 TB, 4 Partitionen)	GPT (max. 9,4 ZB, 128+ Partitionen)
Boot-Modus	16-Bit Real Mode	32-/64-Bit Protected Mode
Boot-Geschwindigkeit	langsam (POST + Boot)	schnell (Fast Boot möglich)
Konfig-Oberfläche	Text-basiert, Tastatur	Grafisch, Maus möglich
Secure Boot	❌ nein	✅ ja
Netzwerk-Boot	nur mit PXE-Erweiterung	nativ eingebaut
Bootloader-Ort	MBR (erste 512 Bytes)	EFI System Partition (ESP)

📌

Was bedeutet das für dich als Admin?

Auf neuen Servern hast du fast immer UEFI mit GPT. Vorteile: schnellerer Boot, mehr als 2 TB Festplatten möglich, Secure Boot für Sicherheit. Auf alten Servern oder VMs kann noch BIOS+MBR laufen — vor allem in Rocky-VMs wird oft BIOS als Default genommen, weil's einfacher ist.

MBR vs. GPT — Festplatten-Partitionsschemata

MBR (Master Boot Record) sitzt in den ersten 512 Bytes der Festplatte. Er enthält den Bootloader-Code UND die Partitionstabelle — beides eng zusammen, was Probleme macht.

GPT (GUID Partition Table) ist neuer und sauberer: Partitionstabelle separat, mit Backup-Kopie am Ende der Platte (Fehlertoleranz!), keine 2-TB-Grenze, viele Partitionen erlaubt.

💡

Selbst prüfen: BIOS oder UEFI?

Auf deinem System kannst du es schnell selbst herausfinden:

[ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS"

Wenn das Verzeichnis /sys/firmware/efi existiert, läuft dein System im UEFI-Modus. Ansonsten Legacy-BIOS. In der Rocky-VM aus Tag 1 ist es meist BIOS+MBR, weil VMware das standardmäßig so anlegt.

1.4

GRUB2 — der Bootloader, den du täglich siehst

Pflicht

GRUB2 (GRand Unified Bootloader, Version 2) ist der Standard-Bootloader auf praktisch allen modernen Linux-Distributionen — Rocky, Debian, Ubuntu, Fedora, RHEL. Wenn du beim Booten ein schwarzes Menü mit Kernel-Auswahl siehst, ist das GRUB2.

Die wichtigsten GRUB-Dateien

Datei / Pfad	Aufgabe
`/etc/default/grub`	Einstellungen in lesbarem Format (Wartezeit, Default-Eintrag, Kernel-Parameter)
`/boot/grub2/grub.cfg`	Generierte Config — wird beim Boot gelesen. NIE direkt editieren!
`/etc/grub.d/`	Skripte, die die `grub.cfg` bauen
`/boot/vmlinuz-*`	Die Kernel-Dateien selbst
`/boot/initramfs-*.img`	Initial RAM filesystems (siehe Deep-Dive oben)

Der Workflow: GRUB-Einstellungen ändern

Wenn du z. B. die Wartezeit im GRUB-Menü ändern willst, gehst du nie direkt in die grub.cfg (die wird beim nächsten Update überschrieben). Stattdessen:

bash

# 1. SICHERHEITSKOPIE machen (immer zuerst!)
sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.backup

# 2. Als root anmelden (oder mit sudo arbeiten)
sudo su -

# 3. Einstellungs-Datei bearbeiten
vim /etc/default/grub
# z. B. GRUB_TIMEOUT_STYLE=menu und GRUB_TIMEOUT=10,
# damit das Menü 10 Sekunden lang erscheint

# 4. Die echte grub.cfg neu generieren lassen
grub2-mkconfig -o /boot/grub2/grub.cfg

# 5. Neustart, um zu testen
reboot

⚠️

Vorsicht beim GRUB-Editieren

Ein falscher Eintrag in /etc/default/grub und das System bootet nicht mehr. Deshalb:

Immer Backup der grub.cfg machen
In der VM: Snapshot vorher!
Nach Änderung: grub2-mkconfig nicht vergessen, sonst greift die Änderung nicht
Auf Produktionsservern: NIE ohne Wartungsfenster

Wichtige Einstellungen in /etc/default/grub

⚠️

Warum siehst du das GRUB-Menü oft gar nicht?

Auf einer Default-Rocky-9-Installation mit nur einem Kernel-Eintrag ist das Menü standardmäßig versteckt (GRUB_TIMEOUT_STYLE=hidden). Du musst sowohl GRUB_TIMEOUT als auch GRUB_TIMEOUT_STYLE=menu setzen, damit das Menü erscheint.

Variable	Bedeutung
`GRUB_TIMEOUT`	Sekunden, die das GRUB-Menü angezeigt wird (0 = sofort booten)
`GRUB_TIMEOUT_STYLE`	`menu` = Menü sichtbar · `hidden` = unsichtbar, nur Timeout · `countdown` = kurzer Countdown ohne Menü
`GRUB_DEFAULT`	Welcher Eintrag default ist (0 = erster, `saved` = zuletzt gewählter)
`GRUB_CMDLINE_LINUX`	Kernel-Parameter, die beim Boot übergeben werden
`GRUB_DISABLE_RECOVERY`	Recovery-Mode-Einträge ein-/ausblenden

🧪

Lab 3.1 — GRUB-Menü sichtbar machen

Lab · 30 min

📧

Auftrag von Markus (aus seiner Mail)

Hallo Tim,

für deine erste eigenständige Aufgabe heute: Lerne unser Boot-System kennen. Du sollst dir das GRUB-Menü ansehen, die Konfigurationsdateien finden und vor allem sicher mit Backups arbeiten. Wenn du das beherrschst, kannst du nächste Woche auch produktive Server gefahrlos anfassen.

Wichtig: Snapshot vorher! Wenn GRUB kaputt geht, kommt die VM nicht mehr hoch. Mit Snapshot kannst du in 5 Sekunden zurück.

— Markus

📸

VOR dem Lab: Snapshot!

Mach jetzt in VMware einen Snapshot deiner VM und nenne ihn vor-grub. Wenn etwas schief geht (z. B. GRUB-Datei kaputt), bist du in Sekunden wieder da.

Phase 1 — Verstehen, was da ist (8 min)

🎯

Deine Aufgabe

Finde heraus, welche GRUB-Dateien dein System hat und wofür sie da sind. Am Ende sollst du einem Kollegen erklären können: „Welche Datei ändere ich, welche fasse ich NIE an — und warum?"

Arbeite selbstständig. Die Hints unten helfen, wenn du nicht weiterkommst.

💡 Hint 1 — Wo soll ich überhaupt schauen?

GRUB lebt an zwei Stellen: in /etc/... liegen die Einstellungen, in /boot/... die generierten Dateien und der eigentliche Kernel.

💡 Hint 2 — Welche zwei Dateien sind die wichtigsten?

Schau dir /etc/default/grub und /boot/grub2/grub.cfg an. Vergleiche ihre Größe mit ls -lh und ihren Inhalt mit cat. Eine ist klein und lesbar, eine groß und automatisch generiert.

💡 Hint 3 — Warum NICHT direkt grub.cfg ändern?

Die Datei grub.cfg wird bei jedem Kernel-Update von grub2-mkconfig neu geschrieben. Deine Änderungen wären weg. Deshalb: immer /etc/default/grub ändern und danach grub2-mkconfig ausführen.

bash

# Was liegt in /boot/?
ls /boot/
# vmlinuz-*    ← der Kernel | initramfs-*  ← initial RAM fs | grub2/

# GRUB-Verzeichnis
ls /boot/grub2/
# grub.cfg     ← generierte Config (NIE direkt ändern!)
# grubenv      ← gespeicherte GRUB-Umgebung

# Die lesbare Einstellungs-Datei
cat /etc/default/grub

# Größenvergleich: klein (Vorlage) vs. groß (generiert)
ls -lh /etc/default/grub /boot/grub2/grub.cfg

Erklärung: Die kleine Datei /etc/default/grub ist die Vorlage — hier beschreibst du, was du willst. Die große /boot/grub2/grub.cfg wird daraus generiert. Faustregel: immer nur die Vorlage ändern, dann neu generieren — die generierte Datei fasst du nie direkt an.

Phase 2 — Markus' Auftrag umsetzen (15 min)

🎯

Deine Aufgabe

„Tim, bei der nächsten Wartung muss ich am Bootmenü Parameter setzen können — aktuell ist das Menü versteckt, ich sehe es gar nicht. Mach mir das sichtbar und gib mir 10 Sekunden Zeit zum Auswählen. Dokumentier dabei, was du tust, falls ich es irgendwann selbst nachvollziehen will." — Markus

Mach das Menü beim nächsten Boot sichtbar mit 10 Sekunden Wartezeit. Sicherheits-Backup nicht vergessen. Teste mit einem Reboot.

💡 Hint 1 — Backup zuerst!

Bevor du irgendetwas änderst: Sicherheitskopie der generierten Config. sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.backup — dann kannst du im Notfall zurück.

💡 Hint 2 — Welche Variablen muss ich überhaupt ändern?

Zwei Variablen in /etc/default/grub: GRUB_TIMEOUT (Wartezeit in Sekunden) und GRUB_TIMEOUT_STYLE (steuert, ob das Menü überhaupt erscheint). Welche Werte du brauchst, ergibt sich aus Markus' Auftrag.

💡 Hint 3 — Datei geändert, aber beim Reboot passiert nichts

Das Ändern von /etc/default/grub allein reicht nicht — die echte Boot-Config muss neu generiert werden: sudo grub2-mkconfig -o /boot/grub2/grub.cfg. Erst danach greift die Änderung beim nächsten Boot.

bash

# 1. Backup zuerst
sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg.backup

# 2. Vorlage anpassen: GRUB_TIMEOUT=10, GRUB_TIMEOUT_STYLE=menu
sudo vim /etc/default/grub

# 3. Echte Config neu generieren
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# 4. Testen
sudo reboot

Was beim Reboot passieren sollte: Das GRUB-Menü erscheint jetzt sichtbar und zählt 10 Sekunden herunter, bevor automatisch der Default-Eintrag startet. In dieser Zeit kann Markus mit den Pfeiltasten einen Eintrag auswählen.

Phase 3 — Dokumentieren (7 min)

🎯

Deine Aufgabe

Schreib in 3–5 Sätzen auf, was du gemacht hast — als kurze Notiz für Markus, damit er es später selbst nachvollziehen kann. Format ist frei: ein Editor deiner Wahl, eine Textdatei, ein Notizzettel.

Bonus-Frage zum Nachdenken: Was wäre passiert, wenn du grub.cfg direkt geändert hättest statt über /etc/default/grub?

💡 Hint — Was gehört in so eine Notiz?

Eine gute Doku beantwortet: Was wurde geändert (welche Datei, welche Variablen)? Wie wurde es wirksam gemacht (welcher Befehl)? Wo liegt das Backup? Und: getestet?

„Bootmenü sichtbar gemacht: /etc/default/grub angepasst (GRUB_TIMEOUT_STYLE=menu, GRUB_TIMEOUT=10), mit grub2-mkconfig -o /boot/grub2/grub.cfg aktiviert, Backup der alten grub.cfg unter grub.cfg.backup. Reboot getestet — Menü erscheint mit 10s Countdown."

Zur Bonus-Frage: Hättest du grub.cfg direkt geändert, wäre deine Änderung beim nächsten grub2-mkconfig-Lauf (z. B. bei einem Kernel-Update) spurlos überschrieben worden. Deshalb immer über die Vorlage /etc/default/grub.

🌟 Bonus für schnelle Teilnehmer

📌

Drei kleine Zusatzaufgaben für alle, die mit Markus' Auftrag früher fertig sind. Jede ist in ein, zwei Zeilen erledigt.

Welche Kernel hast du installiert? Schau dir an, welche Kernel-Versionen dein System verfügbar hat:
```
ls /boot/vmlinuz-*
```
Bei einer frischen Rocky-9-Installation siehst du meist nur einen. Nach einem Kernel-Update wären es zwei — und genau dann wäre der Default-Eintrag im GRUB-Menü relevant, weil du nach einem Update zwischen alt und neu wählen könntest (z. B. zum Zurückrollen, falls der neue Kernel Probleme macht). Heute nur erkunden — nichts ändern.
BIOS oder UEFI? Prüfe selbst auf deinem System: [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS. Was hast du?
Boot-Geschwindigkeit messen: systemd-analyze ausführen — wie lange dauert dein Boot? (Hinweis: Services und Units lernen wir gleich in Kapitel 02 — hier nur ein kurzer Vorgriff.)

bash

# 1) Installierte Kernel anzeigen (nur lesen)
ls /boot/vmlinuz-*
# z. B. nur einer:  /boot/vmlinuz-5.14.0-503.el9.x86_64
# Nach einem "dnf update" käme ein zweiter Eintrag dazu — erst dann
# ist GRUB_DEFAULT relevant (Auswahl zwischen altem und neuem Kernel).

# 2) BIOS oder UEFI?
[ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS"

# 3) Boot-Geschwindigkeit (Vorgriff auf Kap. 02)
systemd-analyze
# z. B.: Startup finished in 1.5s (kernel) + 6.2s (userspace) = 7.7s

🎉

Lab 3.1 geschafft?

Sehr gut! Du hast jetzt verstanden, was zwischen Power-Knopf und Login-Prompt passiert. Du weißt, wo GRUB sitzt, wie man es sicher ändert und wie man Backups macht. Das ist die Basis für Server-Troubleshooting — und in vielen Vorstellungs-Gesprächen wird genau das gefragt.

1.5

Typische Anfänger-Fehler

Vorsicht

❌

Fehler 1 — Direkt in grub.cfg editieren

„Ich ändere mal eben die Wartezeit." → Editor auf /boot/grub2/grub.cfg → speichern. Beim nächsten Kernel-Update wird die Datei automatisch überschrieben, deine Änderung ist weg. Richtig: /etc/default/grub editieren, dann grub2-mkconfig.

❌

Fehler 2 — grub2-mkconfig vergessen

Du hast /etc/default/grub sauber editiert, gespeichert — und es passiert nichts. Grund: Ohne grub2-mkconfig -o /boot/grub2/grub.cfg wird die echte Boot-Config nicht neu erzeugt. Erst der Befehl macht die Änderung wirksam.

❌

Fehler 3 — Kein Backup vor dem Editieren

„Wird schon nichts passieren" → falsch getippter Kernel-Parameter in GRUB_CMDLINE_LINUX → System bootet nicht mehr → Panik. Immer erst cp grub.cfg grub.cfg.backup und in der VM Snapshot.

❌

Fehler 4 — BIOS und UEFI verwechseln

In Prüfungsfragen: „Welches Format nutzt UEFI?" → MBR ist FALSCH, UEFI nutzt GPT. Faustregel: BIOS+MBR sind das alte Paar, UEFI+GPT das moderne Paar.

🎯

Kontrollfragen zum Kapitel

Selbst-Check

Nenne die vier Phasen des Linux-Bootprozesses in der richtigen Reihenfolge.
Welches Programm wird nach BIOS ausgeführt? (Prüfungsfrage!)
Warum ist das GRUB-Menü auf einer Default-Rocky-9-Installation oft gar nicht sichtbar — und welche Variable (mit welchem Wert) macht es sichtbar?
Welche Datei editierst du, um GRUB-Einstellungen zu ändern, und welcher Befehl macht die Änderung wirksam? Warum fasst du die grub.cfg nie direkt an?
Was ist der Unterschied zwischen MBR und GPT?
Mit welchem Ein-Zeilen-Befehl prüfst du, ob dein System im BIOS- oder UEFI-Modus läuft?

Firmware (BIOS/UEFI) → Bootloader (GRUB2) → Kernel → Init (systemd). Merksatz: F-B-K-I.
Der Bootloader (in Linux meistens GRUB2). NICHT der Kernel und NICHT init.
Weil bei nur einem Kernel-Eintrag standardmäßig GRUB_TIMEOUT_STYLE=hidden gesetzt ist — das Menü wird übersprungen. Sichtbar machst du es mit GRUB_TIMEOUT_STYLE=menu (zusammen mit einem GRUB_TIMEOUT > 0).
Editieren: /etc/default/grub. Wirksam machen: sudo grub2-mkconfig -o /boot/grub2/grub.cfg. Die grub.cfg fasst man nie direkt an, weil sie bei jedem grub2-mkconfig-Lauf (z. B. Kernel-Update) neu generiert und dabei überschrieben wird.
MBR (Master Boot Record): alt, max. 2 TB, max. 4 Primärpartitionen, BIOS-typisch. GPT (GUID Partition Table): modern, viele Partitionen, bis zu 9,4 ZB, mit Backup-Tabelle, UEFI-typisch.
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS — existiert das Verzeichnis /sys/firmware/efi, läuft das System im UEFI-Modus, sonst Legacy-BIOS.