Linux usually boots quickly, but a single misbehaving unit can add 10, 30, or 90 seconds. systemd-analyze shows exactly where the time goes. This guide covers how to read it and how to fix the usual culprits.

For background on what happens during boot, see the Linux boot process explained.

Step 1: the overall picture

systemd-analyze

Startup finished in 6.2s (firmware) + 1.9s (loader) + 1.4s (kernel)
  + 2.8s (initrd) + 9.7s (userspace) = 22.1s
graphical.target reached after 9.6s in userspace.

Phase	What it is	Can Linux speed it up?
firmware	BIOS/UEFI initialising hardware	No, but firmware settings can
loader	GRUB or systemd-boot	Yes: shorter menu timeout
kernel	Kernel initialisation	A little
initrd	The initramfs finding and mounting root	Sometimes
userspace	systemd starting services	Usually the biggest win

Step 2: who took the longest

systemd-analyze blame

8.104s NetworkManager-wait-online.service
3.012s plymouth-quit-wait.service
1.904s snapd.service
1.215s docker.service
...

Be careful with this list. systemd starts units in parallel, so a slow unit only matters if something waited for it. A service that takes 20 seconds in the background may not have delayed your login at all.

Step 3: what actually delayed boot

systemd-analyze critical-chain

graphical.target @9.6s
└─multi-user.target @9.6s
  └─docker.service @8.3s +1.2s
    └─network-online.target @8.2s
      └─NetworkManager-wait-online.service @0.1s +8.1s

This is the chain of units that boot actually waited on. The time after @ is when the unit became active; the + time is how long it took. Here, Docker waited for the network to be fully online, and NetworkManager-wait-online took 8 seconds. That is the target.

Check the chain for one unit:

systemd-analyze critical-chain docker.service

Step 4: visualise it

systemd-analyze plot > boot.svg

Open boot.svg in a browser for a timeline of every unit, showing exactly what ran in parallel and what waited.

Common culprits and fixes

NetworkManager-wait-online (or systemd-networkd-wait-online)

The most common one. It holds network-online.target until the network is fully up, for services that need it immediately. On a desktop, usually nothing needs it:

sudo systemctl disable NetworkManager-wait-online.service

On a server with NFS mounts or services that bind to specific addresses, keep it. Alternatively, find which unit pulls it in, and decide whether that unit really needs network-online.target rather than just network.target:

systemctl list-dependencies --reverse network-online.target

Services you do not use

systemctl list-unit-files --state=enabled

Common candidates on a desktop that does not use them: ModemManager, cups (if you never print), bluetooth (no Bluetooth hardware), snapd (no snaps), and old VM or container daemons. Docker can be socket-activated so it starts only on first use; see systemd socket activation.

sudo systemctl disable --now ModemManager.service

Disable, do not mask, unless you are sure nothing should ever start it. Our systemctl guide explains the difference.

Waiting for a missing disk (the 90-second hang)

A “A start job is running for dev-disk-by…” message with a countdown means systemd is waiting for a device that is not there, usually an /etc/fstab entry for a disk that was removed or reformatted. The default wait is 90 seconds.

Fix the entry, or for removable and network disks, tell systemd not to block boot:

UUID=abcd-1234  /mnt/backup  ext4  defaults,nofail,x-systemd.device-timeout=5s  0  2

Our fstab guide and fstab line builder cover these options.

Slow initrd

A large initramfs with drivers you do not need, or waiting for an encryption passphrase, shows up in the initrd phase. Hostonly initramfs images (the default on Fedora and Arch) include only the drivers for your hardware; see initramfs explained.

Bootloader timeout

A 5 or 10 second GRUB menu counts as boot time. Lower GRUB_TIMEOUT in /etc/default/grub and regenerate the config, or use GRUB_TIMEOUT_STYLE=hidden. Our GRUB guide covers the details.

Firmware

Firmware time is spent before Linux runs. Enabling fast boot in the firmware, disabling unused controllers and network boot, and updating firmware with fwupd sometimes helps significantly.

Checking after changes

sudo reboot
systemd-analyze
systemd-analyze critical-chain

Compare with your first measurement. Make one change at a time so you know what helped.

Also useful

systemd-analyze verify /etc/systemd/system/myapp.service   # check a unit file for errors
systemd-analyze security myapp.service                     # sandboxing exposure score
journalctl -b -p warning                                   # warnings from this boot

systemd-analyze security pairs with our systemd service hardening guide.

Frequently Asked Questions

How do I see how long my Linux system takes to boot?

Run systemd-analyze. It prints the time spent in firmware, the bootloader, the kernel, the initramfs, and userspace, plus the total. systemd-analyze blame then lists individual services by how long they took to start.

Why is blame misleading?

systemd starts services in parallel, so a service that took 20 seconds may not have delayed boot at all if nothing waited for it. systemd-analyze critical-chain shows the chain of units that actually determined when boot finished, which is what you need to optimise.

What is NetworkManager-wait-online and can I disable it?

It delays the network-online.target until a network connection is fully up, for services that need the network immediately. On desktops it often adds several seconds and nothing needs it, so disabling it is common. On servers with network filesystems or services binding to specific addresses, keep it.

Why does boot hang for 90 seconds?

Usually a unit waiting for a device that never appears, most often a disk in /etc/fstab that is no longer attached or has a changed UUID. systemd waits up to 90 seconds by default. Fix or remove the fstab entry, or add nofail and x-systemd.device-timeout to entries for removable disks.

Why is firmware time so high?

Firmware time is spent before Linux starts, initialising hardware and running the BIOS or UEFI. It depends on the motherboard, memory training, attached devices, and settings like fast boot. Linux cannot shorten it, but firmware settings and updates sometimes can.

Does a faster boot matter on a server?

Less than on a desktop, but it still matters for recovery time after updates or failures and for virtual machines and containers that start frequently. On servers the bigger priority is that boot is reliable and does not hang on missing devices.