Booting seems slow

Support
1

Recently I observed the booting process seems a bit slower. So I checked with systemd-analyze time and the output is below:

Startup finished in 3.917s (firmware) + 10.083s (loader) + 17.043s (kernel) + 28.494s (userspace) = 59.538s 
graphical.target reached after 27.918s in userspace

~1m boot time seems a bit long considering my boot drive is a Samsung 980 EVO NVME SSD. systemd-analyze blame shows that ntpdate.service is taking whooping 16+ seconds to load. Is this normal? Any tips for reducing the boot time?

16.048s ntpdate.service
 6.352s NetworkManager-wait-online.service
 5.041s nmb.service
 3.811s systemd-cryptsetup@Data_Drive.service
 2.476s systemd-cryptsetup@Web_Drive.service
 2.014s systemd-modules-load.service
 1.077s var-lib-snapd-snap-spotify-45.mount
  979ms dev-mapper-CryptVolumeGroup\x2dRoot.device
  958ms var-lib-snapd-snap-core18-2066.mount
  910ms var-lib-snapd-snap-spotify-46.mount
  906ms fwupd.service
  888ms var-lib-snapd-snap-pycharm\x2dcommunity-238.mount
  855ms var-lib-snapd-snap-core-11081.mount
  849ms var-lib-snapd-snap-snap\x2dstore-518.mount
  844ms var-lib-snapd-snap-core18-1997.mount
  842ms var-lib-snapd-snap-gnome\x2d3\x2d34\x2d1804-66.mount
  842ms var-lib-snapd-snap-gtk\x2dcommon\x2dthemes-1514.mount
  841ms var-lib-snapd-snap-gtk\x2dcommon\x2dthemes-1515.mount
  841ms var-lib-snapd-snap-pycharm\x2dcommunity-236.mount
  837ms var-lib-snapd-snap-gnome\x2d3\x2d28\x2d1804-145.mount
  635ms docker.service
  561ms var-lib-snapd-snap-core-10958.mount
  553ms tlp.service
  525ms ldconfig.service
  504ms systemd-backlight@leds:system76::kbd_backlight.service
  484ms lvm2-monitor.service
  302ms dev-loop6.device
  287ms dev-loop3.device
  286ms dev-loop2.device
  286ms dev-loop4.device
  286ms dev-loop0.device
  256ms systemd-rfkill.service
  230ms snapd.service
  205ms systemd-random-seed.service
  162ms bolt.service
  120ms system76-power.service
  119ms udisks2.service
  115ms upower.service
  114ms user@1000.service
  110ms systemd-vconsole-setup.service
  109ms avahi-daemon.service
  107ms bluetooth.service
  105ms NetworkManager.service
   94ms systemd-udev-trigger.service
   93ms polkit.service
   93ms systemd-journal-flush.service
   92ms systemd-sysusers.service
   88ms ModemManager.service
   87ms apparmor.service
   87ms smb.service
   85ms lvm2-pvscan@254:0.service
   81ms home.mount
   79ms lm_sensors.service
   73ms systemd-logind.service
   71ms systemd-remount-fs.service
   63ms systemd-machined.service
   62ms systemd-journald.service
   59ms unbound.service
   51ms dev-loop8.device
   43ms home-drive_container-data_drive.mount
   40ms systemd-udevd.service
   40ms gvtvgpu.service
   39ms maia-console@tty1.service
   39ms dev-disk-by\x2duuid-97897af4\x2da7ea\x2d47b6\x2d8db1\x2d4745590b229e.swap
   35ms snapd.apparmor.service
   34ms dev-loop5.device
   34ms systemd-timesyncd.service
   32ms dev-hugepages.mount
   31ms boot.mount
   31ms dev-mqueue.mount
   29ms sys-kernel-debug.mount
   27ms sys-kernel-tracing.mount
   25ms systemd-binfmt.service
   24ms dev-loop1.device
   23ms kmod-static-nodes.service
   23ms modprobe@fuse.service
   22ms plymouth-quit-wait.service
   22ms systemd-tmpfiles-clean.service
   22ms plymouth-quit.service
   19ms modprobe@configfs.service
   18ms modprobe@drm.service
   17ms dev-loop7.device
   17ms user-runtime-dir@1000.service
   16ms plymouth-start.service
   14ms systemd-tmpfiles-setup.service
   12ms systemd-journal-catalog-update.service
   11ms plymouth-read-write.service
   10ms home-drive_container-web_drive.mount
    7ms systemd-backlight@backlight:intel_backlight.service
    7ms systemd-tmpfiles-setup-dev.service
    6ms dev-loop12.device
    6ms wpa_supplicant.service
    6ms rtkit-daemon.service
    5ms systemd-update-utmp.service
    4ms dev-loop11.device
    4ms systemd-user-sessions.service
    4ms tmp.mount
    4ms dev-loop9.device
    3ms boot-efi.mount
    3ms systemd-sysctl.service
    3ms systemd-update-done.service
    2ms proc-sys-fs-binfmt_misc.mount
    2ms sys-kernel-config.mount
    2ms sys-fs-fuse-connections.mount
    1ms dev-loop10.device
    1ms docker.socket
  807us snapd.socket
2

Hi, there is first NetworkManager-wait-online.service that can be disabled and hidden.

If you do not use LVM, I’d do the same for lvm2-monitor.service.

I see you use some snaps, it adds some booting time. Personally, I got rid of Snap entirely.

If not using it, you could uninstall Plymouth as well.

1 Like
3

@Falav Thanks for the tips. Yes, loading snap related service during boot is unnecessary. I will switch them to load on demand instead (snap provides this customization I think). I use snap for couple tools like Pycharm, Spotify etc., which are not really needed to installed as system package. This also helps keeping them up to date without delving into system level dependency hell in a relatively better way than traditional AUR packages.

Plymouth is solely there for a graphical LUKS prompt at boot. My disk is encrypted LVM so I guess I need the lvm2-monitor.service? I will look into NetworkManager-wait-online.service

4

It will reduce some seconds already.
Now, as you get an encrypted system, it’s naturally slower.

I don’t know if the encryption delay can be calculated according to your disk characteristics.
I remember a post of @linux-aarhus from some months ago, explaining what happened exactly during a boot from an encrypted system FYI.

5

JetBrains tools (PyCharm) do not need to run as snap - unpacking the downloaded tar file to a location with write-permissions is sufficient. Then run the launcher script from the unpacked bin folder. In the initial splash when no project is preset you can configure a launcher for the menu system.

There is another service for time systemd-timesyncd.service you use instead of ntpdate.service.

Since you mention Plymouth you are most likely using GRUB as bootloader.

GRUB have no support for LUKS2 which means the decrypting of your LUKS devices will be slower than if you used systemd-boot and LUKS2.

I cannot say I have extensive knowledge on neither LVM nor LUKS - I have touched the concepts - played a little - especially with the --itertime factor which I believe is fairly high 200000+ with a Calamares installation.

3 Likes
6

@linux-aarhus Thanks for the tips. I will try to migrate to systemd-boot.

There is another service for time systemd-timesyncd.service you use instead of ntpdate.service.

So I just disable ntpdate.service and enable systemd-timesyncd.service?