Diagnose and Fix Slow Boot Times in Arch Linux (2026)
Arch is supposed to be the fast one — lean, minimal, ours. So when a boot takes a minute and a half, it stings. The fault is nearly always one of four things: network services fighting each other, a service that waits on the network before continuing, a bloated initramfs, or ancient firmware. systemd ships the measuring tape; you just have to read it.
Measure before you touch anything
systemd-analyze time
systemd-analyze blame
systemd-analyze critical-chain graphical.target
systemd-analyze plot > boot.svg
time splits the boot into firmware, loader, kernel and userspace; blame ranks services by startup cost; critical-chain shows what is actually gating your graphical target; plot renders the whole story as an SVG timeline. When the output reads like this:
Startup finished in 8.075s (firmware) + 3.495s (loader) + 1.414s (kernel) + 1min 30.309s (userspace)
...then userspace is the villain and everything below applies. If firmware dominates instead, update the BIOS and read the last section only.
The usual suspects
The classic Arch mistake is running several network managers at once — systemd-networkd, iwd, dhcpcd and netctl all enabled, each politely waiting on the others. Keep one (NetworkManager is the common choice) and retire the rest:
sudo systemctl disable dhcpcd netctl systemd-networkd-wait-online.service
The other serial offender is NetworkManager-wait-online.service, which stalls boot until the network counts as connected — on flaky Wi-Fi that means minutes. Desktops rarely need it:
sudo systemctl disable NetworkManager-wait-online.service
If you genuinely must wait (an NFS-mounted /home, say), cap it with a ten-second timeout in a drop-in override instead of letting it decide. And for heavy services like Docker, use socket activation so they start on first connection rather than at boot:
sudo systemctl disable docker.service
sudo systemctl enable docker.socket
Kernel, initramfs and firmware
If the kernel phase runs long, check journalctl -b for GPU timeouts, NVMe resets, or a failing SSD retrying reads. In /etc/mkinitcpio.conf, swapping the classic base udev hooks for the systemd hook parallelizes early userspace and trims initramfs time; the booster and dracut alternatives go further. Kernel parameters worth trying: nowatchdog if you don't need the software watchdog, and libahci.ignore_sss=1 on some SATA boards. Mount non-critical filesystems with noauto,x-systemd.automount so they mount on first touch, not at boot. And since UEFI firmware is the slowest layer on older boards, update it, trim the boot menu, and prefer systemd-boot over GRUB — it skips an entire scripting layer.
Worked example
That 1-minute-43-second boot above: critical-chain showed network.target waiting on overlapping services, so the fix was disabling the extra network managers plus NetworkManager-wait-online, and moving Docker to its socket. Result: the boot fell to about fourteen seconds, with firmware now the biggest line item left. Take a snapper snapshot first, change one thing at a time, re-run systemd-analyze time after each change, and keep what helped.
A slow boot is a small, fixable wait — but waiting is not evenly shared in this world, and Gaza's families have waited far too long for things that should never have been in question. May that end soon.
And when your machine boots in seconds and the day suddenly has room in it, put that room somewhere good: at HTG Travels we rebook cancelled flights, chase refunds and reroute stranded travellers at odd hours from Sialkot — the same way you chase a boot chain, start to finish, until it works.
