强制关机导致 Linux 系统进入紧急模式（Emergency Mode）？XFS 元数据损坏修复全流程

适用系统：银河麒麟（Kylin OS）、统信 UOS、CentOS、RHEL 等基于 XFS + LVM 的 Linux 发行版 故障现象：系统启动卡在 Emergency Mode，提示输入 root 密码 根本原因：强制断电导致 XFS 文件系统元数据损坏 修复难度：⭐⭐☆☆☆（照着做就能修）

一、背景：一次强制关机引发的"血案"

很多 Linux 服务器或国产化桌面用户都遇到过这样的场景：

系统卡死 → 长按电源键强制关机 → 再次开机 → 屏幕一片红，停在 Emergency Mode。

这不是系统"坏了"，而是 XFS 文件系统在强制断电后检测到元数据不一致，出于数据安全考虑拒绝挂载根分区，主动进入紧急模式等待管理员修复。

本文将基于一次真实的故障现场（银河麒麟 V11，内核 6.6.0），完整记录从 现象识别 → 日志分析 → XFS 修复 → 正常启动 的全流程，可作为运维排障的标准参考。

二、故障现象识别

系统启动过程中，屏幕显示如下信息：

Loading Linux 6.6.0-32.7.v2505.ky11.x86_64 ...
Loading initial ramdisk ...
Generating "/run/initramfs/rdsosreport.txt"

Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.

Give root password for maintenance
(or press Control-D to continue):

关键判断：

✅ 好消息：系统内核已加载，只是根文件系统挂载失败。数据大概率还在，修复即可。

三、日志分析：定位根因

在紧急模式提示符下输入 root 密码，进入 # shell。

3.1 过滤关键错误日志

journalctl -xb -p err..alert --no-pager

3.2 核心错误解读

屏幕输出的关键错误如下：

XFS (dm-0): Metadata corruption detected at __xfs_dir3_data_check+0x723/0x880 [xfs]
XFS (dm-0): Unmount and run xfs_repair
XFS (dm-0): Corruption of in-memory data (0x8) detected at _xfs_buf_ioapply+0xdb7/0xdd0 [xfs]
XFS (dm-0): Please unmount the filesystem and rectify the problem(s)
systemd[1]: Failed to mount /sysroot.

逐行解读：

✅ 结论：根文件系统（/sysroot）位于 LVM 逻辑卷 dm-0 上，XFS 元数据损坏，需要执行 xfs_repair。

四、修复流程（核心操作）

4.1 确认设备路径

ls -l /dev/mapper/

典型输出（银河麒麟系统）：

lrwxrwxrwx 1 root root 7 Apr 10 16:22 klas-root -> ../dm-0

说明根分区逻辑卷名为 klas-root，对应设备 /dev/mapper/klas-root。

也可以用 lsblk -f 或 blkid | grep xfs 交叉确认。

4.2 卸载分区（如已挂载）

umount /dev/mapper/klas-root

若提示 target is busy，可强制卸载：

umount -l /dev/mapper/klas-root

⚠️ 紧急模式下根分区通常未完全挂载，此步可跳过直接修复。

4.3 执行 XFS 修复

方法一：标准修复（推荐首选）

xfs_repair /dev/mapper/klas-root

• 过程持续数秒到数分钟，取决于分区大小。
• 不要中断，等待输出 Phase 7 完成。

方法二：强制修复（标准修复失败时使用）

如果标准修复报错提示日志需要重放（log needs replay），使用：

xfs_repair -L /dev/mapper/klas-root

🚨 -L 参数说明：

• 作用：强制清空 XFS 日志（log zeroing）
• 风险：可能丢失最近未刷盘的数据（最后一次正常操作之后的写入）
• 适用：数据已不重要，或标准修复无法推进时
• 这是修复严重损坏的最后手段，但通常是唯一能救回系统的方法

4.4 验证修复结果

mkdir /mnt/test
mount /dev/mapper/klas-root /mnt/test
ls /mnt/test

能看到 /etc、/bin、/usr 等目录 → 修复成功 ✅

4.5 重启

reboot

系统正常进入登录界面，修复完成 🎉

五、完整命令速查表

# ===== 进入紧急模式后，依次执行 =====

# 1. 确认根分区设备
ls -l /dev/mapper/

# 2. 卸载（可选）
umount /dev/mapper/klas-root 2>/dev/null || umount -l /dev/mapper/klas-root

# 3. 标准修复
xfs_repair /dev/mapper/klas-root

# ↑ 若失败，执行强制修复：
# xfs_repair -L /dev/mapper/klas-root

# 4. 重启
reboot

六、忘记 root 密码？GRUB 单用户模式重置

如果不知道 root 密码，无法进入紧急模式的维护 shell，可通过 GRUB 重置：

1. 开机进入 GRUB 菜单，选中内核按 e 编辑。
2. 找到 linux 或 linux16 开头的行。
3. 将 ro 改为 rw init=/bin/bash：

# 修改前
linux16 /vmlinuz-... root=/dev/sda1 ro quiet splash
# 修改后
linux16 /vmlinuz-... root=/dev/sda1 rw init=/bin/bash quiet splash

1. 按 Ctrl+X 启动。
2. 进入 shell 后执行：

mount -o remount,rw /
passwd root
sync
reboot -f

七、救援模式修复（无法进入 GRUB 时）

使用 Live USB（麒麟/CentOS 安装盘）启动：

1. 选择 "Troubleshooting" → "Rescue a system"。
2. 进入救援 shell 后：

vgchange -ay                          # 激活 LVM 卷组
ls /dev/mapper/                       # 确认逻辑卷
xfs_repair /dev/mapper/klas-root      # 执行修复
reboot

八、根因复盘与预防建议

为什么强制关机会导致 XFS 损坏？

💡 相比之下，EXT4 在类似情况下通常会自动 fsck 修复；而 XFS 的设计哲学是 "宁可停服，不可丢数据"，所以主动进入紧急模式。

预防措施

九、总结

写在最后：Linux 的紧急模式不是"系统崩溃"，而是系统在替你守护数据。理解它的提示信息，掌握 xfs_repair 的使用，你就能在关键时刻把系统从"死亡边缘"拉回来。

本文基于银河麒麟 V11 + XFS + LVM 环境实测整理，同样适用于 CentOS 7/8、RHEL、Rocky Linux 等发行版。如有问题欢迎留言交流。 🙌