fstab UUID 写错导致开机 emergency mode 的快速修复命令

fstab中UUID错误会导致启动卡在Started Dispatch Password Requests或进入Emergency Mode，需在emergency shell中remount为rw、用blkid查真实UUID、修改fstab、reload后继续启动。

fstab 里 UUID 错误触发 emergency mode 的典型表现

系统启动卡在 Started Dispatch Password Requests to console Directory Watch. 或直接进入 Emergency Mode，提示类似 Failed to start File System Check on /dev/disk/by-uuid/xxxxx。本质是 /etc/fstab 中某行的 UUID 不指向真实存在的块设备，systemd 尝试挂载失败后放弃默认启动流程。

不用重装、不进 LiveCD 的原地修复方法

只要能输入 root 密码（或有 sudo 权限的用户密码），就能在 emergency shell 里直接修。关键点是：emergency shell 默认以 ro（只读）方式挂载了根文件系统，必须先重新挂载为可写：

• 执行 mount -o remount,rw /
• 用 blkid 列出当前所有块设备的真实 UUID，例如：blkid | grep sda1
• 用 cat /etc/fstab 查看错误行，通常错在 /、/boot 或 /home 对应的 UUID 字段
• 用 nano /etc/fstab（或 vi）修改对应行，把错误 UUID 替换为 blkid 输出中匹配设备的正确值
• 保存退出后执行 systemctl daemon-reload，再 exec systemctl default 继续启动

fstab 中 UUID 和设备路径混用的风险对比

虽然可以用 /dev/sda1 代替 UUID，但不推荐：

• UUID 是稳定标识，设备名（如 sda1）在多盘、热插拔、驱动加载顺序变化时可能漂移
• 但硬编码错误 UUID 比写错设备名后果更严重——后者有时还能 fallback 到 /dev/disk/by-path/，而错 UUID 直接导致挂载逻辑失败
• 验证修改是否合理：改完后运行 mount -a，无输出即成功；若有报错，说明 UUID 仍不匹配或文件系统类型写错（如把 ext4 写成 xfs）

容易被忽略的两个细节

一是 fstab 中 swap 分区也必须用正确 UUID（或 LABEL），错写会导致 swapon 失败并拖慢启动；二是某些发行版（如 RHEL/centos 8+）默认启用 rd.md=0 rd.lvm=0 rd.dm=0 等内核参数，若磁盘实际用了 LVM/RAID，但 fstab 里又没配对，也会在 initramfs 阶段就卡住——这种不属于 UUID 错误，但现象相似，需检查 /proc/cmdline 和实际存储结构是否一致。