Freigeben über

Virtueller Linux-Computer startet mit GRUB-Rettung

  • Artikel

Gilt für: ✔️ Linux-VMs

Notiz

CentOS, auf das in diesem Artikel verwiesen wird, ist eine Linux-Verteilung und wird End Of Life (EOL) erreichen. Sie sollten sich Ihre Nutzung dieser Distribution ansehen und entsprechend planen. Weitere Informationen finden Sie unter CentOS End Of Life Guidance.

Dieser Artikel behandelt mehrere Bedingungen, die Probleme mit der GRUB-Rettung verursachen, und bietet Anleitungen zur Fehlerbehebung.

Während des Bootvorgangs versucht der Bootloader, den Linux-Kernel zu finden und die Bootkontrolle abzugeben. Wenn diese Übergabe nicht durchgeführt werden kann, ruft der virtuelle Computer (VM) eine GRUB-Rettungskonsole auf. Die Eingabeaufforderung der GRUB-Rettungskonsole wird nicht im Protokoll der seriellen Azure-Konsole angezeigt, kann aber im Azure-Boot-Diagnose-Screenshot angezeigt werden.

Identifizieren des GRUB-Rettungsproblems

Sehen Sie sich einen Screenshot der Boot-Diagnose auf der VM-Seite Boot-Diagnose des Azure-Portals an. Dieser Screenshot hilft, das GRUB-Rettungsproblem zu diagnostizieren und um festzustellen, ob ein Bootfehler das Problem verursacht.

Der folgende Text ist ein Beispiel für ein GRUB-Rettungsproblem:

error: file '/boot/grub2/i386-pc/normal.mod' not found.  
Entering rescue mode...  
grub rescue>

Offline-Behebung von GRUB-Rettungsproblemen

  1. Um ein Problem bei der GRUB-Rettung zu beheben, ist eine VM zur Rettung/Reparatur erforderlich. Verwenden Sie VM-Reparaturbefehle, um eine Reparatur-VM zu erstellen, an die eine Kopie des Betriebssystemdatenträgers der betroffenen VM angehängt ist. Mounten Sie die Kopie der OS-Dateisysteme in der Reparatur-VM mithilfe von chroot.

    Notiz

    Alternativ können Sie mithilfe des Azure-Portals manuell eine Rettungs-VM erstellen. Weitere Informationen finden Sie unter Beheben von Problemen mit einer Linux-VM durch Hinzufügen des Betriebssystemdatenträgers zu einer Wiederherstellungs-VM im Azure-Portal.

  2. Identifizieren eines GRUB-Rettungsproblems. Wenn Sie auf eines der folgenden Probleme bei der GRUB-Rettung stoßen, gehen Sie zum entsprechenden Abschnitt, um es zu beheben:

  3. Nachdem das Problem mit der GRUB-Rettung behoben wurde, führen Sie die folgenden Aktionen durch:

    1. Entfernen Sie die Kopie der Dateisysteme von der Rettungs-/Reparatur-VM.

    2. Führen Sie den Befehl az vm repair restore aus, um den reparierten Betriebssystemdatenträger durch den ursprünglichen Betriebssystemdatenträger der VM auszutauschen. Weitere Informationen finden Sie unter Schritt 5 in Reparieren eines virtuellen Linux-Computers mit dem Reparaturbefehlen virtueller Azure-Computer.

    3. Überprüfen Sie, ob die VM gestartet werden kann, indem Sie einen Blick auf die serielle Azure-Konsole werfen oder versuchen, eine Verbindung zur VM herzustellen.

  4. Wenn die gesamte /boot-Partition oder andere wichtige Inhalte fehlen und nicht wiederhergestellt werden können, empfehlen wir, die VM aus einer Sicherungskopie wiederherzustellen. Weitere Informationen finden Sie unter Wiederherstellen von Azure-VM-Daten im Azure-Portal.

Weitere Informationen zu Fehlern, möglichen Ursachen und Lösungen finden Sie in den folgenden Abschnitten.

Notiz

Ersetzen Sie in den in den folgenden Abschnitten genannten Befehlen /dev/sdX durch den entsprechenden Datenträger für das Betriebssystem (OS).

Fehler: unbekanntes Dateisystem

Der folgende Screenshot zeigt die Fehlermeldung:

Screenshot von „GRUB unbekannter Dateisystemfehler“.

Dieser Fehler kann durch eines der folgenden Probleme verursacht werden:

Beheben einer Beschädigung des /boot-Dateisystems

  1. Überprüfen Sie, ob eine Rettungs-/Reparatur-VM erstellt wurde. Wenn sie nicht erstellt wurde, folgen Sie Schritt 1 in Offline-Fehlerbehebung für GRUB-Rettungsprobleme, um die VM zu erstellen.

  2. Siehe Fehlerbehebung bei Dateisystemfehler in Azure Linux, um die Fehler in der entsprechenden /boot-Partition zu beheben.

  3. Fahren Sie mit Schritt 3 in Offline-Fehlerbehebung von GRUB-Rettungsproblemen fort, um den Betriebssystemdatenträger auszutauschen.

GRUB neu installieren und GRUB-Konfigurationsdatei neu generieren

  1. Überprüfen Sie, ob eine Rettungs-/Reparatur-VM erstellt wurde. Wenn sie nicht erstellt wurde, folgen Sie Schritt 1 in Offline-Fehlerbehebung für GRUB-Rettungsprobleme, um die VM zu erstellen. Binden Sie alle erforderlichen Dateisysteme, einschließlich / und /boot, in die Rettungs-/Reparatur-VM ein und geben Sie dann chroot ein.

  2. Installieren Sie GRUB neu und generieren Sie die entsprechende GRUB-Konfigurationsdatei erneut mit einem der folgenden Befehle:

    • RHEL/CentOS/Oracle 7.x/8.x/9.x Linux-VMs ohne UEFI (BIOS-basiert - Gen1)

      grub2-install /dev/sdX
grub2-mkconfig -o /boot/grub2/grub.cfg
sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg

    • RHEL/CentOS/Oracle 7.x/8.x/9.x Linux-VMs mit UEFI (Gen2)

      yum reinstall grub2-efi-x64 shim-x64
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
sed -i 's/hd2/hd0/g' /boot/efi/EFI/redhat/grub.cfg

      Wenn der virtuelle Computer CentOS ausführt, ersetzen Sie redhat den absoluten Pfad /boot/efi/EFI/centos/grub.cfg durch centos den absoluten Pfad "grub.cfg".

    • SLES 12/15 Gen1 und Gen2

      grub2-install /dev/sdX
grub2-mkconfig -o /boot/grub2/grub.cfg
sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg

    • Ubuntu 20.04/22.04/24.04

      grub-install /dev/sdX
update-grub

  3. Fahren Sie mit Schritt 3 in Offline-Fehlerbehebung von GRUB-Rettungsproblemen fort, um den Betriebssystemdatenträger auszutauschen.

Fehler 15: Datei wurde nicht gefunden

Der folgende Screenshot zeigt die Fehlermeldung:

Screenshot des Grub-Fehlers 15 „Datei wurde nicht gefunden“.

Gehen Sie folgendermaßen vor, um das Problem zu beheben:

  1. Überprüfen Sie, ob eine Rettungs-/Reparatur-VM erstellt wurde. Wenn sie nicht erstellt wurde, folgen Sie Schritt 1 in Offline-Fehlerbehebung für GRUB-Rettungsprobleme, um die VM zu erstellen. Mounten Sie alle erforderlichen Dateisysteme, einschließlich / und /boot, in die Rettungs-/Reparatur-VM und führen Sie dann chroot aus.

  2. Überprüfen Sie den Inhalt des /boot-Dateisystems und stellen Sie fest, was fehlt.

  3. Wenn die GRUB-Konfigurationsdatei fehlt, installieren Sie GRUB neu und generieren Sie die GRUB-Konfigurationsdatei erneut.

  4. Überprüfen Sie, ob die Dateiberechtigungen im /boot-Dateisystem korrekt sind. Sie können die Berechtigungen mit einer anderen VM vergleichen, auf der die gleiche Linux-Version läuft.

  5. Wenn die gesamte /boot-Partition oder andere wichtige Inhalte fehlen und nicht wiederhergestellt werden können, empfehlen wir, die VM aus einer Sicherungskopie wiederherzustellen. Weitere Informationen finden Sie unter Wiederherstellen von Azure-VM-Daten im Azure-Portal.

  6. Wenn das Problem behoben ist, gehen Sie zu Schritt 3 in Offline-Problembehandlung für GRUB-Rettungsprobleme, um den Betriebssystemdatenträger auszutauschen.

Fehler: Datei '/boot/grub2/i386-pc/normal.mod' wurde nicht gefunden

Der folgende Screenshot zeigt die Fehlermeldung:

Screenshot des Grub-Fehlers „normal.mod wurde nicht gefunden“.

  1. Überprüfen Sie, ob eine Rettungs-/Reparatur-VM erstellt wurde. Wenn sie nicht erstellt wurde, folgen Sie Schritt 1 in Offline-Fehlerbehebung für GRUB-Rettungsprobleme, um eine zu erstellen. Binden Sie alle erforderlichen Dateisysteme, einschließlich / und /boot, in die Rettungs-/Reparatur-VM ein und geben Sie dann chroot ein.

  2. Wenn Sie das /boot-Dateisystem aufgrund eines Korruptionsfehlers nicht einbinden können, beheben Sie die Korruption des /boot-Dateisystems.

  3. Wenn Sie sich in chroot befinden, überprüfen Sie den Inhalt des Verzeichnisses /boot/grub2/i386-pc. Wenn der Inhalt fehlt, kopieren Sie diesen aus /usr/lib/grub/i386-pc. Führen Sie zu diesem Zweck die folgenden Befehle aus:

    ls -l /boot/grub2/i386-pc
cp -rp /usr/lib/grub/i386-pc /boot/grub2

  4. Wenn der Inhalt der /boot Partition leer ist, verwenden Sie die folgenden Befehle, um sie erneut zu erstellen:

    Notiz

    Die folgenden Schritte gelten für RHEL/CentOS/Oracle 7.x/8.x Linux-VMs ohne UEFI (BIOS-basiert - Gen1).

    1. Installieren Sie unter dem Chroot-Prozess die Grub erneut. Ersetzen Sie /dev/sd[X] entsprechend durch die entsprechende Kopie des Betriebssystemdatenträgers, der an die Reparatur-/Rettungs-VM angefügt ist:

      grub2-install /dev/sd[X]

    2. Stellen Sie sicher, dass /etc/resolv.conf ein gültiger DNS-Eintrag vorhanden ist, um den Namen des Repositorys aufzulösen:

      cat /etc/resolv.conf

    3. Installieren Sie den Kernel neu:

      yum reinstall $(rpm -qa | grep -i kernel)

    4. Erstellen Sie die Datei grub.cfg :

      grub2-mkconfig -o /boot/grub2/grub.cfg
sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg

  5. Fahren Sie mit Schritt 3 in Offline-Behebung von GRUB-Rettungsproblemen fort, um den Betriebssystemdatenträger auszutauschen.

Fehler: Keine solche Partition

Der folgende Screenshot zeigt die Fehlermeldung:

Screenshot des Grub-Fehlers „Keine solche Partition“.

Dieser Fehler tritt bei einer RHEL-basierten VM (Red Hat, Oracle Linux, CentOS) in einem der folgenden Szenarien auf:

  • Die /boot-Partition wurde versehentlich gelöscht.
  • Die /boot-Partition wird unter Verwendung der falschen Start- und Endsektoren neu erstellt.

Lösung: Erstellen Sie die /boot-Partition neu

Wenn die /boot-Partition fehlt, erstellen Sie sie neu, indem Sie diese Schritte ausführen:

  1. Überprüfen Sie, ob eine Rettungs-/Reparatur-VM erstellt wurde. Wenn sie nicht erstellt wurde, folgen Sie Schritt 1 in Offline-Fehlerbehebung für GRUB-Rettungsprobleme, um die VM zu erstellen.

  2. Stellen Sie mit dem folgenden Befehl fest, ob die Partitionstabelle als Typ DOS oder GPT erstellt wurde:

    sudo fdisk -l /dev/sdX

    • DOS-Partitionstabelle

      Screenshot zeigt das Booten mit DOS-Partitionstabelle

    • GPT-Partitionstabelle

      Screenshot zeigt das Booten mit GPT-Partitionstabelle.

  3. Wenn die Partitionstabelle DOS als Partitionstabellentyp hat, erstellen Sie die /boot-Partition in DOS-Systemen neu. Wenn die Partitionstabelle GPT als Partitionstabellentyp hat, erstellen Sie die /boot-Partition in GPT-Systemen neu.

  4. Stellen Sie sicher, dass der GRUB-Bootloader mit dem richtigen Datenträger installiert ist. Sie können die Schritte in GRUB neu installieren und GRUB-Konfigurationsdatei neu generieren befolgen, um diese zu installieren und zu konfigurieren.

  5. Fahren Sie mit Schritt 3 in Offline-Behebung von GRUB-Rettungsproblemen fort, um den Betriebssystemdatenträger auszutauschen.

Neuerstellen der /boot-Partition in DOS-Systemen

  1. Erstellen Sie die /boot-Partition mit dem folgenden Befehl neu:

    sudo fdisk /dev/sdX

    Verwenden Sie die Standardwerte für den Ersten und Letzten Sektor und Partitionstyp (83). Stellen Sie sicher, dass die /boot-Partitionstabelle als bootfähig markiert ist, indem Sie die Option a im Tool fdisk verwenden, wie in der folgenden Ausgabe gezeigt:

    sudo fdisk /dev/sdc

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Partition number (1,3,4, default 1): 1
First sector (2048-134217727, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-2099199, default 2099199):
Using default value 2099199
Partition 1 of type Linux and of size 1 GiB is set

Command (m for help): t
Partition number (1,2, default 2): 1
Hex code (type L to list all codes): 83
Changed type of partition 'Linux' to 'Linux'

Command (m for help): a
Partition number (1,2, default 2): 1

Command (m for help): p

Disk /dev/sdc: 68.7 GB, 68719476736 bytes, 134217728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Disk identifier: 0x000b7179

Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *        2048     2099199     1048576   83  Linux
/dev/sdc2         2099200   134217727    66059264   8e  Linux LVM

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

  2. Nachdem Sie die fehlende /boot-Partition neu erstellt haben, überprüfen Sie, ob das /boot-Dateisystem erkannt wird. Sie sollten einen Eintrag für /dev/sdX1 (die fehlende /boot-Partition) sehen können.

    sudo blkid /dev/sdX1

    sudo blkid /dev/sdc1
/dev/sdc1: UUID="<UUID>" TYPE="ext4"

  3. Wenn das /boot-Dateisystem in blkid nicht sichtbar ist, nachdem Sie die Partition neu erstellt haben, bedeutet dies, dass die /boot-Daten nicht mehr existieren. Sie müssen das /boot-Dateisystem neu erstellen (indem Sie dieselbe UUID und dasselbe Dateisystemformat verwenden, das im /etc/fstab /boot-Eintrag enthalten ist) und dann den Inhalt aus einem Backup wiederherstellen.

Neuerstellen der /boot-Partition in GPT-Systemen

  1. Erstellen Sie die /boot-Partition mit dem folgenden Befehl neu:

    sudo gdisk /dev/sdX

    Verwenden Sie die Standardwerte für den Ersten und Letzten Sektor und Partitionstyp (8300), wie in der folgenden Abbildung gezeigt:

    sudo gdisk /dev/sdc
GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): n
Partition number (1-128, default 1): 1
First sector (34-134217694, default = 1026048) or {+-}size{KMGTP}:
Last sector (1026048-2050047, default = 2050047) or {+-}size{KMGTP}:
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'

Command (? for help): p
Disk /dev/sdc: 134217728 sectors, 64.0 GiB
Model: Virtual Disk
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 6D915856-445A-4513-97E4-C55F2E1AD6C0
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 134217694
Partitions will be aligned on 2048-sector boundaries
Total free space is 6076 sectors (3.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1         1026048         2050047   500.0 MiB   8300  Linux filesystem
   2         2050048       134215679   63.0 GiB    8E00
  14            2048           10239   4.0 MiB     EF02
  15           10240         1024000   495.0 MiB   EF00  EFI System Partition

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sdc.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.

  2. Prüfen Sie mit dem folgenden Befehl, ob das /boot-Dateisystem vom System erkannt wurde:

    sudo blkid /dev/sdX1

    Sie sollten einen Eintrag für /dev/sdX1 (die fehlende /boot-Partition) sehen können.

    sudo blkid /dev/sdc1
/dev/sdc1: UUID="<UUID>" BLOCK_SIZE="4096" TYPE="xfs" PARTLABEL="Linux filesystem" PARTUUID="<PARTUUID>"

  3. Wenn das /boot-Dateisystem nach dem Neuerstellen der Partition nicht sichtbar ist, bedeutet dies, dass die /boot-Daten nicht mehr existieren. Sie müssen das /boot-Dateisystem neu erstellen (indem Sie dieselbe UUID verwenden, die im /etc/fstab /boot-Eintrag steht) und dann den Inhalt aus einem Backup wiederherstellen.

Fehler: Symbol „grub_efi_get_secure_boot“ nicht gefunden

Der folgende Screenshot zeigt die Fehlermeldung:

Screenshot des Grub-Fehlers „grub_efi_get_secure_boot“ nicht gefunden.

Die Linux-Kernel-Version 4.12.14 (die in SLES 12 SP5 verwendet wird) unterstützt die Option Sicherer Start nicht. Wenn daher bei der Bereitstellung der VM der sichere Start aktiviert ist (d. h. das Feld Sicherheitstyp ist auf Vertrauter Start virtueller Maschinen gesetzt), erzeugt die virtuelle Maschine über die Konsole den Fehler „Sicherer Start“, wenn Sie versuchen, mit dieser SUSE-Kernelversion auf einem Gen2-VM-Image zu starten.

Lösung

Gehen Sie folgendermaßen vor, um den Boot-Fehler zu beheben:

  1. Überprüfen Sie, ob eine Rettungs-/Reparatur-VM erstellt wurde. Wenn sie nicht erstellt wurde, folgen Sie Schritt 1 in Offline-Fehlerbehebung für GRUB-Rettungsprobleme, um die VM zu erstellen. Mounten Sie alle erforderlichen Dateisysteme einschließlich / und /boot und führen Sie dann chroot aus.

  2. Führen Sie den folgenden YaST-Befehl in der chroot-Umgebung aus:

    yast2 bootloader

  3. Löschen Sie das „x“ aus der Option Unterstützung für sicheren Start aktivieren und wählen Sie dann F10 aus, um die Änderung zu speichern.

    Screenshot der YaST2-Bootloader-Einstellungen in der SUSE-Konsole.

  4. Führen Sie Schritt 3 in Offline-Problembehandlung bei GRUB-Rettungsproblemen aus, um die Betriebssystemplatte auszutauschen.

Andere GRUB-Rettungsfehler

Der folgende Screenshot zeigt die Fehlermeldung:

Screenshot eines weiteren Grub-Rettungsproblems.

Diese Art von Fehler wird in einem der folgenden Szenarien ausgelöst:

  • Die GRUB-Konfigurationsdatei fehlt.
  • Es wird die falsche GRUB-Konfiguration verwendet.
  • Die /boot-Partition oder deren Inhalt fehlt.

Um diesen Fehler zu beheben, führen Sie folgende Schritte aus:

  1. Überprüfen Sie, ob eine Rettungs-/Reparatur-VM erstellt wurde. Wenn sie nicht erstellt wurde, folgen Sie Schritt 1 in Offline-Fehlerbehebung für GRUB-Rettungsprobleme, um die VM zu erstellen. Mounten Sie alle erforderlichen Dateisysteme einschließlich / und /boot und führen Sie dann chroot aus.

  2. Stellen Sie sicher, dass die Konfigurationsdatei /etc/default/grub konfiguriert ist. Die unterstützten Azure Linux-Images verfügen bereits über die erforderlichen Konfigurationen. Weitere Informationen finden Sie in den folgenden Artikeln:

  3. Installieren Sie GRUB neu und generieren Sie die GRUB-Konfigurationsdatei erneut.

    Notiz

    Wenn die Datei /boot/grub/menu.lst fehlt, gilt dieser Fehler für ältere Betriebssystemversionen (RHEL 6.x, Centos 6.x und Ubuntu 14.04). Die Befehle unterscheiden sich, da in diesen Systemen die GRUB-Version 1 verwendet wird. GRUB Version 1 wird in diesem Artikel nicht behandelt.

  4. Wenn die gesamte /boot-Partition fehlt, folgen Sie den Schritten im Artikel Fehler: Keine solche Partition.

  5. Wenn das Problem behoben ist, gehen Sie zu Schritt 3 in Offline-Problembehandlung für GRUB-Rettungsprobleme, um den Betriebssystemdatenträger auszutauschen.

Nächste Schritte

Wenn es sich bei dem spezifischen Bootfehler nicht um ein GRUB-Rettungsproblem handelt, finden Sie unter Problembehandlung bei Bootfehlern von virtuellen Linux-Computers weitere Optionen zur Problembehandlung.

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Die Kontaktinformationen zu den in diesem Artikel erwähnten Drittanbietern sollen Ihnen helfen, zusätzliche Informationen zu diesem Thema zu finden. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Sie werden von Microsoft ohne jede Gewähr weitergegeben.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.