Virtueller Linux-Computer startet mit GRUB-Rettung
Hinweis
CentOS, auf das in diesem Artikel verwiesen wird, ist eine Linux-Distribution und erreicht das Ende der Lebensdauer (End Of Life, EOL). Berücksichtigen Sie Ihre Verwendung, und planen Sie sie entsprechend. Weitere Informationen finden Sie unter Leitfaden zum Ende der Lebensdauer von CentOS.
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
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.
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:
Nachdem das Problem mit der GRUB-Rettung behoben wurde, führen Sie die folgenden Aktionen durch:
Entfernen Sie die Kopie der Dateisysteme von der Rettungs-/Reparatur-VM.
Führen Sie den Befehl
az vm repair restoreaus, 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.Ü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.
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.
Hinweis
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:
Dieser Fehler kann durch eines der folgenden Probleme verursacht werden:
Beschädigung des /boot-Dateisystems.
Um dieses Problem zu beheben, folgen Sie den Schritten in Beheben einer Beschädigung des /boot-Dateisystems.
Das GRUB-Startladeprogramm zeigt auf eine ungültige Festplatte oder Partition.
Um dieses Problem zu beheben, installieren Sie GRUB neu und generieren Sie die GRUB-Konfigurationsdatei neu.
Probleme mit der Partitionstabelle des Betriebssystemdatenträgers, die durch menschliches Versagen verursacht wurden.
Um solche Probleme zu beheben, folgen Sie den Schritten unter Fehler: Keine solche Partition mit Empfehlungen, wie die /boot-Partition neu erstellt werden kann, wenn sie fehlt oder falsch erstellt wurde.
Beheben einer Beschädigung des /boot-Dateisystems
Ü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.
Siehe Fehlerbehebung bei Dateisystemfehler in Azure Linux, um die Fehler in der entsprechenden /boot-Partition zu beheben.
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
Ü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.
Installieren Sie GRUB neu und generieren Sie die entsprechende GRUB-Konfigurationsdatei erneut mit einem der folgenden Befehle:
RHEL/CentOS/Oracle 7.x/8.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.cfgRHEL/CentOS/Oracle 7.x/8.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.cfgWenn die VM CentOS ausführt, ersetzen Sie in dem absoluten Pfad /boot/efi/EFI/centos/grub.cfg der Datei grub.cfg
redhatdurchcentos.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.cfgUbuntu 18.04/20.04
grub-install /dev/sdX update-grub
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:
Gehen Sie folgendermaßen vor, um dieses Problem zu beheben:
Ü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.
Überprüfen Sie den Inhalt des /boot-Dateisystems und stellen Sie fest, was fehlt.
Wenn die GRUB-Konfigurationsdatei fehlt, installieren Sie GRUB neu und generieren Sie die GRUB-Konfigurationsdatei erneut.
Ü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.
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.
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:
Ü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.
Wenn Sie das /boot-Dateisystem aufgrund eines Korruptionsfehlers nicht einbinden können, beheben Sie die Korruption des /boot-Dateisystems.
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. Verwenden Sie hierzu die folgenden Befehle:
ls -l /boot/grub2/i386-pc cp -rp /usr/lib/grub/i386-pc /boot/grub2Wenn der Inhalt der
/bootPartition leer ist, verwenden Sie die folgenden Befehle, um sie neu zu erstellen:Hinweis
Die folgenden Schritte gelten für RHEL/CentOS/Oracle 7.x/8.x Linux-VMs ohne UEFI (BIOS-basiert – Gen1).
Installieren Sie im Chroot-Prozess grub neu. 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]Stellen Sie sicher, dass
/etc/resolv.confein gültiger DNS-Eintrag vorhanden ist, um den Namen des Repositorys aufzulösen:cat /etc/resolv.confInstallieren Sie den Kernel neu:
yum reinstall $(rpm -qa | grep -i kernel)Create die Datei grub.cfg:
grub2-mkconfig -o /boot/grub2/grub.cfg sed -i 's/hd2/hd0/g' /boot/grub2/grub.cfg
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 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:
Ü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.
Stellen Sie mit dem folgenden Befehl fest, ob die Partitionstabelle als Typ DOS oder GPT erstellt wurde:
sudo fdisk -l /dev/sdXDOS-Partitionstabelle
GPT-Partitionstabelle
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.
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.
Fahren Sie mit Schritt 3 in Offline-Behebung von GRUB-Rettungsproblemen fort, um den Betriebssystemdatenträger auszutauschen.
Neuerstellen der /boot-Partition in DOS-Systemen
Erstellen Sie die /boot-Partition mit dem folgenden Befehl neu:
sudo fdisk /dev/sdXVerwenden 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
aim Toolfdiskverwenden, 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.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/sdX1sudo blkid /dev/sdc1 /dev/sdc1: UUID="<UUID>" TYPE="ext4"Wenn das /boot-Dateisystem in
blkidnicht 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
Erstellen Sie die /boot-Partition mit dem folgenden Befehl neu:
sudo gdisk /dev/sdXVerwenden 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.Prüfen Sie mit dem folgenden Befehl, ob das /boot-Dateisystem vom System erkannt wurde:
sudo blkid /dev/sdX1Sie 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>"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:
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:
Ü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.
Führen Sie den folgenden YaST-Befehl in der chroot-Umgebung aus:
yast2 bootloaderLö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.
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 deren Inhalt fehlt.
Gehen Sie folgendermaßen vor, um diesen Fehler zu beheben:
Ü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.
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:
Installieren Sie GRUB neu und generieren Sie die GRUB-Konfigurationsdatei erneut.
Hinweis
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.
Wenn die gesamte /boot-Partition fehlt, folgen Sie den Schritten im Artikel Fehler: Keine solche Partition.
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.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für