I dual-booted my laptop with Windows and Debian, and while Windows booted normally, Debian consistently took 2–3 minutes to reach the desktop. The boot process showed multiple “checking” messages and long pauses.
This post documents the exact debugging steps I followed and the single configuration change that fixed the issue permanently.
Problem Overview
Debian boot time was abnormally long:
Startup finished in 7s (firmware)
+ 5s (loader)
+ 4s (kernel)
+ 2min 41s (userspace)
The kernel loaded quickly. The delay was entirely in userspace, meaning system services were blocked waiting for something.
Step 1: Measure the boot process
The first step was to identify where the time was being spent:
systemd-analyze
This confirmed that userspace was responsible for the delay.
Next, I inspected which services were slow:
systemd-analyze blame
Several services appeared to take ~30 seconds, but this output is misleading because many services start in parallel.
To identify the real blocker, I used:
systemd-analyze critical-chain
Step 2: Identify the blocking dependency
The critical chain showed this:
dev-disk-by-uuid-1CEE-9C07.device @ 1min+
└─ systemd-fsck@...
└─ boot-efi.mount
This revealed that everything was waiting on a disk device, specifically the one used for /boot/efi.
Step 3: Identify the device
To find out what this UUID belonged to:
lsblk -f
Relevant output:
nvme0n1p7 vfat UUID=1CEE-9C07 /boot/efi
The blocking device was the EFI system partition, formatted as VFAT and shared with Windows.
Root Cause
On dual-boot systems:
- Windows frequently modifies the EFI partition
- VFAT devices may take time to settle after firmware handoff
- systemd treats
/boot/efias a critical mount - The default timeout is ~90 seconds
Because /boot/efi mounts very early, all other services were blocked until it became available.
This is not a Debian bug. It is a common dual-boot edge case.
Step 4: Apply the fix safely
The goal is not to remove /boot/efi, but to prevent it from blocking the entire boot process.
Edit /etc/fstab:
sudo nano /etc/fstab
Original entry:
UUID=1CEE-9C07 /boot/efi vfat umask=0077 0 1
Updated entry:
UUID=1CEE-9C07 /boot/efi vfat umask=0077,nofail,x-systemd.device-timeout=5s 0 1
What this change does
nofail
Allows the system to continue booting even if EFI is slow
x-systemd.device-timeout=5s
Limits how long systemd waits for the EFI device
The EFI partition still mounts normally, but it no longer blocks the boot.
Result
After rebooting directly into Debian:
Startup finished in 7.0s (firmware)
+ 4.7s (loader)
+ 4.2s (kernel)
+ 8.8s (userspace)
= ~25 seconds total
The issue was completely resolved.
Key Takeaways
- Always start with
systemd-analyze
- Use
critical-chainto find the real blocker - Dual-boot EFI partitions are a common source of boot delays
- One targeted
fstabchange can fix multi-minute boot times - Avoid disabling fsck or core services blindly
Conclusion
This was not a performance issue, a kernel issue, or a broken install.
It was systemd correctly waiting for a shared EFI partition for too long.
Understanding what the system is waiting for is more effective than disabling random services.
If you are dual-booting Linux and Windows and experiencing long boot times, inspect /boot/efi first.