Booting Fedora takes a long time on my Z170x mobo it i1-7700k. These seem to take a long time:
1min 45.729s plocate-updatedb.service
1min 72ms NetworkManager-wait-online.service
I’ve disabled the unused Kiler E3000 NIC as the linux drivers don´t handle this well and cleaned out all bridges that ware still defined on this nic in /etc/NetworkManager/system/connections. What else can/should I do to reduce the boot times?
plocate-updatedb.service is not called at boot time but by plocate-updatedb.timer
daily.
If you don’t mind to not have the network up when loging in, you can disable
NetworkManager-wait-online.service
What gives:
systemd-analyze
systemd-analyze blame | head -20
.nmconnection files from /etc/NetworkManager/system-connections which were related to a Killer E3000 NIC that I disabled because of driver warnings in dmesg.systemd-analyze blame:5.149s sys-module-fuse.device
4.952s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2data\x2d1.0.device
4.952s dev-disk-by\x2ddiskseq-2.device
4.952s sys-devices-pci0000:00-0000:00:1b.3-0000:04:00.0-ata7-host6-target6:0:0-6:0:0:0-block-sr0.device
4.952s dev-disk-by\x2did-ata\x2dBD\x2dW26SS\x2dB.device
4.952s dev-sr0.device
4.952s dev-disk-by\x2dpath-pci\x2d0000:04:00.0\x2data\x2d1.device
4.952s dev-cdrom.device
4.887s sys-devices-LNXSYSTM:00-LNXSYBUS:00-MSFT0101:00-tpm-tpm0.device
4.887s dev-tpm0.device
4.872s sys-module-configfs.device
4.851s sys-devices-platform-serial8250-serial8250:0-serial8250:0.3-tty-ttyS3.device
4.850s dev-ttyS3.device
4.828s sys-devices-platform-serial8250-serial8250:0-serial8250:0.2-tty-ttyS2.device
4.828s dev-ttyS2.device
4.823s dev-ttyS0.device
4.823s sys-devices-platform-serial8250-serial8250:0-serial8250:0.0-tty-ttyS0.device
4.822s dev-ttyS1.device
4.822s sys-devices-platform-serial8250-serial8250:0-serial8250:0.1-tty-ttyS1.device
4.813s dev-tpmrm0.device
And systemd-analyze by itself:
Startup finished in 14.711s (firmware) + 3.668s (loader) + 8.181s (kernel) + 3.345s (initrd) + 49.802s (userspace) = 1min 19.708s
graphical.target reached after 49.782s in userspace.
It’s surprising that systemd-analyze blame does not list
NetworkManager-wait-online.service as taking 1min 72ms
Where did you got this duration from ?
You could see how long it takes in the current boot with:
sudo journalctl --no-hostname -b -u NetworkManager-wait-online.service
Jan 10 21:50:55 systemd[1]: Starting NetworkManager-wait-online.service - Network Manager Wait Online...
Jan 10 21:50:59 systemd[1]: Finished NetworkManager-wait-online.service - Network Manager Wait Online.
4 seconds on my desktop.
This is effectively rather long. On my desktop it’s around 27s.
I suspect that the only way to accelerate the boot is to minimize the number of services
launched in the multi-user target.
Run systemctl list-dependencies multi-user.target, look for the direct dependent
services, disable the ones you are sure you do not need.
A workaround is to suspend your machine instead of powering off. My desktop takes less
than 10s to resume.
You may want to look at systemd-analyze critical-chain to find out what services are holding up the process - a slow starting service isn’t a problem if it isn’t holding anything else up!
The graphical output (systemd-analyze plot > /tmp/boot.svg) can also be interesting to look through for any outliers.
Yes, those commands are really useful.
In my case systemd-analyze critical-chain display-manager shows that the display-manager
waited ~23s because of akmods (one kmod had to be built):
systemd-analyze critical-chain display-manager.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
lightdm.service +43ms
└─akmods.service @2.985s +23.503s
└─akmods-keygen.target @2.984s
but this is also shown in the output of systemd-analyze blame:
systemd-analyze blame
23.503s akmods.service
19.425s plymouth-quit-wait.service
[...]
I may hope that the time spent in userspace by my desktop will go down to ~5s on the next
reboot (if no kmod to build)