1

I have installed Kubuntu 20.04 on several external SSDs and the boot time is about 80 seconds. Kubuntu 18.04 took around 15 seconds to boot and I would like to get closer to that.

Using my 20.04, from the grub menu I select Advanced, then the first item, then I can see loading the vmlinuz image takes 7 seconds (its 11 MB under /boot), loading the initrd.img about 60 seconds (83 MB under /boot), and then there is about 15 seconds of module loading until the graphics screen appears.

I have tried rebuilding initramfs using update-initramfs -c -k $(uname -r) but this has no effect. I have tried the 5.8 kernel and that made no difference. The delay per MB is about the same for loading vmlinuz and initrd. The SSDs have included a T3 and a T5. Could it be a block size issue? Any ideas as to what is causing the delay or how to fix it?

The output from systemd-analyze blame | head is-

30.238s apt-daily-upgrade.service
30.222s apt-daily.service
7.029s NetworkManager-wait-online.service
3.493s udisks2.service
2.754s snapd.service
2.694s networkd-dispatcher.service
2.550s accounts-daemon.service
1.988s dev-sda2.device
1.715s polkit.service
1.700s avahi-daemon.service

The output from systemd-analyze critical-

graphical.target @12.190s └─multi-user.target @12.190s └─kerneloops.service @12.164s +25ms └─network-online.target @12.158s └─NetworkManager-wait-online.service @5.128s +7.029s └─NetworkManager.service @3.438s +1.683s └─dbus.service @3.431s └─basic.target @3.396s └─sockets.target @3.395s └─snapd.socket @3.391s +2ms └─sysinit.target @3.353s └─snapd.apparmor.service @3.311s +40ms └─apparmor.service @3.113s +189ms └─local-fs.target @3.111s └─run-user-1000.mount @9.224s └─local-fs-pre.target @1.310s └─systemd-tmpfiles-setup-dev.service @1.185s +123ms └─systemd-sysusers.service @1.123s +59ms └─systemd-remount-fs.service @1.069s +30ms └─systemd-fsck-root.service @1.017s +48ms └─systemd-journald.socket @970ms └─system.slice @935ms └─-.slice @935ms

user1180195
  • 11

1 Answers1

0

To remove the 2x30 second boot process for apt
open a terminal and type

sudo systemctl disable apt-daily.service
sudo systemctl disable apt-daily.timer

sudo systemctl disable apt-daily-upgrade.timer
sudo systemctl disable apt-daily-upgrade.service

Assumung systemctl works in Kubuntu which I am unable to test ATM.
darth_epoxy
  • 689
  • Thanks, this did remove the two 30 second tasks, but the boot time remains the same with "Loading the initial RAM disk" taking 60 seconds. – user1180195 Feb 10 '21 at 03:07
  • It's not unusual if you have lots of modules so unless you are having other problems I wouldn't worry. And remember that the systemd-analyze includes the time it takes to type your password. So you could go hunting for modules using 'dmesg' or you could try 'sudo time update-initramfs -u' after you backup. – darth_epoxy Feb 10 '21 at 06:20
  • Thanks Darth. the update-initramfs did not change anything. The 60 second delay comes after the message about loading the initial RAM disk, can modules be loaded at this point or is the only thing happening loading of the ram disk? – user1180195 Feb 11 '21 at 09:30
  • I am sure this is because grub is not on the SSD but it is not a problem it's just a slow boot. Unless you want to reload and configure grub you can live with it and no harm is done. You could experiment with some of the grub paramaters at GRUB_CMDLINE_LINUX_DEFAULT= and start with quietsplash etc and note the differences. – darth_epoxy Feb 11 '21 at 10:52
  • Thanks again, the only disk in the system is the external disk.
    Loading of vmlinuz and then the initial ram disk take place at about 1.5 MB/sec from a drive capable of hundreds of MB/sec. This seems very odd.     – user1180195 Feb 15 '21 at 06:29
  • Further reading ... https://askubuntu.com/questions/1283868/dual-booting-ubuntu-and-windows-very-slow-boot-on-ssd – darth_epoxy Feb 15 '21 at 23:54