Boot, GRUB und systemd-boot

Initramfs findet konfigurierte Root-UUID nicht

Eine frühe Shell mit fehlender Root-UUID kann falsche Kennung, ungeöffneten Container oder fehlende Speichertreiber bedeuten; Schichten der Reihe nach prüfen.

Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • Der Start wartet auf Root-Dateisystem und öffnet dann Initramfs-/Notfall-Shell.
  • Die konfigurierte UUID fehlt in der frühen Geräteansicht.

Betroffene Umgebung

Früher Linux-Userspace mit initramfs-tools, dracut oder systemd-Initrd sowie root=UUID=... oder anderer dauerhafter Root-Gerätekennung.

Erkennbare Meldungen (synthetische Beispiele)
ALERT! UUID=11111111-2222-3333-4444-555555555555 does not exist. Dropping to a shell!

Kennung und darunterliegende Speicherschichten prüfen; Fehlen in dieser Umgebung bedeutet kein gelöschtes Dateisystem.

dracut-initqueue[400]: Warning: /dev/disk/by-uuid/11111111-2222-3333-4444-555555555555 does not exist

Befehlszeile und Elternschichten vor Abbild-Neubau oder Änderung von Dateisystemkennungen prüfen.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

  • Ein neu formatiertes, geklontes oder verschobenes Dateisystem kann andere Kennung haben.
  • Physischer Controller, Verschlüsselungsschicht oder LVM-Aktivierung können im Abbild fehlen; eine korrekte UUID kann dennoch unsichtbar sein.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Boot-Argumente aus gescheiterter früher Umgebung oder wiederhergestelltem Start lesen. Dies ändert den Bootloader nicht.

cat /proc/cmdline

Ergebnis einordnen: root= und relevante rd.luks-/rd.lvm-Selektoren festhalten. LUKS-Container-UUID unterscheidet sich von Dateisystem-UUID innerhalb geöffneter Zuordnung.

Prüfschritt 2

Vorhandene Blockgeräteschichten und Dateisystemkennungen lesen. Kleine Initramfs kann lsblk nicht enthalten; dann Distributions-Rettungsumgebung nutzen.

lsblk -f

Ergebnis einordnen: Gewolltes Root-Dateisystem seiner Elternkette statt erster linuxartig aussehender Partition zuordnen. Fehlende untere Schichten sprechen für Erkennung/Entsperren/Aktivierung vor UUID-Korrektur.

Nächste Schritte nach Befund

Verifizierten Root-Geräteselektor korrigieren

Ist vorgesehenes Root mit anderer verifizierter UUID sichtbar, korrigierten root=-Wert über Boot-Menü-Editor für einen Start testen. Nach Bestätigung Quellkonfiguration der Distribution aktualisieren und Einträge erneuern.

Vorsicht: Platten-UUID nicht lediglich zum Anpassen an altes Argument ändern. Dateisysteminhalt und gegebenenfalls Subvolume-rootflags vor Auswahl bestätigen.

Wiederherstellung / Rücknahme: Temporäre Änderung verwerfen oder unveränderten älteren Eintrag starten; bei fehlerhafter Daueränderung gesicherte Quellkonfiguration zurückstellen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Fehlende frühe Boot-Schicht wiederherstellen

Ist Root-UUID korrekt, fehlt aber Elterngerät, unterstützten Speichertreiber oder benötigtes Verschlüsselungs-/LVM-Modul über Distributionstools in Initramfs des gewählten Kernels aufnehmen. Nach Korrektur zugehöriger Erkennungsselektoren neu erzeugen.

Vorsicht: Altes Kernel-/Abbildpaar behalten sowie echte Boot-Partition und freien Platz prüfen. Neuformatieren repariert keine Erkennung.

Wiederherstellung / Rücknahme: Bei fehlender Root-Erkennung vorhandenes Abbild oder Rettungsmedium wählen und vorherige frühe Boot-Konfiguration zurückstellen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.