1. 紧急模式到底在说什么——先看懂提示再动手1.1 emergency mode 的真实身份如果你用过Ubuntu一段时间大概率会在某次重启后遇到这样一幕屏幕上不再是正常的开机画面而是一段提示大意是“You are in emergency mode. After logging in, type journalctl -xb to see system logs, systemctl reboot to reboot...”然后光标停在“Press Enter for maintenance”之类的字样上。很多人的第一反应是“系统是不是废了”甚至有人在群里问“是不是要重装”。其实恰恰相反。emergency mode 是systemd在启动流程中遇到问题时的主动“刹车”动作。它不像Windows那样蓝屏给你看而是保留了一个最小化的root shell环境让你进去排查。系统在告诉你我没办法按正常流程起来但工具还在你自己修。这个机制其实是Linux服务器上很成熟的降级策略。systemd把启动目标分成多个层级最完整的是graphical.target图形界面往下是多用户模式multi-user.target再往下是rescue.target救援模式最底层就是emergency.target紧急模式。正常情况下启动会一路跑到graphical.target如果中间某个关键服务或挂载动作失败且错误严重到无法跳过系统就会落到rescue或emergency。rescue和emergency的区别简单说就是rescue模式会尝试挂载根分区、加载部分服务给你一个相对完整的命令行环境emergency模式则更袖珍几乎不执行额外服务直接给你一个非常基础的shell。Ubuntu在根分区挂载失败、/etc/fstab里有非法配置、指定磁盘设备不存在这类问题时通常会直接进入emergency mode因为它连下一步该做什么都拿不准了宁可停下来让你确认。这也是为什么本文要围绕它展开。进入emergency mode并不可怕可怕的是你根本不知道它为什么进入然后一顿乱操作把系统搞得更糟。先搞清楚提示背后的逻辑比急着敲命令重要得多。1.2 最常见的触发原因fstab 挂载失败在我处理的Ubuntu启动故障里有七成以上紧急模式是 /etc/fstab 里的挂载配置出了问题。fstab 是系统启动时用来挂载文件系统的“清单”里面记录着哪些分区要挂载、挂到哪里、用什么文件系统、挂载选项是什么。每次开机systemd 都会逐行读取并执行这份清单。这份清单一旦出错启动流程就会卡住。最典型的几种错误包括分区的UUID变了但fstab里还写着旧的值某行引用的设备路径不存在比如 /dev/sdb1 实际已经成了 /dev/sdc1加了挂载选项但拼错导致文件系统挂载失败网络共享目录写在fstab里但开机时网络没有就绪挂载直接超时失败手动编辑时多打了个空格、少了分隔符或者行内混入了非ASCII字符我见过最“冤枉”的一次故障是朋友改fstab时想给某个分区加 noatime 参数结果在行尾多敲了一个看不见的字符。重启之后直接进了紧急模式他盯着屏幕看了半天也不知道问题在哪。用生活类比来说fstab 就像你早上出门前贴在玄关的“出门清单”钥匙放在哪、手机充电器要不要带、今天要穿哪双鞋。清单本身没问题但如果你昨天把备用钥匙挪了位置却没更新清单你出门时按照旧清单去拿自然会扑空。系统的反应就是停下来告诉你“我按清单找不到东西了你来处理。”1.3 进入紧急模式后第一步别慌确认你是 root看到emergency mode的提示后屏幕通常会给你两步操作按 CtrlD 继续尝试启动或者输入 root 密码进入维护模式。这里有个细节需要说清楚emergency mode 给你的是 root shell而不是普通用户终端。也就是说你必须用 root 账号登录。如果你安装系统时没有单独设置 root 密码那就需要用到右上角提示里的另一条路——如果你的root密码无法通过常规方式获得就只能用其他恢复手段这点我会在后面单独讲。在输入密码之前先想一下你最后对系统做过什么。这个“最后做过什么”基本就是问题所在。比如刚用分区工具缩容了磁盘、刚装完Windows双系统、刚改过fstab、刚卸载过某些驱动这些都是高危操作。想不起来也没关系进入shell之后有日志可以翻。我自己处理这类故障的顺序永远是先确认为什么失败再动手改配置。不要一上来就执行 mount -a 死磕也不要抱着侥幸心理按 CtrlD 反复尝试重启。紧急模式不会因为你多按几次 CtrlD 就自己好起来反而可能因为反复中断启动流程带来额外的文件系统风险。2. 一步步修复从确认现场到恢复系统2.1 登录到 emergency shell 的细节当你选择“Press Enter for maintenance”进入维护模式后如果系统提示需要root密码输入即可输入过程中屏幕上不会有任何反馈这是正常的不要因为没看到星号就以为键盘没响应。如果你安装Ubuntu时没有为root设置过独立密码那么默认情况下root密码是被锁定的你无法直接登录。这种情况下有两个常见入口。第一个是如果你的当前用户有sudo权限试试用 sudo -i 切换不过在emergency mode里sudo需要系统正常识别用户和组如果只是挂载问题通常是可以用的。第二个是通过启动参数临时指定 init/bin/bash这个稍后再说。进入shell后我建议先不急着改任何配置而是按顺序查看信息。第一个命令是mount -amount -a 的作用是“尝试挂载 /etc/fstab 中所有未挂载的文件系统”。如果fstab里有错误行这条命令会直接报错告诉你具体是哪一行、什么问题。比如最常见的提示是mount: /home: cant find in /etc/fstab.或者mount: /dev/sdb1: cant read superblock看到这类明确报错问题基本就定位了。就算mount -a没报错你进入emergency mode也一定有原因所以要配合日志一起看journalctl -xb这个命令会输出本次启动到失败前的全部日志把最近几十行贴出来基本能看到具体的失败原因。如果日志太长可以用journalctl -xb | grep -i -E fail|error|emergency过滤出关键词快速锁定问题行。2.2 用 blkid 找到正确的 UUID很多紧急模式是因为fstab里的分区标识不对。Linux现在的推荐做法是用UUID而不是设备名来引用分区因为设备名/dev/sda1、/dev/sdb1可能在换硬盘、插U盘、调整BIOS启动顺序之后发生变化而UUID是文件系统创建时生成的唯一标识理论上不会变。但“UUID不会变”有一个前提你确实没动过这个文件系统本身。如果你用GParted调过分区大小、格式化过某分区、或者从别的机器克隆过系统盘UUID都可能变化或重复。还有一种特别容易踩坑的情况你用lsblk看到的“PARTUUID”和“UUID”不是同一个东西。PARTUUID是分区表层面的标识UUID是文件系统层面的标识fstab里用的是后者。进入emergency shell之后查看当前实际分区信息的命令是blkid输出大概长这样/dev/sda1: UUIDA1B2-C3D4 TYPEvfat PARTUUIDabcd1234-01 /dev/sda2: UUID5f8a6d1e-9a2c-4b3e-8f6f-1a2b3c4d5e6f TYPEext4 PARTUUIDabcd1234-02对照 /etc/fstab 里的每一行看它写的UUID是否能在blkid的输出里找到。找不到的就是问题所在。找到对应的正确UUID后把fstab里的旧值替换成新值即可。操作方式很简单先用nano打开fstabnano /etc/fstab找到出问题的行把UUID部分改成blkid查到的正确值。如果你不确定哪一行需要改就把当前fstab先备份一份然后按错误优先顺序处理。备份命令是cp /etc/fstab /etc/fstab.bak有了备份你后面怎么折腾都有退路。这个习惯我在处理任何配置文件前都会做哪怕只是改一个参数。2.3 编辑 /etc/fstab 的正确姿势修改fstab时我推荐的编辑工具是nano。vim在emergency mode下默认不一定有很好的配色而且对新手不友好按错一个键就容易不知所措。nano底部有快捷键提示CtrlO保存、CtrlX退出操作直观。拿到一份坏的fstab之后处理方式有三种按优先级来说第一种是注释掉问题行。在行首加一个#让系统跳过这项挂载。适合那种你已经不确定该分区还要不要用的情况。比如你之前挂载了一个Windows的数据分区后来Windows删了、分区也合并了但fstab里那行还在这时直接注释掉是最干净的解法。第二种是修正错误配置。比如UUID写错了、文件系统类型写错了、挂载点路径写错了直接改成正确的。举一个实际例子原本fstab里有一行UUID8f0f2f1a-1234-4b2e-9a7d-abcdef123456 /data ext4 defaults 0 2结果blkid查出来这个文件系统已经被格式化成了xfs格式UUID也变成了b2a1c3d4-5678-4e1a-8b3c-0987654321ab。那么这一行就要改成UUIDb2a1c3d4-5678-4e1a-8b3c-0987654321ab /data xfs defaults 0 2第三种是临时不挂载但保留配置先通过手动方式恢复系统。适用于你还没找到替代UUID、但系统里有重要服务需要先起来的情况。把对应行注释掉重启进入系统后再慢慢处理。这里要特别提醒fstab的格式。一行七个字段依次是设备标识、挂载点、文件系统类型、挂载选项、dump备份标记、fsck检查顺序。字段之间用空格或Tab分隔。很多人以为“多一个空格没关系”其实多余的空格如果造成了空字段systemd解析时就会报错。建议用Tab键统一分隔肉眼检查时不容易看错。改完之后不要急着重启。先执行验证命令mount -a没有任何输出代表fstab所有行都能正常解析并挂载。这时再重启才有意义。如果mount -a依然报错继续回2.2检查。2.4 手动挂载 重启验证有一种情况是fstab本身没错但某块分区因为文件系统损坏导致挂载失败。这时mount -a会提示类似“wrong fs type, bad option, bad superblock”的信息。遇到这种情况在确认UUID和文件系统类型都正确的前提下可以对损坏分区做一次文件系统检查。先找到问题分区对应的设备名比如 /dev/sda3然后执行fsck -f /dev/sda3fsck会扫描并尝试修复文件系统。注意fsck要求目标分区必须处于未挂载状态所以如果在emergency mode下确认它没有被挂载可以直接执行。修复过程中会问你是否修复某些坏块一般选 y。这个过程可能比较慢取决于分区大小和坏块数量耐心等。修复完成后重新执行 mount -a 验证如果所有挂载都成功重启即可reboot如果重启后正常进入桌面或命令行说明问题解决。如果又回到emergency mode那就需要用日志再次定位但大部分情况下走到这一步问题已经清楚了。3. 常见问题与排查技巧实录3.1 一个典型的“反复回到紧急模式”案例我处理过的一个案例很有代表性。一台Ubuntu 22.04服务器运维同事反馈重启后进不了系统反复到emergency mode。远程连上去看journalctl里反复出现Failed to mount /mnt/backup. dependency failed for /mnt/backup.一看fstab里面有一行UUIDabcd1234 /mnt/backup ext4 defaults 0 0但blkid查不到这个UUID。整个环境里根本没有这个设备。问了一下才知道之前这块备份盘是移动硬盘同事复制完数据后拔掉了硬盘忘了删fstab里的挂载行。系统每次开机都尝试挂载这个不存在的设备反复失败于是被卡在emergency mode。这种问题修复起来很简单注释或删除那行走人重启就好。但这个案例的教训值得说任何外接磁盘、网络共享目录都不建议长期留在fstab里。如果你确实需要经常挂载建议在挂载选项里加上 nofail这样即使设备不存在系统也不会因为挂载失败而进入紧急模式。类似的行可以写成UUIDabcd1234 /mnt/backup ext4 defaults,nofail,x-systemd.device-timeout5 0 0nofail选项的含义是“挂载失败也不影响后续启动流程”。配合 x-systemd.device-timeout 限制尝试时间可以避免网络挂载拖住启动流程几十秒甚至几分钟。3.2 报错信息速查表我在处理过程中整理过一个速查表遇到emergency mode时可以先对着排查报错特征可能原因定位命令解决思路cant find in /etc/fstabfstab里某行引用的UUID或设备不存在blkid、cat /etc/fstab用blkid对照修正UUID或注释掉错误行wrong fs type, bad option, bad superblock文件系统类型不对或分区损坏blkid、fsck -f /dev/设备修正fstab里的文件系统类型损坏则用fsck修复mount: unknown filesystem type ntfs 等缺少对应文件系统驱动ls /sbin/mkfs.*、apt list --installed安装 ntfs-3g 等支持包在fstab中指定正确类型dependency failed for xxxfstab中某挂载点依赖于不存在的设备systemctl status xxx.mount删除/注释对应fstab行或加nofailA start job is running for xxx挂载或服务等待超时systemctl list-jobs检查fstab中设备是否能访问网络挂载加超时选项/dev/sdaX contains a file system with errors文件系统有过错fsck -f /dev/sdaX修复文件系统后重启这张表不能覆盖所有情况但覆盖了我见过的大部分紧急模式场景。核心思路还是那四个字先看日志。3.3 LVM、加密盘和网络挂载的特殊处理如果你的系统盘用LVM管理或者有加密分区修复fstab时要格外小心。LVM逻辑卷在fstab里的标识通常是 /dev/mapper/vgname-lvname 这类路径。在emergency mode下如果LVM卷没有激活你可能需要先执行vgscan vgchange -ay激活卷组然后再用 blkid 查看逻辑卷的UUID。加密分区的情况更特殊。如果根分区本身是LUKS加密的进入emergency mode的前提是你已经能在initramfs阶段输过加密密码。如果加密密码正确但依然进不了系统多半是 /etc/crypttab 里写的设备路径或UUID和实际不符。检查crypttab的方式和fstab类似改之前先备份。网络挂载比如NFS写在fstab里时有两条硬性要求一是挂载选项里要加_netdev告诉systemd“这个挂载依赖网络不能放在网络就绪之前”二是有必要加x-systemd.device-timeout30这类超时参数防止网络不通时一直卡住。没有这两个参数网络抖动一次就可能把你送进emergency mode。3.4 忘记root密码时的恢复路径如果你不知道该设备的root密码还进了emergency mode事情会稍微麻烦一点。但好在Ubuntu的恢复路径很多最常用的是在GRUB启动菜单里临时修改启动参数。重启机器在GRUB菜单出现时按 e 进入编辑界面找到以linux开头的那一行在末尾加上init/bin/bash然后按 CtrlX 或 F10 启动。这样系统会跳过正常的init流程直接给你一个bash shell。接下来重新挂载根分区为可写状态mount -o remount,rw /之后你可以用 passwd 命令给现有用户设置新密码或者修改fstab。这种方式的本质是绕过systemd的启动检查手动控制启动过程。操作完不要直接reboot先执行exec /sbin/init让系统重新按正常流程接管启动避免跳过一些必要的挂载和初始化动作。这个方式能解决大多数“忘记密码”和“fstab配置错误导致无法启动”的组合问题。4. 后续加固与长效建议4.1 修复完成后要不要重建 initramfs很多人在修好fstab之后会问要不要执行 update-initramfs -u我个人的实践结论是如果只改了fstab里的挂载参数、UUID或挂载点不需要重建initramfs。因为fstab是启动后期由systemd读取的不参与initramfs阶段。但如果你的问题涉及根分区本身尤其是LVM卷组结构变化、加密配置改动、或者你换了根分区的文件系统那就要执行update-initramfs -u这个命令会重新生成启动过程中用的临时根文件系统镜像确保新的设备配置被纳入。同理改过GRUB配置之后要执行update-grub两个命令都有点像“重新整理启动清单”一次改完跑一遍能避免很多次启动阶段才暴露的问题。4.2 预防比修复更重要说实话emergency mode本身并不可怕真正可怕的是“不知道自己在改什么也不做任何保护措施”。这里分享几个我自己的血泪习惯每次修改fstab前先备份一份备份文件名带上日期。命令就是cp /etc/fstab /etc/fstab.20250115这样。别小看这一步关键时刻它能让你在1分钟内回到上一个可用状态。调整分区、格式化分区、克隆系统盘之前先确认当前fstab里所有分区的位置和UUID并用blkid把新状态记录下来。实际操作中我见过太多“调整完分区后重启发现fstab里的UUID全部失效”的案例。手边常备一个Ubuntu Live USB。live系统环境下操作磁盘、编辑目标系统文件都很方便而且完全不影响原系统。万一紧急模式下的shell工具不全live U盘里基本什么都有。很多人在虚拟机里玩Ubuntu快照也可以当备份用但物理机上没有任何理由不做Live USB。如果是远程服务器修改fstab前一定要确认自己还能通过控制台比如IPMI、KVM、云厂商的VNC访问机器。否则一个手误服务器重启后进不了系统你又没有除了SSH之外的第二条通道那就真的只能跑一趟机房了。4.3 值得固化的操作习惯改完配置先验证最后说一个我坚持了很多年的习惯。修改任何系统配置文件之后不是直接重启而是先执行与配置对应的“预检命令”。改fstab就执行 mount -a改GRUB就执行 update-grub 和 grub-mkconfig改网络配置就执行 networkctl 或 netplan apply改crontab就执行 crontab -l 检查语法。“先验证再重启”这六个字能帮你把90%的“改完配置起不来”问题掐死在重症之前。毕竟紧急模式虽然能修能不进去才是最好的。另外一个我踩过的坑是手动编辑fstab时不要在行尾留空格不要用Windows系的换行符。如果你是用U盘里的Windows工具编辑过ubuntu的fstab特别注意一下换行符问题。用nano重写一遍或者用 sed -i s/\r$// /etc/fstab 清理一下能避免很多诡异报错。老实说我刚开始接触Ubuntu时第一次遇到emergency mode也是慌的。那个屏幕黑白相间满屏英文日志感觉就像系统在对我宣判“没救了”。后来修的次数多了才意识到这个界面其实是个很贴心的设计它给了你一个带root权限的shell给了你日志等于把一个完整的故障现场交到你手上。关键就是在现场里找到那张“写错的清单”改掉它重新启动。我个人建议你把这篇文章收藏下来等真的遇到那一天时一步一步按照顺序来先看日志再对照blkid然后谨慎修改fstab最后用mount -a验证后重启。整个过程最多需要十几分钟。如果真的修不好至少你还有Live USB这条退路。最后再分享一个小技巧在emergency mode下看到一份你不理解的fstab时别急着删行先把每行最后一个字段0和2这两个数字核对一遍。根分区一般是0 1其他需要检查的文件系统是0 2无需检查的是0 0。很多次所谓的“启动故障”其实只是这个字段被人改错了或者整行是从网上复制来的带多余空格的模板。检查完这个再考虑其他复杂的可能性能省下大量折腾时间。