linux系统fsck是文件系统底层强制检查机制，不由systemd或crontab管理；真正控制需用tune2fs修改超级块中挂载次数（-c）和时间间隔（-i）参数，/etc/fstab的passno仅影响开机扫描顺序而不覆盖元数据设定。
Linux系统自检（fsck）不是用户“配置”的常规任务，而是由文件系统自身机制触发的强制检查行为。它不归 systemd 或 crontab 管理，也不能通过写脚本“启动”——你只能调整它的触发条件或临时跳过它。
为什么改不了 /etc/fstab 就失效
很多人误以为在 /etc/fstab 中给某一分区加上 fs_passno（第6列）为 0 就能禁用自检，结果发现重启后仍被检查。这是因为：fsck 的实际触发逻辑取决于两个独立参数——挂载次数（max mount count）和时间间隔（check interval），而 /etc/fstab 的 fs_passno 仅决定该分区是否参与 开机时的并行 fsck 扫描流程，不覆盖底层文件系统元数据设定。
常见错误现象：systemd-fsck@xxx.service 启动失败、日志里出现 fsck failed 或反复提示 “Checking filesystem”，本质是 ext2/ext3/ext4 文件系统的挂载计数已超限，或距上次检查已过设定周期。
-
fs_passno = 0：该分区不参与开机 fsck 流程（但若元数据强制要求检查，仍可能被拦截并执行） -
fs_passno = 1：根分区，优先检查 -
fs_passno = 2：其他需检查的分区，顺序执行
tune2fs 是唯一有效干预手段
要真正控制自检行为，必须用 tune2fs 修改文件系统超级块中的元数据。它直接写入磁盘，比任何配置文件都底层、更权威。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
典型操作：
- 永久关闭某设备的自动检查：
tune2fs -c -1 -i 0 /dev/sdb1 - 设为每挂载 30 次检查一次：
tune2fs -c 30 /dev/sdb1 - 设为每 3 周检查一次：
tune2fs -i 3w /dev/sdb1 - 查看当前设置：
tune2fs -l /dev/sdb1 | grep -i "mount count\|check interval"
注意：/dev/sdb1 必须是未挂载状态（umount /dev/sdb1），否则会报错 Device or resource busy；对根分区操作需在 initramfs 环境或 Live USB 下进行。
systemd 不负责 fsck，但会暴露它
systemd 只是把 fsck 包装成一个服务单元（如 systemd-fsck@dev-sda1.service），并在启动早期按依赖顺序调用 fsck 二进制。它不决定“要不要检”，只决定“什么时候调用”。所以：
-
systemctl disable systemd-fsck@dev-sda1.service无效——该 unit 是模板生成的，disable 单个实例不影响下次启动时重建 -
systemd-fsck日志藏在 boot 日志里：journalctl -b | grep fsck才能看到真实输出 - 如果想跳过某次检查，可在 GRUB 启动时加内核参数
fsck.mode=force（强制）或fsck.mode=skip（跳过），仅本次生效
真正容易被忽略的点：fsck 不是“服务”，也不是“脚本任务”，它是文件系统自我保护的硬性机制。你想绕开它，就得直面磁盘元数据；你想让它更安静，就得理解挂载计数和时间间隔如何协同工作——而不是去改 rc.local 或写 cron。
