Beheben von Problemen beim Starten von virtuellen Linux-Computern aufgrund von Dateisystemfehlern

Artikel
07/30/2024

Gilt für: ✔️ Linux-VMs

Dieser Artikel enthält Anleitungen zur Problembehandlung von Startproblemen durch virtuelle Linux-Computer (VM), die durch Dateisystemfehler verursacht werden.

Problembeschreibung

Sie können keine Verbindung mit einem virtuellen Azure Linux-Computer (VM) herstellen, indem Sie das Secure Shell Protocol (SSH) verwenden oder den VM-Agent-Status im Azure-Portal nicht bereit ist. Wenn Sie die Startdiagnose in der Azure-Portal ausführen oder eine Verbindung mit der seriellen Konsole herstellen, werden Protokolleinträge angezeigt, die den folgenden Beispielen ähneln:

Notiz

Nicht alle Beispiele sind vorhanden.
Ein Montagefehler führt nicht immer dazu, dass eine VM in den Notfallmodus wechselt. Wenn das Problem mit bestimmten kritischen Dateisystemen auftritt, verwendet der virtuelle Computer möglicherweise nicht den Notfallmodus.

Beispiel 1: Fehler beim Bereitstellen des Ext4-Dateisystems

EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.

Beispiel 2: Fehler beim Bereitstellen des Logischen Volume-Managers (LVM)-Geräts

[   14.382472] EXT4-fs error (device dm-0): ext4_iget:4398: inode #8: comm mount: bad extra_isize 4060 (inode size 256)
[   14.389648] EXT4-fs (dm-0): no journal found
<snipped>
[FAILED] Failed to mount /opt/data.

Beispiel 3: Fehler beim Bereitstellen des XFS-Dateisystems

[    8.543984] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xd0/0xf0 [xfs], xfs_agi block 0x10
[    8.553867] XFS (sdc1): Unmount and run xfs_repair
[    8.558993] XFS (sdc1): First 128 bytes of corrupted metadata buffer:
[    8.564893] 00000000: 58 41 47 49 00 00 00 01 00 00 00 00 00 1f ff c0  XAGI............
[    8.572847] 00000010: 00 00 00 40 00 00 00 06 00 00 00 01 00 00 00 3d  ...@...........=
[    8.580476] 00000020: 00 00 00 60 ff ff ff ff ff ff ff ff ff ff ff ff  ...`............
[    8.588219] 00000030: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.596280] 00000040: ff 07 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.603575] 00000050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.610849] 00000060: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.619261] 00000070: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
[    8.629731] XFS (sdc1): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x10 len 8 error 74
[    8.637799] XFS (sdc1): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
[FAILED] Failed to mount /data.
See 'systemctl status data.mount' for details.
[DEPEND] Dependency failed for Local filesystems.

Beispiel 4: Starten im Notfallmodus

You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or "exit"
to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

Ursache

Die obigen Protokolleinträge deuten auf Datenträgerbeschädigung hin. In bestimmten Situationen wird die Datenträgerbeschädigung verhindern, dass der virtuelle Computer vollständig gestartet wird. Verschiedene Probleme können zu Datenträgerbeschädigungen führen, z. B. Linux-Kernelprobleme, Treiberfehler, Fehler in der zugrunde liegenden physischen oder virtuellen Hardware usw.

Lösung

Um die Startprobleme des virtuellen Linux-Computers zu beheben, die durch Dateisystemfehler verursacht werden, stellen Sie den virtuellen Computer wieder her, indem Sie die Datenträgerbeschädigung reparieren. Führen Sie die folgenden Schritte aus, um die Datenträgerbeschädigung zu reparieren:

Identifizieren Sie, welcher Datenträger beschädigt ist.
Identifizieren sie den Dateisystemtyp.
Wählen Sie den Wiederherstellungsmodus (online oder offline) aus.
Bereiten Sie die Wiederherstellungsumgebung gemäß dem von Ihnen ausgewählten Wiederherstellungsmodus vor:
- Vorbereiten der Umgebung für die Onlinewiederherstellung
- Vorbereiten der Umgebung für die Offlinewiederherstellung
Verwenden Sie Befehlszeilentools, um das problematische Dateisystem auf dem Datenträger zu reparieren.
- Reparieren des Ext4-Dateisystems
- Reparieren des xfs-Dateisystems
Notiz
- Es ist wichtig, wichtige Daten zu sichern, da Datenverlust auf dem wiederhergestellten Datenträger auftreten kann.
- Bevor Sie Änderungen an einem Datenträger vornehmen, erstellen Sie eine Momentaufnahme, um den aktuellen Zustand des Datenträgers beizubehalten, auch wenn er sich in einem Fehlerzustand befindet. Durch das Beheben der Datenträgerbeschädigung werden die Daten auf dem Datenträger geändert, wodurch Risiken entstehen.

Ermitteln, welcher Datenträger beschädigt ist

Um zu ermitteln, welcher Datenträger beschädigt ist, laden Sie das serielle Protokoll für Ihren virtuellen Computer mithilfe der seriellen Konsole oder Startdiagnose herunter, überprüfen Sie die Protokolleinträge während des Starts, und suchen Sie dann nach dem spezifischen Fehler, bei dem der Datenträger oder die Bereitstellung fehlschlägt.

Hier sind drei Protokolleintragsbeispiele. Beachten Sie in diesen Beispielen den Text in Klammern, der das beschädigte Gerät meldet.

Im folgenden Beispiel lautet sdc1das beschädigte Gerät:

[   14.285807] XFS (sdc1): Mounting V5 Filesystem
[   14.426283] XFS (sdc1): Metadata CRC error detected at xfs_agi_read_verify+0xde/0x100 [xfs], xfs_agi block 0x10
[   14.426284] XFS (sdc1): Unmount and run xfs_repair
<snipped>
[FAILED] Failed to mount /opt/parent.

Im folgenden Beispiel lautet sda1die Partition, auf der ein Dateisystemfehler auftritt:

EXT4-fs (sda1): INFO: recovery required on readonly filesystem
EXT4-fs (sda1): write access will be enabled during recovery
EXT4-fs warning (device sda1): ext4_clear_journal_err:4531: Filesystem error recorded from previous mount: IO failure
EXT4-fs warning (device sda1): ext4_clear_journal_err:4532: Marking fs in need of filesystem check.
<snipped>
[FAILED] Failed to mount /boot.

Im folgenden Beispiel ist dm-2das beschädigte Gerät . Es handelt sich um ein Linux Device Mapper-Gerät, das ein LVM-Volume angibt.

[   18.014318] EXT4-fs (dm-2): VFS: Can't find ext4 filesystem
[FAILED] Failed to mount /home.
See 'systemctl status home.mount' for details.
[DEPEND] Dependency failed for Local File Systems.
[DEPEND] Dependency failed for Mark the need to relabel after reboot.

Wenn das aufgerufene Datenträgergerät einen Namen des Formats "sdXN" verwendet, wobei X ein Buchstabe von a-z ist und N eine optionale Partitionsnummer ist, bedeutet dies, dass der Datenträger unformatiert ist und mithilfe des Pfads "/dev/sdXN " betrieben werden kann.

Wenn das bereitgestellte Datenträgergerät einen Namen wie "/dev/mapper/vgname/lvname", "/dev/vgname/lvname" oder "dm-N" verwendet, bedeutet dies, dass ein LVM-Gerät verwendet wird. Achten Sie darauf, alle physischen Datenträgervolumes (PVs) zu erkennen, die möglicherweise verwendet werden.

Es wird für die LVM-Volumegruppe (VG) nicht unterstützt, um den Betriebssystemdatenträger und eine beliebige Anzahl von Datenträgern zu enthalten. Für ein solches Szenario besteht ein hohes Risiko für Datenverlust. Mehrere Datenträger sind jedoch in einer LVM-VG zulässig.

Beim Bestimmen der Zuordnung von Betriebssystemdatenträgerverweisen zu Azure-Datenträgerobjekten:

Bei Marketplace-Images befindet sich die Stammdateisystem (/), /boot und /boot/efi auf dem Betriebssystemdatenträger.
Bei LVM-basierten Images können viele andere Systemhalter vorhanden sein, z. B. "/home", "/tmp", "/usr", "/var", "/var/log" und "/opt".
Zusätzliche Dateisysteme, die für Anwendungen erstellt werden, befinden sich auf Datenträgern, z. B. /data, /datadisk oder /sap. Konfigurieren Sie sie ordnungsgemäß, damit das System auch dann gestartet werden kann, wenn ein Fehler auftritt. Wenn es sich bei einem Datenträger um ein Gerät handelt, das im Notfallmodus gestartet wird, lesen Sie die Verhinderung von Startfehlern.

Identifizieren des Dateisystemtyps

Während der anfänglichen Identifizierung verwendet die einzige Methode, um den Datenträgertyp zu ermitteln, das serielle Protokoll verwendet, wie zuvor unter "Identifizieren, welcher Datenträger beschädigt ist". Wenn das Datenträgergerät im seriellen Protokoll gemeldet wird, werden Fehler aus dem Linux-Kernelmodul für das Dateisystem angezeigt. Notieren Sie sich jede Zeile, in der EXT4-fs bzw XFS . die angegeben wird. Für alle anderen Dateisystemtypen befindet sich das Protokoll im selben Bereich. Das in den Protokolleinträgen aufgeführte Dateisystem wird durch die Datei "/etc/fstab " bestimmt. Stellen Sie sicher, dass das angegebene Format bei einer Reparatur korrekt ist.

Sobald Sie Zugriff auf eine interaktive Shell haben, führen Sie den lsblk Befehl mit dem -f Kennzeichen wie folgt aus, um Geräte, Pfade (wenn das Dateisystem bereitgestellt ist) und den Dateisystemtyp anzuzeigen, der vom Datenträger selbst gelesen wird.

[root@localhost ~]# lsblk -f
NAME              FSTYPE      LABEL UUID                                   MOUNTPOINT
sda
|-sda1            vfat              93DA-8C20                              /boot/efi
|-sda2            xfs               d5da486e-fdfe-4ad8-bc01-aa72b91fd47d   /boot
|-sda3
`-sda4            LVM2_member       pdSI2Q-ZEzV-oT6P-R2JG-ZW3h-cmnf-iRN6pU
  |-rootvg-tmplv  xfs               9098eb05-0176-4997-8132-9152a7bef207   /tmp
  |-rootvg-usrlv  xfs               2f9ff36c-742d-4914-b463-d4152801b95d   /usr
  |-rootvg-optlv  xfs               aeacea8e-3663-4569-af25-c52357f8a0a3   /opt
  |-rootvg-homelv xfs               a79e43dc-7adc-41b4-b6e1-4e6b033b15c0
  |-rootvg-varlv  xfs               c7cb68e9-7865-4187-b3bd-e9a869779d86   /var
  `-rootvg-rootlv xfs               d8dc4d62-ada5-4952-a0d9-1bce6cb6f809   /
sdb
`-sdb1            ext4              1dac7c4c-bf8e-4964-8a59-7359eef53d0a   /mnt
sdc               LVM2_member       CRWEZQ-iLhH-ev0b-BAaA-dfLD-nbPT-GgtG0r
`-vgapp-lvapp     xfs               733e25ee-565f-4bfa-a2a1-2451efd25cd1
sdd
`-sdd1            ext4              704d9fb1-2207-4bb9-998c-029f776dc6d2   /opt/data

Hier sind einige wichtige Punkte in der Ausgabe:

Mithilfe der ASCII-Grafikanzeige können Sie sehen, dass LVM-Volumes vorhanden sind, da ein LVM2_MEMBER FSTYPE für Sda4 mit Objekten mit Namen wie und rootvg-rootlv rootvg-homelv.
rootvg-homelv wird nicht bereitgestellt, das durch das leere MOUNTPOINT-Feld gekennzeichnet ist.
rootvg-homelv hat den Dateisystemtyp XFS. Es ist ein Kontrast zum EXT4-Bereitstellungsfehler beim Starten. Wenn der Dateisystemtyp inkonsistent ist, vertrauen Sie der lsblk Ausgabe anstelle des Inhalts von fstab.

Wiederherstellungsmodus auswählen

Sie können einen virtuellen Computer online über den Notfallmodus oder den Einzelbenutzermodus oder offline wiederherstellen, indem Sie einen virtuellen Rettungscomputer verwenden.

Anforderungen für die Onlinewiederherstellung

Der Zugriff auf die serielle Konsole auf den virtuellen Computer.
Wenn der Notfallmodus verwendet wird, muss die serielle Konsole eine Aufforderung für den Notfallmodus anzeigen, das Stammkonto muss entsperrt sein, und das Kennwort muss bekannt sein.
Wenn der Einzelbenutzermodus verwendet wird, ist das Stammkennwort nicht erforderlich. Der Einzelbenutzermodus kann verwendet werden, wenn ein anderes Dateisystem als erforderliche Systempartitionen wie Stamm (/) oder /usr beschädigt ist.

Anforderungen für die Offlinewiederherstellung

Wenn die Anforderungen der seriellen Konsole für die Onlinewiederherstellung nicht erfüllt werden können, führen Sie die Offlinewiederherstellung mithilfe eines virtuellen Rettungscomputers aus. Um die Offlinewiederherstellung durchzuführen, ist die Möglichkeit zum Erstellen einer VM und zum Verwalten von Datenträgern in Azure erforderlich. Alternativ können Sie eine funktionierende Linux-VM mit Zugriff auf beschädigte Datenträger auf Azure-Ebene verwenden.

Vorbereiten der Umgebung für die Onlinewiederherstellung

Wenn der Notfallmodus in der Anmeldeaufforderung wie folgt angezeigt wird, geben Sie das Stammkennwort ein:

Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to
try again to Give root password for maintenance
(or press Control-D to continue):

Wenn das Stammkennwort nicht bekannt ist oder das Stammkonto gesperrt ist, wie in der folgenden Ausgabe dargestellt, verwenden Sie den Einzelbenutzermodus:

Welcome to emergency mode! After logging in, typ
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.

Press Enter to continue.

Wenn die Onlinewiederherstellungsumgebung nicht verwendbar ist, fahren Sie mit der Offlinewiederherstellung fort.

Vorbereiten der Umgebung für die Offlinewiederherstellung

Bei VMs auf einem einzelnen Datenträger oder wenn es sich bei der fehlerhaften Bereitstellung um eine Systempartition wie die Stammdateisystem (/) oder /usrum die zuverlässigste Methode zum Reparieren des Datenträgers handelt, verwenden Sie eine Rettungs-VM, um Zugriff auf den Datenträger zu erhalten. Sie können einen virtuellen Rettungscomputer automatisch oder manuell erstellen.

Eine automatisierte Erstellung eines virtuellen Rettungscomputers finden Sie unter Azure Virtual Machine Repair. Informationen zum manuellen Erstellen eines virtuellen Rettungscomputers finden Sie unter Erstellen einer Wiederherstellungs-VM. Stellen Sie in beiden Fällen die Volumes nicht vom Problemdatenträger bereit, da ein Dateisystem nicht bereitgestellt werden darf, damit Reparaturhilfsprogramme ausgeführt werden können.

Ausführen der Dateisystemreparatur

Stellen Sie vor der Reparatur des Dateisystems sicher, dass die folgenden Schritte abgeschlossen wurden:

Der Problemdatenträger und die Partition oder die LVM-Volumestruktur wurden identifiziert.
Der Dateisystemtyp wurde bestimmt.
(Optional) Eine Kopie des Problemdatenträgers oder Datenträgers in einer übergreifenden LVM-Volumegruppe wurde an eine Rettungs-VM angefügt.
Der Zugriff auf eine interaktive Shell wurde mithilfe des Zugriffs auf den Datenträger gesichert.

Um die Dateisystemreparatur durchzuführen, wechseln Sie zum Reparieren des Ext4-Dateisystems oder zum Reparieren des XFS-Dateisystems gemäß dem Dateisystemtyp.

Unabhängig davon, welcher Wiederherstellungsmodus verwendet wird, sind die Befehle zum Ausführen der Dateisystemreparatur identisch. Die Notfallshell kann Einschränkungen aufweisen. Wenn die Befehle in einer Notfallmodusumgebung nicht verfügbar sind oder Fehler bei unbekannten Dateisystemtypen auftreten, bereiten Sie die Umgebung für die Offlinewiederherstellung vor.

Die Befehle zum Reparieren des Dateisystems beheben möglicherweise nicht alle Fehler. Sie umgehen Datenträgerbeschädigungen, aber datenverluste können weiterhin auftreten. Sobald die Befehlsausgabe angibt, dass das Dateisystem sauber ist, können Sie die ursprüngliche VM mit dem reparierten Datenträger neu zusammenbauen und die VM starten, um Die Daten zu überprüfen.

In den folgenden Abschnitten /dev/sdc1 handelt es sich um das beschädigte Dateisystem im unformatierten Modus, und das LV homelv im VG rootvg ist das LVM-Volume. Ersetzen Sie diese Werte durch das tatsächliche beschädigte Dateisystem in allen Instanzen.

Reparieren des Ext4-Dateisystems

Verwenden Sie den fsck [-y] FILESYSTEM Befehl, um ein ext4-Dateisystem zu reparieren. Geben Sie das Dateisystem als Datenträgerpartition für ein unformatiertes Dateisystem an, z /dev/sdc1. B. den logischen LVM-Volumepfad /dev/rootvg/homelv.

Hier ist ein Beispiel für die Befehlsausgabe:

[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
ext2fs_check_desc: Corrupt group descriptor: bad block for block bitmap
fsck.ext4: Group descriptors look bad... trying backup blocks...
/dev/sdc1 was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #0 (23508, counted=23509).
Fix<y>? yes
Free blocks count wrong (8211645, counted=8211646).
Fix<y>? yes

/dev/sdc1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc1: 11/2097152 files (0.0% non-contiguous), 176706/8388352 blocks
[root@vm1dev ~]#

Die Ausgabe zeigt, dass die Bestätigung zum Ändern des Dateisystems dreimal angefordert wird. Wenn viele Anforderungen vorhanden sind, drücken Sie STRG+C, und starten Sie mit der -y Kennzeichnung neufsck, um bei allen Fragen "Ja" anzunehmen. Wenn Dateien als platziert lost+foundgemeldet werden, identifizieren Sie sie manuell, und platzieren Sie sie an richtigen Speicherorten.

Wenn einige Fehler auftreten und anschließend behoben werden, führen Sie den fsck Befehl erneut aus. Wiederholen Sie den Vorgang, bis der fsck Befehl mit dem clean Status beendet wird. Sehen Sie sich die folgende Ausgabe als Beispiel an:

[root@vm1dev ~]# fsck /dev/sdc1
fsck from util-linux 2.23.2
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdc1: clean, 11/2097152 files, 176706/8388352 blocks
[root@vm1dev ~]#

Reparieren des xfs-Dateisystems

Hier sind Befehle zum Reparieren eines XFS-Dateisystems:

xfs_repair [-n] FILESYSTEM
xfs_repair [-L] FILESYSTEM
mount FILESYSTEM MOUNTPOINT

Führen Sie die folgenden Schritte aus, um ein XFS-Dateisystem zu reparieren:

Überprüfen Sie Dateisystemfehler mithilfe des xfs_repair -n Befehls wie folgt:
```
xfs_repair -n /dev/rootvg/homelv
```
Wenn die Überprüfung erfolgreich ist, fahren Sie mit dem Reparaturmodus fort, indem Sie die -n Kennzeichnung entfernen, die versucht, aufgetretene Fehler wie folgt zu beheben:
```
xfs_repair /dev/rootvg/homelv
```

Bei XFS-Dateisystemen werden aufgezeichnete, aber nicht freigegebene Änderungen durch das Einbinden des Dateisystems behandelt. Wenn während der Problembehandlung der folgende Fehler auftritt, versuchen Sie, eine Bereitstellung bereitzustellen, und zeigen Sie die Ergebnisse an.

FEHLER: Das Dateisystem hat wertvolle Metadatenänderungen in einem Protokoll, das wiedergegeben werden muss

Wenn eine Wiederherstellungs-VM verwendet wird, erstellen Sie ein Verzeichnis für einen temporären Bereitstellungspunkt, z /recovery. B. das Dateisystem, und stellen Sie das Dateisystem bereit. Wenn sich die Wiederherstellungsumgebung im Notfallmodus oder im Einzelbenutzermodus befindet, stellen Sie das Dateisystem an seinem vorgesehenen Speicherort bereit. Weitere Informationen finden Sie in den folgenden Befehlen als Beispiele:

mount /dev/rootvg/homelv /recovery

oder

mount /home

Wenn die aufgezeichneten Änderungen nicht geschrieben werden, wenn Sie Dateisysteme bereitstellen, verwenden Sie das -L Flag, um das Journal zu verwerfen und das Dateisystem so einzugeben, als ob alle Änderungen erfolgreich abgeschlossen wurden. Wenn das -L Flag verwendet wird, treten Datenverluste auf, da im Protokoll unvollständige Dateivorgänge verworfen werden.

xfs_repair -L /dev/rootvg/homelv /recovery

Verhindern eines Startfehlers

Wenn die nofail Option beim Einbinden von Dateisystemen angegeben wird, kann die Beschädigung eines nicht kritischen Dateisystems nicht verhindern, dass Linux vollständig gestartet wird. Weitere Informationen nofailfinden Sie unter Bereitstellen des Datenträgers. Die meisten Mounts werden neben dem Stamm (/), /usrund /var können mit nofail.

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.

Freigeben über