磁盘挂载失败导致进入emergency mode，九成以上源于/etc/fstab中uuid错误；需先用blkid和lsblk -f核对真实uuid，再对比fstab条目，注释可疑行后执行mount -a验证，确认后更新uuid并重建initramfs。
磁盘挂载失败，尤其是启动卡在紧急模式（emergency mode）或提示 Failed to start Local File Systems，十有八九是 /etc/fstab 里 UUID 写错了——系统按这个 UUID 找不到对应设备，就拒绝继续启动。
确认是不是 UUID 问题
先别急着改文件。进入紧急模式后，输入 root 密码登录，第一步执行：
-
检查当前实际设备和 UUID：运行
lsblk -f或blkid，列出所有已识别分区及其真实 UUID 和文件系统类型； -
对比 fstab 记录：用
cat /etc/fstab查看挂载条目，把每一行里的UUID=xxx和上一步输出逐个比对； - 重点看根分区、/boot、/home 等关键挂载点**是否匹配**——哪怕只有一行错，系统也可能停在 emergency mode。
临时绕过错误快速验证
如果怀疑某一行有问题，又不确定改哪，可以先临时注释掉：
- 用
vim /etc/fstab编辑，在疑似出错的行最前面加#； - 执行
mount -a测试其余配置是否正常——没报错说明问题就在这行； - 测试通过后，再决定是修复 UUID 还是改用设备名（不推荐长期用
/dev/sda1）。
修复 UUID 错误的三步操作
确认哪个分区 UUID 不对后，按顺序处理：
-
更新分区自身 UUID：对 ext2/3/4 分区运行
tune2fs -U random /dev/sdXN（如/dev/sda1）；XFS 分区则用xfs_admin -U generate /dev/sdXN； -
同步改写 fstab：把
blkid /dev/sdXN输出的新 UUID 复制进去，替换原值； -
重建 initramfs：Ubuntu/Debian 执行
update-initramfs -u，RHEL/CentOS 执行dracut -f，否则重启后内核仍按旧 UUID 查找，还会失败。
预防下次再踩坑
UUID 错误常发生在克隆硬盘、复制系统、更换主板或虚拟机迁移后。日常注意：
- 新增或更换磁盘后，第一时间用
blkid核对并更新/etc/fstab； - 避免直接复制整个系统盘却不重生成 UUID；
- 备份前先确认
mount -a能成功，这是最简单的配置健康检查。
