Fixing Extremely Slow Debian Boot on a Windows Dual-Boot System

Source: Dev.to

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

Identify where the time was being spent:

systemd-analyze

This confirmed that userspace was responsible for the delay.

Inspect which services were slow:

systemd-analyze blame

Several services appeared to take ~30 seconds, but many start in parallel, so the output can be misleading.

To find the real blocker, use:

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

Everything was waiting on a disk device, specifically the one used for /boot/efi.

Step 3: Identify the device

Find out what this UUID belongs 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/efi as 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 a common dual‑boot edge case, not a Debian bug.

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 the EFI partition is slow or missing.
• 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-chain to find the real blocker.
• Dual‑boot EFI partitions are a common source of boot delays.
• A single targeted fstab change can fix multi‑minute boot times.
• Avoid disabling fsck or core services blindly.

Conclusion

The long boot time was not a performance issue, kernel problem, or broken installation. 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.