You are not logged in.
Enabling the fastboot (efivar FastBootOption) breaks the boot process on my UEFI machine (using grub), and this post from 2010 is the only thing I could find on the subject. The takeaway was "don't bother."
Has anyone since then successfully improved boot times by enabling fastboot, and if so, how?
Last edited by zpg443 (2020-09-05 23:32:45)
Offline
Nope. It appears to me that my system takes 40-45 seconds to go from a reboot command to a fully loaded system, with or without fastboot. I tried it this week after replacing a motherboard
Offline
I haven’t noticed a big improvement upon testing in a long time, maybe a couple of seconds but not something impressive...
Now if you feel up to the challenge you may research about kexec.
I have used it for a while for a quick warm reboot and it work quite nice, even after a little system update involving the kernel, of course you will not reload microcode that way tho...and it’s not an actual cold boot...
Is that useful for you?
Offline
I use fastboot by enabling it in the BIOS. For me it is simply cosmetic because if I enable fastboot, the graphics driver kicks in very early which enables me to have sharp 4K resolution for my highly customized rEFInd bootloader.
Without fastboot, rEFInd complains that the 4K framebuffer is unavailable.
With fastboot, I would say fairly good. Output of systemd-analyze:
Startup finished in 7.352s (firmware) + 9.073s (loader) + 4.477s (kernel) + 4.479s (userspace) = 25.382s
graphical.target reached after 4.479s in userspace
Difference in speed without fastboot seems negligible but the graphics kicking in early is a big plus.
Offline
I think the 2010 thread is referring to a different use of fastboot that was dropped in 2.6.30 https://github.com/torvalds/linux/commi … 7bf6de47bc
Offline
Just finished changing bootloaders and found rEFInd works with fastboot enabled, as d_fajardo mentions, and it shaved firmware load time by almost 2 seconds.
Startup finished in 5.717s (firmware) + 1.500s (loader) + 2.044s (kernel) + 5.122s (userspace) = 14.384s
graphical.target reached after 5.122s in userspace
Given this is a setup with KDE, 14.383s is a nice improvement.
Another improvement in boot time done before this was masking lvm2-monitor.service, lvm2-lvmetad.service, lvm2-lvmetad.socket, lvm2-lvmpolld.socket, and systemd-udev-settle.service.
Offline
systemd-udev-settle.service being started means some other service required it to ensure /dev/ was populated which the other service expects.
Offline
Updated the note for rEFInd at: https://wiki.archlinux.org/index.php/Arch_boot_process
Offline