系统崩溃进紧急模式多数因/etc/fstab中UUID与实际设备不匹配，需在emergency shell中执行mount -o remount,rw /、blkid核对并修正fstab、mount -a验证后重启。
系统崩溃进紧急模式，多数是因为 /etc/fstab 里写的 UUID 和实际设备对不上——比如分区重装、ESP 重建、磁盘顺序变动，都可能让旧 UUID 失效。只要能进 emergency shell，不用重装、不靠 LiveCD，几分钟就能修好。
确认根文件系统可写
emergency shell 默认以只读方式挂载根分区，必须先解锁编辑权限：
- 执行
mount -o remount,rw /（Debian/Ubuntu 等主流发行版） - 若提示
/不在 mount 列表中，可能是挂载在/sysroot，改用mount -o remount,rw /sysroot - 运行
mount | grep " / "或mount | grep sysroot确认已变成rw
查出当前所有设备的真实 UUID
别凭记忆或旧备份猜，直接读硬件：
- 运行
blkid——列出所有块设备及其 UUID、LABEL、TYPE - 配合
lsblk -f看树状结构，快速定位哪个 UUID 对应/、/boot、/home等挂载点 - 特别注意 ESP 分区（FAT32 类型），它的 UUID 在 UEFI 启动中很关键；若你重分过 ESP，
blkid输出的新 UUID 就是唯一可信依据
比对并修正 /etc/fstab
打开配置文件，逐行核对：
- 用
cat /etc/fstab查看内容，重点关注报错日志里提到的挂载点（如 journalctl -xb 中出现的Failed to mount /data） - 检查每行第一列：是否为
UUID=xxx格式？长度是否为 36 位（含连字符）？是否在blkid输出中真实存在？ - 常见错误包括：UUID 少一位、多空格、抄错字母（如 0 和 O 混淆）、把 ESP 的 UUID 错贴到
/boot/efi行但实际设备已变 - 用
nano /etc/fstab（推荐）或vi /etc/fstab修改：删掉错误 UUID，粘贴blkid输出中对应设备的完整 UUID 字符串
验证无误再重启
改完别急着 reboot，两步验证保稳：
- 运行
mount -a——尝试挂载 fstab 中所有未注释条目；若无输出即成功，有报错则说明某行仍有问题 - 执行
systemctl daemon-reload（通知 systemd 重新加载配置） - 输入
exit或按Ctrl+D，系统会自动继续启动流程；若仍卡住，说明还有其他单元失败，可再跑journalctl -xb定位
swapon 失败和启动延迟；另外，修改后建议立即备份当前 fstab：cp /etc/fstab /etc/fstab.bak-$(date +%Y%m%d) 
