How Intel's Clear Linux Team Cut The Kernel Boot Time From 3 Seconds To 300 ms

[starshipeleven]

no, the Dell R420 I have that takes a full minute to get to the bootloader is an extreme case. about 15 seconds is the fastest I've seen for UEFI.

That's a rack server. A full minute for UEFI in a server is common.

[tildearrow]

Hell yes. Also get rid of weird instruction set, overcomplicated overgrown CPU cores full of funny legacy like 16-bit mode, simplify design, add reasonable firmware ... and it maybe would look like ... er, ARM or RISC-V with something like u-boot (maybe only SPL part of it, if speed is all we care of - dumb as hell, not configurable, but FAST and does what it supposed to - without exposing gazillion of firmware bugs that nobody would ever fix anyway to Linux, like it usually happens on x86).

The problem is that by doing this they'll be dropping compatibility with e.g. BIOS. Yes, BIOS still requires 16-bit mode at the beginning and I'm pretty sure even UEFI does too (but initializes a 64-bit environment fairly quickly).

[hotaru]

That is a extreme case. None of my personal systems takes 15 seconds until grub show up. I'm not saying you haven't a system like that, but not all of them are as bad as this.

no, the Dell R420 I have that takes a full minute to get to the bootloader is an extreme case. about 15 seconds is the fastest I've seen for UEFI.

[caligula]

That loader part only shows if you include/use something in the initrd I think related to using systemd, and only for UEFI iirc.

Not really a problem.

My 2016 system has settings to speed up boot, FastBoot and UltraFastBoot. The latter will reduce the initialization time by firmware quite a bit iirc, but you'll not be able to have multi-boot setup without disabling it afaik, keyboard/mouse is unresponsive until the OS begins loading(or you reboot directly into BIOS/UEFI).

It's nice to have, but for me, the ultra fast boot is hardly any faster. Probably a bad UEFI BIOS on this board. I think the machine restarts about 3 times to "train" the DDR4. I can hear the fans spinning up 3 times. It goes a bit faster if I used the default memory settings, but in that case the DDR4-3200 memory would operate in DDR4-2666 mode. I can set the number of DDR4 training rounds from the BIOS. 3 seems to be the minimum, otherwise it won't boot.

Anyway the problem with the ultra fast boot mode is that if a kernel update won't boot, I'm stuck. Happened few times. I can't switch to some other boot entry since the keyboard won't work.

[concatime]

Can someone provides a list of modules that should be run in parallel to speed up boot? amdgpu?
driver_async_probe=[list]

[SystemCrasher]

It seems there's still a lot to gain by throwing away old x86 baggage (UEFI, ACPI). 500ms just to get linux to load is a lot of time when the CPU runs at >2GHz.

Hell yes. Also get rid of weird instruction set, overcomplicated overgrown CPU cores full of funny legacy like 16-bit mode, simplify design, add reasonable firmware ... and it maybe would look like ... er, ARM or RISC-V with something like u-boot (maybe only SPL part of it, if speed is all we care of - dumb as hell, not configurable, but FAST and does what it supposed to - without exposing gazillion of firmware bugs that nobody would ever fix anyway to Linux, like it usually happens on x86).

[starshipeleven]

The command for rebooting into UEFI settings given earlier was because when using a feature like UltraFastBoot, Grub or rEFInd become unresponsive to input devices, the system needs to get past that and start booting the OS.

Ok.

In that case you can ask GRUB to boot a specific entry on next boot by
sudo grub-editenv - set next_entry=X
where X is the menu entry you want to boot next time.

List available entries with

sudo  awk -F\' '$1=="menuentry " || $1=="submenu " {print i++ " : " $2}; /\tmenuentry / {print "\t" i-1">"j++ " : " $2};' /boot/grub2/grub.cfg

or

sudo  awk -F\' '$1=="menuentry " || $1=="submenu " {print i++ " : " $2}; /\tmenuentry / {print "\t" i-1">"j++ " : " $2};' /boot/grub/grub.cfg

or edit the last path to point to where your distro places grub.cfg.

an example.

0 : openSUSE Tumbleweed
1 : Advanced options for openSUSE Tumbleweed
        1>0 : openSUSE Tumbleweed, with Linux 5.2.11-1-default
        1>1 : openSUSE Tumbleweed, with Linux 5.2.11-1-default (recovery mode)
        1>2 : openSUSE Tumbleweed, with Linux 5.2.10-1-default
        1>3 : openSUSE Tumbleweed, with Linux 5.2.10-1-default (recovery mode)
2 : Windows Boot Manager (on /dev/sdc2)

On OpenSUSE there is grub2-once that is basically a Perl script wrapper for the above and is a bit more advanced because OpenSUSE has snapshots and stuff and you might need to do this to rollback.
This is what I can also do with GRUB interface.

sudo  grub2-once --list
     0 openSUSE Tumbleweed
     1 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.11-1-default
     2 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.11-1-default (recovery mode)
     3 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.10-1-default
     4 Advanced options for openSUSE Tumbleweed>openSUSE Tumbleweed, with Linux 5.2.10-1-default (recovery mode)
     5 Windows Boot Manager (on /dev/sdc2)
     6 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:31,post,zypp(packagekitd))
     7 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:29,post,yast snapper)
     8 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:29,pre,yast snapper)
     9 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-11T08:27,pre,zypp(packagekitd))
    10 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-09T07:13,post,zypp(zypper))
    11 Start bootloader from a read-only snapshot> openSUSE Tumbleweed  (5.2.11-1,2019-09-09T07:10,pre,zypp(zypper))
    12 Start bootloader from a read-only snapshot>*openSUSE Tumbleweed  (5.2.11-1,2019-09-05T16:10,post,zypp(zypper))
    13 Start bootloader from a read-only snapshot>*openSUSE Tumbleweed  (5.2.10-1,2019-09-05T16:06,pre,zypp(zypper))

This is useful for rebooting to UEFI settings if you added the menu entry as said above, and also for changing the kernel, or boot any other menu entry too, as you cannot do that anymore if you can't use the keyboard on boot.

I don't know about a similar functioanlity in rEFInd, but quite frankly if you have rEFInd you are not going to have UltraFastBoot enabled.

[polarathene]

If the above does not work

The command for rebooting into UEFI settings given earlier was because when using a feature like UltraFastBoot, Grub or rEFInd become unresponsive to input devices, the system needs to get past that and start booting the OS.

[starshipeleven]

That is nice to see, will try it in the weekend.

GRUB is also able to do that with the "grub commands", in UEFI systems there is a command to reboot to UEFI setup, "fwsetup".
You can add them as GRUB menu options or by getting into GRUB commandline and writing the command directly

https://wiki.archlinux.org/index.php/GRUB#GRUB_commands

Also rEFInd boot loader/manager can do that (and offers it by default).

If the above does not work (many want UEFI to not be like that, but it do), there is a more manual way with efibootmgr (that writes this in UEFI vars) from inside the booted system.

It's usually

sudo efibootmgr -n 0

as the "0" boot option is commonly the UEFI setup menu or a boot menu where you can then select to go in UEFI setup, but check what options you actually have in your system.

sudo efibootmgr

See the following example for a HP laptop

BootCurrent: 000A
Timeout: 0 seconds
BootOrder: 000A,000B,000E,000F,0010,000D,000C,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,0011
Boot0000  Startup Menu
Boot0001  System Information
Boot0002  Bios Setup
Boot0003  3rd Party Option ROM Management
Boot0004  System Diagnostics
Boot0005  System Diagnostics
Boot0006  System Diagnostics
Boot0007  System Diagnostics
Boot0008  Boot Menu
Boot0009  HP Recovery
Boot000A* opensuse-secureboot
Boot000B* Windows Boot Manager
Boot000C* Samsung SSD 850 EVO 1TB
Boot000D* WDC WD5000LPCX-60VHAT0
Boot000E* Samsung SSD 850 EVO 1TB

[starshipeleven]

My sysvinit antiX system boots in a lot less than minutes. Not sure why it would take so long unless you purposely or incompetently set it up that way.

Ok, ok, that's a special case, you can get away with less if your hardware is more powerful.

Those times are from an embedded device running Debian. Kirkwood SoC. Not terribly powerful ARMv5 (armel Debian arch), and OS is on a flash drive that isn't particularly fast. Took 1 minute and something to fully boot the OS and the 2-3 services I needed it to do.
And no it was not just sitting there waiting for ethernet connection.

Switched to systemd on the same system when Debian did the switch, boom. 20 seconds of OS boot time, like a boss.