A slow boot feels like an old-machine problem, but on most modern Linux desktops it is a startup-queue problem. A printer service you never use, a network wait that holds the whole boot hostage, or a mount that times out can each add tens of seconds before you see your wallpaper. The fix is not a random "speed up Linux" script from the internet. It is a measurement loop: time the boot, find the slowest stage, change one thing, and time it again.

This guide walks through that loop on any systemd-based distribution: Ubuntu, Fedora, Debian, Arch, and their derivatives. You need a terminal, sudo access, and about fifteen minutes. The core commands below were verified on Ubuntu 24.04. If you are still getting comfortable with the terminal, read our weekend guide to the Linux command line basics first.

Before you touch anything, make a safety net. Disabling the wrong service can leave you without networking or a login screen. Take a system snapshot first if your setup supports it; our Btrfs snapshots with Snapper playbook covers one reliable way. At minimum, write down each service you disable.

1. Measure the boot before you change anything

Open a terminal and run:

BASH
systemd-analyze

You will get one line like this:

TEXT
Startup finished in 4.213s (firmware) + 2.840s (loader) + 3.102s (kernel) + 9.731s (userspace) = 19.887s

Firmware time is spent before Linux even starts, and no service tweak will fix it. Kernel and userspace time are where your changes pay off. Write the total down; that is your baseline.

Next, list the slowest services:

BASH
systemd-analyze blame | head -20

The output is sorted with the slowest service at the top. Two things trip up beginners. First, services start in parallel, so the times do not add up to the total boot time; a 5-second service and a 4-second service running side by side cost roughly 5 seconds, not 9. Second, a long time does not automatically mean a problem. A service waiting on a network timeout is a suspect. A service taking 8 seconds doing work you want, like mounting an encrypted disk, is not.

2. Find the chain that actually delays your login

blame shows individual suspects. The critical chain shows the sequence that gates your login screen:

BASH
systemd-analyze critical-chain

Look for the longest chain ending at graphical.target. If one service sits on that chain with a big time next to it, that is your prime suspect. If the chain is short but the total is still long, the delay is spread across parallel services, or it lives in the firmware stage, which points at BIOS or UEFI settings rather than Linux.

Also check for failed units, because a service that fails and retries can stall the boot quietly:

BASH
systemctl --failed

A failed unit is worth investigating before any optimisation; fixing one broken service often beats disabling three healthy ones.

3. Check the two classic time sinks

The network wait

On many desktops, the single biggest boot delay is NetworkManager-wait-online.service. It holds the boot until a network connection is up, which can mean a long wait on slow Wi-Fi. Disabling it does not disable networking; the desktop simply stops waiting for the network before showing the login screen.

If you see it near the top of blame, disable it:

BASH
sudo systemctl disable NetworkManager-wait-online.service

Exception: leave it alone on machines that need the network before boot finishes, such as a server mounting NFS shares at startup. On a normal laptop or desktop, it is safe to drop.

A mount that times out

A stale /etc/fstab entry for a drive that no longer exists is another classic: systemd waits for the device, gives up after a long timeout, and only then continues. Check your boot log:

BASH
journalctl -b -p err

If you find a device timeout for a non-essential disk, add nofail and a short timeout to its /etc/fstab options, for example nofail,x-systemd.device-timeout=10s, so a missing disk costs at most ten seconds.

4. Disable only services you recognise and do not use

List what is set to start at boot:

BASH
systemctl list-unit-files --state=enabled

Compare that list against what your machine actually does. Common candidates include the print service (cups.service) on a machine with no printer, bluetooth.service on a machine with no Bluetooth devices, and ModemManager.service on a machine with no mobile broadband modem.

The rule is strict: if you do not recognise a service, leave it alone. Disabling dbus.service, systemd-udevd.service, NetworkManager.service itself, or your display manager (gdm.service or sddm.service) will break your system in ways that are unpleasant to repair from a black screen.

BASH
sudo systemctl disable cups.service

That only stops it starting at boot; it does not uninstall anything, and the undo is one command:

BASH
sudo systemctl enable cups.service

Change one or two services at a time, reboot, and re-measure. If you change six things at once and the boot breaks, you will not know which one did it. If you are unsure about a service, search its name plus your distribution before touching it.

5. Tame desktop autostart

Not all boot slowness is systemd. The desktop itself launches applications after login, and a browser, chat client, and cloud sync tool all starting at once can make a fast boot feel slow. In GNOME, open Tweaks and check Startup Applications. In KDE Plasma, check System Settings, then Autostart. Remove anything you do not need within the first minute of logging in.

The same applies to systemd user services, listed with systemctl --user list-unit-files --state=enabled; disable only ones you recognise.

6. Trim the bootloader timeout

If your machine dual-boots or shows a boot menu, part of your wait is simply the menu counting down. On Ubuntu and Debian, edit /etc/default/grub and set GRUB_TIMEOUT to 5, then apply it:

BASH
sudo update-grub

On Fedora, apply the change with:

BASH
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Do not set the timeout to zero: you lose the fallback kernel menu when an update goes wrong. Five seconds is a sensible floor for dual-boot; a single-OS machine can go to two.

7. Verify the result, then stop

Reboot and run the measurement again:

BASH
systemd-analyze

Compare it with your baseline. A realistic win on a typical desktop is a few seconds to a bit over ten, depending on what was stalling. If your total barely moved, re-check blame: either the delay is in the firmware stage, which only BIOS or UEFI settings can touch, or it is a hardware limit. A spinning hard drive will never boot like an SSD, and no service tweak changes that.

For a deeper look, generate a visual timeline:

BASH
systemd-analyze plot > boot.svg

Open boot.svg in a browser to see every service on a timeline.

Keep a short note of what you disabled and the before-and-after numbers. Boot times drift as you install software, and that note is what tells you, six months from now, whether a new slowdown is a new service or an old one creeping back.

Once you are comfortable reading systemd-analyze output, our guide to systemd timers versus crontab is a good next step.

Sources