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 和实际存储结构是否一致。
