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

[M@GOid]

Actually you can boot into UEFI in this case - Windows 10 has a special button in Settings app On Linux Google says

systemctl reboot --firmware-setup

can do that also.

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

[M@GOid]

while you can disable the ~3 second timeout for entering setup, those 3 seconds are insignificant compared to the 15 or more seconds the firmware takes regardless of the quick boot setting.

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.

[TheLexMachine]

Why not just use Clear Linux itself?

Because - as you yourself said in your review - it has some nuisances and drawbacks. For a personal use system, I want something a bit more polished and put-together, with the ability to install the stuff I want to install, without having to do a ton of manual config work via command line, hacks, or text file configs.

[Michael]

Because - as you yourself said in your review - it has some nuisances and drawbacks. For a personal use system, I want something a bit more polished and put-together, with the ability to install the stuff I want to install, without having to do a ton of manual config work via command line, hacks, or text file configs.

It's getting fairly polished these days, even more so since switching to it myself they introduced their new installer / developer edition and other enhancements. More than likely Intel would better polish Clear Linux itself than the chances of someone else creating a downstream of it and trying to get it all polished into a better state.

[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.

[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

[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]

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.

[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).

[concatime]

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