★ FEATURED ARTICLE 1. 先别慌emergency mode 到底是什么如果你在 Ubuntu 开机时看到 Welcome to emergency mode! 这样一行字多半心里会咯噔一下。屏幕上是黑底白字的命令行界面旁边还提示刚才的启动过程哪里出了问题让你登录后执行 journalctl -xb 查看日志。这场景我第一次碰到时也懵了几分钟但冷静下来后会发现emergency mode 本身并不是文件系统报废而是 systemd 的一种主动保护机制——它把系统停在一个最小的可用状态把你丢进根目录 shell让你去把系统恢复正常后再继续开机。从设计上看systemd 在启动时会对文件系统挂载、关键 unit 服务做依赖检查。只要有一项核心资源没有按预期就绪启动流程就会被中断自动落到 emergency mode 或 rescue mode。两者的区别在于rescue mode 会尝试挂载本地文件系统emergency mode 则连挂载这一步都省了给你一个尽量干净的环境来排查严重故障。很多朋友以为进了 emergency mode 就只能重装系统其实绝大多数情况下问题出在 fstab 配置错误、磁盘 UUID 变化、文件系统损害或者某个服务启动失败这几类原因上修复优先级最高的就是 fstab 问题因为它在启动阶段最容易触发紧急模式。这篇文章要分享的正是最常见的 fstab 配置错误导致的 emergency mode并且会给出从进入紧急模式到修复重启的完整操作过程。我也把文件系统损坏、磁盘 UUID 漂移等常见诱因一并梳理清楚这样不管你遇到的是哪一种情况都能自己动手排查不用一上来就格式化重装。1.1 systemd 在什么时候会把你关进“紧急模式”systemd 的启动流程里local-fs.target 和 sysinit.target 是两个关键节点它们负责把 /etc/fstab 里声明的分区挂载到位。fstab 文件如果写得有问题比如挂载点不存在、文件系统类型写错、UUID 和实际设备不匹配systemd 就无法完成挂载。此时它不会默默跳过而是把启动流程卡住最终进入 emergency mode。还有一类情况是启动时某个 systemd 服务报了硬错误。系统日志里会明确标出 Failed to start xxx.service 之类的信息随后进入 emergency mode。这类问题虽然也常见但排查路径稍长需要看 journal 日志定位到具体是哪个 unit 导致的。fstab 的问题则相对更直观错误几乎必然出现在挂载阶段而且日志里会给出设备名或者 UUID。简单说emergency mode 相当于系统层面的“带安全网的重启失败提示”。它告诉我们有个必须的东西没准备好先手动整一整再走下一步。只要懂几个基础命令就能在最短时间内解开这个死结。1.2 触发 emergency mode 的四种常见原因我根据踩坑经历和社区反馈把导致 Ubuntu 进 emergency mode 的原因归成四类第一类是 fstab 语法错误或挂载配置失效。如果你在 fstab 里用了设备名比如 /dev/sdb1而系统重启后设备顺序变了原来的 /dev/sdb1 可能变成 /dev/sdc1这时挂载自然失败。更常见的是 UUID 填写错误或者是挂载目录还没创建。第二类是文件系统损坏。非正常关机、强制断电、硬盘坏道等都可能导致分区上的文件系统元数据损坏启动检查时发现 superblock 异常就会拒绝继续挂载。第三类是部分硬件或外部设备挂载失败。比如 fstab 里配置了网络硬盘 NFS启动时网络还没就绪挂载超时再比如接了移动硬盘启动时硬盘没插上或者 USB 设备枚举顺序变了会同样触发紧急模式。第四类是 initramfs 阶段出了问题。比如内核更新后 initramfs 和当前内核不匹配、根分区所在磁盘驱动加载失败等也会在启动早期就跌进 emergency mode。这四类中fstab 配置错误是出现频率最高的尤其适合作为“一个解决方法”的切入点。后面的修复步骤就是围绕它展开的其他原因的排查思路我也在第 4 节里单独覆盖。2. 事故现场复盘一次 fstab 改动引发的 emergency mode我自己的这次事故起因说起来有点手痒当时给一台 Ubuntu 22.04 机器加装了一块 4TB 的数据盘想着开机自动挂载到 /data 目录于是手动去 /etc/fstab 末尾加了一行。为了省事我直接用了当时系统里显示的设备名没有先去确认分区的 UUID。改完文件我还自我感觉良好顺手执行了 reboot结果重启后直接就躺在 emergency mode 里了。这台机器平时是 7x24 小时运行的服务节点掉链子的那一刻我还挺懊恼的。但比起后悔更重要的是先看清楚系统到底给了什么提示。在 emergency mode 界面中日志会直接把挂载失败的设备名打印出来比如 Failed to mount /data 或者 Dependency failed for local-fs.target后面通常还跟着一行 See systemctl status xxx.service for details。到了这个地步第一反应不应该是重装而是先冷静下来用自己的账号或者 root 账号登录系统去定位问题。2.1 我做了什么操作才触发的问题复盘时发现自己犯了一个很典型的错误写 fstab 时用了 /dev/sdb1 这种设备路径。当时的系统里确实能看到 /dev/sdb1但设备名是由内核按扫描顺序动态分配的重启后如果磁盘顺序发生变化/dev/sdb1 就可能不再对应原先的 4TB 盘。更麻烦的是只要 fstab 里有一行挂载失败systemd 就认为 local-fs.target 没有达成直接拒绝继续启动到图形界面或多用户模式。除了设备名之外我还要补充一个常见的翻车点fstab 的挂载参数和 dump/fsck 列写错。fstab 每行有六个字段分别是文件系统、挂载点、类型、选项、dump 标志、fsck 顺序。很多新手只在前面三个字段上下功夫后面两个字段随意填但第六列的 fsck 顺序如果写得不规范也可能在启动检查时报错。那次我其实是写了设备名加默认参数看起来挺合理结果却因为设备名漂移触发了 emergency mode。如果当时用的是 parted 输出的明确参数或者用 blkid 查看 UUID 后填进 fstab系统就不至于挂不上。所以并不是“要挂载一块盘”这个需求有多复杂而是我偷懒省掉了确认 UUID 这一步才把一行配置变成了一次应急排障。2.2 为什么 fstab 是“重灾区”fstab 之所以是 emergency mode 的头号触发源是因为它在启动早期就必须被执行而且不能像普通服务那样失败后重启重试。fstab 里面每一行声明的是一个“硬性依赖”系统按这条配置去找设备如果找不到或挂不上挂载流程就会推进不下去。另外 fstab 的容错空间很小。有些朋友以为像 Windows 的启动项那样写错了可以跳过去但实际上 systemd 对 fstab 缺失设备的情形倾向于判定为失败而不是自动跳过。尤其是你把 fstab 字段写错比如把挂载点写在设备名的位置或者把 UUID 拼错了启动时找半天设备最后报错进入 emergency mode。所以说凡是动过 fstab 的朋友重启前最好先在脑子里过一遍这行配置对应的设备真的存在吗挂载点已经创建了吗UUID 是 blkid 查出来的吗如果不敢拍胸脯那就跑一下 mount -a 再重启。2.3 进入 emergency mode 后的第一反应很多人看到 emergency mode 界面就直接傻眼觉得系统已经没救了。这里我要很明确地告诉你你的数据基本是安全的系统内核还在跑根文件系统虽然以只读方式挂在上面但修复空间完全够。进入界面后你会先看到几行系统日志大意是告诉你现在处于紧急模式可以输入 root 密码登录。如果你是普通用户也可以输入你的账号和密码但根据实际经验普通用户可能需要配合 sudo 才有足够权限执行修复命令所以如果登录时用 root 身份最省事。Ubuntu 桌面版默认 root 没有密码这种情况下你可以用自己设置过 sudo 权限的账号登录然后在命令前加 sudo。登录后的第一件事不是急着权衡要不要重装而是先用 root 权限把根文件系统重新挂载成可写。因为在 emergency mode 下根分区默认以只读方式挂载你直接修改 /etc/fstab 会提示文件系统只读保存不了。这就是很多人卡在第一步的坑。3. 核心解决流程一步步把系统拉回来下面的流程是我实际验证过的能从 fstab 类问题导致的 emergency mode 里把系统完整拉回来。整个过程中用到的基础命令不超过十个但每一步都不要跳尤其是重新挂载根分区那一项。3.1 应急第一步把根分区变成可写在 emergency mode 里登录后先执行以下命令确认当前根文件系统状态mount | grep / 输出里通常会包含 ro 字样比如 /dev/sda2 on / type ext4 (ro,relatime,...)。这说明根文件系统是只读挂载的。此时修改任何根目录下的配置文件都会失败必须先重新挂载为可写mount -o remount,rw /这条命令的含义是把根分区以 read-write 方式重新挂载一次而不是额外挂载一个新的分区。执行完可以再次运行 mount | grep / 确认输出里变成了 rw。这一步做完之后你就能正常编辑 /etc/fstab 了。如果你连这一步都无法完成说明根分区本身可能存在问题比如文件系统损坏导致挂载失败。这种情况我会在第 4 节补充 fsck 的修复思路。3.2 精准定位问题审查 fstab 内容接下来查看 fstab。一个常见习惯是先用 cat 看全文但我更推荐带行号查看cat -n /etc/fstab这样你能快速看到最近修改过的行也不会漏掉带空格的挂载点。我那次故障里出错行就是末尾追加的一行内容是 /dev/sdb1 加上 /data 和 ext4 那一串。看完 fstab把可疑的行用 # 号暂时注释掉。比如# /dev/sdb1 /data ext4 defaults 0 2这里我建议把被注释的行保留在文件里不要急着删除这样重启用不起来时还能对比哪些行是启用的哪些是被注释掉的。如果你不明确哪行有问题可以先逐行注释掉所有非系统必需的行只保留根分区、/boot、/home 等系统固有挂载项然后尝试重启。系统固有挂载项在 fstab 里一般能通过挂载点名称分辨例如 / 和 /boot而你自己追加的一般是 /data、/mnt/xxx 这类自定义路径。3.3 修改配置的正确姿势用 blkid 重取 UUID如果问题确实出在设备名漂移比如 /dev/sdb1 对应的硬盘已经不是你想挂的那块那就需要用 blkid 查清楚真实信息blkid输出会列出每个块设备的 UUID、PARTUUID、文件系统类型等信息。比如 4TB 盘的输出可能是 /dev/sdb1: UUIDa1b2c3... TYPEext4。把这个 UUID 复制下来然后编辑 fstabnano /etc/fstab把刚才注释掉或写错的那一行改成UUIDa1b2c3... /data ext4 defaults 0 2这里有个细节值得强调用 UUID 而不是设备名是 Linux 社区长期实践下来的稳妥做法。设备名会因为磁盘枚举顺序变化而漂移UUID 则是文件系统创建时固定下来的标识只要分区还在它的 UUID 就不会变。如果你不想用 nano也可以直接从终端的 GUI 文本编辑器编辑但在 emergency mode 的纯命令行环境里nano 或者 vi/vim 是更可靠的选择。我用的是 nano因为界面对新手友好底部有操作提示不会像 vim 那样需要先熟悉模式切换。3.4 提交验证并重启修改完 fstab 之后先不要急着重启。最好的验证方式是先让系统尝试挂载所有条目mount -a如果没有任何报错说明刚写的 fstab 配置至少语法和挂载层面没问题。如果你看到类似 mount point /data does not exist 的报错说明挂载目录没创建需要先建目录再重新挂载。如果看到 wrong fs type 之类提示说明文件系统类型写错需要对照 blkid 的实际 TYPE 修改。确认 mount -a 顺利通过以后执行systemctl daemon-reload reboot重启后系统通常能正常进入桌面或命令行登录界面。如果问题依然存在那就不是简单 fstab 语法层面的问题需要转到第 4 节的思路去排查。4. 其他因素与更深层的排查思路虽然我这次事故的根因是 fstab 写得有误但 emergency mode 并不是只有这一种解法。我遇到过好几个朋友按 fstab 排查了半天发现配置完全正确最后还是靠 fsck 才把系统救回来。这一节把其他常见因素和排查方法列出来方便你遇到类似问题时不走弯路。4.1 文件系统损坏用 fsck 修复非正常关机或硬盘出现坏块后开机时文件系统检查可能失败此时根分区可能以只读方式挂载甚至无法挂载。你可以在 emergency mode 下执行fsck -f /dev/sda2这里 /dev/sda2 是根分区设备名可以通过 df -h 或 blkid 确认。fsck 全称是 file system check它专门扫描并修复文件系统元数据。执行时可能会提示若干 Fix? 的询问输入 y 让它自动修复。修复完之后要记得重启让内核重新读取干净的文件系统状态。这里有个关键注意事项fsck 不能对已经挂载的文件系统执行否则可能出现更严重的损坏。所以如果你发现根分区处于 rw 挂载状态最好先卸载它或者至少不要把根分区用于其他任务。文件系统这层如果修复好了emergency mode 就解除了。但如果 fsck 反复报坏块可能意味着磁盘硬件本身有物理损坏那就需要重视数据备份考虑更换硬盘了。4.2 用日志精准定位非 fstab 类错误如果 fstab 和文件系统都没问题下一步是看 systemd 日志。在 emergency mode 下执行journalctl -xb这是 emergency mode 界面提示里最常见的命令。-x 表示补充解释-b 表示只查看本次启动日志。日志会按时间顺序滚动你可以把输出导向 less 或 grep 来筛选关键字journalctl -xb | grep -i failed\|error\|emergency重点观察 Failed to start 和 Dependency failed 这类字样的后面跟的是什么 unit。比如看到 NetworkManager 或者某个硬件驱动服务失败就可以把排查方向转向服务配置或驱动兼容性。大多数情况下定位到这个 unit 之后要么禁用这个服务要么修复它的配置问题就能解决。如果你连日志都看不懂还有一个务实做法把故障出现前最近修改过的系统配置项逐个回退。无论是新装软件、改了内核参数还是改了网络配置回退到能启动的状态是最高效的策略。4.3 后续加固建议让问题不复发恢复启动之后我给这台机器做了三件加固措施避免再次栽进 emergency mode。第一件是把 fstab 里的所有设备引用替换成 UUID包括根分区和挂载盘这样设备顺序变化再也不会影响挂载第二件是在修改任何配置文件之前先备份比如cp /etc/fstab /etc/fstab.bak.$(date %F)第三件是给磁盘做定期健康检查用 smartctl 或系统的 disk utility 监控硬盘 SMART 数据发现坏道或重映射扇区增长时提前预警区。另外建议大家对自己的运维操作养成一个习惯凡是在 fstab 里新加一行都先执行 mount -a 测试。这条命令不会立刻让你重启如果配置有误它会马上报错你就有机会修改到正确为止。这个习惯能避免绝大多数 fstab 导致的 emergency mode。5. 常见问题速查与避坑实录5.1 新手常见的三个失误差错我见过不少新手在 emergency mode 里手忙脚乱错把简单问题复杂化。这里列三个频率最高的失误差错。第一个是忘了先 remount 根分区就直接编辑 fstab。当你发现文件改不了、保存报 Read-only file system 时不是 fstab 权限问题而是根分区压根是只读挂载。先执行 mount -o remount,rw / 是铁律。第二个是修改 fstab 时用设备名。有人觉得 /dev/sda1 这么好认为什么要用 UUID因为你的 /dev/sda 在下次启动时可能就变成 /dev/sdb这个飘移在有多块磁盘的机器上非常常见。用 UUID 不会背这种锅。第三个是改完 fstab 不测试直接 reboot。哪怕只有一行配置也请先 mount -a 验证一遍。系统重启的成本高而且一旦再次失败你又得从 emergency mode 来一轮来回折腾的时间够写十行配置了。5.2 排查技巧如何在最短时间内确定根因emergency mode 的界面虽然简陋但本身就会给你有效的提示。如果你稍加留意屏幕上会滚动显示挂载失败的分区路径或者失败的 systemd 服务名。这些信息是非常重要的线索不要直接忽略。如果已经错过了屏幕上的日志第一时间看 journalctl -xb把输出里 Failed to mount 或 Failed to start 之后的 unit 名记下来。fstab 问题通常定位到挂载相关 unit比如 media-数据目录的挂载单元软件服务问题则定位到对应服务。定位到 unit 后看它依赖的具体设备名或文件路径就知道矛头指向哪里了。还有一个小技巧登录后先执行 df -h看看当前根分区和磁盘占用情况。如果根分区空间满了也可能导致启动阶段无法写入必要文件从而流进 emergency mode。这种情况虽然少见但 df 一眼就能发现省得瞎猜。5.3 给系统上双保险配置备份与恢复预案如果你常折腾服务器建议在 /etc/fstab 顶部加一排注释记录这块盘是干什么用的、什么时候加的、UUID 是多少。这样下次看到这一行的时候不用去翻 blkid 再对一遍。更稳妥的是把 fstab 备份到一个不会随系统启动失败而丢失的地方比如另一块独立磁盘或远程备份目录。万一修复过程中改乱了还能从备份里最快恢复。我把这种配置备份称为“橡皮擦原则”就是给自己留好反悔的余地。数据安全上重要数据一定要有异地备份。emergency mode 大多能靠命令修回来但硬盘物理故障这种事不是软件层面能完全兜底的。修好系统之后顺手做一次完整备份既是对这次事故的复盘也是给下次可能出现的意外上双保险。这个内容后续还可以这样扩展如果你在虚拟机里复现一次 fstab 错误把整个排障流程完整跑一遍等下次真遇到 emergency mode 时就能轻车熟路地处理。我自己也是在虚拟机里模拟了几次故障场景才做到遇到问题时真正不慌的。
阅读完成 · 觉得有帮助？
