fsck必须在文件系统未挂载时运行，否则极大概率导致二次损坏；对根分区需进单用户模式或救援环境，ext4应优先用e2fsck而非fsck，xfs则必须用xfs_repair。
fsck 必须在文件系统未挂载时运行
直接对已挂载的分区（尤其是 / 根分区）执行 fsck 极大概率导致二次损坏，这是最常被忽略的前提。系统会报错 busy device 或静默跳过关键检查，修复结果不可信。
常见应对方式：
- 对非根分区（如
/home）：先执行umount /dev/sdb1，确认无进程占用（可用fuser -v /home查看） - 对根分区
/：必须进单用户模式或救援环境，不能靠reboot后立刻跑fsck—— 此时内核已自动挂载，fsck无法获得独占访问权 - 某些发行版（如 RHEL/CentOS）支持
systemctl rescue进入最小化维护环境，比光盘救援更快
Ext4 分区该用 fsck 还是 e2fsck？
fsck 是前端调度器，实际调用的是对应文件系统的专用工具。对 Ext2/3/4，它默认调用 e2fsck；你手动执行 e2fsck 反而更可控，参数也更精准。
关键区别：
-
fsck -t ext4 /dev/sda1和e2fsck /dev/sda1效果相同，但后者能用更多底层参数 -
-f必须加：Ext4 默认只在“dirty”标记置位时才检查，异常断电后可能未置位，不加-f会直接跳过 -
-y要慎用：自动确认所有修复动作，但如果遇到严重 inode 损坏（如链接计数为负），-y可能强制清空整个文件，而非尝试恢复 - 真正需要交互时，用
-p（等价于-a）比-y更安全：它只对“明确可安全修复”的错误自动处理，其余暂停等待确认
看到 “UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY” 怎么办
这是 init 进程在启动早期检测到文件系统元数据不一致时抛出的致命提示，意味着内核拒绝继续挂载，必须人工介入。此时系统卡在命令行界面，光标闪烁但无响应。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
操作要点：
- 不要反复按回车或 Ctrl+C，这不会跳过检查
- 输入 root 密码登录（若启用 root shell），然后立即执行：
fsck -f /dev/mapper/VolGroup00-LogVol00（路径需根据mount | grep "on /"确认） - 如果提示 “
/dev/xxx is mounted”，说明你没进对环境 —— 必须用systemctl rescue或光盘启动进救援模式再chroot /mnt/sysimage - 修复完成后，务必执行
exit退出 chroot，再reboot -f强制重启，避免残留挂载状态
XFS 文件系统不能用 fsck
fsck 对 XFS 完全无效，强行运行只会报错 fsck.xfs: not found 或直接忽略。XFS 使用完全不同的日志与修复机制，必须用 xfs_repair。
注意点：
-
xfs_repair同样要求目标设备未挂载，且不能用于已损坏的 XFS 日志（此时需先用xfs_repair -L清空日志，但会丢失未提交事务） - 若
xfs_info /dev/sdb1显示logdev是单独设备，修复时得同时指定：xfs_repair /dev/sdb1 -l /dev/sdc1 - XFS 不支持“只读检查”模式；
-n参数仅做试运行（dry-run），仍需卸载，且不保证覆盖所有一致性路径
真正麻烦的从来不是命令本身，而是判断「这个分区到底属于哪种文件系统」和「它此刻是否真的处于可安全修复的状态」——这两个问题没搞清，后面所有参数都白搭。
