Beheben von Problemen beim Starten eines virtuellen Linux-Computers aufgrund von Dateisystemfehlern
Dieser Artikel enthält Anleitungen zur Behebung von Problemen beim Starten von virtuellen Linux-Computern (VM), die durch Dateisystemfehler verursacht werden.
Problembeschreibung
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:
Hinweis
- 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:
Wählen Sie den Wiederherstellungsmodus (online oder offline).
Bereiten Sie die Wiederherstellungsumgebung entsprechend dem von Ihnen ausgewählten Wiederherstellungsmodus vor:
Verwenden Sie Befehlszeilentools, um das problematische Dateisystem auf der Festplatte zu reparieren.
Hinweis
- 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-rootlvundrootvg-homelventhält. rootvg-homelvist nicht gemountet, was durch das leere MOUNTPOINT-Feld gekennzeichnet ist.rootvg-homelvhat den Dateisystemtyp XFS. Es ist ein Kontrast zum EXT4-Mount-Fehler beim Starten. Wenn der Dateisystemtyp inkonsistent ist, vertrauen Sie eher der Ausgabe vonlsblkals 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/usrbeschä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] FILESYSTEMxfs_repair [-L] FILESYSTEMmount 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/homelvWenn die Überprüfung erfolgreich ist, fahren Sie mit dem Reparaturmodus fort, indem Sie das Flag
-nentfernen, 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
oder
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.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für