这个场景要解决什么
服务器重启后卡在 emergency mode，或者某个挂载点起不来，最常见的原因是 fstab 里的设备不存在、UUID 变了、文件系统损坏或网络存储不可达。systemd 在挂载依赖失败时会进入应急模式，把人留在控制台上，等你手工修好配置再继续启动。整个过程的关键是三步：先看清是哪一条挂载失败，再改配置，最后一定要验证。
基本信息
| 适用场景 | 开机进入 emergency mode、mount 失败、启动被挂载阻塞 |
|---|---|
| 目标 | 恢复启动并修正 fstab 或设备状态 |
| 工具链 | mount -a、journalctl、blkid、lsblk、findmnt、编辑 fstab、systemctl default |
| 前提 | 进入应急控制台需要 root 口令；云主机一般通过 VNC 或串口控制台进入 |
常见触发原因
- fstab 里写的是设备名，换盘或加盘后设备名发生漂移
- 磁盘做过分区变更，对应的 UUID 跟着变了
- 文件系统损坏，挂载时的校验失败
- 网络存储在启动阶段不可达，配置里又没写 _netdev
- 挂载点被占用或权限不对，mount 直接报 target is busy
第 1 步 看失败原因
第 1 步 看失败原因
mount -a # 复现失败，直接看到报错的那一行
journalctl -xb | grep -i -E 'mount|failed|dependency' | tail -n 40
systemctl --failed # 列出进入失败状态的单元第 2 步 核对设备
第 2 步 核对设备
blkid # 列出各设备的 UUID 与文件系统类型
lsblk -f # 树状查看设备、文件系统与挂载点
findmnt --verify # 检查 fstab 语法与挂载点是否成立
cat /etc/fstab # 逐行读，对照上面的结果第 3 步 修正并验证
第 3 步 修正并验证
cp /etc/fstab /etc/fstab.bak # 改前备份
vi /etc/fstab # 改 UUID，或为数据盘补 nofail
mount -a # 有错立即报出来
systemctl daemon-reload第 4 步 继续启动
第 4 步 继续启动
systemctl default # 或 systemctl isolate multi-user.target
reboot # 重启验证不再进入应急模式fstab 关键选项
| 选项 | 作用 | 使用提示 |
|---|---|---|
| defaults | 默认挂载参数组合 | 大多数场景直接沿用 |
| nofail | 挂载失败不影响启动 | 数据盘建议加，避免一块盘拖垮整机启动 |
| _netdev | 等网络就绪后再挂载 | 所有网络存储都必须加 |
| noatime | 不更新访问时间 | 减少元数据写入，数据盘常用 |
| x-systemd.automount | 首次访问时才挂载 | 大容量冷数据盘可节省启动时间 |
| 0 2 | 尾部的 dump 标记与 fsck 顺序 | 数据盘写 0 2，根分区通常是 0 1 |
应急模式下根文件系统通常以只读方式挂载，编辑 fstab 之前要先执行 mount -o remount,rw / 改成可写，否则保存动作会失败。
改完 fstab 不验证就重启，很可能再进一次应急模式。规范动作是改完立刻跑 mount -a 与 findmnt --verify，两条都干净再重启。
进入应急模式后先做的事
- 执行不带参数的 mount，看当前挂了哪些文件系统，确认根分区是不是只读状态
- 看 journalctl -xb 的尾部，找最近一条失败记录，定位触发点
- 记下失败单元的完整名字，之后可以用 systemctl status 单独查看详情
- 改配置前先 cp 一份 fstab 备份，出问题能立刻回退
先回到能启动的最小配置
先回到能启动的最小配置
cp /etc/fstab /etc/fstab.bak
# 把可疑的那一行临时注释掉，先让系统能起来
grep -v '/data' /etc/fstab.bak > /etc/fstab
mount -a && systemctl default # 确认能进系统，再逐条加回来修复期间不要直接断电：已挂载的文件系统可能还有未落盘的数据，用 reboot 或 systemctl reboot 正常重启更安全。
交换分区或 tmpfs 写错通常影响有限，真正会阻塞启动的是被其它单元依赖的关键挂载，例如 /var、/usr，或数据库的数据盘。
云主机拿不到应急控制台时，多数平台都提供 VNC 或串口登录入口，部分平台还有救援模式：把系统盘以数据盘方式挂到一台临时实例上修改 fstab，比在应急模式里操作更从容。
常见报错与处置
| 报错提示 | 原因 | 处置 |
|---|---|---|
| unknown filesystem type | 类型字段写错或驱动缺失 | 核对类型并确认内核模块可用 |
| can not read superblock | 设备不是文件系统或已损坏 | 核对设备并对文件系统做检查 |
| mount point does not exist | 挂载点目录不存在 | 先创建目录再重试 |
| mount is denied | 普通用户挂载或选项受限 | 以 root 操作或改用允许普通用户挂载的选项 |
| already mounted | 重复挂载或挂载点被占用 | 先用查找挂载的命令看清现状 |
修正后的验证节奏是两步：先用配置校验命令检查条目语法与设备存在性，再用一次性挂载全部条目的方式试挂一次，两条都通过再重启。只做其中一步就重启，很可能连续两次进应急模式，没有控制台时会很被动。