The Extensible Firmware Interface - an introduction

Posted Aug 11, 2011 15:50 UTC (Thu) by nye (guest, #51576)
In reply to: The Extensible Firmware Interface - an introduction by jhhaller
Parent article: The Extensible Firmware Interface - an introduction

>On some server configurations, the BIOS takes longer to run than the OS boot.

Not just server configurations. For about 3 years now all my Debian systems have taken around as long, if not longer, to get from power on->grub than from grub->login screen.

Sometimes there are options you can disable to improve matters, eg my main desktop has two SATA controllers built in to the motherboard, one of which also does PATA. Disabling it means losing PATA and a couple of SATA ports, but saving about 10s from each boot. When grub->desktop takes ~40-50s, that's a lot. With an SSD grub->desktop is likely to be more like 20-30s, so it's even more significant.

The Extensible Firmware Interface - an introduction

Posted Aug 14, 2011 20:32 UTC (Sun) by cortana (subscriber, #24596) [Link] (3 responses)

Check out the kexec-tools package, if you haven't already.

The Extensible Firmware Interface - an introduction

Posted Aug 15, 2011 17:58 UTC (Mon) by knobunc (subscriber, #4678) [Link]

kexec helps reduce reboot time, does it help with a cold boot?

The Extensible Firmware Interface - an introduction

Posted Aug 23, 2011 10:22 UTC (Tue) by etienne (guest, #25256) [Link] (1 responses)

If I may, I would like to say something about kexec.
It is not to criticise kexec, that probably works perfectly, it is just about one use case: booting a different kernel release.

Let's imagine yesterday kernel managing yesterday device.
That yesterday device has some configuration bits labelled "do not touch", i.e. bits that you should write to the same value that you read them.
Having "do not touch" bits in configuration words is a usual way to plan for extensibility, those bits are currently zero, but in future (backward compatible) version of the device they may have a meaning, like enabling the super-duper new function.
So yesterday kernel behaves perfectly well, preserving the value of the "do not touch" bits, and obviously do not have the driver of the super-duper function.

Back to today, I have currently booted the today kernel, which knows how to drive the super-duper function, and because it has recognised the more powerful today's device, it has enabled the super-duper function in the device by setting the previously "do not touch" bit (now enable super-duper function bit) to the device register.

Now, if I kexec yesterday's kernel, it will not change the "do not touch" bit, but it does not have the super-duper function driver neither.
I am not saying this pattern happens often, I am not saying the system will always misbehave, I am just saying there is a risk.

The Extensible Firmware Interface - an introduction

Posted Aug 23, 2011 10:28 UTC (Tue) by cortana (subscriber, #24596) [Link]

It is a real risk, to be certain: but not in kexec itself; just in the tools that decide which kernel will be kexec'd when the shutdown command is issued.

Debian's kexec-tools package for instance always boots /vmlinuz, which is a symlink maintained by the various linux-image-* packages and which usually points to the latest installed kernel. IMO this is a mistake, and kexec should attempt to boot into the currently installed kernel, if it still exists.

This doesn't sound too hard--just look at the results of uname(2) and then look for a matching file in /boot. I think this would make your scenario less likely, however (at least in Debian's case) they only use a different filename for different kernel releases and ABI-changing updates to the same release, so the file /boot/vmlinux-3.0.0-1-amd64 that currently exists on my system may have been updated since the system booted with a file of the same name.