Freigeben über


Azure virtueller Linux-Computer kann nicht gestartet werden und gelangt in die Dracut-Notfallshell.

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. Erwägen Sie Ihre Verwendung und planen Sie entsprechend. Weitere Informationen finden Sie unter CentOS End Of Life Guidance.

Zusammenfassung

Dieser Artikel enthält Lösungen für ein Problem, bei dem ein Azure virtuellen Linux-Computer (VM) nicht starten kann, da auf das Betriebssystemdateisystem nicht über die RAMdisk zugegriffen werden kann. Die VM gerät in die Dracut-Notfallshell.

Voraussetzungen

Stellen Sie sicher, dass die serielle Konsole in der Linux-VM aktiviert und funktionsfähig ist.

So identifizieren Sie ein Dracut-Startproblem

Um ein Dracut-Startproblem zu identifizieren, verwenden Sie das Azure-Portal, um die Ausgabe des seriellen Konsolenprotokolls der VM im Bereich für Startdiagnosen oder im Bereich für serielle Konsolen anzuzeigen, oder nutzen Sie AZ CLI.

Alle virtuellen Computer mit dem Startproblem landen in der Dracut- oder Initramfs-Notfallshell und werden am Ende des seriellen Konsolenprotokolls angezeigt:

  • RHEL/CentOS/SLES/Oracle Linux:

    [  201.935612] dracut-initqueue[455]: Warning: dracut-initqueue timeout - starting timeout scripts
    [  201.941153] dracut-initqueue[455]: Warning: Could not boot.
             Starting Setup Virtual Console...
    [[0;32m  OK  [0m] Started Setup Virtual Console.
             Starting Dracut Emergency Shell...
    Warning: /dev/mapper/rootvg-rootlv does not exist
    
    Generating "/run/initramfs/rdsosreport.txt"
    
    
    Entering emergency mode. Exit the shell to continue.
    Type "journalctl" to view system logs.
    You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
    after mounting them and attach it to a bug report.
    
    
    dracut:/# 
    
  • Ubuntu:

    mdadm: No arrays found in config file or automatically
    done.
    Gave up waiting for root file system device.  Common problems:
     - Boot args (cat /proc/cmdline)
       - Check rootdelay= (did the system wait long enough?)
     - Missing modules (cat /proc/modules; ls /dev)
    ALERT!  /dev/mapper/osencrypt does not exist.  Dropping to a shell!
    
    
    BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.4) built-in shell (ash)
    Enter 'help' for a list of built-in commands.
    
    (initramfs)
    

Onlineproblembehandlung

Tipp

Wenn Sie über eine kürzliche Sicherung der VM verfügen, stellen Sie den virtuellen Computer aus der Sicherung wieder her, um das Startproblem zu beheben.

Die serielle Konsole ist die schnellste Methode zum Beheben von Problemen. Es ermöglicht Ihnen, das Problem direkt zu beheben, ohne den Systemdatenträger auf einer Wiederherstellungs-VM präsentieren zu müssen. Stellen Sie sicher, dass Sie die erforderlichen Voraussetzungen für Ihre Verteilung erfüllen. Weitere Informationen finden Sie in der seriellen Konsole für virtuelle Computer für Linux.

  1. Ermitteln Sie, ob Ihre VM in der Dracut-Notfallshell landet.

  2. Versuchen Sie, das Problem mithilfe der seriellen Konsole Azure zu beheben.

    Notiz

    Nicht jedes Problem kann mithilfe der seriellen Azure Konsole behoben werden.

    1. Lösen Sie Neustart der VM (Hard) von der seriellen Konsole aus.
    2. Unterbrechen Sie Ihren virtuellen Computer im GRUB-Menü mit der ESC-Taste .
    3. Wählen Sie "E " aus, um den ersten Kerneleintrag im GRUB-Menü zu ändern.
    4. Wechseln Sie zur linux16 Zeile, und überprüfen und korrigieren Sie dann die GRUB-Fehlkonfiguration wie folgt:
  3. Nachdem Sie die GRUB-Einstellungen manuell geändert haben, wählen Sie STRG+X aus, um den virtuellen Computer zu starten.

    Jede Änderung, die zu diesem Zeitpunkt erfolgt ist, ist eine nicht persistente Änderung. Wenn der virtuelle Computer gestartet werden kann, beheben Sie dieses Problem in der GRUB-Konfigurationsdatei, oder sie tritt erneut auf.

  4. Sobald der virtuelle Computer wieder online ist, beheben Sie die Konfigurationsprobleme in der /etc/default/grub Konfigurationsdatei, und aktualisieren Sie die GRUB-Konfiguration. Um dies zu tun, lesen Sie GRUB neu installieren und die GRUB-Konfigurationsdatei neu generieren.

  5. Starten Sie den virtuellen Computer neu, um sicherzustellen, dass er ohne manuelle Eingriffe gestartet werden kann.

Offlineproblembehandlung

Tipp

Wenn Sie über eine kürzliche Sicherung der VM verfügen, stellen Sie den virtuellen Computer aus der Sicherung wieder her, um das Startproblem zu beheben.

  1. Falls die serielle Konsole Azure nicht in der jeweiligen VM funktioniert oder keine Option in Ihrem Abonnement ist, beheben Sie dieses Problem mithilfe einer Rettungs-/Reparatur-VM. 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 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. Wechseln Sie zu den folgenden Abschnitten, um bestimmte Probleme zu beheben:

  3. Führen Sie nach dem Beheben des dracut/initramfs-bezogenen Startproblems die folgenden Aktionen aus:

    1. Chroot verlassen.
    2. Entfernen Sie die Kopie der Dateisysteme von der Rettungs-/Reparatur-VM.
    3. 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.
    4. Überprüfen Sie, ob der virtuelle Computer gestartet werden kann, indem Sie sich die serielle Azure Konsole ansehen oder versuchen, eine Verbindung mit dem virtuellen Computer herzustellen.

ADE-verschlüsselte VM kann nicht gestartet werden, da VFAT deaktiviert ist

Weitere Informationen finden Sie unter ADE-verschlüsselte VMs, die nicht gestartet werden können.

Hyper-V Treiber fehlen

Wenn die im Linux-Kernel enthaltenen Hyper-V Treiber aller modernen Linux-Distributionen deaktiviert sind, aktivieren Sie sie erneut, und regenerieren Sie das Initramfs/initrd-Image. Weitere Informationen finden Sie unter Scenario 3: Andere Hyper-V Treiber sind deaktiviert.

Wenn der virtuelle Computer Red Hat ist und von der lokalen Bereitstellung migriert wird, aktivieren Sie die erforderlichen Hyper-V Treiber im Initramfs-Image. Weitere Informationen finden Sie unter Die Hyper-V Treiber konnte bei Verwendung eines Nicht-Hyper-V Hypervisors nicht in den ursprünglichen RAM-Datenträger aufgenommen werden.

GRUB-Fehlkonfiguration

Der rd.break Parameter zwingt die VM, in der Dracut-Notfallshell zu starten. Stellen Sie sicher, dass dieser Parameter in der GRUB-Konfigurationsdatei nicht hartcodiert ist.

Falscher Stammgerätepfad in der GRUB-Konfigurationsdatei

Überprüfen Sie, ob der Stammpfad root=/dev/*** in der GRUB-Konfigurationsdatei korrekt ist. Stellen Sie sicher, dass der richtige Gerätepfad verwendet wird.

Stellen Sie während dieser Überprüfung folgendes sicher:

  • Stellen Sie in Ubuntu-VMs mit Betriebssystemverschlüsselung sicher, dass der Gerätename lautet /dev/mapper/osencrypt.
  • In VMs mit logischem Volume-Manager (LVM) auf dem Betriebssystemdatenträger ist das Root-Volume /dev/mapper/rootvg-rootlv. Derselbe Pfad wird in RHEL-VMs mit verschlüsseltem ADE-Betriebssystemdatenträger verwendet.
  • Stellen Sie sicher, dass keine Gerätenamen in Form verwendet /dev/sdX werden, da sie sich über Neustarts ändern und in Linux nicht beständig sind. Weitere Informationen finden Sie unter Problembehandlung bei Änderungen des Linux-VM-Gerätenamens.
  • Wenn UUIDs verwendet werden, stellen Sie sicher, dass das richtige Stammdateisystem UUID verwendet wird und die Syntax lautet root=UUID=xxx-yyy-zzz.

Falsches Austauschen des Gerätepfads in der GRUB-Konfigurationsdatei

In diesem Szenario kann ein virtueller Computer den Startvorgang nicht abschließen und die Dracut-Notfallshell mit einem Fehler wie den folgenden eingeben:

[  188.000765] dracut-initqueue[324]: Warning: /dev/VG/SwapVol does not exist
         Starting Dracut Emergency Shell...
Warning: /dev/VG/SwapVol does not exist

Die GRUB-Konfigurationsdatei in diesem Beispiel ist so festgelegt, dass ein logisches Volume (LV) als Swap mit dem Parameter rd.lvm.lv=VG/SwapVolgeladen wird. Der virtuelle Computer kann diesen LV jedoch während des Startvorgangs nicht finden.

Es ist wichtig zu beachten, dass die Verwendung eines Swap-Geräts auf diese Weise in Azure Linux-VMs nicht empfohlen wird. Weitere Informationen finden Sie unter Create a SWAP file for an Azure Linux VM.

Um dieses Problem zu beheben, suchen Sie den Swappfad rd.lvm.lv=VG/SwapVol in der GRUB-Konfigurationsdatei (/etc/default/grub) und entfernen Sie es. Wenden Sie hierzu eine der folgenden Methoden an:

Duplizierte Parameter in GRUB-Konfigurationsdatei

Überprüfen Sie, ob in der GRUB-Konfigurationsdatei doppelte Parameter vorhanden sind:

Stammdateisystembeschädigung

Wenn das Stammdateisystem beschädigt ist, kann es nicht aus dem Initrd/initramfs-Image bereitgestellt werden.

Um die Beschädigung des Stammdateisystems zu beheben, befolgen Sie die Anweisungen in der Problembehandlung bei Startproblemen des virtuellen Linux-Computers aufgrund von Dateisystemfehlern – Führen Sie die Dateisystemreparatur durch.

Probleme bei der LVM-Aktivierung

Einige Probleme können auftreten, wenn Sie auf das physische LVM-Volume (PV), die Volumegruppe (VG) und/oder das logische Volume (LV) zugreifen. Sie können nicht über die serielle Azure Konsole adressiert werden. Um sie zu beheben, verwenden Sie eine Reparatur-/Rettungs-VM.

  1. Führen Sie Schritt 1 in der Offline-Problembehandlung aus.

  2. Um die Probleme zu identifizieren, führen Sie die folgenden Befehle aus, und sehen Sie sich die Befehlsausgabe an.

    1. Ermitteln Sie, welches Gerät dem Betriebssystemdatenträger entspricht, und überprüfen Sie, ob es als PV erkannt wird:

      lsblk
      pvs
      
    2. Überprüfen Sie, ob die rootvg VG erkannt wird:

      vgs
      
    3. Überprüfen Sie, ob das LV erkannt wird:

      lvs
      
  3. Behandeln Sie die folgenden allgemeinen LVM-Fehler, die Probleme beim Zugriff auf das Stammvolume verursachen:

    • Unbekanntes PV, wenn das "rootvg"-VG nur über ein einzelnes PV verfügt (dies ist die Standardkonfiguration von Azure)

      Die Partition, die die PV-Datei hält, wird fälschlicherweise gelöscht, verkleinert oder erstellt. Informationen zum Beheben dieses Problems finden Sie unter "Stammpartition fehlt".

    • Unbekannter PV-Wert, wenn das Rootvg-VG geändert und auf mehrere Datenträger aufgeteilt wird

      Das Vorhandensein von 2 PVs im rootvg VG ist keine empfohlene Konfiguration. In diesem Szenario kann der Datenträger vom virtuellen Computer getrennt werden, und auf die logischen Rootvg-Volumes kann nicht mehr zugegriffen werden. Um dieses Problem zu beheben, schließen Sie den ursprünglichen Datenträger wieder an den virtuellen Computer an und starten Sie ihn neu.

  4. Sollte die PV nicht wiederhergestellt werden können, führen Sie eine Wiederherstellung aus der Sicherung durch.

Die Stammpartition fehlt.

Auf das Stammdateisystem kann möglicherweise nicht zugegriffen werden, weil bei Partitionsänderungsvorgängen oder anderen damit verbundenen Problemen auf Partitionsebene Schwierigkeiten auftreten können.

Wenn Sie in diesem Szenario das ursprüngliche Partitionstabellenlayout dokumentiert haben, mit den genauen Anfangs- und Endbereichen für jede der ursprünglichen Partitionen (und keine weiteren Änderungen am System vorgenommen werden, z. B. die Erstellung neuer Dateisysteme), erstellen Sie die Partitionen mit demselben ursprünglichen Layout neu. Sie können dies mit Tools wie fdisk (für MBR-Partitionstabellen) oder gdisk (für GPT-Partitionstabellen) tun, um Zugriff auf das nicht zugängliche Dateisystem zu erhalten. Folgen Sie diesem Wiederherstellungsvorgang von einer Reparatur-/Rettungs-VM. Weitere Informationen finden Sie im Abschnitt zur Offline-Problembehandlung .

Wenn dieser Ansatz nicht funktioniert, empfehlen wir, eine Wiederherstellung aus der Sicherung auszuführen.

Initrd-Beschädigung oder Initramfs-Beschädigung

Das Initrd/Initramfs-Image weist eine gewisse Beschädigung auf, wodurch das Einbinden des Root-Volumes und der Start des Betriebssystems fehlschlägt.

Führen Sie die folgenden Schritte innerhalb von chroot in einer Reparatur-/Rettungs-VM aus, um dieses Problem zu beheben:

  1. Führen Sie Schritt 1 in der Offline-Problembehandlung aus.
  2. Manuelles Generieren fehlender Initramfs.
  3. Starten Sie den virtuellen Computer neu, um zu bestätigen, ob er gestartet werden kann.

Nächste Schritte

Falls der spezifische Startfehler kein Problem mit Dracut oder Initramfs ist, finden Sie unter Troubleshoot Azure Linux Virtual Machines Startfehler weitere Problembehandlungsoptionen.