大概率是/etc/fstab配置错误；启动时Failed to mount或Dependency failed提示直接指向挂载失败行，journalctl -xb | grep mount可定位具体错误，修复需先备份fstab、注释可疑行、mount -a验证后再重启。
系统卡在启动阶段、反复提示进入紧急模式，大概率是 /etc/fstab 配置出错了。这个文件控制开机自动挂载行为，一行写错，整个启动流程就可能中断。修复不难，关键是要进得去、改得准、验得稳。
识别错误表现，快速锁定问题
不用猜，看屏幕提示就能判断：
- 启动时出现 Failed to mount /xxx 或 Dependency failed for /xxx —— 明确指向 fstab 中某一行挂载失败
- 停在 Welcome to emergency mode 界面，要求输入 root 密码 —— 系统已放弃自动挂载，等待人工干预
- 输入 root 密码后执行
journalctl -xb | grep mount，能直接看到哪条路径挂载失败、报什么错（比如can't find UUID、wrong fs type、mount point does not exist）
进入可操作环境的两种可靠方式
不能登录图形界面或 SSH？没关系，有两条路都能进命令行：
-
通过 GRUB 启动参数临时跳过挂载：开机时按
e编辑内核行，在linux行末尾加rd.break（RHEL/CentOS/Fedora）或init=/bin/bash（部分 Debian/Ubuntu），再按Ctrl+X启动。系统会停在 initramfs 环境或 bash shell，此时根分区尚未挂载为只读，需先执行mount -o remount,rw /sysroot，再chroot /sysroot -
用安装介质启动进救援模式：插入 Linux 安装 U 盘或光盘，选择 Rescue a broken system；系统会自动扫描并提示挂载原根分区，选中后它会被挂载到
/mnt/sysimage；接着运行chroot /mnt/sysimage，就等同于回到了原系统环境
安全修改 /etc/fstab 的实操要点
进到可写环境后，别急着删或乱改，按步骤来：
- 先备份：
cp /etc/fstab /etc/fstab.bak，防止改错无法回退 - 用
vi或nano打开：vi /etc/fstab - 逐行检查四项核心字段：设备标识（推荐用
UUID=xxx，避免用/dev/sdb1）、挂载点（确认目录真实存在，如/data要提前mkdir -p /data）、文件系统类型（ext4、xfs、vfat等必须准确）、挂载选项（避免ro和rw冲突，网络存储建议加nofail,x-systemd.device-timeout=30） - 不确定哪行有问题？先用
#注释掉非系统盘的所有条目（保留/、/boot、/boot/efi等必要项），保存退出，再重启验证基础系统能否起来
验证与后续优化
重启前做两件事，能大幅降低二次失败风险：
- 手动测试挂载：
mount -a—— 它会按 fstab 全部尝试挂载，报错会立刻指出哪一行、什么问题，比重启更高效 - 检查挂载结果：
findmnt或mount | grep "your-mount-point"，确认目标路径确实已成功挂载且权限正常 - 恢复后建议：对非关键数据盘启用
nofail选项；优先使用UUID而非设备名；定期用blkid核对 UUID 是否匹配，尤其在更换磁盘或克隆系统后
