Symptome und Geltungsbereich
- Der Start öffnet grub rescue> statt normalem Menü.
- Eine Meldung nennt fehlenden normal.mod-Pfad.
Betroffene Umgebung
GNU-GRUB-Rescue-Prompt vor Linux-Kernelstart, nach Partitionsverschiebung, gelöschten Boot-Dateien oder inkonsistenten GRUB-Komponenten.
Erkennbare Meldungen (synthetische Beispiele)
error: file '/boot/grub/x86_64-efi/normal.mod' not found.GRUB-root/prefix und Dateisystemsichtbarkeit prüfen; enges Muster ordnet nicht jeden allgemeinen unknown-filesystem-Fehler zu.
Mögliche Ursachen
Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.
- Eingebetteter Prefix kann auf falsche Partition oder Verzeichnis zeigen.
- Richtiges Dateisystem kann unlesbar sein oder benötigte GRUB-Module fehlen; Rescue-Prompt allein bedeutet keinen Verlust der Linux-Daten.
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
Diese lesende Form am GRUB-Rescue-Prompt statt Linux-Shell ausführen. Ohne Zuweisung listet sie GRUB-Variablen.
setErgebnis einordnen: root und prefix exakt festhalten. GRUB-Gerätenamen wie (hd0,gpt2) sind nicht mit Linux-/dev-Namen austauschbar.
Prüfschritt 2
Am GRUB-Rescue-Prompt ohne Ziel ausführen; sichtbare Geräte werden ohne Mount oder Reparatur aufgelistet.
lsErgebnis einordnen: Vorhandene Partitionen mit root/prefix vergleichen. Gezieltes ls auf verifizierter Partition kann Verzeichnisse prüfen; lesbare Partition ist nicht automatisch vorgesehenes /boot.
Nächste Schritte nach Befund
Verifizierten Prefix für einen Start wiederherstellen
Findet Prüfung richtiges GRUB-Modulverzeichnis, GNU-Rescue-Verfahren nutzen: root/prefix auf verifizierten Ort setzen, normal laden und Menü erreichen. Sitzungsänderungen ermöglichen Wiederherstellung ohne vorheriges Umschreiben von Boot-Strukturen.
Vorsicht: Beispiel-Plattennummern nicht kopieren. Secure-Boot-Builds können Modulladen einschränken; bei Bedarf signierten Rettungsweg der Distribution nutzen.
Wiederherstellung / Rücknahme: Neustart verwirft Rescue-Sitzungsvariablen. Ursprüngliche Werte dokumentiert und passendes Rettungsmedium bereit halten.
Hat dir dieser Hinweis geholfen?
Installierte GRUB-Komponenten konsistent reparieren
Nach Erreichen von Linux oder korrekt eingehängter Rettungsumgebung bestehende GRUB-Variante der Distribution neu installieren und Konfiguration für verifizierten Firmware-Modus sowie Boot-Ziel erneuern. Tatsächlich eingehängtes /boot und ESP prüfen.
Vorsicht: grub-install nicht gegen geratene ganze Platte ausführen und signierte shim-Kette nicht durch unsignierten Lader ersetzen. Funktionierenden alternativen Eintrag behalten.
Wiederherstellung / Rücknahme: Bei fehlerhaft repariertem Pfad gesicherte Boot-Dateien/Konfiguration per Distributions-Rettungsverfahren wiederherstellen oder erhaltenen Alternativ-Eintrag wählen.
Hat dir dieser Hinweis geholfen?
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.
- GNU GRUB: GRUB only offers a rescue shell (Projekt- oder Distributionsdokumentation)
- System76: repairing GRUB boot components (Projekt- oder Distributionsdokumentation)
- LFS: GRUB partition-relative paths and recoverable boot configuration (Projekt- oder Distributionsdokumentation)