Linux进入emergency模式通常因关键服务或文件系统异常，如/etc/fstab错误、根分区无法挂载、systemd单元失败、磁盘损坏或LUKS解密失败；需通过journalctl和systemctl定位问题，修复后exit退出并更新initramfs。
Linux进入emergency模式，通常是因为系统启动时关键服务或文件系统异常，比如/etc/fstab配置错误、根分区无法挂载、systemd单元失败、磁盘损坏或加密卷解密失败等。此时系统不会继续启动图形或网络服务，而是停在命令行界面，提示你手动干预。
确认当前状态和报错线索
进入emergency模式后，屏幕会显示类似“Welcome to emergency mode!”的提示，并给出操作指引（如按Ctrl+D继续，或输入root密码进入shell）。关键信息在报错行：
- 留意红色高亮的failed unit名称，例如dev-sda2.device、local-fs.target或cryptsetup@xxx.service
- 运行journalctl -xb -p3查看最近的错误日志（-p3表示优先级为error及以上）
- 用systemctl --failed列出所有失败的服务
常见原因与对应修复方法
多数emergency问题集中在以下几类：
- /etc/fstab 配置错误：新增了不存在的设备UUID、挂载点路径错误、文件系统类型写错。修复方式：执行mount -o remount,rw /重新挂载根为可写，然后用nano /etc/fstab检查并注释/修正错误行，保存后执行systemctl daemon-reload再exit退出emergency
- 根文件系统只读或损坏：先运行mount | grep " / "确认挂载状态；若为ro（只读），尝试mount -o remount,rw /；若失败，可能是ext4损坏，运行e2fsck -f /dev/sdXN（替换为实际设备）强制检查修复
- LUKS加密卷无法解锁：检查/etc/crypttab中设备路径、keyscript或密码文件是否存在；临时手动解锁测试：cryptsetup luksOpen /dev/sdXN myvol，成功后再排查systemd-cryptsetup服务配置
退出emergency并恢复启动
完成修复后，不要直接重启——先验证是否能正常进入multi-user目标：
- 执行systemctl default尝试切换到默认目标（通常是graphical或multi-user）
- 若无报错且进入登录界面，说明修复成功；否则重复查看journalctl -xb
- 确认无误后，输入exit或按Ctrl+D，系统将自动继续启动流程
- 为防再次进入emergency，建议更新initramfs：update-initramfs -u（Debian/Ubuntu）或dracut -f（RHEL/CentOS/Fedora）
不复杂但容易忽略：很多问题其实源于一次手动修改fstab后没验证就重启，或者升级内核后initramfs未重建。日常维护中养成mount -a测试fstab、lsinitrd | grep crypt检查initramfs内容的习惯，能大幅减少emergency模式出现概率。
