Diagnosing a Slow Ubuntu Boot with systemd-analyze

Your Ubuntu machine used to reach the login screen in twenty seconds and now takes two minutes. The fix is rarely \"reinstall\" — it is usually one unit, one mount, or one network wait blocking everything else. Ubuntu ships the tool you need: systemd-analyze, which tells you exactly which boot phase and which service ate the time. This guide walks through recognizing the condition, localizing the stall, applying targeted fixes, and knowing when the problem is deeper than unit tuning.

Recognizing the condition

A slow boot worth investigating has a pattern: it is consistently slower than the machine's own baseline, not just slower than a different PC. One-off slow boots after a kernel update or an unclean shutdown (which triggers a filesystem check) are normal. If three consecutive boots are all slow, start measuring.

Step 1: Split the boot into phases

Run this in a terminal after logging in — no root needed:

systemd-analyze

Output looks like:

Startup finished in 4.2s (firmware) + 3.1s (loader) + 8.5s (kernel) + 45.3s (userspace) = 1min 1.1s

Each phase points to a different class of problem:

If userspace dominates, keep going. If firmware or kernel dominates, skip to the escalation section.

Step 2: Find the unit that actually delayed boot

Two commands matter, and the second is more useful than the first:

systemd-analyze blame\nsystemd-analyze critical-chain

blame ranks units by how long they took to initialize. Treat it as a list of suspects, not a verdict: units start in parallel, so a service can take 30 seconds without delaying the login screen at all.

critical-chain shows the dependency path that actually held up the boot target. The unit at the top of that chain is your real problem. A typical finding:

graphical.target @1min 5.230s\n└─multi-user.target @1min 5.229s\n  └─NetworkManager-wait-online.service @15.2s +50.0s

That reads as: boot was blocked 50 seconds by NetworkManager-wait-online.

Step 3: Match the finding to a cause

Fixes tied to each finding

Network wait services

On a desktop or laptop using DHCP, nothing usually needs the network to be fully up before the login screen. Disable the wait:

sudo systemctl disable NetworkManager-wait-online.service

Run this in a terminal; it requires sudo and takes effect on next boot. Risk: if any unit genuinely needs networking at boot — an NFS or CIFS mount, a license check, a configuration-management agent — it will now fail or start before the network is ready. Check first with systemctl list-dependencies --reverse NetworkManager-wait-online.service and review your fstab for network mounts. On servers, prefer fixing why the link is slow (unplugged cable, spanning-tree delay on the switch port) over disabling the wait.

fstab entries blocking on a missing device

A missing disk or unreachable share costs a default 90-second timeout per entry. Edit /etc/fstab (sudo, any editor) and add options to non-essential mounts:

UUID=xxxx  /mnt/archive  ext4  nofail,x-systemd.device-timeout=5s  0  2

nofail lets boot continue if the device is absent; x-systemd.device-timeout shortens the wait. Before rebooting, validate the file:

sudo systemctl daemon-reload\nsudo mount -a

Any error here means fix fstab now — a malformed fstab can drop you to an emergency shell on next boot. Keep a live USB handy if you are editing mounts on a remote or headless machine.

Repeated fsck runs

If fsck appears every boot, the filesystem is not being marked clean — check dmesg and journalctl -b -p err for I/O errors, which suggest a failing disk rather than a configuration issue. Do not just tune out the checks.

Slow third-party service

If the service is not needed at boot, sudo systemctl disable <unit>. If it is needed but slow, check its logs for what it waits on; sometimes adding an explicit After= dependency fixes an accidental serialization.

Verify the fix

Record systemd-analyze output before changing anything. After each fix, reboot at least twice — the first boot after a change can be unrepresentative due to cache state — and compare userspace time and the critical chain. Expect the offending unit to disappear from the chain or drop to a small time.

When to escalate

Unit tuning stops helping when:

• The firmware or kernel phase dominates systemd-analyze output — look at BIOS/UEFI settings, initramfs contents (lsinitramfs /boot/initrd.img), and kernel command line.
• journalctl -b -p err shows driver failures or repeated device timeouts.
• dmesg shows I/O errors, ATA resets, or NVMe controller resets — that is hardware, and the next step is SMART data (sudo smartctl -a /dev/sda) and backups, not systemd changes.

At that point the boot time is a symptom, and the diagnostic target shifts from systemd to the kernel and the disk.