Landet dein Linux-Server beim Start in der Notfallkonsole (initramfs), kann er seine Root-Partition nicht einhängen. Meist ist das Dateisystem inkonsistent, zum Beispiel nach dem Einspielen eines Backups oder einem harten Stop. Das reparierst du in fast allen Fällen selbst mit fsck: direkt in der initramfs-Konsole über VNC oder bequemer im Rescue-System.

Woran du es erkennst

  • Per SSH kommst du nicht mehr auf den Server, weil das System gar nicht bis zum SSH-Dienst startet.
  • In der VNC-Konsole steht am Ende die Eingabezeile (initramfs).
  • Darüber stehen Meldungen wie UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY, /dev/vda1 contains a file system with errors oder Gave up waiting for root file system device.
  • Ein mount /dev/vda1 in der Konsole schlägt fehl, obwohl Partition und UUID stimmen.

Siehst du dagegen You are in emergency mode, hat das System die Root-Partition schon eingehängt. Dann hakt es meist an einem anderen Eintrag in /etc/fstab. Den korrigierst du wie im Rescue-System beschrieben.

Warum das nach einem Backup passieren kann

Unsere Backups entstehen im laufenden Betrieb, damit dein Server währenddessen nutzbar bleibt. Schreibt das System gerade viel, etwa eine Datenbank, entspricht das Abbild ungefähr dem Zustand nach einem Stromausfall. Das Journal von ext4 fängt das fast immer ab. In seltenen Fällen bleibt eine Inkonsistenz, und Debian oder Ubuntu weigern sich beim Start, die Partition ohne Prüfung einzuhängen. Das ist Absicht: Lieber anhalten als ein beschädigtes Dateisystem weiter beschreiben.

Dasselbe kann nach einem harten Stop passieren, zum Beispiel wenn der Server während eines Updates gestoppt wurde.

Weg 1: fsck direkt in der initramfs-Konsole

Der schnellste Weg, wenn nur wenige Fehler vorliegen.

  1. VNC im Cloud Manager unter „Aktionen“, „VPS-Einstellungen“, Reiter „VNC“ aktivieren. Danach einmal Stop und Start im Webinterface. Details in Wie kann ich mich per VNC verbinden?
  2. „NoVNC (Web-VNC) öffnen“ und warten, bis die Eingabezeile (initramfs) erscheint.
  3. Den Befehl aus der Fehlermeldung ausführen. Meist ist es diese Partition:
fsck -f -y /dev/vda1

-f erzwingt eine vollständige Prüfung, -y beantwortet alle Reparaturfragen mit Ja. Läuft der Befehl durch, startest du mit

exit

den normalen Bootvorgang. Klappt das nicht, hilft ein Stop und Start im Webinterface. Schalte VNC danach wieder aus.

Kommen in der VNC-Konsole Zeichen wie / oder - falsch an, liegt das am Tastaturlayout. Dann nimm lieber Weg 2, dort arbeitest du per SSH und kannst Befehle einfügen.

Weg 2: fsck im Rescue-System

Der zuverlässigere Weg bei vielen Fehlern: Du arbeitest per SSH, siehst die komplette Ausgabe und kannst sie kopieren.

  1. Im Cloud Manager unter „Aktionen“ im Bereich „Backups und Wiederherstellung“ auf „Rescue Modus aktivieren“ klicken und bestätigen. Die Anleitung mit Bildern steht in Wie nutze ich das VPS Rescue-System?
  2. Per SSH als root auf die angezeigte IP-Adresse verbinden.
  3. Deine Festplatte suchen:
lsblk -f

Wichtig: Im Rescue-System heißt deine Platte nicht mehr vda. Die Platte, die unter / eingehängt ist, gehört dem Rescue-System. Deine ist die andere, nicht eingehängte, zum Beispiel /dev/vdb. Deine Systempartition ist dann meist /dev/vdb1.

  1. Dateisystem prüfen und reparieren:
fsck -f /dev/vdb1

Reparaturvorschläge bestätigst du mit y. Bei sehr vielen Fragen hängst du -y an. Lass fsck so oft laufen, bis keine Fehler mehr gemeldet werden.

  1. Rescue-Modus im selben Dialog im Cloud Manager deaktivieren. Der Server startet wieder von seiner eigenen Platte.

Prüfe nie eine eingehängte Partition. Hast du deine Platte vorher schon unter /mnt eingehängt, hängst du sie mit umount /mnt zuerst aus.

Häufige Stolpersteine

  • „Checkdisk“ im Webinterface zeigt nichts an: Das ist normal. Die Funktion arbeitet best effort und gibt keine Ausgabe zurück. Hilft sie nicht, nimm einen der beiden Wege oben. Mehr zur Funktion in Wie kann ich einen CHKDSK durchführen?
  • mount meldet „wrong fs type“ oder „bad superblock“: Das passt zu einem beschädigten Dateisystem. Erst fsck, dann mounten.
  • fsck findet den Superblock nicht: ext4 hat Sicherungskopien. Deren Positionen zeigt dir dumpe2fs /dev/vdb1 | grep -i superblock, danach prüfst du mit einer davon, zum Beispiel e2fsck -f -b 32768 /dev/vdb1.
  • Dateien fehlen nach der Reparatur: Was fsck nicht mehr zuordnen kann, landet in /lost+found. Schau dort nach, bevor du etwas neu anlegst.
  • Kein ext4: Nutzt du XFS, heißt das Werkzeug xfs_repair. Welches Dateisystem du hast, zeigt lsblk -f in der Spalte FSTYPE.
  • Weiter Ärger nach einem frischen Restore: Spiel ein anderes Backup ein, am besten eines, das zu einer ruhigen Zeit entstanden ist. Siehe Wie spiele ich ein Backup wieder ein? Vorher sicherst du neue Daten über das Rescue-System.

So vermeidest du es beim nächsten Mal

Planst du eine größere Änderung, stoppe vor dem manuellen „Backup erstellen“ die Dienste, die viel schreiben, zum Beispiel deine Datenbank. Für einen schnellen Rückweg in den nächsten Stunden eignet sich außerdem ein Snapshot.

Wenn nichts hilft

Meldet fsck Fehler, die es nicht beheben kann, oder landet der Server weiter im initramfs, schreib uns ein Ticket. Häng die vollständige Ausgabe von fsck und einen Screenshot der Meldung aus der VNC-Konsole an. Funktioniert VNC oder das Rescue-System selbst nicht, liegt der Fehler bei uns, und wir helfen sofort.