fstab 中 pass 字段值非0且对应设备异常时，fsck检查失败会导致启动卡在emergency mode；需配合fsck.mode=skip、注释pass列或修改后执行systemctl daemon-reload才能跳过。
为什么 fstab 里的 pass 字段会卡住启动
Linux 启动时，fsck 会在挂载前按 /etc/fstab 第六列（pass）决定是否检查文件系统。值为 0 表示跳过，1 是根分区专用，2+ 表示普通分区按顺序检查。一旦某一分区检查失败（比如设备不存在、文件系统损坏、UUID 错误），systemd 就会中止启动流程，直接进 emergency mode。
临时跳过 fsck 检查的三种方法
不是所有场景都适合永久禁用检查，但紧急修复时可快速绕过：
- 启动时在 GRUB 菜单按
e编辑内核参数，在linux行末尾加fsck.mode=skip，然后Ctrl+X启动 —— 这次启动完全跳过所有fsck - 若已进 emergency shell，且根分区已
remount,rw，可临时注释掉/etc/fstab中出问题那行的第六列，比如把UUID=xxx /data ext4 defaults 0 2改成UUID=xxx /data ext4 defaults 0 0 - 更激进但有效：把出错分区的
pass值改成0后，运行systemctl daemon-reload，再exit—— systemd 会重新解析 fstab 并跳过该检查
fsck.mode=force 和 fsck.mode=skip 的实际区别
这两个参数控制的是「是否执行检查」，不是「是否挂载」：
-
fsck.mode=skip：跳过所有fsck调用，哪怕fstab里写的是2也无视；适合确认设备存在但只想先起来再说 -
fsck.mode=force：强制对所有支持的文件系统执行检查，不管pass值是多少；适合怀疑有静默损坏但又没报错的情况 - 注意：
fsck.mode=skip不影响挂载本身 —— 如果 UUID 错了或设备根本不存在，仍会因挂载失败进 emergency，它只管“检查”这一步
改完 pass 值后为什么还要 systemctl daemon-reload
systemd 在启动早期就缓存了 /etc/fstab 的解析结果，直接改文件不会自动刷新。不 reload 的话，即使你把 2 改成 0，下次 exit 继续启动时，systemd 仍按旧缓存执行检查。这个步骤常被忽略，导致反复进 emergency。
真正容易被绕过的点是：很多人只改了 fstab 就 exit，却忘了 reload 单元配置；而 GRUB 参数方式虽然不用 reload，但每次都要手动输，不适合长期使用。
