Share via

Beheben von Problemen beim Starten von Linux-VMs aufgrund von Fehlern in „fstab“

  • Artikel

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.

Die Linux-Dateisystemtabelle fstab ist eine Konfigurationstabelle, die dazu dient, Regeln zu konfigurieren, nach denen bestimmte Dateisysteme während des Systemstartvorgangs erkannt und in geordneter Weise eingebunden werden. In diesem Artikel werden mehrere Fälle behandelt, in denen eine falsche fstab-Konfiguration zu Boot-Problemen führen kann, und es werden Hinweise zur Fehlerbehebung gegeben.

Im Folgenden sind einige häufige Gründe aufgeführt, die zu Problemen beim Booten einer virtuellen Maschine aufgrund einer falschen Konfiguration der fstab führen können:

  • Der herkömmliche Dateisystemname wird anstelle des Universally Unique Identifier (UUID) des Dateisystems verwendet.
  • Es wird eine falsche UUID verwendet.
  • Es existiert ein Eintrag für ein nicht angeschlossenes Gerät ohne nofail-Option in der fstab-Konfiguration.
  • Falscher Eintrag in der fstab-Konfiguration.

fstab-Probleme identifizieren

Überprüfen Sie den aktuellen Boot-Status der VM im seriellen Protokoll im Blade [Boot-Diagnose] (/azure/virtual-machines/boot-diagnostics#boot-diagnostics-view) im Azure-Portal. Die VM wird im Notfallmodus sein. Sie sehen Protokolleinträge, die dem folgenden Beispiel ähneln und zum Status „Notfallmodus“ führen:

[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)

Hinweis

„/data“ ist ein Beispiel für einen verwendeten Einbindungspunkt. Das Scheitern von Abhängigkeiten für Dateisystem-Einhängepunkte hängt von den verwendeten Namen ab.

Fehlerbehebung

Es gibt 2 Möglichkeiten, das Problem zu lösen:

Reparieren des virtuellen Computers online

Verwenden der seriellen Konsole

  1. Verbinden Sie sich mit der seriellen Konsole der VM vom Azure-Portal aus.
  2. Um fstab neu zu konfigurieren, ist ein manueller Zugriff auf den Einzelbenutzermodus erforderlich. Die Schritte können je nach Art des verwendeten Linux-Betriebssystems und des Zugriffs auf das Root-Konto variieren. Folgen Sie der Einzelbenutzermodus-Dokumentation, um auf den Einzelbenutzermodus für jedes unterstützte Linux-Partner-Image zuzugreifen.
fstab-Problembehandlungsschritte

  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 Starten des virtuellen Computers eingebunden wird. Weitere Informationen zur Syntax der Datei „fstab“ bekommen Sie, wenn Sie den Befehl „man fstab fstab“ ausführen. Um einen Boot-Fehler zu beheben, überprüfen Sie den Eintrag für das Dateisystem, das nicht eingebunden werden konnte. Es hat sich bewährt, jede Zeile zu überprüfen, um sicherzustellen, dass sowohl ihre Struktur als auch ihr Inhalt korrekt sind. Um eine fstab-Datei korrekt zu verwalten, sind einige Punkte zu beachten:

    • 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 die Zeilen in „fstab“, bei denen Sie unsicher sind, nicht entfernen, sondern auskommentieren.

    • Binden Sie die Datenlaufwerke auf Azure-VMs ein, indem Sie die UUID der Dateisystempartition verwenden. Um die UUID des Dateisystems zu ermitteln, führen Sie den Befehl blkid aus. Weitere Informationen zur Syntax erhalten Sie durch Ausführen des Befehls „man blkid“. Beispiel für einen UUID-Eintrag in der fstab-Datei:

      UUID=<UUID number here>  /data      xfs    defaults,nofail 0  0

    • Verwenden Sie die Option nofail in den Dateisystemeinträgen (Datenlaufwerke), damit der Startvorgang auch dann fortgesetzt werden kann, wenn in den Partitionen der entsprechenden Einträge Fehler auftreten. Mit der Option „nofail“ können Sie sicherstellen, dass der virtuelle Computer auch dann gestartet wird, wenn das Dateisystem beschädigt oder beim Start nicht vorhanden ist.

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

  4. Verwenden Sie am besten mount -a, nachdem Sie Änderungen an den fstab-Einträgen vorgenommen haben. Dadurch wird die fstab-Konfiguration erneut ausgeführt und die Benutzer werden auf vorhandene Syntax- oder Eingabefehler hingewiesen.

  5. Sobald die Syntax und die Eingaben überprüft sind, 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.

Hinweis

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

Reparieren des virtuellen Computers im Offlinestatus

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

Verwenden von Azure Linux Auto Repair (ALAR)

Azure Linux Auto Repair (ALAR) Skripte ist ein Teil der VM-Reparatur-Erweiterung, die in Reparieren Sie eine Linux-VM mit den Azure Virtual Machine Reparaturbefehlen beschrieben wird. ALAR deckt die Automatisierung mehrerer Reparaturszenarien einschließlich /etc/fstab Problemen ab.

Die ALAR-Skripte verwenden den Befehl repair extension run und seine Option --run-id. Die Skript-ID für die automatische Wiederherstellung lautet: linux-alar2. Führen Sie die folgenden Schritte durch, um fstab-Fehler über einen Offline-ALAR-Ansatz zu automatisieren:

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

Hinweis

Der Name der Ressourcengruppe „centos7“, der Name des VM „cent7“ und der Name des Kopierlaufwerks „repairdiskcopy“ sind Beispiele, und die Werte müssen entsprechend geändert werden.

Das Skript „fstab repair“ erstellt eine Sicherungskopie der Originaldatei und entfernt alle Zeilen in der Datei „/etc/fstab“, die zum Starten eines Systems nicht benötigt werden. Nach erfolgreichem Start des Betriebssystems bearbeiten Sie die fstab erneut und korrigieren Sie alle Fehler, die einen Neustart des Systems zuvor nicht zuließen.

Alternativ können die Änderungen nach der Erstellung einer Reparatur-VM auch durch manuelles Einloggen in die Reparatur-VM, Einhängen der angehängten Kopie des Betriebssystems und Änderungen an der fstab-Datei vorgenommen werden. Führen Sie die folgenden Schritte aus:

  • Erstellen Sie eine Reparatur-VM mit dem Befehl az vm repair create.
  • Um die Dateisysteme des angeschlossenen Betriebssystemdatenträgers in einer Rettungs-VM einzubinden und Chroot auszuführen, folgen Sie den detaillierten Chroot-Anweisungen.
  • Führen Sie anschließend die gleichen fstab-Fehlerbehebungsschritte wie oben aus.
  • Sobald die Änderungen übernommen wurden, kann der Befehl az vm repair restore verwendet werden, um einen automatischen Tausch des Betriebssystems mit der ursprünglichen VM durchzuführen.

Manuelle Methode verwenden

Wenn sowohl die serielle Konsole als auch der ALAR-Ansatz nicht möglich sind oder fehlschlagen, muss die Reparatur manuell durchgeführt werden. Befolgen Sie die hier beschriebenen Schritte, um den Betriebssystemdatenträger manuell an eine Wiederherstellungs-VM anzuhängen und den Betriebssystemdatenträger zurück in die ursprüngliche VM zu tauschen:

Sobald der Betriebssystemdatenträger erfolgreich an die Wiederherstellungs-VM angeschlossen ist, folgen Sie den detaillierten Chroot-Anweisungen, um die Dateisysteme des angeschlossenen Betriebssystemlaufwerks einzuhängen und zu chrooten. Führen Sie dann die fstab-Fehlerbehebungsschritte durch, um entsprechende Änderungen an der fstab-Datei des problematischen Betriebssystemlaufwerks 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.