Boot, GRUB und systemd-boot

GRUB-Rescue findet sein Normal-Modul nicht

GRUB-Rescue bedeutet oft einen ungültigen Prefix zu lesbaren Modulen; GRUB-eigene Geräteansicht vor einer dauerhaften Neuinstallation 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 ö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.

set

Ergebnis 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.

ls

Ergebnis 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?

Hinweis teilen#

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?

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.