linux启动进入emergency mode是因为系统在关键阶段（如root文件系统挂载、systemd单元启动等）遇到严重错误，systemd停止流程并进入最小化shell等待人工干预；常见原因包括fstab错误、根文件系统无法挂载、initramfs缺失驱动、服务依赖失败或加密卷未解锁。
Linux 启动进入 emergency mode，说明系统在某个关键阶段（如 root 文件系统挂载、systemd 单元启动、磁盘检查等）遇到了严重错误，无法继续正常启动。此时 systemd 会停止启动流程，进入最小化 shell 环境（通常是 /bin/bash），等待人工干预。
为什么进 emergency mode？常见原因
根本原因是某个依赖项失败，导致 systemd 无法满足启动目标（如 default.target）。典型触发点包括：
- fstab 配置错误：比如 UUID 写错、挂载点路径不存在、文件系统类型不匹配、noauto/defaults 冲突等；
- 根文件系统无法挂载：硬盘离线、LVM/VG 未激活、加密卷未解锁、文件系统损坏（如 ext4 superblock 损坏）；
- initramfs 缺失关键驱动或模块：如 RAID、NVMe、特定网卡或存储控制器驱动未包含，导致 initrd 里找不到根设备；
- systemd 服务单元启动失败且被设为 Required：例如自定义 service 依赖某个 mount 或 device，而该依赖不可用；
- /etc/crypttab 错误或密码输入失败：加密分区无法解密，root 或 /boot 无法访问。
进入 emergency mode 后第一步做什么？
你会看到类似 Starting Emergency Shell... 的提示，并停留在一个带 [root@localhost ~]# 的命令行。此时：
- 先运行
journalctl -p 3 -xb查看最近的错误日志（-p 3只显示 Error 级别及以上，-xb显示本次 boot 的完整上下文）； - 重点找关键词：
Failed to start、Mounting、Dependency failed、timed out、No such file or Directory； - 用
systemctl --failed快速列出所有失败的服务和挂载单元； - 尝试
lsblk和blkid确认磁盘、分区、UUID 是否可见； - 若怀疑 fstab 问题，可临时注释掉可疑行：
mount -o remount,rw /sysroot（如果已挂载只读根），再编辑/sysroot/etc/fstab。
常见修复操作示例
根据错误类型选择对应处理：
- fstab 有误导致挂载失败：执行
mount -o remount,rw /sysroot→vi /sysroot/etc/fstab→ 注释或修正出错行 →exit退出 emergency shell，系统将自动继续启动； - 根文件系统损坏（如 ext4）：先确认设备（如
/dev/sda2），再运行e2fsck -y /dev/sda2（注意：必须卸载或确保只读挂载，emergency 模式下通常未挂载，可直接运行）； - LVM 根卷未激活：运行
lvm vgscan && lvm vgchange -ay，再检查lvs是否列出 root LV，然后手动挂载测试：mount /dev/vg00/lv_root /mnt； - 加密卷未解锁：确认
/etc/crypttab正确，手动运行cryptsetup luksOpen /dev/sdb1 mydata，再mount /dev/mapper/mydata /mnt测试； - initramfs 过期或缺失模块：修复后需重建 initrd，例如 centos/RHEL：
dracut -f，ubuntu/debian：update-initramfs -u。
如何避免再次进入 emergency mode？
预防比抢救更高效：
- 修改
/etc/fstab或/etc/crypttab前，先用mount -a或cryptdisks_start测试语法和可达性； - 更新内核或重大系统升级后，主动重建 initramfs；
- 对生产系统，启用
systemd-fsck自动修复（在 fstab 中对关键分区加1或2的 pass 字段），但谨慎用于根分区； - 定期备份
/boot和/etc，尤其是grub.cfg、fstab、crypttab、dracut.conf等关键配置； - 设置 GRUB 启动参数临时绕过问题：开机时按
e编辑启动项，在linux行末尾加systemd.unit=multi-user.target或rd.debug获取更多调试信息。