Is kubuntu 18.04 slow to boot?

[bendy]

Hi

Just wondering if anyone else has noticed this. On both my desktop and my girlfriends laptop, 18.04 seems quite slow to boot up. The laptop dual-boots with windows 7 pro, and windows gets to the log in screen in half the time. The laptop has a mobile core i7 cpu and an intel ssd, so it's decent hardware.

Could it be effect of the spectra mitigations? Or systemd?

Any suggestions for speeding up the boot time?

[jlittle]

My i7-6700 on a goodish SSD cold boots 18.04 (a fresh install) in 3 seconds from the grub screen to password screen, and it's 1 second from there to desktop.

If your boot is much longer than that, I suspect something is wrong.

Regards, John Little

[chimak111]

The output of systemd-analyze blame may offer some hints?

[Rod J]

Jeez, Jlittle, that's incredible boot speed ... I thought mine was really fast:

My desktop Core-i5-4670 on a Crucial SSD boots K18.04 (fresh install) in 8 seconds from Grub screen to password screen and about the same again from there to the desktop.

It boots much, much faster than the old K14.04 install did on the same hardware.

[gnomek]

My boot was also slow on 16.04 because of some bugs. Check commands that I used to identify problems:
https://www.kubuntuforums.net/showth...l=1#post417004
Now:

systemd-analyze
Startup finished in 1.274s (kernel) + 12.940s (userspace) = 14.214s

Not bad on old E7400 CPU and not the best SSD.

[kc1di]

It's a bit slow on my old I3 but have never really measured it. But then I retired so not in a rush

[bendy]

I'm getting nowhere near those speeds:

systemd-analyze
Startup finished in 179us (firmware) + 163us (loader) + 34.558s (kernel) + 18.879s (userspace) = 53.438s
graphical.target reached after 7.905s in userspace

Are you guys using UEFI or old fashioned bios mode? The other change I made is switching to UEFI when I installed 18.04.

Also:

systemd-analyze blame
       10.401s apt-daily.service
        6.285s NetworkManager-wait-online.service
         918ms dev-sdb1.device
         580ms apt-daily-upgrade.service
         228ms systemd-cryptsetup@cryptswap1.service
         198ms NetworkManager.service
         197ms mpd.service
         187ms udisks2.service
         179ms systemd-resolved.service
         176ms systemd-logind.service
         176ms systemd-timesyncd.service
         171ms upower.service
         139ms systemd-journal-flush.service
         132ms systemd-fsck@dev-disk-by\x2duuid-9810\x2dE5FB.service
         124ms networkd-dispatcher.service
         104ms keyboard-setup.service

[Rod J]

Are you guys using UEFI or old fashioned bios mode? The other change I made is switching to UEFI when I installed 18.04.

My system is UEFI booting, no compatibility mode, no secure mode, no Windows on this system. The SSD drive is GPT partitioned (not MS-Dos). I have one EFI partition (200Mb) which I created when I initially installed K14.04.

This is a screenshot showing my Crucial SSD setup:


You say you changed to UEFI when you installed 18.04. Are you dual booting with Windows or is Kubuntu the only OS?

Qqmike is one of our forum experts on UEFI booting. He has posted some pretty thorough tutorials on this forum which might help you.

[oshunluvr]

I'm not using UEFI and mine boots very fast.

This:

Startup finished in 179us (firmware) + 163us (loader)

tells you it's not UEFI or GRUB causing the problem. However, this:

34.558s (kernel) + 18.879s (userspace)

is the problem.

Try "sudo systemd-analyze blame" to get details on what processes are taking so long.

[bendy]

Thanks guys. The top 5 lines are:

systemd-analyze blame
      10.401s apt-daily.service
       6.285s NetworkManager-wait-online.service
        918ms dev-sdb1.device
        580ms apt-daily-upgrade.service
        228ms systemd-cryptsetup@cryptswap1.service

The apt-daily.service obviously stands out, although my understanding is that systemd isn't necessarily stopped waiting. Please can someone else post the top lines of your systemd-analyze blame to compare?

Also, my system is set to check for updates weekly, so I'm not sure what apt is doing on a daily basis.

[bendy]

OK, this is better:

sudo systemd-analyze
Startup finished in 148us (firmware) + 163us (loader) + 3.337s (kernel) + 4.673s (userspace) = 8.011s
graphical.target reached after 4.646s in userspace

I managed to catch a glimpse of a message during boot saying something along the lines of "gave up waiting for suspend resume service". It looks like it was trying to resume from a swap partition UUID that doesn't exist because it's encrypted, and it doesn't get unencrypted until after I enter my password.

I opened up /etc/initramfs-tools/conf.d/resume and replaced what was in there with "RESUME=NONE" and then ran:

sudo update-initramfs -u

I may have lost the ability to suspend/resume using swap, but I never do that anyway, and it may be possible to fix the situation by correcting the UUID in /etc/initramfs-tools/conf.d/resume

[oshunluvr]

OK, this is better:

sudo systemd-analyze
Startup finished in 148us (firmware) + 163us (loader) + 3.337s (kernel) + 4.673s (userspace) = 8.011s
graphical.target reached after 4.646s in userspace

I managed to catch a glimpse of a message during boot saying something along the lines of "gave up waiting for suspend resume service". It looks like it was trying to resume from a swap partition UUID that doesn't exist because it's encrypted, and it doesn't get unencrypted until after I enter my password.

I opened up /etc/initramfs-tools/conf.d/resume and replaced what was in there with "RESUME=NONE" and then ran:

sudo update-initramfs -u

I may have lost the ability to suspend/resume using swap, but I never do that anyway, and it may be possible to fix the situation by correcting the UUID in /etc/initramfs-tools/conf.d/resume

Sounds like you answered your own question. As to apt-daily:
https://askubuntu.com/questions/8004...-daily-service

[gnomek]

By some tweaks and workarounds of bugs I went down from original 3min 3.515s to 14.214s and now to 6.684s"

systemd-analyze
Startup finished in 2.726s (kernel) + 3.957s (userspace) = 6.684s

6.285s NetworkManager-wait-online.service

You can disable it:

sudo systemctl disable NetworkManager-wait-online.service

It helped me but I don't use any complicated networking settings. You may want to first read about it:

https://www.linuxquestions.org/quest...ce-4175594791/

https://askubuntu.com/questions/6150...edirect=1&lq=1

https://askubuntu.com/questions/1018...ine-service-do

Also check for errors in

journalctl -b -p 3 >output.txt

Update:
after disabling plymouth and removing samba

systemd-analyze
Startup finished in 2.863s (kernel) + 2.260s (userspace) = 5.123s

Not bad, but I still have some issues to fix.

[jlittle]

That's great, and also that you've posted your results.

Note that the boot doesn't wait for Network Manager to finish. At least it doesn't on my 18.04, often I get a notification a second or two after I've logged in. systemd-analyze blame shows a time that roughly agrees with that, boot + login + 1. This using wired ethernet, I expect wireless would take longer.

Regards, John Little