Problembehandlung bei Linux-VM-Startproblemen aufgrund von fstab-Fehlern

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.

Die Linux-Dateisystemtabelle fstab ist eine Konfigurationstabelle, die für die Konfiguration von Regeln konzipiert ist, bei denen bestimmte Dateisysteme während des Systemstartvorgangs ordnungsgemäß erkannt und bereitgestellt werden. In diesem Artikel werden mehrere Bedingungen erläutert, bei denen eine falsche fstab-Konfiguration zu Startproblemen führen kann und Anleitungen zur Problembehandlung enthält.

Nachfolgend sind einige häufige Gründe aufgeführt, die zu Startproblemen des virtuellen Computers führen können, da fstab fehlkonfiguriert wurde:

  • Der herkömmliche Dateisystemname wird anstelle der Universally Unique Identifier (UUID) des Dateisystems verwendet.
  • Es wird eine falsche UUID verwendet.
  • Für ein nicht angefügtes Gerät ohne nofail Option innerhalb der Fstab-Konfiguration ist ein Eintrag vorhanden.
  • Falscher Eintrag in der Fstab-Konfiguration.

Identifizieren von Fstab-Problemen

Überprüfen Sie den aktuellen Startstatus der VM im seriellen Protokoll im Blatt [Startdiagnose] (/azure/virtual-machines/boot-diagnostics#boot-diagnostics-view) im Azure-Portal. Der virtuelle Computer befindet sich im Notfallmodus. Es werden Protokolleinträge angezeigt, die dem folgenden Beispiel ähneln, das zum Status des Notfallmodus führt:

[K[[1;31m TIME [0m] Timed out waiting for device dev-incorrect.device.
[[1;33mDEPEND[0m] Dependency failed for /data.
[[1;33mDEPEND[0m] Dependency failed for Local File Systems.
…
Welcome to emergency mode! After logging in, type "journalctl -xb" to viewsystem logs, "systemctl reboot" to reboot, "systemctl default" to try again to boot into default mode.
Give root password for maintenance
(or type Control-D to continue)

Notiz

"/data" ist ein Beispiel für den verwendeten Bereitstellungspunkt. Abhängigkeitsfehler für den Dateisystem-Bereitstellungspunkt unterscheiden sich je nach verwendeten Namen.

Lösung

Es gibt zwei Möglichkeiten, das Problem zu beheben:

Reparieren der VM Online

Verwenden der seriellen Konsole

  1. Stellen Sie über Azure-Portal eine Verbindung mit der seriellen Konsole der VM her.
  2. Der manuelle Zugriff auf den Einzelbenutzermodus ist erforderlich, um fstab neu zu konfigurieren. Die Schritte können je nach Art des verwendeten Linux-Betriebssystems und dem Zugriff auf das Stammkonto variieren. Befolgen Sie die Dokumentation für den Einzelbenutzermodus, um für jede unterstützte Linux-Partnerimages auf den Einzelbenutzermodus zuzugreifen.
Schritte zur Problembehandlung bei Fstab
  1. Nachdem der virtuelle Computer im Einzelbenutzermodus gestartet wurde. Öffnen Sie die Datei „fstab“ mit Ihrem bevorzugten Text-Editor.

    vi /etc/fstab
    
  2. Überprüfen Sie die aufgelisteten Dateisysteme in /etc/fstab. Jede Zeile in der Datei "fstab" gibt ein Dateisystem an, das beim Start der VM bereitgestellt wird. Wenn Sie weitere Informationen zur Syntax der Fstab-Datei wünschen, führen Sie den man fstab Befehl aus. Um einen Startfehler zu beheben, überprüfen Sie den Eintrag für das Dateisystem, das nicht bereitgestellt werden konnte. Es empfiehlt sich, jede Zeile zu überprüfen, um sicherzustellen, dass sie sowohl in Struktur als auch in Inhalten korrekt ist. Einige Punkte, die sie berücksichtigen sollten, um eine fstab-Datei richtig zu verwalten, sind wie folgt:

    • Felder in den einzelnen Zeilen werden durch Tabstopps oder Leerzeichen voneinander getrennt. Leere Zeilen werden ignoriert. Zeilen, die als erstes Zeichen ein Nummernzeichen (#) aufweisen, sind Kommentare. Auskommentierte Zeilen können in der Datei „fstab“ verbleiben, werden aber nicht verarbeitet. Es wird empfohlen, dass Sie Fstab-Zeilen kommentieren, die Sie nicht sicher sind, anstatt die Zeilen zu entfernen.

    • Mount the data disks on Azure VMs by using the UUID of the file system partition. Um die UUID des Dateisystems zu ermitteln, führen Sie den blkid Befehl aus. Wenn Sie weitere Informationen zur Syntax wünschen, führen Sie den man blkid Befehl aus. Beispiel für den UUID-Eintrag in der Datei "fstab":

      UUID=<UUID number here>  /data      xfs    defaults,nofail 0  0
      
    • Verwenden Sie die nofail Option in den Dateisystemeinträgen (Datenträger), um den Start auch nach Fehlern in Partitionen für die entsprechenden Einträge fortzusetzen. Mit nofail der Option wird sichergestellt, dass der virtuelle Computer gestartet wird, auch wenn das Dateisystem beschädigt ist oder nicht beim Start vorhanden ist.

  3. Speichern Sie die Änderungen an der Datei „fstab“.

  4. Wird als bewährte Methode verwendet mount -a , nachdem Änderungen an den Fstab-Einträgen vorgenommen wurden. Dadurch wird die Fstab-Konfiguration erneut ausgeführt und die Benutzer über vorhandene Syntax- oder Eintragsfehler benachrichtigt.

  5. Sobald die Syntax und die Einträge überprüft werden, starten Sie den virtuellen Computer mit dem folgenden Befehl neu.

    reboot -f
    
  6. Wenn die Auskommentierung oder Korrektur der Einträge erfolgreich war, sollte das System eine Bash-Eingabeaufforderung im Portal erreichen. Überprüfen Sie, ob Sie eine Verbindung mit der VM herstellen können.

Notiz

Sie können auch den Befehl „Strg + X“ verwenden, um den virtuellen Computer neu zu starten.

Reparieren des virtuellen Computers im Offlinestatus

Wenn der zugriff auf die serielle VM-Konsole nicht verfügbar ist, besteht eine alternative Lösung darin, den virtuellen Computer offline zu reparieren. Es gibt zwei Möglichkeiten, einen Offline-Ansatz zu ergreifen:

Verwenden der Automatischen Reparatur von Azure Linux (ALAR)

Azure Linux Auto Repair (ALAR)-Skripts sind Teil der VM-Reparaturerweiterung, die unter "Reparieren einer Linux-VM" beschrieben wird, indem Sie die Reparaturbefehle des virtuellen Azure-Computers verwenden. ALAR deckt die Automatisierung mehrerer Reparaturszenarien einschließlich /etc/fstab Problemen ab.

Die ALAR-Skripts verwenden den Reparaturerweiterungsbefehl run und dessen --run-id Option. Die Skript-ID für die automatisierte Wiederherstellung lautet: linux-alar2. Implementieren Sie die folgenden Schritte zum Automatisieren von Fstab-Fehlern über den Offline-ALAR-Ansatz:

az vm repair create --verbose -g centos7 -n cent7 --repair-username rescue --repair-password 'password!234' --copy-disk-name  repairdiskcopy
az vm repair run --verbose -g centos7 -n cent7 --run-id linux-alar2 --parameters fstab --run-on-repair
az vm repair restore --verbose -g centos7 -n cent7

Notiz

Der Ressourcengruppenname "centos7, vm name "cent7" und --copy-disk-name "repairdiskcopy" sind Beispiele, und die Werte müssen entsprechend geändert werden.

Das Fstab-Reparaturskript übernimmt eine Sicherung der ursprünglichen Datei und entfernt alle Zeilen in der Datei "/etc/fstab", die zum Starten eines Systems nicht benötigt werden. Nachdem das Betriebssystem erfolgreich gestartet wurde, bearbeiten Sie den Fstab erneut, und korrigieren Sie alle Fehler, die zuvor keinen Neustart des Systems zugelassen haben.

Alternativ können die Änderungen, nachdem eine Reparatur-VM erstellt wurde, auch implementiert werden, indem sie sich manuell bei der Reparatur-VM anmelden, die angefügte Kopie des Betriebssystemdatenträgers einbinden und Änderungen an der Datei "fstab" vornehmen. Führen Sie die folgenden Schritte aus:

  • Erstellen Sie eine Reparatur-VM mithilfe des az vm repair create Befehls.
  • Befolgen Sie die detaillierten Chroot-Anweisungen, um die Dateisysteme des angefügten Betriebssystemdatenträgers in einem virtuellen Rettungscomputer zu mounten und zu chroot.
  • Führen Sie als Nächstes die gleichen Schritte zur Problembehandlung wie oben aus.
  • Sobald die Änderungen angewendet wurden, kann der Befehl verwendet werden, az vm repair restore um den automatischen Austausch des Betriebssystemdatenträgers mit der ursprünglichen VM durchzuführen.

Manual-Methode verwenden

Wenn sowohl die serielle Konsole als auch der ALAR-Ansatz nicht möglich oder fehlschlägt, muss die Reparatur manuell ausgeführt werden. Führen Sie die hier beschriebenen Schritte aus, um den Betriebssystemdatenträger manuell an eine Wiederherstellungs-VM anzufügen und den Betriebssystemdatenträger wieder an die ursprüngliche VM zu tauschen:

Nachdem der Betriebssystemdatenträger erfolgreich an die Wiederherstellungs-VM angefügt wurde, folgen Sie den detaillierten Chroot-Anweisungen zum Bereitstellen und Chroot an die Dateisysteme des angefügten Betriebssystemdatenträgers. Implementieren Sie dann fstab-Schritte zur Problembehandlung, um geeignete Änderungen an der Datei "fstab" des problematischen Betriebssystemdatenträgers vorzunehmen.

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.