场景与自救顺序
系统启动中断进入 emergency 模式，说明某个关键单元失败，常见诱因是 fstab 里指向了不存在的设备、根分区检查失败、关键服务启动超时。此时系统只挂载了最小集合，根分区通常是只读的。自救顺序是：先读本次启动的错误日志，再列出失败单元，逐项处理；如果短时间内无法修复，可以临时屏蔽问题单元让系统先起来恢复访问，但要记入待办，避免屏蔽项长期潜伏。
基本信息
| 场景 | 开机进入 emergency mode，要求输入 root 密码继续 |
|---|---|
| 目标 | 找到阻塞启动的单元并恢复系统正常启动 |
| 处置链路 | journalctl -xb 看错误 → systemctl --failed 列失败项 → 处置或临时屏蔽 |
| 关键前提 | 根分区常为只读挂载，改配置前需先 remount rw |
| 常见诱因 | fstab 挂载失败、文件系统检查失败、关键服务启动超时 |
典型使用场景
- 改完 fstab 重启后直接进入 emergency 模式
- 磁盘故障导致挂载失败无法继续启动
- 单元依赖超时阻塞了启动流程
- 需要临时绕过问题单元先恢复系统访问
- 事后复盘是哪次变更引入了启动问题
常用示例
常用示例
journalctl -xb -p err --no-pager | tail -n 60 # 本次启动的错误
systemctl --failed # 失败单元清单
systemctl list-jobs | head # 卡住的任务
mount -o remount,rw / # 根分区只读时先恢复可写
cat /etc/fstab # 对照报错设备与条目
mount -a # 验证 fstab 能否全部挂载
systemctl mask problem.service # 临时屏蔽问题单元（确认安全后）
systemctl default # 继续启动到默认目标常见阻塞原因
| 现象 | 原因 | 处置方向 |
|---|---|---|
| 报设备不存在 | fstab 中的设备名或 UUID 已失效 | 修正条目或先注释该行，再核对设备状态 |
| 要求手动运行 fsck | 文件系统检查失败或存在损坏 | 手工执行 fsck 修复后继续启动 |
| 单元启动超时 | 依赖的存储或网络尚未就绪 | 调整超时与续行配置，或延后启动顺序 |
| 提示输入 root 密码 | 系统进入 emergency target | 修复后执行 systemctl default 继续启动 |
| 无法保存修改 | 根分区以只读方式挂载 | 先 remount rw 再编辑配置 |
emergency 模式下根分区通常只读，直接编辑配置文件会报只读错误，这并不代表磁盘故障。先执行 mount -o remount,rw / 再操作。
临时 mask 的单元必须记入变更单并及时恢复。长期屏蔽会让问题被遗忘，后续排查时很难联想到曾经做过这个操作。