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

Dotyczy: ✔️ maszyny wirtualne z systemem Linux

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

Objawy

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

Uwaga

• Nie wszystkie przykłady będą obecne.
• Awaria instalowania nie zawsze powoduje, że maszyna wirtualna wchodzi 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 menedżera woluminów logicznych (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ą na 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 w 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. Zidentyfikuj, który dysk jest uszkodzony.

2. Identyfikowanie typu systemu plików.

3. Wybierz pozycję 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

   • Ważne jest, aby utworzyć kopię zapasową krytycznych danych, ponieważ utrata danych może wystąpić na odzyskanym dysku.
   • Przed wprowadzeniem zmian na dysku utwórz 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 seryjny dla maszyny wirtualnej przy użyciu konsoli szeregowej lub diagnostyki rozruchu, sprawdź wpisy dziennika podczas rozruchu, a następnie poszukaj określonego błędu, który powoduje niepowodzenie dysku lub instalacji.

Oto trzy przykłady wpisu 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 urządzenie dysku, które jest wywoływane, używa nazwy formatu "sdXN", gdzie X jest literą z a-z i N jest opcjonalnym numerem partycji, oznacza to, że dysk jest nieprzetworzona i może być obsługiwana przy użyciu ścieżki /dev/sdXN .

Jeśli instalowane urządzenie dysku używa nazwy takiej jak /dev/mapper/vgname/lvname, /dev/vgname/lvname lub dm-N, oznacza to, że używane jest urządzenie LVM. Należy pamiętać o rozpoznaniu wszystkich woluminów fizycznych dysku (VV), 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 duże ryzyko utraty danych. Jednak w przypadku maszyn wirtualnych LVM dopuszczalne jest wiele dysków danych.

Podczas określania mapowania odwołań dysku 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 znajdują się na dysku systemu operacyjnego.
• W przypadku obrazów opartych na LVM wiele innych instalacji systemowych może istnieć, 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ł uruchomić się nawet wtedy, gdy wystąpi błąd. Jeśli dysk danych jest urządzeniem, które uruchamia się w trybie awaryjnym, zobacz zapobieganie awarii rozruchu.

Określanie typu systemu plików

Podczas początkowej identyfikacji jedyną metodą określania typu dysku jest użycie dziennika szeregowego, jak pokazano wcześniej w artykule Identyfikowanie, który dysk jest uszkodzony. Gdy urządzenie dysku jest zgłaszane w dzienniku seryjnym, 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 lub XFS jest określony. W przypadku innych typów systemów plików dziennik znajduje się w tym samym obszarze. System plików zanotowany w wpisach dziennika jest określany przez plik /etc/fstab . Upewnij się, że określony format jest poprawny podczas naprawy.

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

Poniżej przedstawiono kilka ważnych kwestii w danych wyjściowych:

• Za pomocą wyświetlacza sztuki ASCII widać, że istnieją woluminy LVM, ponieważ istnieje LVM2_MEMBER FSTYPE dla sda4 zawierające obiekty o nazwach takich jak rootvg-rootlv i rootvg-homelv.
• rootvg-homelv nie jest zainstalowany, co jest oznaczone 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 lsblk danych wyjściowych, a nie zawartości pliku fstab.

Wybieranie trybu odzyskiwania

Maszynę wirtualną można odzyskać w trybie online za pomocą trybu awaryjnego lub trybu pojedynczego użytkownika albo w trybie offline przy użyciu maszyny wirtualnej ratowniczej.

Wymagania dotyczące odzyskiwania w trybie online

• Dostęp konsoli szeregowej do maszyny wirtualnej.

• Jeśli jest używany tryb awaryjny, konsola szeregowa musi wyświetlić monit trybu awaryjnego, konto główne musi być 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 root (/) lub /usr jest uszkodzony.

Wymagania dotyczące odzyskiwania w trybie offline

Jeśli nie można spełnić wymagań konsoli szeregowej na potrzeby odzyskiwania w trybie online, wykonaj odzyskiwanie w trybie offline przy użyciu maszyny wirtualnej ratowniczej. Aby przeprowadzić odzyskiwanie w trybie offline, wymagana jest możliwość tworzenia maszyny wirtualnej i zarządzania dyskami na platformie Azure. Alternatywnie można 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, tak jak w następujących danych wyjściowych, użyj trybu pojedynczego 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

W przypadku maszyn wirtualnych z jednym dyskiem lub awarii instalacji 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 uzyskać informacje na temat automatycznego tworzenia maszyny wirtualnej ratowniczej, zobacz Naprawa maszyny wirtualnej platformy Azure. Aby uzyskać instrukcje ręcznego tworzenia maszyny wirtualnej ratowniczej, zobacz tworzenie maszyny wirtualnej odzyskiwania. W obu przypadkach nie należy instalować woluminów z dysku problemu, ponieważ system plików nie może być zainstalowany w celu naprawy narzędzi do działania.

Wykonaj naprawę systemu plików

Przed naprawą systemu plików upewnij się, że zostały wykonane następujące kroki:

• Zidentyfikowano dysk problemu i partycję lub strukturę woluminu LVM.
• Typ systemu plików został określony.
• (Opcjonalnie) Kopia dysku problemu lub dysków w rozproszonej 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 sekcji Napraw system plików ext4 lub Napraw system plików XFS zgodnie z typem systemu plików.

Niezależnie od tego, jaki tryb odzyskiwania jest używany, polecenia do wykonania naprawy systemu plików są takie same. Powłoka ratunkowa 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 systemu plików, przygotuj środowisko do odzyskiwania w trybie offline.

Polecenia do naprawy systemu plików mogą nie naprawiać wszystkich błędów. Działają one wokół uszkodzeń dysku, ale nadal może wystąpić utrata danych. Gdy w danych wyjściowych polecenia zostanie wyświetlony komunikat, że system plików jest czysty, ponownie utwórz oryginalną maszynę wirtualną z naprawionym dyskiem i uruchom maszynę wirtualną, aby zweryfikować dane.

W poniższych sekcjach /dev/sdc1 jest uszkodzony system plików w trybie nieprzetworzonym, a LV homelv w sieci wirtualnej rootvg to wolumin 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 żądanie modyfikacji systemu plików jest wymagane trzy razy. Jeśli istnieje wiele żądań, naciśnij CTRL+C i uruchom ponownie fsck z flagą -y , aby założyć "tak" na wszystkie pytania. Jeśli jakiekolwiek pliki są zgłaszane jako umieszczane w programie lost+found, należy je ręcznie zidentyfikować i umieścić w odpowiednich lokalizacjach.

Jeśli wystąpią jakieś błędy, a następnie zostaną naprawione, uruchom fsck ponownie polecenie. Powtarzaj, fsck aż polecenie zakończy działanie ze stanem clean . Zapoznaj się z następującymi przykładowymi danymi wyjściowymi:

[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 umożliwiające naprawę 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, kontynuuj pracę z trybem naprawy, usuwając flagę -n , 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 dzienniku, ale niezatwierdzone są obsługiwane przez zainstalowanie 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 zawiera cenne zmiany metadanych w dzienniku, który należy odtworzyć

Jeśli używana jest maszyna wirtualna odzyskiwania, utwórz katalog dla tymczasowego punktu instalacji, takiego jak /recovery, i zainstaluj system plików. Jeśli środowisko odzyskiwania jest w trybie awaryjnym lub w trybie pojedynczego użytkownika, 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 dziennikowane zmiany 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 ukończone pomyślnie. Gdy flaga -L zostanie użyta, utrata danych wystąpi, ponieważ dziennik pokazuje, że niekompletne operacje na plikach są odrzucane.

xfs_repair -L /dev/rootvg/homelv /recovery

Zapobieganie awarii rozruchu

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

Skontaktuj się z nami, aby uzyskać pomoc

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