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

[starshipeleven]

Is there any reason why does it take so long?

There is no official explanation so "the firmware is shit" could very well be the real reason. I suspect RAM controller training (calibration and such). Servers that take ages to boot (Dell, Fujitsu) have been less picky with ECC RAM in my experience.
Also doing a more extensive POST (power on self test) sequence for diagnostic reasons is another possibility.

Supermicro boot is faster but is a bit more bitchy with RAM, and it WILL NOT BOOT if you are not using ECC ram or if it does not like the ECC RAM you install, not printing shit on screen nor giving any other indication of what went wrong.

Note that I'm not counting the time needed for RAID cards to power up and enumerate drives, do scans and whatever, as that's not part of the server's UEFI. But in practice you also have that to add on top of the UEFI boot times in most servers.

[skeevy420]

Also doing a more extensive POST (power on self test) sequence for diagnostic reasons is another possibility.

That's what it is.

The lights on the front of mine output in code during the POST and it isn't until that is over that the GPU fires up. Mine does ECC checks, HDD checks, RAID checks, dual CPU checks, etc. Tweak one thing hardware wise and it'll know and start nagging me.

[starshipeleven]

The lights on the front of mine output in code during the POST and it isn't until that is over that the GPU fires up. Mine does ECC checks, HDD checks, RAID checks, dual CPU checks, etc. Tweak one thing hardware wise and it'll know and start nagging me.

Yeah I noticed this too on servers that provide a LCD panel for boot status codes (Fujitsu), it shows a ton of different codes that I never saw on a normal PC through a POST card. (this is also available on high end "gaming" or overclocking motherboards, they use a 2-digit segment display soldered on the board)

I don't know what they mean though.

[skeevy420]

Yeah I noticed this too on servers that provide a LCD panel for boot status codes (Fujitsu), it shows a ton of different codes that I never saw on a normal PC through a POST card. (this is also available on high end "gaming" or overclocking motherboards, they use a 2-digit segment display soldered on the board)

I don't know what they mean though.

I got lucky and found the meanings to the codes of my system digging through Dell's documentation. I should probably print that one of these days.

[aht0]

If your English is not the best, then maybe you can write in your native language and auto-translate it for us.

Google Translate frankly sucks. At least when you are translating between major/minor languages (by amount of speakers worldwide) and/or languages which lack linguistic relation. Examples: Germanic and non-Germanic languages (Germanic/Fenno-Ugric, Germanic/Slavic).
Output is often anywhere from garbage quality to being incomprehensible.

So if his native happens to be something non-Germanic, spoken by million or two, however crappy his English, it would be more understandable than copy-paste from Google Translate could ever be.

[starshipeleven]

Google Translate frankly sucks. At least when you are translating between major/minor languages

It works decently for English-> something or the reverse.

I've had better results with X -> english -> Y than with X-> Y directly. It's still kinda broken and open to interpretation, but at least it's usable.

On Chinese -> english it's decent too, especially the "translate what my camera sees".

[aht0]

It's probably because both languages, English & Chinese, have over a billion users and so both would receive immense amount of fixes.

Example: "Auto sõitis ristmikul hunnikusse"
Real meaning: Car got wrecked on intersection.

Feel free to check how Google Translate sees that. I'll note there's also meaningful difference between junction and intersection. It can't get even short random sentence mostly right, not to mention choosing correct terms. It becomes exponentially worse when dealing with synonymes and contextual differences in longer actual texts. Doing couple of translations back and forth ends up as completely incomprehensible bs .

[sb56637]

and removing lots of kernel modules that they have no use for, note that this is a tailored installation where they know exactly what hardware that will exist at all times so not everything that they have done here can be applied to a generic desktop distribution. Then there is the problem which they stated in the PDF that lots of drivers use large timeouts to handle various pieces of broken hardware out there.

Maybe something like the old Mandriva installer approach of offering to remove unneeded hardware drivers during installation? The live/install media could use a bloated everything-and-the-kitchen-sink kernel + drivers, and then pare it down automatically based on what hardware it's installed on. Although this would have the disadvantage of removing Linux's hardware agnosticism where you can normally pull the root disk out of a machine and pop it in another and usually expect it to boot like nothing happened.

As for broken hardware devices that requires dirty hacks, yeah, that one sounds harder to work around.

[geearf]

Maybe something like the old Mandriva installer approach of offering to remove unneeded hardware drivers during installation? The live/install media could use a bloated everything-and-the-kitchen-sink kernel + drivers, and then pare it down automatically based on what hardware it's installed on. Although this would have the disadvantage of removing Linux's hardware agnosticism where you can normally pull the root disk out of a machine and pop it in another and usually expect it to boot like nothing happened.

As for broken hardware devices that requires dirty hacks, yeah, that one sounds harder to work around.

Since storage is not the issue, instead of that you could offer 2 kernels, one standard with all needed and one trimmed. You'd usually use the trimmed one, unless it fails then you'd switch to the other. It's the same thing that is done today with trimmed and full initrd.

[caligula]

Mine will disable the feature if it boots unsuccessfully 3 times iirc. Don't have to pop out the CMOS battery, personally easier to just detach the OS disk(s) by unplugging the SATA cables.

Of course modern machines like mine use NVMe disks instead. You'd have to unscrew a bolt. On my other system the NVMe disk happens to be located on the backside of the mobo so unscrewing that requires unassembling the whole mobo and all PCIe cards.

I think it might prevent USB stick(or other storage) from being bootable option though, if not then having that as a higher priority when plugged in could work for recovery.

Ok that might work.

Really though, it's barely an important time savings as I rarely reboot(Once every few months usually), so I just don't see much point in it myself.

Fair enough. I reboot daily and would really love faster boot time. I'm pretty sure my old Haswell machine actually booted faster than the current one, which is funny cause the old board was full size ATX board with all the bells and whistles (i.e. more firmware to set up during boot) while the current board is mATX. The current board also uses faster RAM, faster disks etc. But still boots slower.