I’m somehow hoping, although I won’t trust it that much, that this is going to be the last post in the trilogy of myths in need of debunking — the previous two posts involved ccache and x32 and both of them has been quite the controversy. Unfortunately, seeing how much some news sites decided to mangle my words on the topic, I expect this to happen again.
So here it is a list of myths that I heard, especially in relation of my recent posts on the topic.
I didn’t write about Secure Boot. I actually linked to a video from Jo Shields of Debian fame. If you wish, you can pair that with Greg’s video on the same subject. Looks like people need to see computers booting to actually know it is possible. Stupid times we’re in.
I didn’t say that it’s impossible to boot with UEFI! Some (pretend) news site decided to use my post – that explained how to solve the chicken-and-egg problem with needing EFI variables support to set up GRUB 2 to boot off EFI – was actually saying that it’s impossible to boot Linux on UEFI systems.
The only thing in my post that referred to the inability to boot was regarding the default install that Sabayon had: the DVD boots off as BIOS legacy, but there is no way to boot off the harddrive that way.This is not unexpected as, at that point, Sabayon didn’t support EFI at that point at all — Fabio now got that one fixed, and he also implemented some (naïve maybe, at this point) Secure Boot support.
UEFI is not there just to let you use a mouse. Some people expect that the only thing that UEFI is good to do is to have support for mice and graphical setup interfaces. This is a faulty assumption because I have had BIOS-based software that used graphical interfaces and mice before, and my ZenBook has a “classic” textual interface. Sure the new UEFI system allows for a cleaner way to write such interfaces, as it provides drivers for the video card as well as for the input devices, but that’s far from it.
Basically, UEFI does not make that much of a difference for the final user, even though the new Secure Boot can actually make a much more interesting technology for the end user, as it allows (to some degree, depending on the vendor) to only trust your own key and disallow other operating systems to be booted. If you’re a device manufacturer, this has its own importance, even though is what people refers to as “TiVoization” — it makes it extremely easy to set up a signed EFI stub to be the only one being booted … If you have a server or a desktop that you don’t want other people, even with physical access, to access, you probably want to have your key as the only trusted one. Sure there is some “Trusted GRUB” project that many see as a response to the Secure Boot feature — from Matthew’s comments, I wouldn’t want to go near it (storing the whole kernel into the TPM? Are you kidding me?).
SystemRescueCD does not support UEFI. This was my mistake. Indeed the version of SysRescueCD that I had available was 2.x which did not support UEFI. The new SysRescueCD 3 works perfectly fine. And since they boot an UEFI-capable kernel through UEFI boot, you no longer need to do anything in particular beside using grub2-install, and that will take care of efibootmgr.
By the way, I wouldn’t mind having a KDE-based interface that would let me choose what to boot on the next reboot, akin to what OS X already had for a long time… of course that would mean that I would have to find one for Windows as well — my Dell laptop uses dual boot with an external HDD, as I described before.