紧急模式下先用 journalctl -xb | grep mount 定位 fstab 挂载错误，再用 blkid 和 lsblk -f 验证 uuid 是否真实存在，修改前 remount 根分区为可写，改后执行 mount -a 验证，非关键挂载点加 nofail 防卡死。
直接进紧急模式后输 root 密码，别急着改配置——90% 的情况是 /etc/fstab 里某一行挂载失败，而最常见的是 UUID 不匹配或设备根本不存在。先确认问题再动手，否则越修越卡。
journalctl -xb | grep mount 能快速定位哪行 fstab 出了问题
登录紧急模式后第一件事不是 vi /etc/fstab，而是看日志：
-
journalctl -xb | grep mount会直接打出挂载失败的路径和错误，比如Failed to mount /data或can't find UUID=abcd1234 - 如果看到
timed out waiting for device dev-disk-by-uuid-abcd1234，说明系统在等一个根本没识别到的磁盘 - 错误里带
Dependency failed for /xxx，基本可以断定就是/etc/fstab对应那行有问题
blkid 和 lsblk -f 必须一起用，才能判断 UUID 是否真实存在
光看 fstab 里的 UUID 没用，得验证它是不是当前系统能识别的设备：
-
blkid输出所有已识别块设备的 UUID 和文件系统类型（注意：只显示已探测到的设备） -
lsblk -f显示挂载树、文件系统类型、以及是否已挂载；如果某分区在blkid里有 UUID，但lsblk里没出现，大概率是磁盘没通电、线松了、或虚拟机里没加载磁盘控制器 -
ls -l /dev/disk/by-uuid/看 udev 是否为该 UUID 创建了软链接；如果blkid有输出但这里没对应链接，说明 udev 规则没生效，可能是 initramfs 没更新（dracut -f可重建）
mount -a 是修改 fstab 后必须跑的验证命令
改完 /etc/fstab 别直接 reboot，先验证是否真能挂上：
- 执行
mount -a—— 它会按fstab逐行尝试挂载所有未挂载项，出错立刻报错，不中断后续 - 如果提示
mount point does not exist，说明挂载目录（如/mnt/backup）还没创建，先mkdir -p /mnt/backup - 如果提示
unknown filesystem type 'xfs'，说明内核模块没加载，CentOS/RHEL 需确认xfs.ko是否在 initramfs 里（lsinitrd | grep xfs） - 如果提示
special device UUID=xxx does not exist，就回到上一步用blkid对比，要么注释掉这行，要么换用/dev/disk/by-path/这类更稳定的设备标识（仅限物理服务器）
fstab 里加 nofail 才算真正防卡死
非系统盘（比如外接硬盘、NAS、备份盘）挂载失败本不该导致启动失败，但默认行为就是卡住。修复的关键是加 nofail：
- 把原行末尾的
0 0改成nofail,x-systemd.device-timeout=30 0 0（x-systemd.device-timeout防止无限等待） - 注意
nofail只对非关键挂载点有效；根分区（/）、/boot、/boot/efi不能加，否则系统可能无法启动 - swap 分区建议也加
nofail，尤其在虚拟机里，克隆后 swap UUID 冲突很常见
真正容易被忽略的是：紧急模式下根分区默认只读，mount -o remount,rw / 必须在编辑 fstab 前执行；还有，mount -a 报错时别只盯着最后一行，有时前面某行挂载成功但破坏了后续路径权限（比如挂载到了 /usr 下某个子目录），也会让后面服务起不来——得结合 systemctl status 看具体哪个单元 failed。
