fsck 运行前必须卸载文件系统，否则可能损坏数据；应使用 e2fsck 而非通用 fsck 检查 ext4，优先自动修复（-p），遇 journal 问题需 -y 手动确认；“in use”提示多因 LVM/LUKS 占用，须先关闭相关设备；修复后仍无法启动常因 fstab、initramfs 或 grub 配置错误。
fsck 运行前必须卸载文件系统
直接对已挂载的分区跑 fsck，大概率会把文件系统搞坏，不是警告，是真实风险。Linux 内核在挂载状态下持续缓存和写入元数据，fsck 读到的可能是不一致的中间状态。
- 检查是否挂载：用
mount | grep /dev/sdX1或findmnt /path/to/mount - 安全做法：从 Live USB 启动，或单用户模式下执行（
systemctl rescue后umount /dev/sdX1） - 根分区无法卸载？只能用
fsck -f /加force参数——但仅限于系统刚崩溃重启后、自动检测失败时手动补救，且需确认没人在写盘
ext4 下优先用 e2fsck 而非通用 fsck
fsck 本身只是个调度器，实际调用哪个具体工具取决于文件系统类型。对 ext2/3/4，e2fsck 更精准、选项更全，也更稳定。
- 直接调用：
e2fsck -p /dev/sdX1（自动修复可安全处理的问题） -
-c检测坏块，-D优化目录结构，-f强制检查（跳过“干净”标记） - 别用
fsck -t ext4—— 它可能绕过e2fsck的某些关键逻辑，尤其在 journal 损坏时恢复能力弱 - 错误信息里如果出现
journal has been deleted或recovery required，说明得靠e2fsck -y手动确认修复
“/dev/sdX is apparently in use” 错误怎么破
这个提示不是说设备正被程序读写，而是内核还持有该块设备的引用——常见于 LVM、加密卷（LUKS）、快照或残留的 device-mapper 映射。
- 查占用：
lsof +D /mount/point（如果还能挂载）、dmsetup ls、losetup -a - LVM 卷要先
vgchange -an vgname；LUKS 卷先cryptsetup close name - 遇到
device-mapper: remove ioctl failed？试试echo 1 > /sys/block/dm-X/device/delete（谨慎，仅限确定无依赖时） - 虚拟机里挂载的磁盘镜像，宿主机上也要确保没进程（如
qemu-img、guestmount）正在访问它
fsck 后系统仍无法启动的常见盲区
修复完文件系统不等于系统能起来。很多问题藏在更底层：initramfs 没更新、grub 配置错、/etc/fstab 里 UUID 变了或路径失效。
- 进不了系统？先用 Live 环境挂载根分区，检查
/etc/fstab是否有拼写错误或旧 UUID（用blkid核对） - 修复后黑屏或卡在 initramfs 提示符？很可能
update-initramfs -u没运行，或者grub-install和update-grub漏了 - ext4 启用了
metadata_csum但老内核不支持？dmesg | grep -i "checksum"看有没有报错，必要时用tune2fs -O ^metadata_csum关闭（仅临时救急）
fsck 命令本身，而是它背后那一整套设备状态、挂载依赖和启动链路。修完一个分区，顺手 check 一遍 fstab 和 initramfs，比反复跑 e2fsck -f 有用得多。 
