fsck报“device or Resource busy”需先卸载分区；根文件系统须进recovery模式或用emergency.target；ext4推荐直接用e2fsck -y；superblock校验失败多因断电，先试备份超级块。
fsck 报错 “Device or resource busy” 怎么办
fsck 不能在挂载的分区上运行，这是硬限制。系统会直接拒绝，报错信息就是 Device or resource busy。不是权限问题，也不是磁盘坏了，纯粹是内核锁住了设备。
- 确保目标分区未挂载：用
mount | grep /dev/sdXN检查，如果输出中有对应行，先umount /dev/sdXN - 根文件系统无法手动卸载：必须进 recovery 模式或使用 initramfs 启动项（如加
systemd.unit=emergency.target或 GRUB 中临时改启动参数） - 别试
fsck -f /dev/sdXN强制——加了-f也过不了 busy 检查，只会更快失败
ext4 下该用 e2fsck 还是 fsck
fsck 是通用前端，实际调用哪个子命令取决于文件系统类型；但直接调 e2fsck 更可控，尤其修复时。
-
fsck /dev/sdXN会自动识别类型并调e2fsck，但某些旧系统或定制 initrd 可能没配好fsck.ext4软链，导致 fallback 到只读检查 - 生产环境建议直用
e2fsck -y /dev/sdXN（-y自动确认所有修复），避免依赖fsck的自动分发逻辑 - 注意：
e2fsck不支持 xfs、btrfs 等非 ext 系列，强行用会报错Superblock invalid
“Superblock checksum does not match” 是不是硬盘要坏了
不一定。ext4 默认启用元数据校验和（metadata_csum），校验失败常见于异常断电后日志未刷盘，不等于物理损坏。
- 先试备份超级块：
e2fsck -b 32768 /dev/sdXN（常见备份位置有 32768、98304、163840……可用dumpe2fs -h /dev/sdXN | grep -i "superblock backup"查） - 如果多个备份块都校验失败，再怀疑硬件：运行
smartctl -a /dev/sdX看Reallocated_Sector_Ct和UDMA_CRC_Error_Count - 别一上来就
e2fsck -c扫描坏道——那是针对存储介质物理缺陷的，和 superblock 校验和错误无关，耗时且无必要
修复后启动卡在 “Started File System Check on Root Device”
这通常是 initramfs 里的 fsck 阶段卡住，原因多为修复未完成或配置冲突。
- 检查
/etc/fstab中 root 分区的第 6 列（pass number）是否为 0：如果是，fsck就会被跳过，但 initramfs 可能仍尝试执行，导致超时等待 - 确认 initramfs 是否包含最新
e2fsck：更新内核后记得重生成 initramfs（update-initramfs -u或dracut -f） - 若修复后仍反复触发检查，可能是 journal 损坏残留：加
-E journal=journal_device参数重指定日志位置，或用tune2fs -j /dev/sdXN重建日志
文件系统修复最麻烦的从来不是命令怎么敲，而是得判断「现在能不能修」「该不该现在修」——比如 RAID 阵列里一块盘刚掉线，你急着 e2fsck，可能把还能抢救的数据彻底搞乱。