通过

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

  • 项目

本文提供了排查 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：无法将外部逻辑卷管理器装载 (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/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 内核模块显示错误。 记下指定 或 XFS 的每EXT4-fs一行。 对于任何其他文件系统类型，日志位于同一区域。 日志条目中记下的文件系统由 /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。

联机恢复的要求

  • 对 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 文件系统，请执行以下步骤：

  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，请参阅 装载磁盘。 除根 (/) 之外/var，/usr大多数装载都可以使用 nofail完成。

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 还可以向 Azure 反馈社区提交产品反馈。