Fix Slow Boot on Ubuntu with systemd-analyze

systemd-analyze
systemd-analyze critical-chain
systemd-analyze blame | head -n 15
# desktop: stop waiting for the network to be "online"
sudo systemctl disable NetworkManager-wait-online.service

Step 1: Measure the boot

systemd-analyze

Example output:

Startup finished in 7.912s (firmware) + 2.104s (loader) + 2.380s (kernel) + 1min 34.551s (userspace) = 1min 46.948s
graphical.target reached after 1min 34.402s in userspace.

Each part points to a different area:

A clean 90-second-ish delay (1min 30s plus a few seconds) is the signature of a systemd job timeout: something waited for its default 90 s limit.

Step 2: Find what is on the critical path

systemd-analyze critical-chain

Example output:

graphical.target @1min 34.402s
└─multi-user.target @1min 34.401s
  └─plymouth-quit-wait.service @1min 31.020s +3.380s
    └─systemd-user-sessions.service @1min 30.990s +25ms
      └─network-online.target @1min 30.981s
        └─systemd-networkd-wait-online.service @1.112s +1min 29.866s
          └─systemd-networkd.service @1.010s +98ms

Read it bottom-up. The time after @ is when the unit became active; the time after + is how long it took to start. Here systemd-networkd-wait-online.service took 1 min 29 s and everything above waited for it.

blame lists units by start time, useful as a second view:

systemd-analyze blame | head -n 15

1min 29.866s systemd-networkd-wait-online.service
      6.204s snapd.seeded.service
      4.118s NetworkManager-wait-online.service
      2.977s plymouth-quit-wait.service
      1.403s dev-nvme0n1p2.device

Don't disable everything near the top of blame: many units start in parallel and don't hold up the desktop. Fix what critical-chain shows. For a visual timeline, systemd-analyze plot > boot.svg and open the file in a browser.

Finally, check the log for timeouts and failures during the last boot:

journalctl -b -p warning --no-pager | grep -i -E 'timed out|timeout|failed|start job'
systemctl --failed

The journalctl cheat sheet has more filters.

Fix: network wait-online services

network-online.target exists for services that must not start before the network has an address. Its wait services block until every managed interface is configured. A disconnected Ethernet port or a Wi-Fi network that needs a login makes them wait until timeout.

Desktop (NetworkManager)

sudo systemctl disable NetworkManager-wait-online.service

On a laptop or desktop, nothing important needs it, and NetworkManager still connects as soon as it can. If you mount network shares at boot, mark them _netdev in fstab instead of relying on this service.

Ubuntu Server (systemd-networkd and Netplan)

Tell Netplan which interfaces are optional, so the wait service ignores them:

network:
  version: 2
  ethernets:
    enp3s0:
      dhcp4: true
    enp4s0:
      dhcp4: true
      optional: true

Apply with sudo netplan apply. Alternatively, wait for any one interface instead of all with a drop-in:

sudo systemctl edit systemd-networkd-wait-online.service

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any --timeout=20

The empty ExecStart= clears the original command before setting a new one. See systemd basics for how drop-ins work.

Fix: fstab and swap timeouts

A boot message like this means systemd is waiting for a device listed in /etc/fstab:

A start job is running for /dev/disk/by-uuid/3f2a...-c41e (1min 12s / 1min 30s)

Compare fstab with the UUIDs that actually exist:

cat /etc/fstab
lsblk -f
sudo blkid

Any UUID in fstab that isn't in lsblk -f is the problem, often an old swap partition replaced by a swap file, or a removed USB or second disk. Edit the file with sudo nano /etc/fstab and either correct the UUID, comment the line out with #, or, for removable or optional disks, add nofail and a short timeout:

UUID=3f2a...-c41e  /mnt/data  ext4  defaults,nofail,x-systemd.device-timeout=10s  0  2

Test without rebooting: sudo systemctl daemon-reload && sudo mount -a. No output means the syntax is fine.

Swap resume device (slow kernel phase)

If the kernel phase is slow and the boot pauses before the logo, the initramfs may be waiting for a hibernation resume device that no longer exists. Check for a configured resume device:

cat /proc/cmdline
cat /etc/initramfs-tools/conf.d/resume 2>/dev/null
swapon --show

If a resume=UUID=... setting points to a swap partition you no longer have, remove it. On Ubuntu 24.04 and Mint, set RESUME=none in /etc/initramfs-tools/conf.d/resume and run sudo update-initramfs -u. Ubuntu 26.04 builds the initramfs with Dracut, which takes the resume device from the kernel command line; remove any stale resume= from GRUB_CMDLINE_LINUX_DEFAULT, run sudo update-grub, then sudo dracut --force. See kernel parameters for editing the command line.

Fix: other common slow units

To find out what a unit does before touching it: systemctl cat UNIT and systemctl list-dependencies --reverse UNIT. Disable only units you understand; masking core units can stop the system from booting.

Compare before and after

After each change, reboot and run systemd-analyze again. Change one thing at a time so you know what helped, and write down what you disabled so you can undo it with sudo systemctl enable UNIT if something stops working later.

Slow after login (desktop)

If the boot is fast but the desktop takes long to become usable after you log in, check the user session:

systemd-analyze --user blame | head
systemd-analyze --user critical-chain

Common causes are GNOME Shell extensions (disable them all in the Extensions app to test), many autostart apps (~/.config/autostart/), and file indexing right after a large file copy (localsearch or tracker-miner on GNOME, Baloo on KDE).

GRUB menu delay and seeing what happens

If the GRUB menu always appears and waits, lower the timeout in /etc/default/grub:

GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=2

Then sudo update-grub. On dual-boot systems GRUB always shows the menu; keep a short timeout rather than zero so you can still reach Windows or recovery mode.

The splash screen hides what the boot is waiting for. To see messages for one boot, press e at the GRUB menu and remove quiet splash from the linux line, or press Esc during the splash. Status lines with timers show the waiting unit.

Shutdown is slow too?

"A stop job is running for ..." on shutdown has a similar cause: a service that doesn't stop and waits for its 90 s timeout. After the next boot, look at the end of the previous boot's log:

journalctl -b -1 -n 80 --no-pager

Fix or report the service that hangs. Lowering DefaultTimeoutStopSec in /etc/systemd/system.conf hides the symptom and can interrupt services that are legitimately saving data, so prefer fixing the unit. For other boot problems, see the Ubuntu troubleshooting hub; upstream documentation is the systemd-analyze man page.

Frequently asked questions