Investigating why Ubuntu boots slowly can be difficult. There are a lot of things that can go wrong: a lingering service, a bad config file, a wrong disk uuid in fstab and others.
In my opinion the easiest way to start is by using “systemd-analyze” which is part of systemd.
Since version 15.04, Ubuntu has switched from upstart to systemd as the default system and service manager. Systemd is not something specific to Ubuntu, but rather an industry standard that other major distributions have adopted as well: Debian, Fedora and CentOS to name a few.
“systemd-analyze” gives us information about what programs are run on startup and how much time they need to start.
There are around a dozen options that we can use from systemd-analyze to see where the startup bottleneck is. But from a time perspective we’re only interested in a few of them (to see the rest of the options available you can run “man systemd-analyze” in a terminal):
The options that we are interested in are:
Outputs the svg code with all the started services, their dependencies and how long it took for them to start.
For a better visualization you can pipe the output to an svg file and then open it with an image viewer:
$ systemd-analyze plot > init.svg
You should be looking for long red bars. These bars represent the time it took for that process to start.
When opening the generated svg, you should see something similiar to
Shows the amount of time spent after the bootloader has given control to the kernel up until the userspace finished initialization.
$ systemd-analyze time Startup finished in 7.541s (firmware) + 5.696s (loader) + 4.053s (kernel) + 8.206s (userspace) = 25.498sgraphical.target reached after 8.068s in userspace
The values in this example are for my laptop which has an i7 processor, 16GB of RAM and a 512GB SSD.
If you use an older system, you may not see the firmware data as this is available only for EFI/UEFI systems.
If a lot of time is spent in firmware, there might be an hardware issue.
Time in loader is the time needed by your bootloader, typically Grub. If a considerable amount of time is spent here it might mean that the bootloader can’t find some disks or maybe some kernel boot parameters are wrong.
Kernel time is used for loading drivers and other initializations. After the kernel finished its startup it will launch the init process (which usually has the id 1).
The init process, in our case is systemd and represents time spent in userspace.
Displays an ordered list of services, from slowest to fastest.
$ systemd-analyze blame 6.272s NetworkManager-wait-online.service 2.998s plymouth-quit-wait.service 930ms dev-sda6.device 795ms fwupd.service 632ms snapd.service 547ms motd-news.service 449ms plymouth-start.service 396ms NetworkManager.service 325ms upower.service 274ms systemd-logind.service
Similar to blame, but it takes into account dependencies between services. The slow starting services will be highlighted in red.
$ systemd-analyze critical-chain The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. graphical.target @8.068s └─multi-user.target @8.068s └─kerneloops.service @8.058s +10ms └─network-online.target @8.056s └─NetworkManager-wait-online.service @1.783s +6.272s └─NetworkManager.service @1.385s +396ms └─dbus.service @1.359s └─basic.target @1.356s └─sockets.target @1.356s └─snapd.socket @1.354s +2ms └─sysinit.target @1.354s └─systemd-timesyncd.service @1.137s +215ms └─systemd-tmpfiles-setup.service @1.125s +9ms └─local-fs.target @1.123s └─run-snapd-ns-docker.mnt.mount @2.093s └─run-snapd-ns.mount @1.818s └─swap.target @262ms └─swapfile.swap @157ms +104ms └─systemd-remount-fs.service @147ms +7ms └─systemd-journald.socket @140ms └─system.slice @139ms └─-.slice @137ms
By using all this information from systemd-analyze we can find out what is slowing the startup process. Once we know that, we can dig deeper and get to the root of the problem.