Rozwiązywanie problemów z rozruchem maszyny wirtualnej z systemem Linux z powodu błędów systemu plików

Ten artykuł zawiera wskazówki dotyczące rozwiązywania problemów z rozruchem maszyny wirtualnej z systemem Linux spowodowanych błędami systemu plików.

Symptomy

Nie można nawiązać połączenia z maszyną wirtualną platformy Azure z systemem Linux przy użyciu protokołu SSH (Secure Shell Protocol) lub stan agenta maszyny wirtualnej w Azure Portal nie jest gotowy. Po uruchomieniu diagnostyki rozruchu w Azure Portal lub nawiązaniu połączenia z konsolą szeregową zostaną wyświetlone wpisy dziennika podobne do następujących przykładów:

Uwaga

• Nie wszystkie przykłady będą obecne.
• Błąd instalowania nie zawsze powoduje, że maszyna wirtualna przechodzi w tryb awaryjny. Jeśli problem dotyczy niektórych krytycznych systemów plików, maszyna wirtualna może nie używać trybu awaryjnego.

Przykład 1: Nie można zainstalować systemu plików ext4

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.

Przykład 2: Nie można zainstalować urządzenia ext Logical Volume Manager (LVM)

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

Przykład 3: Nie można zainstalować systemu plików xfs

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

Przykład 4. Rozruch w trybie awaryjnym

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

Przyczyna

Powyższe wpisy dziennika wskazują uszkodzenie dysku. W niektórych sytuacjach uszkodzenie dysku uniemożliwi pełne uruchomienie maszyny wirtualnej. Różne problemy mogą powodować uszkodzenie dysku, takie jak problemy z jądrem systemu Linux, błędy sterowników, błędy na podstawowym sprzęcie fizycznym lub wirtualnym itd.

Rozwiązanie

Aby rozwiązać problemy z rozruchem maszyny wirtualnej z systemem Linux spowodowane błędami systemu plików, odzyskaj maszynę wirtualną, naprawiając uszkodzenie dysku. Aby naprawić uszkodzenie dysku, wykonaj następujące kroki:

1. Określ, który dysk jest uszkodzony.

2. Zidentyfikuj typ systemu plików.

3. Wybierz tryb odzyskiwania (online lub offline).

4. Przygotuj środowisko odzyskiwania zgodnie z wybranym trybem odzyskiwania:

   • Przygotowywanie środowiska do odzyskiwania w trybie online
   • Przygotowywanie środowiska do odzyskiwania w trybie offline

5. Użyj narzędzi wiersza polecenia, aby naprawić problematyczny system plików na dysku.

   • Naprawianie systemu plików ext4
   • Naprawianie systemu plików xfs

   Uwaga

   • Tworzenie kopii zapasowej danych krytycznych jest ważne, ponieważ może wystąpić utrata danych na odzyskanym dysku.
   • Przed wprowadzeniem zmian na dysku wykonaj migawkę, aby zachować bieżący stan dysku, nawet jeśli jest w stanie błędu. Naprawienie uszkodzenia dysku spowoduje zmianę danych na dysku, co spowoduje ryzyko.

Określanie, który dysk jest uszkodzony

Aby określić, który dysk jest uszkodzony, pobierz dziennik szeregowy maszyny wirtualnej przy użyciu diagnostyki konsoli szeregowej lub rozruchu, sprawdź wpisy dziennika podczas rozruchu, a następnie poszukaj określonego błędu, który wskazuje, który dysk lub instalacja kończy się niepowodzeniem.

Oto trzy przykłady wpisów dziennika. W tych przykładach zanotuj tekst w nawiasie, który zgłasza uszkodzone urządzenie.

W poniższym przykładzie uszkodzone urządzenie to 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.

W poniższym przykładzie partycja, w której występuje błąd systemu plików, to 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.

W poniższym przykładzie uszkodzonym urządzeniem jest dm-2. Jest to urządzenie mapowania urządzeń z systemem Linux, które wskazuje wolumin LVM.

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

Jeśli wywoływane urządzenie dyskowe używa nazwy formatu "sdXN", gdzie X jest literą a-z, a N jest opcjonalnym numerem partycji, oznacza to, że dysk jest nieprzetworzony i może być obsługiwany przy użyciu ścieżki /dev/sdXN .

Jeśli instalowane urządzenie dyskowe używa nazwy takiej jak /dev/mapper/vgname/lvname, /dev/vgname/lvname lub dm-N, oznacza to, że jest używane urządzenie LVM. Pamiętaj, aby rozpoznać wszystkie woluminy fizyczne dysku (PV), które mogą być używane.

Nie jest obsługiwane, aby grupa woluminów LVM (VG) zawierała dysk systemu operacyjnego i dowolną liczbę dysków danych. W takim scenariuszu istnieje wysokie ryzyko utraty danych. Jednak wiele dysków danych jest dozwolonych w maszynie wirtualnej LVM.

Podczas określania mapowania odwołań dysków systemu operacyjnego do obiektów dysków platformy Azure:

• W przypadku obrazów z witryny Marketplace główny system plików (/), /boot i /boot/efi znajduje się na dysku systemu operacyjnego.
• W przypadku obrazów opartych na systemie LVM może istnieć wiele innych instalacji systemowych, takich jak /home, /tmp, /usr, /var, /var/log i /opt.
• Dodatkowe systemy plików utworzone dla aplikacji znajdują się na dyskach danych, na przykład /data, /datadisk lub /sap. Skonfiguruj je prawidłowo, aby system mógł się uruchomić nawet wtedy, gdy wystąpi błąd. Jeśli dysk danych jest urządzeniem uruchamianym w trybie awaryjnym, zobacz Zapobieganie awarii rozruchu.

Identyfikowanie typu systemu plików

Podczas początkowej identyfikacji jedyną metodą określania typu dysku jest użycie dziennika szeregowego, jak wcześniej zbadano w sekcji Identyfikowanie, który dysk jest uszkodzony. Gdy urządzenie dysku jest zgłaszane w dzienniku szeregowym, błędy będą wyświetlane z modułu jądra systemu Linux dla systemu plików. Zanotuj każdy wiersz, w którym EXT4-fs określono lub XFS . W przypadku innych typów systemu plików dziennik znajduje się w tym samym obszarze. System plików zanotowany we wpisach dziennika jest określany przez plik /etc/fstab . Podczas wykonywania naprawy upewnij się, że określony format jest poprawny.

Po uzyskaniu dostępu do interaktywnej powłoki uruchom lsblk polecenie z -f flagą w następujący sposób, aby wyświetlić urządzenia, ścieżki (jeśli system plików jest zainstalowany) i typ systemu plików odczytany z samego dysku.

[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

Oto kilka ważnych punktów w danych wyjściowych:

• Korzystając z wyświetlacza sztuki ASCII, można zobaczyć, że istnieją woluminy LVM, ponieważ istnieje LVM2_MEMBER FSTYPE dla sda4 zawierających obiekty o nazwach takich jak rootvg-rootlv i rootvg-homelv.
• rootvg-homelv nie jest zainstalowany, co jest oznaczane pustym polem MOUNTPOINT.
• rootvg-homelv ma typ systemu plików XFS. Jest to kontrast z błędem instalacji EXT4 podczas rozruchu. Jeśli typ systemu plików jest niespójny, ufaj danym wyjściowym lsblk , a nie zawartości fstab.

Wybieranie trybu odzyskiwania

Maszynę wirtualną można odzyskać w trybie online w trybie awaryjnym, trybie pojedynczego użytkownika lub w trybie offline przy użyciu ratunkowej maszyny wirtualnej.

Wymagania dotyczące odzyskiwania online

• Dostęp konsoli szeregowej do maszyny wirtualnej.

• Jeśli jest używany tryb awaryjny, konsola szeregowa musi wyświetlić monit o tryb awaryjny, konto główne musi zostać odblokowane, a hasło musi być znane.

• Jeśli jest używany tryb pojedynczego użytkownika, hasło główne nie jest potrzebne. Tryb pojedynczego użytkownika może być używany, gdy system plików inny niż wymagane partycje systemowe, takie jak główny (/) lub /usr jest uszkodzony.

Wymagania dotyczące odzyskiwania w trybie offline

Jeśli nie można spełnić wymagań konsoli szeregowej dotyczących odzyskiwania w trybie online, wykonaj odzyskiwanie w trybie offline przy użyciu maszyny wirtualnej ratowniczej. Aby można było przeprowadzić odzyskiwanie w trybie offline, wymagana jest możliwość tworzenia maszyny wirtualnej i zarządzania dyskami na platformie Azure. Alternatywnie możesz użyć działającej maszyny wirtualnej z systemem Linux z dostępem na poziomie platformy Azure do uszkodzonych dysków.

Przygotowywanie środowiska do odzyskiwania w trybie online

Gdy tryb awaryjny jest wyświetlany w wierszu polecenia logowania w następujący sposób, wprowadź hasło główne:

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

Jeśli hasło główne nie jest znane lub konto główne jest zablokowane, jak w poniższych danych wyjściowych, użyj trybu jednego użytkownika:

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.

Jeśli środowisko odzyskiwania online jest bezużyteczne, przejdź do odzyskiwania w trybie offline.

Przygotowywanie środowiska do odzyskiwania w trybie offline

Na maszynach wirtualnych z pojedynczym dyskiem lub gdy instalacja kończy się niepowodzeniem, jest partycja systemowa, taka jak główny system plików (/) lub /usr, najbardziej niezawodną metodą naprawy dysku jest użycie maszyny wirtualnej ratowniczej w celu uzyskania dostępu do dysku. Maszynę wirtualną ratunkową można utworzyć automatycznie lub ręcznie.

Aby zautomatyzować tworzenie maszyny wirtualnej ratowniczej, zobacz Naprawa maszyny wirtualnej platformy Azure. Aby ręcznie utworzyć maszynę wirtualną ratunkową, zobacz tworzenie maszyny wirtualnej odzyskiwania. W obu przypadkach nie należy zainstalować woluminów z dysku problemu, ponieważ nie można zainstalować systemu plików, aby narzędzia naprawcze działały.

Wykonywanie naprawy systemu plików

Przed naprawą systemu plików upewnij się, że wykonano następujące kroki:

• Zidentyfikowano problem z dyskiem i partycją lub strukturą woluminu LVM.
• Typ systemu plików został określony.
• (Opcjonalnie) Kopia dysku problemu lub dysków w grupie woluminów LVM została dołączona do maszyny wirtualnej ratowniczej.
• Dostęp do interaktywnej powłoki został zabezpieczony przy użyciu dostępu do dysku.

Aby przeprowadzić naprawę systemu plików, przejdź do pozycji Napraw system plików ext4 lub Napraw system plików XFS zgodnie z typem systemu plików.

Niezależnie od używanego trybu odzyskiwania polecenia służące do naprawy systemu plików są takie same. Powłoka awaryjna może mieć ograniczenia. Jeśli polecenia nie są dostępne w środowisku trybu awaryjnego lub występują błędy dotyczące nieznanych typów systemów plików, przygotuj środowisko do odzyskiwania w trybie offline.

Polecenia naprawy systemu plików mogą nie naprawić wszystkich błędów. Działają one wokół uszkodzeń dysku, ale nadal może wystąpić utrata danych. Gdy dane wyjściowe polecenia wykażą, że system plików jest czysty, ponownie zmontuj oryginalną maszynę wirtualną z naprawionym dyskiem i uruchom maszynę wirtualną w celu zweryfikowania danych.

W poniższych sekcjach jest uszkodzony system plików /dev/sdc1 w trybie pierwotnym, a LV homelv w sieci wirtualnej rootvg jest woluminem LVM. Zastąp te wartości rzeczywistym uszkodzonym systemem plików we wszystkich wystąpieniach.

Naprawianie systemu plików ext4

Użyj polecenia , fsck [-y] FILESYSTEM aby naprawić system plików ext4. Określ system plików jako partycję dysku dla nieprzetworzonego systemu plików, na przykład /dev/sdc1, lub ścieżkę /dev/rootvg/homelvwoluminu logicznego LVM .

Oto przykład danych wyjściowych polecenia:

[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 ~]#

Dane wyjściowe pokazują, że potwierdzenie modyfikacji systemu plików jest wymagane trzy razy. Jeśli istnieje wiele żądań, naciśnij klawisze CTRL+C i uruchom ponownie fsck z -y flagą, aby założyć "tak" dla wszystkich pytań. Jeśli jakiekolwiek pliki są zgłaszane jako umieszczone w lost+foundprogramie , ręcznie je zidentyfikuj i umieść w odpowiednich lokalizacjach.

Jeśli wystąpią pewne błędy, a następnie zostaną naprawione, uruchom fsck polecenie ponownie. Powtarzaj, aż fsck polecenie zakończy działanie ze stanem clean . Skorzystaj z następujących danych wyjściowych jako przykładu:

[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 ~]#

Naprawianie systemu plików xfs

Poniżej przedstawiono polecenia naprawy systemu plików XFS:

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

Aby naprawić system plików XFS, wykonaj następujące kroki:

1. Sprawdź błędy systemu plików przy użyciu xfs_repair -n polecenia w następujący sposób:

   xfs_repair -n /dev/rootvg/homelv
   

2. Jeśli sprawdzanie zakończy się pomyślnie, przejdź do trybu naprawy, usuwając -n flagę, która spróbuje naprawić wszelkie napotkane błędy w następujący sposób:

   xfs_repair /dev/rootvg/homelv
   

W przypadku systemów plików XFS zmiany w dziennikach, ale niezatwierdzone są rozwiązywane przez instalowanie systemu plików. Jeśli podczas rozwiązywania problemów wystąpi następujący błąd, spróbuj zainstalować i wyświetlić wyniki.

BŁĄD: System plików ma cenne zmiany metadanych w dzienniku, które należy odtworzyć

Jeśli używana jest maszyna wirtualna odzyskiwania, utwórz katalog tymczasowego punktu instalacji, takiego jak /recovery, i zainstaluj system plików. Jeśli środowisko odzyskiwania jest w trybie awaryjnym lub pojedynczym użytkownikiem, zainstaluj system plików w zamierzonej lokalizacji. Zapoznaj się z następującymi poleceniami jako przykładami:

mount /dev/rootvg/homelv /recovery

lub

mount /home

Jeśli zmiany w dzienniku nie są zapisywane podczas instalowania systemów plików, użyj -L flagi, aby odrzucić dziennik i zainstalować system plików tak, jakby wszystkie zmiany zostały pomyślnie zakończone. Gdy flaga -L zostanie użyta, nastąpi utrata danych, ponieważ dziennik pokazuje, że niekompletne operacje na plikach są odrzucane.

xfs_repair -L /dev/rootvg/homelv /recovery

Zapobieganie awarii rozruchu

nofail Jeśli opcja zostanie określona podczas instalowania systemów plików, uszkodzenie niekrycyjnego systemu plików może nie uniemożliwić pełnego rozruchu systemu Linux. Aby uzyskać więcej informacji na temat nofailprogramu , zobacz Instalowanie dysku. Większość instalacji oprócz katalogu głównego (/), /usri /var można to zrobić za pomocą nofailpolecenia .

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii platformy Azure.