DEV Community

Cover image for Fixing Extremely Slow Debian Boot on a Windows Dual-Boot System
Siddharth Magesh
Siddharth Magesh

Posted on

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

#linux #debian #dualboot #systems

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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

This confirmed that userspace was responsible for the delay.

Next, I inspected which services were slow:

systemd-analyze blame
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Step 2: Identify the blocking dependency

The critical chain showed this:

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

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
Enter fullscreen mode Exit fullscreen mode

Relevant output:

nvme0n1p7  vfat  UUID=1CEE-9C07  /boot/efi
Enter fullscreen mode Exit fullscreen mode

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 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
Enter fullscreen mode Exit fullscreen mode

Original entry:

UUID=1CEE-9C07  /boot/efi  vfat  umask=0077  0  1
Enter fullscreen mode Exit fullscreen mode

Updated entry:

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

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
Enter fullscreen mode Exit fullscreen mode

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
  • One targeted fstab change 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.

Top comments (0)