修复 Windows 双启动系统中 Debian 启动极慢的问题

Source: Dev.to

问题概述

Debian 的启动时间异常长：

Startup finished in 7s (firmware)
+ 5s (loader)
+ 4s (kernel)
+ 2min 41s (userspace)

内核加载很快。延迟全部出现在 userspace，也就是说系统服务被某些东西阻塞。

第一步：测量启动过程

找出时间花在哪里：

systemd-analyze

确认是 userspace 导致的延迟。

检查哪些服务比较慢：

systemd-analyze blame

有几个服务大约耗时 30 秒，但很多是并行启动的，输出可能会产生误导。

要找出真正的阻塞点，使用：

systemd-analyze critical-chain

第二步：确定阻塞的依赖

关键链显示如下：

dev-disk-by-uuid-1CEE-9C07.device @ 1min+
└─ systemd-fsck@...
└─ boot-efi.mount

所有内容都在等待一个磁盘设备，具体是用于 /boot/efi 的那个。

第三步：确认该设备

查看该 UUID 属于哪个设备：

lsblk -f

相关输出：

nvme0n1p7  vfat  UUID=1CEE-9C07  /boot/efi

阻塞的设备是 EFI 系统分区，格式为 VFAT，并且与 Windows 共享。

根本原因

在双系统环境下：

• Windows 经常会修改 EFI 分区。
• VFAT 设备在固件交接后可能需要一些时间才能就绪。
• systemd 将 /boot/efi 视为关键挂载点。
• 默认超时时间约为 90 秒。

因为 /boot/efi 在启动的非常早期就要挂载，所有其他服务都会被阻塞，直到它可用。这是常见的双系统边缘案例，并非 Debian 的 bug。

第四步：安全地应用修复

目标 不是 删除 /boot/efi，而是防止它阻塞整个启动过程。

编辑 /etc/fstab：

sudo nano /etc/fstab

原始条目

UUID=1CEE-9C07  /boot/efi  vfat  umask=0077  0  1

更新后的条目

UUID=1CEE-9C07  /boot/efi  vfat  umask=0077,nofail,x-systemd.device-timeout=5s  0  1

这项更改的作用

• nofail – 即使 EFI 分区加载缓慢或缺失，系统仍继续启动。
• x-systemd.device-timeout=5s – 限制 systemd 等待 EFI 设备的时间。

EFI 分区仍会正常挂载，只是不会再阻塞启动。

结果

直接进入 Debian 后重新启动：

Startup finished in 7.0s (firmware)
+ 4.7s (loader)
+ 4.2s (kernel)
+ 8.8s (userspace)
= ~25 seconds total

问题彻底解决。

关键要点

• 始终先使用 systemd-analyze。
• 用 critical-chain 找到真正的阻塞点。
• 双系统的 EFI 分区是常见的启动延迟来源。
• 只需针对性的 fstab 修改即可解决数分钟的启动时间。
• 避免盲目禁用 fsck 或核心服务。

结论

长时间的启动并非性能问题、内核故障或系统损坏，而是 systemd 正在为共享的 EFI 分区等待过久。了解 系统在等什么 往往比随意关闭服务更有效。

如果你在 Linux 与 Windows 双启动时遇到启动缓慢，首先检查 /boot/efi。