共用方式為


針對因檔案系統錯誤而發生的 Linux 虛擬機器開機問題進行疑難排解

適用於:✔️ Linux VM

本文提供針對文件系統錯誤所造成的Linux虛擬機 (VM) 開機問題進行疑難解答的指引。

徵兆

您無法使用安全殼層通訊協定 (SSH) 連線到 Azure Linux 虛擬機,或 Azure 入口網站 中的 VM 代理程式狀態尚未就緒。 當您在 Azure 入口網站 中執行開機診斷或連線到序列主控台時,您會看到類似下列範例的記錄專案:

注意

  • 並非所有範例都會存在。
  • 掛接失敗不一定會導致 VM 進入緊急模式。 如果問題與特定的重要文件系統發生,VM 可能無法使用緊急模式。

範例 1:無法掛接 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.

範例 2:無法掛接 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.

範例 3:無法掛接 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.

範例 4:開機進入緊急模式

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

原因

上述記錄專案表示磁碟損毀。 在某些情況下,磁碟損毀會防止 VM 完全開機。 各種問題可能會導致磁碟損毀,例如 Linux 核心問題、驅動程式錯誤、基礎實體或虛擬硬體中的錯誤等等。

解決方法

若要解決文件系統錯誤所造成的 Linux VM 開機問題,請修復磁碟損毀來復原 VM。 若要修復磁碟損毀,請遵循下列步驟:

  1. 識別哪些磁碟已損毀

  2. 識別檔案系統類型

  3. 選取 [恢復模式] [在線或脫機]。

  4. 根據您選取的復原模式準備復原環境:

  5. 使用命令行工具來 修復磁碟上有問題的檔案系統

    注意

    • 請務必備份重要數據,因為數據遺失可能發生在復原的磁碟上。
    • 在對磁碟進行變更之前,請建立快照集以保留磁碟的目前狀態,即使它處於錯誤狀態也一樣。 修正磁碟損毀將會變更磁碟上的數據,這會產生風險。

識別哪些磁碟損毀

若要判斷哪個磁碟已損毀,請使用序列控制台或開機診斷下載 VM 的序列記錄檔、在開機期間檢查記錄專案,然後尋找呼叫磁碟或掛接失敗的特定錯誤。

以下是三個記錄專案範例。 在這些範例中,請注意括弧中的文字,其會報告損毀的裝置。

在下列範例中,損毀的裝置為 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.

在下列範例中,發生檔案系統錯誤的分割區是 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.

在下列範例中,損毀的裝置為 dm-2。 它是 Linux 裝置對應程式裝置,表示 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.

如果呼叫的磁碟裝置使用 「sdXN」 格式的名稱,其中 X 是 a-z 的字母,而 N 是選擇性的數據分割編號,表示磁碟是原始的,而且可以使用 /dev/sdXN 路徑操作。

如果掛接的磁碟裝置使用 /dev/mapper/vgname/lvname、/dev/vgname/lvnamedm-N名稱,則表示使用 LVM 裝置。 請小心辨識可能正在使用的所有磁碟實體磁碟區(PV)。

LVM 磁碟區群組 (VG) 不支援包含 OS 磁碟和任意數目的數據磁碟。 針對這類案例,數據遺失的風險很高。 不過,LVM VG 中允許多個數據磁碟。

判斷 OS 磁碟參考與 Azure 磁碟物件的對應時:

  • 針對市集映像,根文件系統 (/)、/boot 和 /boot/efi 位於OS磁碟上。
  • 針對 LVM 型映射,許多其他系統掛接可能存在,例如 /home/tmp/usr/var/var/log/opt
  • 為應用程式建立的額外文件系統位於數據磁碟上,例如 /data/datadisk/sap。 正確設定它們,讓系統即使發生錯誤也能開機。 如果數據磁碟是開機進入緊急模式的裝置,請參閱 防止開機失敗

識別檔案系統類型

在進行初始識別時,判斷磁碟類型的唯一方法是使用序列記錄檔,如先前在識別磁碟損毀檢查過。 在序列記錄檔中報告磁碟裝置時,檔系統的 Linux 核心模組會顯示錯誤。 請記下指定 或 XFS 的每個行EXT4-fs。 對於任何其他文件系統類型,記錄檔位於相同的區域中。 記錄專案中所指出的文件系統是由 /etc/fstab 檔案所決定。 請小心確認執行修復時指定的格式是否正確。

存取互動式殼層之後,請使用-f旗標執行 lsblk 命令,如下所示來顯示裝置、路徑(如果掛接文件系統),以及從磁碟本身讀取的文件系統類型。

[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

以下是輸出中的一些重點:

  • 藉由使用 ASCII 藝術顯示,您可以看到有 LVM 磁碟區,因為 sda4 有一個LVM2_MEMBER FSTYPE,其中包含名稱為 和 rootvg-homelv的物件rootvg-rootlv
  • rootvg-homelv 未掛接,這是由空白 MOUNTPOINT 欄位表示。
  • rootvg-homelv 具有檔案系統類型 XFS。 這與啟動期間 EXT4 掛接錯誤形成鮮明對比。 如果文件系統類型不一致,請信任 lsblk 輸出,而不是 fstab 的內容。

選取復原模式

您可以透過緊急模式或單一使用者模式或使用救援 VM 離線,在線復原 VM。

在線復原的需求

  • 序列 主控台 對 VM 的存取權。

  • 如果使用緊急模式,序列控制台必須顯示緊急模式提示、必須解除鎖定根帳戶,而且必須知道密碼。

  • 如果使用單一使用者模式,則不需要根密碼。 當文件系統以外的系統分割區,例如 root (/) 或 /usr 損毀時,可能會使用單一使用者模式。

離線復原的需求

如果無法符合在線復原的序列主控台需求,請使用救援 VM 執行離線復原。 若要執行脫機復原,必須在 Azure 中建立 VM 和管理磁碟。 或者,您可以使用運作中的Linux VM搭配 Azure 層級存取損毀的磁碟。

準備環境以進行在線復原

當緊急模式顯示在登入提示中時,如下所示,輸入根密碼:

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

如果不知道根密碼,或根帳戶已鎖定,如下列輸出所示,請使用 單一使用者模式

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.

如果在線復原環境無法使用,請繼續進行脫機復原。

準備環境以進行離線復原

在單一磁碟 VM 中,或當失敗掛接是系統磁碟分區,例如根文件系統 (/) 或 /usr時,最可靠的修復磁碟方法是使用救援 VM 來存取磁碟。 您可以自動或手動建立救援 VM。

如需自動建立救援 VM,請參閱 Azure 虛擬機修復。 如需手動建立救援 VM,請參閱 建立復原 VM。 不論是哪一種情況,都不要從問題磁碟掛接磁碟區,因為無法掛接文件系統,修復公用程式才能運作。

執行檔案系統修復

修復檔案系統之前,請確定下列步驟已完成:

  • 已識別出磁碟和磁碟分區或 LVM 磁碟區結構的問題。
  • 已判斷檔案系統類型。
  • (選擇性)問題磁碟或跨 LVM 磁碟群組中的磁碟復本已連結至救援 VM。
  • 使用對磁碟的存取來保護對互動式殼層的存取。

若要執行檔案系統修復,請移至 [修復 ext4 檔案系統 ] 或 [根據檔案系統類型修復 XFS 檔案系統 ]。

無論使用何種復原模式,執行文件系統修復的命令都相同。 緊急殼層可能有限制。 如果命令無法在緊急模式環境中使用,或有未知文件系統類型的錯誤, 請準備環境以進行離線復原

修復檔案系統的命令可能無法修正所有錯誤。 它們可解決磁碟損毀,但數據遺失仍可能發生。 一旦命令輸出指出文件系統已清除,請使用修復的磁碟重新組合原始 VM,然後開機 VM 以驗證數據。

在下列各節中,/dev/sdc1是原始模式中損毀的文件系統,而 VG rootvg 中的 LV homelv 則是 LVM 磁碟區。 將所有實例中實際損毀的文件系統取代這些值。

修復 ext4 文件系統

fsck [-y] FILESYSTEM使用 命令修復 ext4 檔案系統。 將檔案系統指定為原始檔案系統的磁碟分區,例如 /dev/sdc1, 或 LVM 邏輯磁碟區路徑 /dev/rootvg/homelv

以下是命令輸出範例:

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

輸出會顯示要求確認修改檔案系統三次。 如果有許多要求,請按 CTRL+C,並使用 旗標重新啟動fsck-y,以假設所有問題為 「是」。 如果任何檔案回報為放置於 中 lost+found,請手動識別檔案,並將其放在適當的位置。

如果發生某些錯誤並後續修正,請再次執行 fsck 命令。 重複執行, fsck 直到命令以狀態結束 clean 為止。 請參閱下列輸出作為範例:

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

修復 xfs 檔案系統

以下是修復 XFS 檔案系統的命令:

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

若要修復 XFS 文件系統,請遵循下列步驟:

  1. 使用 xfs_repair -n 命令檢查檔案系統錯誤,如下所示:

    xfs_repair -n /dev/rootvg/homelv
    
  2. 如果檢查成功,請移除 -n 旗標以繼續進行修復模式,這會嘗試修正任何遇到的錯誤,如下所示:

    xfs_repair /dev/rootvg/homelv
    

針對 XFS 文件系統,掛接文件系統會處理已日誌但未認可的變更。 如果您在疑難解答期間遇到下列錯誤,請嘗試掛接並檢視結果。

錯誤:文件系統在需要重新執行的記錄檔中有寶貴的元數據變更

如果使用復原 VM,請建立暫存裝入點的目錄,例如 /recovery,並掛接文件系統。 如果復原環境處於緊急或單一使用者模式,請在其預定位置掛接文件系統。 請參閱下列命令作為範例:

mount /dev/rootvg/homelv /recovery

mount /home

如果您在掛接文件系統時未寫入日誌變更,請使用 -L 旗標來捨棄日誌並掛接文件系統,就好像所有變更都成功完成一樣。 -L使用旗標時,因為記錄檔顯示未完成的檔案作業遭到捨棄,所以會發生數據遺失。

xfs_repair -L /dev/rootvg/homelv /recovery

防止開機失敗

nofail如果在掛接文件系統時指定了 選項,非關鍵文件系統的損毀可能無法防止 Linux 完全開機。 如需 的詳細資訊 nofail,請參閱 掛接磁碟。 除了根目錄以外//usr/var,大部分掛接都可以使用 nofail來完成。

與我們連絡,以取得說明

如果您有問題或需要相關協助,請建立支援要求,或詢問 Azure community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。