VMware ESXi Ubuntu 虚拟机 fsck 修复文件系统损坏

ESXi 平台上的 Ubuntu 虚拟机因异常关机导致 ext4 文件系统损坏，开机后自动进入 (initramfs) 紧急 Shell 无法正常启动。本文记录从问题现象分析到使用 fsck 手动修复文件系统的完整处理流程，以及 ESXi 平台上的最佳实践建议。

目录

• 1. 问题现象
• 2. 原因分析
• 3. 处理方法
• 4. 优化建议

1. 问题现象

VMware ESXi 平台上的 Ubuntu 虚拟机在一次异常关机后，再次开机时无法正常进入系统。

具体表现：

• 虚拟机电源可以正常开启
• 能看到 GRUB 启动菜单，选择启动项后开始加载内核
• 内核加载过程中屏幕上打印大量 SATA link down 信息（虚拟机正常现象，可忽略）
• 随后自动进入 (initramfs) 紧急 Shell，无法继续进入系统

在进入 initramfs Shell 前，屏幕上有以下关键报错：

/dev/sda2 contains a file system with errors, check forced.
Inodes that were part of a corrupted orphan linked list found.

/dev/sda2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
fsck exited with status code 4

Failure: File system check of the root filesystem failed
The root filesystem on /dev/sda2 requires a manual fsck

2. 原因分析

虚拟机在运行过程中遭遇了非正常关机（如 ESXi 宿主机宕机、虚拟机被强制断电、或管理界面直接执行强制关机等操作），导致 ext4 文件系统的元数据写入操作被中断。

Linux 系统在启动时会自动对根分区执行 fsck 文件系统检查。当检测到不一致时，系统会尝试自动修复（-a 模式）。但如果损坏程度超出了自动修复的能力，系统会停止启动并要求管理员手动执行 fsck。

本例中的具体损坏类型是 孤立 inode 链表损坏（corrupted orphan linked list），即文件系统中存在一些 inode 记录指向了已被删除的文件或目录，但这些 inode 没有被正确回收。

2.1 损坏机制示意

正常状态：
  inode 链表: inode_A → inode_B → inode_C → NULL
  每个 inode 指向有效的磁盘块

异常关机后：
  inode 链表: inode_A → inode_B → [损坏的 inode_D] → ???
  inode_D 指向的元数据未写入完成，链表断裂

fsck 的工作就是遍历整个文件系统的元数据结构，找到这些不一致的地方并修复它们。

3. 处理方法

3.1 第一步：在 initramfs Shell 中手动执行 fsck

系统已经停在 (initramfs) 提示符下，直接输入以下命令，对根分区 /dev/sda2 进行手动修复：

fsck -y /dev/sda2

参数说明：

如果一次修复后仍然提示 UNEXPECTED INCONSISTENCY，再执行一次，直到文件系统检查通过。多次执行是正常的，因为每次修复可能暴露出新的不一致。

3.2 第二步：重启系统

reboot

如果 reboot 命令不可用，直接在 ESXi 控制台中重启虚拟机。

3.3 第三步：验证系统正常启动

重启后虚拟机应能正常通过 GRUB 菜单、加载内核、启动 systemd 服务，最终进入系统。可以通过以下命令确认文件系统状态：

# 确认根分区挂载正常
df -h /

# 确认无文件系统错误
dmesg | grep -i "ext4\|error"

4. 优化建议

为了防止异常关机导致文件系统损坏，在 ESXi 平台上应遵循以下最佳实践：

4.1 ESXi 关机方式对比

推荐方式（安全）：
  虚拟机内部 → shutdown / poweroff
  文件系统正确卸载 → 数据安全写入磁盘

不推荐方式（危险）：
  ESXi 管理界面 → 电源 → 关闭客户机
  等同于直接断电 → 文件系统元数据可能未写入完成 → 损坏