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