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

Artikel
11/20/2024

Gilt für: ✔️ Linux-VMs

Dieser Artikel enthält Anleitungen zur Behebung von Problemen beim Starten von virtuellen Linux-Computern (VM), die durch Dateisystemfehler verursacht werden.

Symptome

Sie können keine Verbindung zu einem virtuellen Azure Linux-Computer (VM) über das Secure Shell Protocol (SSH) herstellen, oder der VM-Agent-Status im Azure-Portal ist nicht Bereit. Wenn Sie die Startdiagnose im Azure-Portal ausführen oder sich mit der seriellen Konsole verbinden, sehen Sie Protokolleinträge, die den folgenden Beispielen ähneln:

Notiz

Nicht alle Beispiele werden vorhanden sein.
Ein Fehler beim Mounten führt nicht immer dazu, dass eine VM in den Notfallmodus wechselt. Wenn es sich um ein Problem mit bestimmten kritischen Dateisystemen handelt, kann die VM den Notfallmodus nicht verwenden.

Beispiel 1: Das ext4-Dateisystem konnte nicht gemountet werden

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 Mounten des LVM-Geräts (ext Logical Volume Manager)

[   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: Das xfs-Dateisystem kann nicht gemountet werden

[    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: In den Notfallmodus starten

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 eine Festplattenbeschädigung hin. In bestimmten Fällen verhindert eine Beschädigung der Festplatte, dass die VM vollständig hochfährt. Festplattenbeschädigungen können durch verschiedene Probleme verursacht werden, wie Linux-Kernel-Probleme, Treiberfehler, Fehler in der zugrunde liegenden physischen oder virtuellen Hardware usw.

Lösung

Um die durch Dateisystemfehler verursachten Linux-VM-Startprobleme zu beheben, reparieren Sie die VM, indem Sie die Beschädigung der Festplatte beheben. Gehen Sie folgendermaßen vor, um die Festplatte zu reparieren:

Identifizieren Sie, welche Festplatte beschädigt ist.
Identifizieren Sie den Dateisystemtyp.
Wählen Sie den Wiederherstellungsmodus (online oder offline).
Bereiten Sie die Wiederherstellungsumgebung entsprechend dem von Ihnen ausgewählten Wiederherstellungsmodus vor:
- Vorbereitung der Umgebung für die Online-Wiederherstellung
- Vorbereitung der Umgebung für die Offline-Wiederherstellung
Verwenden Sie Befehlszeilentools, um das problematische Dateisystem auf der Festplatte zu reparieren.
- Reparieren eines ext4-Dateisystems
- Xfs-Dateisystem reparieren
Notiz
- Es ist wichtig, kritische Daten zu sichern, da auf der wiederhergestellten Festplatte ein Datenverlust auftreten kann.
- Bevor Sie Änderungen an einer Festplatte vornehmen, machen Sie einen Schnappschuss, um den aktuellen Zustand der Festplatte zu erhalten, selbst wenn sie sich in einem Fehlerzustand befindet. Wenn Sie die Beschädigung der Festplatte beheben, ändern sich die Daten auf der Festplatte, was ein Risiko darstellt.

Identifizieren, welche Festplatte beschädigt ist

Um festzustellen, welche Festplatte beschädigt ist, laden Sie das serielle Protokoll für Ihre VM herunter, indem Sie die serielle Konsole oder die Startdiagnose verwenden, die Protokolleinträge während des Startvorgangs überprüfen und dann nach dem spezifischen Fehler suchen, der anzeigt, welche Festplatte oder welches Mounten fehlgeschlagen ist.

Hier sind drei Beispiele für Protokolleinträge. Beachten Sie in diesen Beispielen den Text in Klammern, der das beschädigte Gerät meldet.

Im folgenden Beispiel ist das beschädigte Gerät sdc1:

[   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 die Partition, auf der ein Dateisystemfehler auftritt, sda1:

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 das beschädigte Gerät dm-2. Es ist ein Linux Device Mapper, der ein LVM-Volume anzeigt.

[   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 für das Laufwerk, das aufgerufen wird, ein Name im Format „sdXN“ verwendet wird, wobei X ein Buchstabe von a-z und N eine optionale Partitionsnummer ist, bedeutet dies, dass die Festplatte im RAW-Zustand ist und mit dem Pfad /dev/sdXN betrieben werden kann.

Wenn das zu mountende Laufwerk 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 Festplattenvolumes (PVs) zu erkennen, die möglicherweise verwendet werden.

Eine LVM-Volume-Gruppe (VG), die die Betriebssystem-Festplatte und eine beliebige Anzahl von Daten-Festplatten enthält, wird nicht unterstützt. Für ein solches Szenario besteht ein hohes Risiko von Datenverlust. In einem LVM-VG sind jedoch mehrere Datenträger zulässig.

Beim Bestimmen der Zuordnung von OS-Datenträgerverweisen auf Azure-Datenträgerobjekte:

Bei Marktplatz-Images befindet sich das Stamm-Dateisystem (/), /boot und /boot/efi auf dem Betriebssystemdatenträger.
Für LVM-basierte Images können viele andere System-Mounts vorhanden sein, wie /home, /tmp, /usr, /var, /var/log und /opt.
Zusätzliche Dateisysteme, die für Anwendungen erstellt wurden, befinden sich auf Datenträgern, zum Beispiel /data, / datadisk oder /sap. Konfigurieren Sie sie richtig, damit das System auch bei einem Fehler starten kann. Wenn es sich bei einem Datenträger um ein Gerät handelt, das in den Notfallmodus startet, siehe Verhindern von Startfehlern.

Dateisystemtyp identifizieren

Während der anfänglichen Identifizierung ist die einzige Methode, um den Datenträgertyp zu bestimmen, die Verwendung des seriellen Protokolls, wie zuvor in Identifizieren, welche Festplatte beschädigt ist. Wenn das Laufwerk im seriellen Protokoll gemeldet wird, werden Fehler aus dem Linux-Kernelmodul für das Dateisystem angezeigt. Notieren Sie jede Zeile, in der EXT4-fs oder XFS angegeben ist. Für alle anderen Dateisystemtypen befindet sich das Protokoll im gleichen Bereich. Das in den Protokolleinträgen vermerkte Dateisystem wird durch die Datei /etc/fstab bestimmt. Achten Sie darauf, dass das angegebene Format korrekt ist, wenn Sie eine Reparatur durchführen.

Sobald Sie Zugriff auf eine interaktive Shell haben, führen Sie den Befehl lsblk mit dem Flag -f wie folgt aus, um Geräte, Pfade (wenn das Dateisystem gemountet ist) und den Dateisystemtyp anzuzeigen, der von der Festplatte 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:

Durch die Verwendung der ASCII-Art-Anzeige können Sie sehen, dass LVM-Volumes vorhanden sind, da es einen LVM2_MEMBER FSTYPE für sda4 gibt, der Objekte mit Namen wie rootvg-rootlv und rootvg-homelv enthält.
rootvg-homelv ist nicht gemountet, was durch das leere MOUNTPOINT-Feld gekennzeichnet ist.
rootvg-homelv hat den Dateisystemtyp XFS. Es ist ein Kontrast zum EXT4-Mount-Fehler beim Starten. Wenn der Dateisystemtyp inkonsistent ist, vertrauen Sie eher der Ausgabe von lsblk als dem Inhalt von fstab.

Wiederherstellungsmodus auswählen

Sie können eine VM online im Notfallmodus oder im Einzelbenutzermodus oder offline mithilfe einer Rettungs-VM wiederherstellen.

Anforderungen für die Online-Wiederherstellung

Der Zugriff der seriellen Konsole auf die VM.
Wenn der Notfallmodus verwendet wird, muss die serielle Konsole eine Aufforderung für den Notfallmodus anzeigen, das Root-Konto muss entsperrt werden und das Passwort muss bekannt sein.
Wenn der Einzelbenutzermodus verwendet wird, wird das Root-Passwort nicht benötigt. Der Einzelbenutzermodus kann verwendet werden, wenn ein anderes Dateisystem als die erforderlichen Systempartitionen wie root (/) oder /usr beschädigt ist.

Anforderungen für die Offline-Wiederherstellung

Wenn die Anforderungen der seriellen Konsole für die Online-Wiederherstellung nicht erfüllt werden können, führen Sie die Offline-Wiederherstellung mithilfe einer Rettungs-VM durch. Für die Offline-Wiederherstellung ist die Möglichkeit erforderlich, eine VM zu erstellen und Festplatten in Azure zu verwalten. Alternativ können Sie eine funktionierende Linux-VM mit Zugriff auf Azure-Ebene auf die beschädigten Festplatten verwenden.

Vorbereitung der Umgebung für die Online-Wiederherstellung

Wenn der Notfallmodus in der Anmeldeaufforderung wie folgt angezeigt wird, geben Sie das Root-Passwort 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 Root-Passwort nicht bekannt ist oder das Root-Konto gesperrt ist, wie in der folgenden Ausgabe, 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 Online-Wiederherstellungsumgebung unbrauchbar ist, fahren Sie mit der Offline-Wiederherstellung fort.

Vorbereitung der Umgebung für die Offline-Wiederherstellung

In VMs mit einzelnen Festplatten oder wenn das fehlgeschlagene Mount eine Systempartition wie das Root-Dateisystem (/) oder /usr ist, ist die zuverlässigste Methode zur Reparatur der Festplatte die Verwendung einer Rettungs-VM, um Zugriff auf die Festplatte zu erhalten. Sie können eine Rettungs-VM automatisch oder manuell erstellen.

Informationen zum automatisierten Erstellen einer Rettungs-VM finden Sie unter Reparatur eines virtuellen Azure-Computers. Informationen zum manuellen Erstellen einer Rettungs-VM finden Sie unter Erstellen einer Wiederherstellungs-VM. In beiden Fällen sollten Sie die Volumes nicht von der Problemfestplatte mounten, da ein Dateisystem nicht gemountet werden darf, wenn Reparaturdienstprogramme ausgeführt werden sollen.

Ausführen der Dateisystemreparatur

Stellen Sie vor der Reparatur des Dateisystems sicher, dass die folgenden Schritte durchgeführt wurden:

Die Problemfestplatte und -partition, oder LVM-Volume-Struktur, wurde identifiziert.
Der Dateisystemtyp wurde ermittelt.
(Optional) Eine Kopie des Problemdatenträgers oder der Datenträger in einer übergreifenden LVM-Volume-Gruppe wurde an eine Rettungs-VM angehängt.
Der Zugriff auf eine interaktive Shell wurde durch den Zugriff auf die Festplatte gesichert.

Um die Dateisystemreparatur durchzuführen, gehen Sie je nach Dateisystemtyp zu Ext4-Dateisystem reparieren oder XFS-Dateisystem reparieren.

Unabhängig davon, welcher Wiederherstellungsmodus verwendet wird, sind die Befehle, um die Dateisystemreparatur durchzuführen, die gleichen. Die Notfall-Shell kann Einschränkungen aufweisen. Wenn die Befehle in einer Notfallmodusumgebung nicht verfügbar sind oder Fehler wegen unbekannten Dateisystemtypen vorliegen, bereiten Sie die Umgebung auf die Offline-Wiederherstellung vor.

Die Befehle zum Reparieren des Dateisystems beheben möglicherweise nicht alle Fehler. Sie umgehen zwar Festplattenbeschädigungen, aber es kann trotzdem zu Datenverlusten kommen. Sobald die Befehlsausgabe feststellt, dass das Dateisystem sauber ist, fügen Sie die ursprüngliche VM wieder mit der reparierten Festplatte zusammen und starten Sie die VM, um die Daten zu überprüfen.

In den folgenden Abschnitten ist /dev/sdc1 das beschädigte Dateisystem im RAW-Modus, und der LV homelv im VG rootvg ist das LVM-Volume. Ersetzen Sie diese Werte in allen Instanzen für das tatsächliche beschädigte Dateisystem.

Reparieren eines ext4-Dateisystems

Verwenden Sie den Befehl fsck [-y] FILESYSTEM, um ein ext4-Dateisystem zu reparieren. Geben Sie das Dateisystem als Festplattenpartition für ein RAW-Dateisystem, beispielsweise /dev/sdc1, oder den logischen LVM-Volume-Pfad an/dev/rootvg/homelv.

Beispiel für eine 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 zur Änderung des Dateisystems dreimal angefordert wird. Wenn es viele Anfragen gibt, drücken Sie STRG+C und starten Sie fsck mit dem Flag -y neu, um bei allen Fragen "Ja" anzunehmen. Wenn Dateien als in lost+found abgelegt gemeldet werden, identifizieren Sie sie manuell und legen Sie sie an den richtigen Speicherorten ab.

Wenn Fehler aufgetreten und anschließend behoben worden sind, führen Sie den Befehl fsck erneut aus. Wiederholen Sie dies, bis der Befehl fsck mit dem clean Status beendet wird. In der folgenden Ausgabe finden Sie ein Beispiel.

[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 eines XFS-Dateisystems

Hier sind die Befehle, um ein XFS-Dateisystem zu reparieren:

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

Gehen Sie folgendermaßen vor, um ein XFS-Dateisystem zu reparieren:

Überprüfen Sie Dateisystemfehler wie folgt mit dem Befehl xfs_repair -n:
```
xfs_repair -n /dev/rootvg/homelv
```
Wenn die Überprüfung erfolgreich ist, fahren Sie mit dem Reparaturmodus fort, indem Sie das Flag -n entfernen, wodurch versucht wird, aufgetretene Fehler wie folgt zu beheben:
```
xfs_repair /dev/rootvg/homelv
```

Bei XFS-Dateisystemen werden protokollierte, aber nicht übermittelte Änderungen durch Mounten des Dateisystems behandelt. Wenn während der Fehlerbehebung der folgende Fehler auftritt, versuchen Sie einen Mount und sehen Sie sich die Ergebnisse an.

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

Wenn eine Wiederherstellungs-VM verwendet wird, erstellen Sie ein Verzeichnis für einen temporären Punkt zum Mounten, z. B. /recovery, und mounten Sie das Dateisystem. Wenn sich die Wiederherstellungsumgebung im Notfall- oder Einzelbenutzermodus befindet, mounten Sie das Dateisystem an seinem vorgesehenen Speicherort. Die folgenden Befehle dienen als Beispiele:

mount /dev/rootvg/homelv /recovery

mount /home

Wenn die protokollierten Änderungen beim Mounten von Dateisystemen nicht geschrieben werden, verwenden Sie das Flag -L, um das Protokoll zu verwerfen und das Dateisystem so zu mounten, als ob alle Änderungen erfolgreich abgeschlossen wären. Wenn das Flag -L verwendet wird, wird ein Datenverlust auftreten, weil das Protokoll zeigt, dass unvollständige Dateivorgänge verworfen werden.

xfs_repair -L /dev/rootvg/homelv /recovery

Verhindern von Startfehlern

Wenn die Option nofail beim Mounten von Dateisystemen angegeben wird, kann es vorkommen, dass die Beschädigung eines nicht kritischen Dateisystems Linux nicht daran hindert, vollständig zu starten. Weitere Informationen zu nofail finden Sie unter Mounten der Festplatte. Die meisten Mounts außer dem Stamm (/), /usr und /var können mit nofail durchgeführt werden.

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