Ubuntu 进入紧急模式（emergency mode）的一个解决方法

文章目录

一、前言
二、问题排查
三、解决方法
小结

一、前言

这里只介绍一种可能导致 windows+ubuntu 的双系统，在启动 ubuntu22.04 的时候进入紧急模式（无图像界面，只有命令行）的解决方法。这个问题大概率会出现在 windows 系统 的大版本更新 （如 22H2 → 23H2）的时候，因为大版本更新可能会自动创建恢复分区、EFI 备份分区等，插入到现有分区之间，导致后续分区编号整体后移，特别是先装 windows 后装 ubuntu，windows 更新可能重排分区。而在 Linux 中，NVMe 磁盘的分区命名规则是：nvme0n1表示第一块 NVMe 硬盘，nvme0n1p1, nvme0n1p2依次表示硬盘上的分区。
如果我们之前在/etc/fstab中定义系统启动时或运行中自动挂载文件系统是：/dev/nvme0n1p4 /media/xxx/data ext4 defaults 0 0，但实际上现在的分区编号变成了/dev/nvme0n1p5，系统启动时尝试挂载不存在的/dev/nvme0n1p4就会失败，从而进入紧急模式并跳过图形界面。
当前的问题仅适用于，安装了 桌面版的ubuntu 系统，并且之前可以正常使用的情况下，如果是服务器版本，那么就有可能是其他问题，这里不涉及。

二、问题排查

对于这种紧急模式，一般会先进行常规的排查，确认核心文件是否存在，链接指向是否正确。

bash 复制代码

# 检查 display-manager.service 软链接，正常应该链接到 gdm3.service
ls -l /etc/systemd/system/display-manager.service

# 检查服务状态
systemctl status gdm3.service
 
# 检查 gdm3 是否安装
dpkg -l | grep gdm3

# 检查是否安装了桌面环境
dpkg -l | grep ubuntu-desktop

# 查看 default.target 实际指向
systemctl get-default

检查 graphical.target 是否 active ，如果是 inactive ，说明系统根本没有激活图形目标，所以 gdm3 根本不会被启动。
bash 复制代码
```
systemctl is-active graphical.target  # 观察终端返回结果 
```
检查 default.target 实际指向，正常应该是链接到 graphical.target ，但 systemd 在启动时可能因某种原因回退到了 multi-user.target（命令行）。
bash 复制代码
```
ls -l /etc/systemd/system/default.target
```

默认目标的两种不同的链接路径。

bash 复制代码

/etc/systemd/system/default.target -> /lib/systemd/system/graphical.target
/etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

如果默认目标的实际指向不是图形目标，可以尝试显式设置为 graphical.target。
bash 复制代码
```
sudo systemctl set-default graphical.target
```

或者直接手动重建 systemd 链接。

bash 复制代码

# 删除旧链接
sudo rm -f /etc/systemd/system/default.target

# 创建新链接
sudo ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target

# 重载配置
sudo systemctl daemon-reload

# 验证
systemctl get-default  # 应输出 graphical.target

如果上述排查都没有问题，在紧急模式的终端中输入 sudo mount -a 按照 /etc/fstab 文件中的配置，挂载所有还没有挂载的文件系统。我的问题就出现在这里，会出现类似的结果：
bash 复制代码
```
mount: /media/xxx/data: wrong fs type, bad option, bad superblock on /dev/nvme0n1p4, missing codepage or helper program, or other error.
```
在 systemd 里，路径/media/xxx/data会自动变成 mount unit 名media-xxx-data.mount，查找与 nvme01p4 相关的 systemd 单元执行，指令并利用 .* 正则表达式过滤：systemctl list-units --all | grep -i media.*data，大概率会看到如下的结果：
bash 复制代码
```
media-xxx-data.mount    loaded    failed    failed    /media/xxx/data
```
从这个结果中也可以看出，这个分区当前挂载失败也没有启动，因为正常情况下的输出结果如下：
bash 复制代码
```
media-xxx-data.mount    loaded    active    mounted    /media/xxx/data
```

三、解决方法

注释/etc/fstab 文件中的挂载配置，为了避免类似情况，后续其实可以使用UUID来挂载，而不是使用/dev/nvme0n1p4，这个很容易被修改，而 UUID 一般不会被改变。

停止并禁用该挂载单元。

bash 复制代码

sudo systemctl stop media-xxx-data.mount
sudo systemctl disable media-xxx-data.mount

重载 systemd 配置。
bash 复制代码
```
sudo systemctl daemon-reload
```
重启系统，应该可以进入图形界面。
bash 复制代码
```
sudo reboot
```

小结

上述问题是我在更新过windows大版本系统之后，因为硬盘编号问题导致的挂载异常，从而触发紧急模式，现实中也可能因为磁盘损坏、格式错误等其他问题导致紧急模式的触发，这里也只能提供有限的参考，如果其他问题，欢迎在评论区讨论！！