How do I reduce boot time

I’m running EOS latest version with lts kernel and nvidia driver 470 and I recall that linux used to boot very fast compared to windows on my hardware when I first dualbooted windows and linux. Now windows boots faster than linux with 5-7 secs difference or something. I’m using dualbooting in legacy bios mode and this slowness in boot isn’t EOS specific. The boot was faster in my first one or two distros and after that I started to experince slower bootups. EOS and windows are installed on the SSD, while I use HDD for data. I’m posting these in case it helps.

FSTAB

# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=<bootuuid> /boot          ext4    defaults,noatime 0 2
UUID=<homeuuid> /home          ext4    defaults,noatime 0 2
UUID=<rootuuid> /              btrfs   subvol=/@,defaults,noatime,compress=zstd 0 0
UUID=<rootuuid> /var/cache     btrfs   subvol=/@cache,defaults,noatime,compress=zstd 0 0
UUID=<rootuuid> /var/log       btrfs   subvol=/@log,defaults,noatime,compress=zstd 0 0
UUID=<rootuuid> /swap          btrfs   subvol=@swap                       0    0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
UUID=<uuid>                  /mnt/Storage      auto    nosuid,nodev,nofail,uid=1000,gid=1000,dmask=007,fmask=117,x-gv
fs-show  0    0
/swap/swapfile                             none          swap    sw                                 0    0

lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 238.5G  0 disk 
├─sda1   8:1    0   549M  0 part 
├─sda2   8:2    0 135.9G  0 part 
├─sda3   8:3    0     2G  0 part /boot
├─sda4   8:4    0     1K  0 part 
├─sda5   8:5    0    25G  0 part /home
└─sda6   8:6    0    75G  0 part /var/log
                                 /var/cache
                                 /swap
                                 /
sdb      8:16   0 465.8G  0 disk 
├─sdb1   8:17   0 465.7G  0 part /mnt/Storage
└─sdb2   8:18   0    32M  0 part 
sr0     11:0    1  1024M  0 rom

systemd-analyze

Startup finished in 7.203s (kernel) + 5.429s (userspace) = 12.632s                                                              
graphical.target reached after 5.429s in userspace

systemd-analyze blame

2.529s optimus-manager.service
2.411s systemd-random-seed.service
1.351s boot.mount
 887ms dev-sda6.device
 365ms mnt-Storage.mount
 300ms home.mount
 230ms systemd-tmpfiles-setup.service
 229ms user@1000.service
 225ms systemd-rfkill.service
 205ms udisks2.service
 183ms lvm2-monitor.service
 179ms plymouth-read-write.service
 160ms systemd-modules-load.service
 142ms systemd-journal-flush.service
 118ms systemd-backlight@backlight:intel_backlight.service
 103ms systemd-udev-trigger.service
 101ms systemd-remount-fs.service
  89ms systemd-timesyncd.service
  81ms systemd-journald.service
  66ms systemd-logind.service
  63ms plymouth-deactivate.service
  62ms systemd-udevd.service
  60ms plymouth-quit-wait.service
  59ms plymouth-quit.service
  57ms dbus.service
  49ms polkit.service
  48ms systemd-vconsole-setup.service
  47ms plymouth-start.service
  47ms pamac-daemon.service
  46ms upower.service
  43ms systemd-tmpfiles-clean.service
  42ms NetworkManager.service
  40ms var-log.mount
  39ms systemd-fsck@dev-disk-by\x2duuid-f3d697c0\x2dbe62\x2d4452\x2da9a9\x2db7a5c35d519b.service
  36ms systemd-update-utmp.service
  34ms systemd-fsck@dev-disk-by\x2duuid-3a337de5\x2d8914\x2d46fd\x2d8c63\x2dacb6c00865ca.service
  30ms systemd-tmpfiles-setup-dev.service
  21ms swap-swapfile.swap
  21ms modprobe@fuse.service
  17ms swap.mount
  15ms var-cache.mount
  14ms wpa_supplicant.service
  14ms dev-hugepages.mount
  13ms dev-mqueue.mount
  13ms sys-kernel-debug.mount
  12ms sys-kernel-config.mount
  12ms sys-kernel-tracing.mount
  11ms kmod-static-nodes.service
  10ms tmp.mount
  10ms modprobe@configfs.service
   9ms user-runtime-dir@1000.service
   9ms modprobe@drm.service
   8ms alsa-restore.service
   6ms systemd-user-sessions.service
   5ms rtkit-daemon.service
   4ms systemd-sysctl.service
   2ms sys-fs-fuse-connections.mount

systemd-analyze critical-chain

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.

graphical.target @5.429s
└─sddm-plymouth.service @5.429s
  └─optimus-manager.service @2.897s +2.529s
    └─basic.target @2.893s
      └─sockets.target @2.893s
        └─dbus.socket @2.893s
          └─sysinit.target @2.892s
            └─systemd-timesyncd.service @2.802s +89ms
              └─systemd-tmpfiles-setup.service @2.568s +230ms
                └─local-fs.target @2.556s
                  └─boot.mount @1.204s +1.351s
                    └─systemd-fsck@dev-disk-by\x2duuid-f3d697c0\x2dbe62\x2d4452\x2da9a9\x2db7a5c35d519b.service @1.163s +39ms
                      └─dev-disk-by\x2duuid-f3d697c0\x2dbe62\x2d4452\x2da9a9\x2db7a5c35d519b.device @1.162s

Also, I followed this (https://wiki.archlinux.org/title/plymouth) to add a plymouth, but this haven’t affected the boot time in a sensible way.

I wonder if this is a bit too long :thinking:

Mine is:

1.086s (kernel)

Then I use lz4 as compression algorithm for kernel images. A trade off between speed and size.

That’s a terrible feeling! I feel you.

local-fs.target @2.556s

2.529s optimus-manager.service
2.411s systemd-random-seed.service
1.351s boot.mount

If I were you, I would remove optimus-manager, random-seed and my local disks.
That would definitely make the system boot like a flash! :zap:

Your other choice might be to ignore a few seconds on each boot, and try to do something productive with your PC after boot has finished. Something like gaming, watching YT videos and such.
But that’s just my personal opinion. :smile: :person_shrugging:

I am using standard kernel and its about 1.7s.
While I do not see that as a long time to boot, you can try with removing quite and splash (if it’s there) from kernel parameters at grub and see exactly what is holding back your boot up time.
Windows is almost always in hibernation with fast startup setting turned on (it’s on by default). So it’s not fresh start when you turn on your PC. When you add faster and faster storage drives, difference between Linux and Windows at startup times is negligible in most cases.
https://wiki.archlinux.org/title/silent_boot

Fast startup is disabled in windows so that I can access NTFS data drive rw on linux.

It probably is. I remember seeing bootsplash immediately after I select linux with 1-2 sec. Now it’s about that 7.203s before my boot logo appears (manually configured from link above). Is it possible to reduce it?

Can’t promise that choosing another compression algorithm would significantly decrease your boot time.

If you are up for experimenting, have a look at:

https://wiki.archlinux.org/title/Mkinitcpio#COMPRESSION

If/when you have modified the file, you need to run:


sudo mkinitcpio -P

Also, take a look here:

I have tried uncompressed and lz4 compressed images, No improvement for kernel boot time.
With no compression

Startup finished in 7.182s (kernel) + 6.567s (userspace) = 13.749s 
graphical.target reached after 6.567s in userspace

With lz4

Startup finished in 7.124s (kernel) + 8.171s (userspace) = 15.295s 
graphical.target reached after 8.171s in userspace

what are systemd-random-seed.service and local-fs.target ?

And baring all that, if you just boot to the CLI and avoid all that graphical nonsense, it’ll be tons faster. :rofl:

My opinion is that the 7 second difference between the two boot times is still tolerable.

Indeed, but I posted in the first place because linux had the advantage when I first switched and I was happy with it.

FYI: If you use SDDM and disable systemd-random-seed, SDDM won’t initialize for a long time due to a bug.

You’re right, SDDM initializes for long, but running systemctl disable systemd-random-seed.service achived nothing, it still runs on boot.

EDIT:
I masked it as well with no significant improvement