fsck不能在挂载状态下运行，否则大概率损坏文件系统；报“device or resource busy”错误几乎总是因分区仍挂载，须先用mount或findmnt确认状态，再umount设备节点，根分区需进recovery模式或live cd操作。
不能在挂载状态下运行 fsck，否则大概率损坏文件系统——这是最常被忽略、也最危险的操作前提。
为什么 fsck 报 “Device or resource busy” 错误
这个错误几乎总是因为目标分区仍处于挂载状态。Linux 不允许对正在读写的文件系统做一致性检查，fsck 会直接拒绝执行（哪怕加了 -y 或 -f）。
- 用
mount | grep /dev/sdX1或findmnt /dev/sdX1确认是否挂载； - 若已挂载，必须先执行
umount /dev/sdX1（注意不是umount /mnt/xxx，后者可能因 busy 失败）； - 如果提示 “target is busy”，可用
lsof +D /mount/point或fuser -v /mount/point查看占用进程； - 对于 root 分区，无法在线卸载，只能进 recovery 模式或 Live CD 环境操作。
修复 ext4 根分区的实操路径
当系统启动卡在 UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY，说明 root 文件系统脏了且未自动修复，此时必须人工介入。
- 重启，在 GRUB 菜单按
e编辑启动项，在linux行末尾添加rd.break（RHEL/CentOS）或init=/bin/bash（Ubuntu/Debian），然后Ctrl+X启动； - 进入紧急 shell 后，先执行
mount -o remount,rw /sysroot（RHEL）或mount -o remount,rw /（Ubuntu）； - 再切换环境：
chroot /sysroot或直接操作； - 查根设备名：
findmnt / | awk '{print $1}' | tail -1，通常为/dev/mapper/VolGroup00-LogVol00或/dev/nvme0n1p2； - 执行修复：
fsck -y /dev/xxx—— 注意别用-p，它对严重损坏可能跳过关键修复； - 完成后
exec /sbin/init或reboot -f重启。
fsck 参数选错会导致修复失败甚至丢数据
fsck 是个封装器，实际调用的是 fsck.ext4、fsck.xfs 等具体工具，参数不通用。比如 xfs 文件系统根本不能用 fsck -y 修复——它没有“交互式修复”逻辑，必须用 xfs_repair。
- 先确认类型：
lsblk -f或blkid /dev/sdX1； - ext 系列（ext2/ext3/ext4）可用
fsck -y /dev/sdX1，等价于fsck.ext4 -y /dev/sdX1； - XFS 必须用
xfs_repair /dev/sdX1，且要求设备已卸载，不支持-y，默认即自动处理可修复项； - 若 superblock 损坏（报
Superblock invalid），ext4 需换备份块：e2fsck -b 32768 /dev/sdX1（常用备份位置：8193、32768、131072）； -
-n是安全预演参数，只扫描不修改，适合评估损坏程度。
修复后系统仍无法启动的常见盲点
fsck 成功返回 “clean” 并不等于系统一定能起来——它只保证元数据结构一致，不恢复丢失的文件或修复内核模块依赖。
- 修复完立即
touch /forcefsck并重启，可强制下次启动再扫一次（某些发行版需要）； - 检查
/etc/fstab中 UUID 是否变化：blkid对比，若变了需同步更新，否则启动卡在 “Waiting for /dev/disk/by-uuid/xxx”； - LVM 逻辑卷需确认
vgscan && vgchange -ay是否成功激活卷组； - 若修复后进单用户模式，检查
/etc/passwd和/etc/shadow权限是否被意外改掉（应为 644 / 600）； - 日志里搜
dmesg | grep -i "error\|fail\|ext4\|xfs"，看是否有底层 I/O 故障，那可能是磁盘物理坏道，fsck无能为力。
