Freigeben über

Virtueller Linux-Computer startet mit GRUB-Rettung

Gilt für: ✔️ Linux-VMs

Hinweis

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.

    Hinweis

    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, den virtuellen Computer aus einer Sicherung 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.

Hinweis

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

Installieren Sie GRUB erneut, und regenerieren Sie die GRUB-Konfigurationsdatei mithilfe der Automatischen Reparatur von Azure Linux

Azure Linux Auto Repair (ALAR)-Skripts sind Teil der vm-Reparaturerweiterung, die unter Verwendung von Azure Linux Auto Repair (ALAR) beschrieben wird, um eine Linux-VM zu reparieren. ALAR deckt die Automatisierung mehrerer Reparaturszenarien ab, einschließlich GRUB-Rettungsproblemen.

Die ALAR-Skripts verwenden die Reparaturerweiterungrepair-button, um GRUB-Probleme zu beheben, indem sie für VMs der Generation 1 oder --button-command efifix für VMs der Generation 2 angeben--button-command grubfix. 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

Wichtig

Ersetzen Sie den Ressourcengruppennamen $RGNAME und den VM-Namen $VMNAME entsprechend.

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. Mount all the required file systems, including / and /boot in the rescue/repair VM, and then enter the chroot environment.

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

Screenshot von „GRUB unbekannter Dateisystemfehler“.

Dieser Fehler kann durch eines der folgenden Probleme verursacht werden:

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. Informationen zur Problembehandlung von Dateisystembeschädigungsfehlern in Azure Linux , um die Beschädigungsprobleme 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.

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 dieses 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. Mount all the required file systems, including / and /boot in the rescue/repair VM, and then enter the chroot environment.

  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 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. Mount all the required file systems, including / and /boot in the rescue/repair VM, and then enter the chroot environment.

  2. Wenn Sie das Dateisystem aufgrund eines Beschädigungsfehlers nicht bereitstellen können, beheben Sie die Beschädigung des /boot Dateisystems /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:

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 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 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 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-Behebung von GRUB-Rettungsproblemen fort, um den Betriebssystemdatenträger auszutauschen.

Neuerstellen der /boot-Partition in DOS-Systemen

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

    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 /boot erneuten Erstellen der Partition nicht sichtbar blkid 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 mithilfe des folgenden Befehls erneut von einer Rettungs-/Reparatur-VM:

    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 /etc/fstab/boot sich im Eintrag befindet), und dann deren Inhalt aus einer Sicherung 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. Mount all the required file systems, including / and /boot, and then enter the chroot environment.

  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 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 sie nicht erstellt wurde, folgen Sie Schritt 1 in Offline-Fehlerbehebung für GRUB-Rettungsprobleme, um die VM zu erstellen. Mount all the required file systems, including / and /boot, and then enter the chroot environment.

  2. Stellen Sie sicher, dass die /etc/default/grub Konfigurationsdatei 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 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 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" aus : 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.