# Boot Process & Recovery: Wenn Linux nicht mehr startet

TL;DR / Management Summary Ein hängender Server beim Booten ist der Albtraum jedes Admins. Um das Problem zu lösen, muss man die Kette verstehen: UEFI/BIOS -> Bootloader (GRUB) -> Kernel & Initramfs -> Init-System (systemd). Wer weiß, wie man Parameter in GRUB editiert oder in ein chroot einsteigt, kann fast jedes System ohne Neuinstallation retten.

# 1. Einführung & Architektur

Die Anatomie des Boot-Vorgangs.

Der Boot-Prozess ist eine Übergabe von Verantwortung von Hardware zu Software.

# Die Phasen (Mermaid)

graph TD
    A[Hardware Power On] --> B[UEFI / BIOS]
    B -->|Finds Boot Device| C[Bootloader: GRUB]
    C -->|Loads| D[Kernel & Initramfs]
    D -->|Mounts Root FS| E[PID 1: systemd]
    E -->|Starts Units| F[User Login / Services]
    
    subgraph "The Recovery Points"
        C -.->|Edit 'e'| G[Single User Mode]
        E -.->|Failure| H[Emergency Mode]
    end

# 2. GRUB Manipulation: Der “First Aid” Einstieg

In das System schauen, bevor es läuft.

Wenn das System in eine Kernel-Panic läuft oder beim Laden eines Treibers hängt, ist GRUB Ihr Freund.

# Den Boot-Vorgang unterbrechen

1. Im GRUB-Menü die Taste e drücken.
2. Die Zeile suchen, die mit linux beginnt.
3. Parameter ändern oder anhängen:
   • nosplash: Zeigt Text-Ausgaben statt des Logos.
   • systemd.unit=emergency.target: Bootet direkt in die minimalistische Shell.
   • init=/bin/bash: Erzwingt eine Root-Shell ohne Passwortabfrage (wenn kein BIOS-Passwort gesetzt ist).

# 3. Recovery via Live-System (The chroot Method)

Wenn nichts mehr geht.

Wenn GRUB selbst defekt ist oder das Dateisystem Fehler hat, nutzen Sie eine Live-ISO (z.B. Ubuntu Desktop oder SystemRescue).

# Den Patienten operieren (chroot)

Sobald Sie von der Live-CD gebootet haben:

# 1. Root-Partition finden
lsblk
mount /dev/sda2 /mnt

# 2. Virtuelle Filesysteme binden (essenziell für grub-install)
for i in /dev /dev/pts /proc /sys /run; do mount -B $i /mnt$i; done

# 3. Falls vorhanden: /boot und /boot/efi mounten
mount /dev/sda1 /mnt/boot/efi

# 4. In das System 'eintauchen'
chroot /mnt /bin/bash

Jetzt befinden Sie sich “im” kaputten System und können Befehle wie passwd, apt install oder grub-install ausführen.

# 4. Day-2 Operations: Grub & Initramfs Pflege

Prävention ist besser als Heilung.

# GRUB Konfiguration

Änderungen niemals direkt in /boot/grub/grub.cfg machen! Nutzen Sie:

• /etc/default/grub (Haupteinstellungen)
• sudo update-grub (Wendet Änderungen an)

# Initramfs aktualisieren

Wenn Sie Treiber für Storage oder Netzwerk ändern, muss das Initramfs (die “Mini-Disk” für den Kernel) neu gebaut werden:

sudo update-initramfs -u -k all

# 5. Troubleshooting & “War Stories”

Praxiserfahrung aus dem RZ.

# Story 1: “Duplicate UUIDs”

Symptom: Nach dem Klonen einer VM bootet das System nicht mehr oder mountet die falsche Platte. Ursache: /etc/fstab nutzt UUIDs, die nun mehrfach vorhanden sind. Lösung: Im GRUB root=/dev/sda2 statt der UUID angeben, booten und mit tune2fs -U random /dev/sda2 eine neue UUID generieren. Danach /etc/fstab anpassen.

# Story 2: “Das volle /boot”

Symptom: Kernel-Update schlägt fehl, System bootet nach Reboot in alten Kernel oder grub-rescue. Ursache: /boot ist voll mit alten Kernel-Versionen. Lösung: chroot-Methode nutzen, alte Kernel mit dpkg --purge löschen und update-grub ausführen.

# 6. Fazit & Empfehlung

• Keine Angst vor der Shell: Lernen Sie die chroot-Methode auswendig. Sie rettet Leben.
• Backups: Ein Backup der /etc/fstab und der GRUB-Config spart bei der Wiederherstellung viel Zeit.
• Serielle Konsole: Aktivieren Sie in Proxmox immer die serielle Konsole (console=ttyS0 in GRUB), damit Sie auch ohne Grafik-Output sehen, wo der Bootvorgang hängt.

# Anhang: Cheatsheet