排查文件系统错误导致的 Linux 虚拟机启动问题

项目
07/30/2024

适用于：✔️ Linux VM

本文提供有关排查文件系统错误导致的 Linux 虚拟机（VM）启动问题的指南。

现象

无法使用安全外壳协议（SSH）连接到 Azure Linux 虚拟机（VM），或者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。若要修复磁盘损坏，请执行以下步骤：

确定哪个磁盘已损坏。
标识文件系统类型。
选择恢复模式（联机或脱机）。
根据选择的恢复模式准备恢复环境：
- 准备用于联机恢复的环境
- 为脱机恢复准备环境
使用命令行工具修复磁盘上有问题的文件系统。
- 修复 ext4 文件系统
- 修复 xfs 文件系统
注意
- 备份关键数据非常重要，因为恢复的磁盘上可能发生数据丢失。
- 在对磁盘进行更改之前，请拍摄快照以保留磁盘的当前状态，即使它处于错误状态也是如此。修复磁盘损坏将更改磁盘上的数据，这将造成风险。

确定哪些磁盘已损坏

若要确定磁盘已损坏，请使用串行控制台或启动诊断下载 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/lvname 或 dm-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 内核模块显示错误。记下每个行，其中 EXT4-fs 或 XFS 指定了每行。对于任何其他文件系统类型，日志位于同一区域。日志条目中记下的文件系统由 /etc/fstab 文件确定。请注意，在执行修复时，验证指定的格式是否正确。

访问交互式 shell 后，按如下所示运行 lsblk 带有标志的 -f 命令，以显示设备、路径（如果装载了文件系统），以及从磁盘本身读取的文件系统类型。

[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-rootlv 和 rootvg-homelv。
rootvg-homelv 未装载，由空 MOUNTPOINT 字段表示。
rootvg-homelv 具有文件系统类型 XFS。这与启动过程中的 EXT4 装载错误形成鲜明对比。如果文件系统类型不一致，请信任 lsblk 输出而不是 fstab 的内容。

选择恢复模式

可以通过紧急模式或单用户模式或使用救援 VM 脱机恢复 VM。

联机恢复的要求

串行控制台对 VM 的访问。
如果使用紧急模式，串行控制台必须显示紧急模式提示，必须解锁根帐户，并且密码必须已知。
如果使用单用户模式，则不需要根密码。当文件系统（例如根（/） /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。
通过使用对磁盘的访问来保护对交互式 shell 的访问。

若要执行文件系统修复，请转到根据文件系统类型修复 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，并使用-y标志重启fsck以假定所有问题为“是”。如果报告任何文件被置于其中 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 文件系统，请执行以下步骤：

使用 xfs_repair -n 命令检查文件系统错误，如下所示：
```
xfs_repair -n /dev/rootvg/homelv
```
如果检查成功，请通过删除 -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 社区支持。你还可以将产品反馈提交到 Azure 反馈社区。

通过