Linux Boot-Probleme lösen – GRUB, Recovery Mode und Kernel-Panics

Der schlimmste Moment für jeden Linux-Nutzer: Der Server startet nicht mehr. Schwarzer Bildschirm, GRUB-Fehler, Kernel Panic – das klingt nach Katastrophe, ist es aber oft nicht. Die meisten Boot-Probleme sind lösbar, wenn man die richtigen Schritte kennt.

Dieser Guide führt dich systematisch durch die häufigsten Boot-Probleme und ihre Lösungen.

Boot-Prozess verstehen

UEFI/BIOS
    │
    ▼ (liest EFI-Partition oder MBR)
GRUB-Bootloader
    │
    ▼ (lädt Kernel und initramfs)
Linux-Kernel
    │
    ▼ (Kernel initialisiert Hardware)
initramfs
    │
    ▼ (montiert Root-Dateisystem)
systemd (PID 1)
    │
    ▼ (startet Services)
Login-Prompt

Wenn das System hängt, bestimmt der Schritt, wo es hängt, die Lösung:

GRUB-Probleme: Fehler und Reparatur

GRUB-Fehlermeldungen

"error: no such partition"
"error: file '/grub/i386-pc/normal.mod' not found"
"Minimal BASH-like line editing is supported"  → GRUB Rescue

GRUB Rescue: Minimales GRUB reparieren

# In der GRUB-Rescue-Shell: Root-Partition finden
grub rescue> ls
# (hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3)  ← Partitionen

grub rescue> ls (hd0,gpt2)/
# bin/ boot/ etc/ home/ ...  ← das ist das Linux-Root!

# GRUB-Module laden
grub rescue> set root=(hd0,gpt2)
grub rescue> insmod normal
grub rescue> normal

# → Normales GRUB-Menü erscheint

Manuell vom GRUB-Menü booten

Wenn GRUB-Menü erscheint, aber falsche Konfiguration:

# In GRUB: "c" drücken für Kommandozeile
grub> ls
# (hd0,gpt1) (hd0,gpt2) ...

# Root setzen
grub> set root=(hd0,gpt2)

# Kernel suchen
grub> ls (hd0,gpt2)/boot/
# vmlinuz-6.8.0-48-generic  initrd.img-6.8.0-48-generic

# Kernel laden
grub> linux (hd0,gpt2)/boot/vmlinuz-6.8.0-48-generic root=/dev/sda2
# mit Kernel-Parameter:
grub> linux (hd0,gpt2)/boot/vmlinuz-6.8.0-48-generic root=/dev/sda2 ro quiet

# initrd laden
grub> initrd (hd0,gpt2)/boot/initrd.img-6.8.0-48-generic

# Booten
grub> boot

GRUB von Live-System reparieren

# 1. Live-USB booten (Ubuntu ISO)
# 2. Terminal öffnen

# Root-Partition identifizieren
sudo fdisk -l
# /dev/sda2  Linux filesystem

# Root-Partition einhängen
sudo mount /dev/sda2 /mnt

# EFI-Partition einhängen (UEFI-Systeme)
sudo mount /dev/sda1 /mnt/boot/efi

# In das System chrooten
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt

# GRUB reinstallieren (UEFI)
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
update-grub

# GRUB reinstallieren (Legacy BIOS)
grub-install /dev/sda   # auf die gesamte Disk, nicht Partition!
update-grub

# Chroot verlassen
exit
sudo umount -R /mnt
sudo reboot

GRUB-Konfiguration reparieren

# Wenn GRUB-Menü erscheint, aber falsche Einträge:
sudo update-grub

# Windows nicht im Menü
sudo nano /etc/default/grub
# GRUB_DISABLE_OS_PROBER=false
sudo update-grub

# GRUB-Timeout-Problem (zu schnell)
sudo nano /etc/default/grub
# GRUB_TIMEOUT=10
sudo update-grub

Recovery Mode: Das Schweizer Taschenmesser

Der Ubuntu/Debian Recovery Mode ist der einfachste Weg, ein nicht-startendes System zu reparieren.

Recovery Mode starten

1. Computer neu starten
2. Beim GRUB-Menü: ↓ Taste → "Advanced options for Ubuntu"
3. "Ubuntu, with Linux X.X.X-XX-generic (recovery mode)" wählen

Recovery-Menü Optionen

resume          → Normal booten (Ende Recovery)
clean           → Disk aufräumen (wenn voll)
dpkg            → Unterbrochene Installationen reparieren
failsafeX       → Grafik im Failsafe-Modus
fsck            → Dateisystem prüfen
grub            → GRUB aktualisieren
network         → Netzwerk aktivieren
root            → Root-Shell (wichtigste Option!)
system-summary  → Hardware-Übersicht

Root-Shell im Recovery Mode

# Nach Auswahl von "root":
# Dateisystem ist zunächst read-only!

# Read-Write mounten
mount -o remount,rw /

# Jetzt können Reparaturen durchgeführt werden:

# Passwort zurücksetzen
passwd andre

# Kaputtes Paket reparieren
apt --fix-broken install
dpkg --configure -a

# Konfigurationsdatei wiederherstellen
cp /etc/nginx/nginx.conf.backup /etc/nginx/nginx.conf

# Netzwerk aktivieren (für Updates)
dhclient eth0
# oder:
ip link set eth0 up
dhclient eth0

# Paket entfernen das beim Booten Probleme macht
apt purge schlechtes-paket

# Neustart
reboot

Kernel Panic debuggen

Eine Kernel Panic ist ein fataler Fehler des Linux-Kernels – das System kann nicht mehr sicher laufen und stoppt.

Typische Kernel-Panic-Ausgaben

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Kernel panic - not syncing: Fatal exception
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100

Alten Kernel booten

GRUB-Menü → "Advanced options for Ubuntu"
→ Ältere Kernel-Version wählen (ohne "(recovery mode)")

# Wenn das funktioniert: Neuer Kernel hat Problem

# Installierte Kernel anzeigen
dpkg -l "linux-image*" | grep "^ii"

# Defekten Kernel entfernen
sudo apt purge linux-image-6.8.0-52-generic
sudo update-grub

# Oder: Alten Kernel als Standard
sudo nano /etc/default/grub
# GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-48-generic"
sudo update-grub

VFS-Kernel-Panic: Root-Partition nicht gefunden

Kernel panic - not syncing: VFS: Unable to mount root fs

Ursachen und Lösungen:

# 1. Root-Partition im Bootloader falsch
# GRUB manuell starten (siehe oben) und richtige Partition setzen

# 2. initramfs beschädigt
# Im Recovery-Mode oder von Live-System:
sudo update-initramfs -u -k all
sudo update-grub

# 3. UUID hat sich geändert (z.B. nach Disk-Austausch)
# Korrekte UUID herausfinden
sudo blkid /dev/sda2
# /dev/sda2: UUID="abc-123-def" TYPE="ext4"

# In /etc/fstab prüfen
cat /etc/fstab | grep "UUID"
# Falls falsch: UUID in /etc/fstab korrigieren

Dateisystem-Fehler (fsck)

Automatisches fsck beim Booten

Wenn das Dateisystem nicht sauber abgehängt wurde (Stromausfall, Kernel Panic), läuft fsck automatisch:

/dev/sda2: recovering journal
/dev/sda2: clean, 123456/2621440 files, 789012/10485760 blocks

Das ist normal und dauert einige Minuten.

Manueller fsck

# WICHTIG: Dateisystem muss unmounted oder read-only sein!

# Von Live-System oder Recovery Mode:
umount /dev/sda2   # falls gemountet

# Dateisystem prüfen (ohne Reparatur)
sudo fsck -n /dev/sda2

# Dateisystem prüfen und reparieren
sudo fsck -y /dev/sda2   # -y = alle Fragen mit "ja" beantworten

# Für ext4 spezifisch
sudo e2fsck -f /dev/sda2   # Force-Check
sudo e2fsck -fy /dev/sda2  # Force + auto-fix

# Für XFS (Fedora)
sudo xfs_repair /dev/sda2

# Für Btrfs
sudo btrfs check /dev/sda2
sudo btrfs scrub start /dev/sda2

initramfs-Prompt: fsck-Fehler beim Booten

(initramfs) fsck exited with status 4

# Im initramfs-Prompt:
fsck /dev/sda2 -y

# Nach Reparatur: neu starten
reboot

# Oder: Dateisystem-Prüfung beim nächsten Boot erzwingen
# Boot-Parameter hinzufügen: fsck.mode=force

Schwarzer Bildschirm / Display-Probleme

nomodeset: Grafiktreiber deaktivieren

Im GRUB-Menü:
1. Kernel-Eintrag markieren
2. "e" drücken
3. Zeile mit "linux ... quiet splash" suchen
4. Am Ende "nomodeset" hinzufügen:
   linux /boot/vmlinuz-... root=... quiet splash nomodeset
5. Strg+X oder F10 zum Booten

# Wenn nomodeset hilft: dauerhaft setzen
sudo nano /etc/default/grub
# GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
sudo update-grub

NVIDIA: Blackscreen nach Treiber-Update

# Im Recovery Mode oder TTY (Strg+Alt+F2):

# NVIDIA-Treiber entfernen
sudo apt purge nvidia-*
sudo apt autoremove

# Nouveau reaktivieren (falls geblacklisted)
sudo rm -f /etc/modprobe.d/blacklist-nouveau.conf
sudo update-initramfs -u

sudo reboot

# Danach: saubere Treiber-Neuinstallation
sudo ubuntu-drivers autoinstall
sudo reboot

TTY als Fallback

# Wenn GNOME/X11 nicht startet aber Konsole geht:
Strg+Alt+F2   # TTY2 öffnen (Text-Login)
Strg+Alt+F3   # TTY3 öffnen
Strg+Alt+F7   # Zurück zu GNOME versuchen

# In TTY: X11 neu starten
sudo systemctl restart gdm   # GNOME
sudo systemctl restart sddm  # KDE

Passwort vergessen: Root-Passwort zurücksetzen

Methode 1: Recovery Mode (Ubuntu)

1. Recovery Mode starten (siehe oben)
2. "root" → Root-Shell auswählen
3. Dateisystem read-write mounten:

mount -o remount,rw /

4. Passwort zurücksetzen:
passwd BENUTZERNAME

5. Neustart:
reboot

Methode 2: GRUB-Kernel-Parameter (alle Distros)

1. GRUB-Menü → Kernel auswählen → "e" drücken
2. Zeile mit "linux ... ro quiet splash" finden
3. "ro quiet splash" durch "rw init=/bin/bash" ersetzen:
   linux /boot/vmlinuz-... root=UUID=... rw init=/bin/bash
4. Strg+X zum Booten
5. Du bist direkt als root ohne Login!

# Passwort zurücksetzen
passwd BENUTZERNAME

# Dateisystem synchronisieren
sync

# Neustart
exec /sbin/reboot -f

Von Live-System chroot'en

Der ultimative Rettungsanker: Von einem Live-Ubuntu booten und ins installierte System "einsteigen".

# 1. Live-USB booten

# 2. Partitionen identifizieren
lsblk
sudo fdisk -l | grep "Linux filesystem"
# /dev/sda2 ... Linux filesystem

# 3. Partitionen einhängen
sudo mkdir -p /mnt/system
sudo mount /dev/sda2 /mnt/system

# EFI-Partition (UEFI)
sudo mount /dev/sda1 /mnt/system/boot/efi

# Separate /home-Partition (falls vorhanden)
sudo mount /dev/sda3 /mnt/system/home

# 4. Systempfade binden
sudo mount --bind /dev /mnt/system/dev
sudo mount --bind /dev/pts /mnt/system/dev/pts
sudo mount --bind /proc /mnt/system/proc
sudo mount --bind /sys /mnt/system/sys
sudo mount --bind /run /mnt/system/run

# 5. DNS für Internet-Zugriff
sudo cp /etc/resolv.conf /mnt/system/etc/resolv.conf

# 6. Ins System wechseln
sudo chroot /mnt/system /bin/bash

# JETZT befindest du dich im installierten System!
# Alle Befehle laufen im installierten System

# Typische Reparaturen:
apt update && apt upgrade         # Updates
dpkg --configure -a               # kaputte Pakete
update-grub                       # GRUB neu konfigurieren
grub-install /dev/sda             # GRUB reinstallieren
passwd BENUTZERNAME               # Passwort zurücksetzen
systemctl enable nginx            # Service aktivieren

# 7. Chroot verlassen und aufräumen
exit
sudo umount -R /mnt/system
sudo reboot

Häufige Szenarien und Lösungen

"Server nach Update nicht mehr erreichbar"

# Sofortmaßnahme: Cloud-Konsole (Hetzner, DigitalOcean, AWS)
# → Server-Konsole öffnen → Direkt auf dem System arbeiten

# Status prüfen
sudo systemctl status sshd   # SSH läuft?
sudo ufw status              # Firewall hat SSH gesperrt?

# Häufig: Update hat sshd_config überschrieben
sudo cat /etc/ssh/sshd_config | grep "PasswordAuthentication\|Port"

# GRUB: Boot ohne Netzwerk (Notfall-Kernel)

"System hängt bei Starting Wait for Plymouth"

# Plymouth = Splash-Screen
# Lösung: Plymouth aus GRUB-Parametern entfernen

# GRUB → e → linux-Zeile bearbeiten
# "splash" entfernen → Textmodus statt Plymouth

# Dauerhaft:
sudo nano /etc/default/grub
# GRUB_CMDLINE_LINUX_DEFAULT="quiet"  # kein "splash"
sudo update-grub

"System hängt bei bestimmtem Service beim Boot"

# Service deaktivieren um zu booten
# Im Recovery Mode oder GRUB-Startparameter:
# "systemd.unit=multi-user.target" → minimal booten

# Dann:
sudo systemctl disable schlechter-service
sudo systemctl mask schlechter-service  # stärker: kann nicht gestartet werden

sudo reboot

# Problem analysieren und lösen, dann wieder aktivieren
sudo systemctl unmask schlechter-service
sudo systemctl enable schlechter-service

Fazit

Die meisten Boot-Probleme sind lösbar – selbst ohne Backup, wenn man die richtigen Werkzeuge kennt:

• Recovery Mode (Ubuntu/Debian): einfachster Zugang zur Root-Shell
• GRUB-Kommandozeile: manuelles Booten wenn GRUB-Config kaputt
• Live-USB + chroot: universelle Rettungslösung für alle Situationen
• nomodeset: löst die meisten Grafik-Boot-Probleme
• fsck: repariert Dateisystem-Fehler

Vorbeugung ist besser als Heilung: Regelmäßige Backups mit Timeshift und rsync sparen im Ernstfall Stunden. Teste Kernel-Updates immer zuerst auf nicht-kritischen Systemen.