Virtuelle Linux-Maschine startet im GRUB Rescue-Modus

Gilt für: ✔️ Linux-VMs

Zusammenfassung

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 GRUB-Rettungskonsolenaufforderung wird nicht im Azure seriellen Konsolenprotokoll angezeigt, kann aber im Screenshot der Azure Startdiagnose angezeigt werden.

GRUB-Rettungsproblem identifizieren

Zeigen Sie einen Screenshot der Startdiagnose auf der Seite Startdiagnosen der VM im Azure-Portal 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>

GRUB-Rettungsproblem offline beheben

1. Um ein GRUB-Rettungsproblem zu beheben, wird eine Rettungs- oder Reparatur-VM benötigt. 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.

   Hinweis

   Alternativ können Sie einen virtuellen Rettungscomputer manuell mithilfe des Azure Portals erstellen. Weitere Informationen finden Sie unter Beheben von Problemen mit einer Linux-VM durch Anfügen der Betriebssystemfestplatte an eine Wiederherstellungs-VM mithilfe des Azure-Portals.

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

   • Fehler: unbekanntes Dateisystem
   • Fehler 15: Datei nicht gefunden
   • Fehler: Datei '/boot/grub2/i386-pc/normal.mod' nicht gefunden
   • Fehler: keine solche Partition
   • Fehler: Symbol „grub_efi_get_secure_boot“ nicht gefunden
   • Sonstige GRUB-Rettungsfehler

3. Nachdem das Problem mit der GRUB-Rettung behoben wurde, führen Sie die folgenden Schritte 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 in Schritt 5 in Reparatur einer Linux-VM mithilfe der Reparaturbefehle für Azure-VMs.

   3. Überprüfen Sie, ob der virtuelle Computer gestartet werden kann, indem Sie sich die serielle Azure Konsole ansehen oder versuchen, eine Verbindung mit der VM herzustellen.

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

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

Installieren Sie GRUB erneut, und regenerieren Sie die GRUB-Konfigurationsdatei mit Azure Linux Auto Repair

Azure Linux Auto Repair (ALAR)-Skripts sind Teil der vm-Reparaturerweiterung, die in Use Azure Linux Auto Repair (ALAR) zum Beheben einer Linux-VM beschrieben wird. ALAR deckt die Automatisierung mehrerer Reparaturszenarien ab, einschließlich GRUB-Rettungsproblemen.

Die ALAR-Skripte verwenden die Reparaturerweiterung repair-button, um GRUB-Probleme zu beheben, indem sie --button-command grubfix für VMs der Generation 1 oder --button-command efifix für VMs der Generation 2 angeben. Dieser Parameter löst die automatisierte Wiederherstellung aus. Implementieren Sie die folgenden Befehle, um die Behebung allgemeiner GRUB-Fehler zu automatisieren, indem Sie GRUB erneut installieren und die entsprechende Konfigurationsdatei neu generieren:

• Linux-VMs ohne UEFI (BIOS-basiert - Gen1):

  az extension add -n vm-repair
  az extension update -n vm-repair
  az vm repair repair-button --button-command 'grubfix' --verbose $RGNAME --name $VMNAME
  

• Linux-VMs mit UEFI (Gen2):

  az extension add -n vm-repair
  az extension update -n vm-repair
  az vm repair repair-button --button-command 'efifix' --verbose $RGNAME --name $VMNAME
  

Das Reparatur-VM-Skript in Verbindung mit dem ALAR-Skript erstellt vorübergehend eine Ressourcengruppe, eine Reparatur-VM und eine Kopie des Betriebssystemdatenträgers der betroffenen VM. Es installiert GRUB neu, generiert die entsprechende GRUB-Konfigurationsdatei erneut und tauscht dann den Betriebssystemdatenträger des fehlerhaften virtuellen Computers mit dem kopierten Festplattendatenträger aus. Schließlich löscht das repair-button Skript automatisch die Ressourcengruppe, die die temporäre Reparatur-VM enthält.

Installieren Sie GRUB erneut, und generieren Sie die GRUB-Konfigurationsdatei manuell neu.

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 im Rescue-/Repair-VM, und betreten Sie dann die chroot-Umgebung.

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 die VM CentOS ausführt, ersetzen Sie redhat im grub.cfg-Dateipfad /boot/efi/EFI/centos/grub.cfg mit centos.

   • 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 Gen1 und Gen2

     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: unbekanntes Dateisystem

Der folgende Screenshot zeigt die Fehlermeldung:

Dieser Fehler kann durch eines der folgenden Probleme verursacht werden:

• /boot Dateisystembeschädigung.

  Um dieses Problem zu beheben, folgen Sie den Schritten in Beheben einer Beschädigung des /boot-Dateisystems.

• GRUB-Startladeprogramm verweist auf einen ungültigen Datenträger oder eine ungültige Partition.

  Um dieses Problem zu beheben, installieren Sie GRUB erneut, und generieren Sie die GRUB-Konfigurationsdatei manuell neu.

• Probleme mit der Partitionstabelle des Betriebssystemdatenträgers, die durch menschliches Versagen verursacht wurden.

  Um solche Probleme zu beheben, führen Sie die Schritte im Abschnitt Error: No such partition aus, um die /boot Partition neu zu erstellen, falls sie fehlt oder falsch erstellt wurde.

Beheben einer Beschädigung des /boot-Dateisystems

Führen Sie die folgenden Schritte aus, um Dateisystembeschädigungen zu beheben /boot :

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. Lesen Sie Beheben von Dateisystemfehlern in Azure Linux, um die Probleme mit der entsprechenden /bootPartition zu beheben.

3. Gehen Sie zu Schritt 3 in der Offline-Fehlerbehebung von GRUB-Rettungsproblemen, um den OS-Datenträger auszutauschen.

Fehler 15: Datei wurde nicht gefunden

Der folgende Screenshot zeigt die Fehlermeldung:

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

1. Überprüfen Sie, ob eine Rettungs-/Reparatur-VM erstellt wurde. Wenn die VM 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 im Rescue-/Repair-VM, und betreten Sie dann die chroot-Umgebung.

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

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

4. Überprüfen Sie, ob die Dateiberechtigungen im /boot Dateisystem OK 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 Wie können Sie Azure VM-Daten im Azure Portal wiederherstellen.

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:

1. Überprüfen Sie, ob eine Rettungs-/Reparatur-VM erstellt wurde. Wenn er nicht erstellt wurde, folgen Sie Schritt 1 in Offline-Fehlerbehebung im GRUB-Rettungsmodus, um einen zu erstellen. Mounten Sie alle erforderlichen Dateisysteme, einschließlich / und /boot im Rescue-/Repair-VM, und betreten Sie dann die chroot-Umgebung.

2. Wenn Sie das /boot Dateisystem aufgrund eines Beschädigungsfehlers nicht bereitstellen können, reparieren Sie die Dateisystembeschädigung von /boot.

3. Wenn Sie sich in chroot befinden, überprüfen Sie den Inhalt im /boot/grub2/i386-pc Verzeichnis. Wenn der Inhalt fehlt, kopieren Sie den Inhalt aus /usr/lib/grub/i386-pc. Verwenden Sie hierzu die folgenden Befehle:

   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:

   Hinweis

   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:

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

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

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

Wenn die /boot Partition fehlt, erstellen Sie sie erneut, indem Sie die folgenden Schritte ausführen:

1. Überprüfen Sie, ob eine Rettungs-/Reparatur-VM erstellt wurde. Wenn die VM 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

     

   • 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 unter "GRUB erneut installieren" ausführen und die GRUB-Konfigurationsdatei manuell neu generieren, um sie zu installieren und zu konfigurieren.

5. Fahren Sie mit Schritt 3 in Offline-Fehlerbehebung von GRUB-Recovery-Problemen fort, um die Betriebssystemfestplatte auszutauschen.

Neuerstellen der /boot-Partition in DOS-Systemen

1. Erstellen Sie die /boot Partition erneut aus einer Rettungs-/Reparatur-VM mithilfe des folgenden Befehls:

   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 mit der a Option im fdisk Tool als startbar gekennzeichnet ist, wie in der folgenden Ausgabe dargestellt:

   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. Überprüfen Sie nach dem erneuten Erstellen der fehlenden /boot Partition, 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 Dateisystem nach dem Neu Erstellen der Partition nicht in blkid sichtbar ist, bedeutet dies, dass die /boot Daten nicht mehr vorhanden sind. Sie müssen das /boot Dateisystem erneut erstellen (indem Sie das gleiche UUID- und Dateisystemformat verwenden, das sich im /etc/fstab/boot Eintrag befindet), und dann den Inhalt aus einer Sicherung wiederherstellen.

Neuerstellen der /boot-Partition in GPT-Systemen

1. Erstellen Sie die /boot Partition von einer Wiederherstellungs-/Reparatur-VM mithilfe des folgenden Befehls erneut.

   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. Überprüfen Sie mithilfe des folgenden Befehls, ob das /boot Dateisystem vom System erkannt wird:

   sudo blkid /dev/sdX1
   

   Sie sollten in der Lage sein, einen Eintrag für /dev/sdX1 (die fehlende /boot Partition) anzuzeigen.

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

3. Wenn das Dateisystem nach dem /boot erneuten Erstellen der Partition nicht sichtbar ist, bedeutet dies, dass die /boot Daten nicht mehr vorhanden sind. Sie müssen das /boot Dateisystem erneut erstellen (indem Sie dieselbe UUID verwenden, die im /etc/fstab/boot Eintrag steht), und dann dessen Inhalte aus einem Backup wiederherstellen.

Fehler: Symbol „grub_efi_get_secure_boot“ nicht gefunden

Der folgende Screenshot zeigt die Fehlermeldung:

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 die VM 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 betreten Sie dann die chroot-Umgebung.

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.

   

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:

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 der Inhalt fehlen.

Gehen Sie folgendermaßen vor, um diesen Fehler zu beheben:

1. Überprüfen Sie, ob eine Rettungs-/Reparatur-VM erstellt wurde. Wenn die VM 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 betreten Sie dann die chroot-Umgebung.

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

   • GRUB-Zugriff in RHEL
   • GRUB-Zugriff in CentOS
   • GRUB-Zugriff in Ubuntu
   • GRUB-Zugriff in SUSE SLES
   • GRUB-Zugriff in Oracle Linux

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

   Hinweis

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

4. Wenn die gesamte /boot Partition fehlt, führen Sie die Schritte unter "Fehler: keine solche Partition" aus.

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 der spezifische Startfehler kein GRUB-Rettungsproblem ist, finden Sie unter Troubleshoot Azure Linux Virtual Machines Startfehler weitere Problembehandlungsoptionen.

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel erläuterten Drittanbieterprodukte werden von Unternehmen hergestellt, die unabhängig von Microsoft sind. Microsoft übernimmt keine Garantie, impliziert oder anderweitig, über die Leistung oder Zuverlässigkeit dieser Produkte.

Haftungsausschluss für Kontaktinformationen von Drittanbietern

Microsoft enthält Kontaktinformationen von Drittanbietern, die Ihnen bei der Suche nach zusätzlichen Informationen zu diesem Thema helfen. Diese Kontaktinformationen können ohne vorherige Ankündigung geändert werden. Microsoft garantiert nicht die Genauigkeit von Kontaktinformationen von Drittanbietern.