Debunking EFI myths

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.

Further notes about UEFI booting

So after having to get one laptop to boot on UEFI I got to make the Latitude work with that as well, if anything, as a point of pride. Last time I was able to get Windows booting as UEFI but I ended up using GRUB 2 with the legacy BIOS booting instead of UEFI for Linux, and promisd myself to find a way to set this up before.

Well, after the comments on my previous post I made sure to update my copy of SysRescueCD, as I only had a version 2.x on my USB key the other day, and that does not support EFI booting — but the new version (3.0) actually supports it out of the box, which makes it much easier, as I no longer need the EFI shell to boot an EFI stub kernel. To be precise, there also no need to use EFI stub, if not to help in recovery situations.

So, after booting into SysRescueCD, I zeroed out the Master Boot Record (to remove the old-style GRUB setup), re-typed the first partition to EF00 — it was set to EF02 which is what GRUB2 uses to install its modules on non-EFI systems), and formatted it to vfat, then… I chrooted into the second partition (which is my Gentoo Linux’s root partition), rebuilt GRUB2 to support efi-64, and just used grub2-install. Done!

Yes, the new SysRescueCD makes it absolutely piece of cake. And now I actually disabled the non-UEFI booting of that laptop and, not sure if it’s just my impression, though, it feels like it’s actually a second or two faster.

Still on the UEFI topic, turns out that Fabio ordered the same laptop I got (and I’m writing from right now), which means that soon Sabayon will have to support UEFI booting. On the other hand, I got Gentoo working fine on this laptop and the battery life is great, s I’m not complaining about it too much. I’ll actually write something about the laptop and how it feels soon, but tonight, I’m just too tired for it.

Random Gentoo fixes

In the past week or so, I’ve been working in parallel on two Gentoo-related project; one is that I wrote about, for which I need to bypass NATs and allow external IPv6 access while the other will probably be more known in the next few days, when I deploy in Gentoo the code I’m developing.

Both works are something I’m paying to do, even though for the former I’m paid not nearly enough I should, and interestingly, both seem to require me to make some seemingly random, but to my aim quite important changes to Gentoo. Since they are unlikely to show up on anybody’s radar as they are, but some might be of interest to other people doing similar things, I thought I could give you a couple of heads’ up on these:

  • first of all, speaking about Quagga I changed the init scripts to make use of logger if available; this should depend on the configuration files (you can decide whether to use syslog or not) but since that only works with OpenRC and I’m not sure how to test for OpenRC within an init script, I decided to simply add a use requirement on all of them; as it is, it won’t require the logger, but if it’s in the runlevel, it’ll run after it;
  • again on topic of init script, I tweaked the OpenSSH sshd init script so that it doesn’t forcefully regenerate the RSA1 host key, as that’s only used by the version 1 of the SSH protocol, which is not enabled by default; if you do enable it, then RSA1 host key is regenerated, but it’s no longer happening if you don’t request it in sshd_config; I wanted to make it possible to disable RSA/DSA keys for SSH2 but it’s unclear how that would work; this reduces the amount of time needed to start up a one-off instance of Gentoo, such as a SysRescueCD live, or EC2, and reduces the entropy consumption at boot time;
  • tying it up, I’ve tried running audio-entropyd on the two boxes I have to deploy, hoping that it would make it possible for me to replenish the entropy without having to buy two more EntropyKeys (which would erode my already narrow profit margin); unfortunately it didn’t work at all, turning up a number of I/O errors, but the good news is that the timer_entropyd software – that Pavel is proxy-maintaining through me – works pretty nicely for this usage, and I’ve now opened a stable request for it;
  • also while trying to debug audio-entropyd, I’ve noted that strace didn’t really help when calls to ioctl() are made with ALSA-related operations; the problem is that by default, the upstream package is sent down with a prebuilt list of ioctl definitions; I’ve found a way to remove this limitation, which is now in tree as 4.5.20-r1, although I did break build with Estonian language — because the upstream code is not compatible in the first place; I’ll be fixing the Estonian problem tomorrow as soon as I have time;
  • I have started looking into the pwgen init script that is used by our live CDs and by SysRescueCD; again, there are a few useful things with that approach, but I really want to look more into it because I think there is room for improvement;
  • tomorrow and in the next days, depending on how much time I’m left with, I’ll be starting to try again the PKCS#11 authentication — last time I ended up with a system that let me in as root with any password, now I think how I can solve it, but it’ll require me to rewrite pambase almost from scratch;
  • not really related to my work project but I helped a bit our Hardened team to fix a suhosin bug and sent the patch upstream; I’ll be writing in deeper details about this – again as I find time – since it actually motivates me to resume my work on Ruby-ELF to solve the problem at the root.

On a different note, I switched my router from using pdnsd to unbound; while documentation leaves a lot to be desired, unbound seems to perform much better, and also does work with both IPv4 and IPv6 socket listening, which doesn’t seem to be the case at all for pdnsd. I also taken down some notes about using the bind ddns protocol since the documentation “robbat2’:http://robbat2.livejournal.com/ pointed me at is probably out of date now.

Hardware, Windows, Pain

So after the previous post I had another computer to set up; yes seems like I spend all the Saturdays this way lately. This time it’s a Fujitsu-Siemens branded computer; unfortunately, it had quite a few issues:

  • no PS/2 ports, and the BIOS does not seem to initialise USB HID keyboards soon enough; my recovery station used a Microsoft PS/2 keyboard, and my only USB keyboard is Apple’s… Apple’s keyboards are HID and with a hub in the middle, which that BIOS didn’t like; got a new USB keyboard to work around this;
  • while the computer was shipped with a valid Windows XP license, the label was tore apart; result: I had to recover the product key from the running system;
  • of course, I didn’t have the administrator password; one very quick ophcrack later, I have it (too bad sysrescuecd doesn’t ship with ophcrack by default);
  • the system has a SiS-based motherboard (which incidentally comes with a Via Firewire chip, but that doesn’t really matter); SiS website, as I commented on the other post, have both two click-through license agreements and captcha to download the drivers;
  • of course I had to make a backup; partimaged refuses to receive the image from the client, both the client and the server gets stuck on the same socket, the former receiving and the latter accepting;
  • the SiS on-board Gigabit Ethernet card… fails with the Linux driver, that’s both with 2.6.27 and 2.6.31 (different versions of SysRescueCD); neither kernels enabled Gigabit transfer (and the cable is good); the first froze in 10 minutes, the latter in an hour and something;
  • the firewire-net module does not work at all; after updating SysRescue CD 1.2.0 → 1.3.0, where the module is at least present, and setting up the two firewire0 interfaces… nothing happens, I cannot ping the two sides…

And I don’t even want to wonder what will happen when I’ll finally be able to install Windows on it. I guess if I start doing this kind of support as a job, I’ll have to fetch some extra hardware, like Linux-compatible USB network adapters, fast external drive bays (I have seen one model that allows you to just plug in a 3.5” or 2.5” drive without having to screw it on something), and a dedicated external hard drive for backups. Not that I’d like to do this as a job, but it generally adds up.

Booting from USB sticks, when it fails

Today I set up an USB stick to act as a SysRescueCD LiveUSB disk, since my CD-RW started failing on me (probably they are too old by now, they have more than five years, and huge amount of erasing in their count). Since I end up using SysRescue a fair amount of times, also to install Gentoo on my boxes many times, I decided to put it on a flash drive; most of the systems I maintain nowadays boot from USB sticks just fine.

My hopes actually are for having a decent Live DVD-like system to use, something with a little more software on it for when I have to actually USE foreign systems, and I already found a 4GB USB stick cheap enough for that. But in the mean time, SysRescue will do just fine. I already had the latest ISO image so I ended up just following the instructions on their site .

But there is a note that is missing there, and even on Fedora’s LiveUSB page it does not seem to put much emphasis on that issue, although it gives a way to fix it. While SysRescue seem to say that the results depend on the hardware (which I highly doubt), Fedora’s How To actually has a section “Errors and Solutions” that shows how to make a partition bootable, and even there’s a note about adding an MBR to the flash drive.

I think that’s most likely the common problem there: most USB keys lack an MBR so computers won’t boot from them by default. Add the sample MBR you find with syslinux, even in Gentoo, and you’ll be done with it.

I hope this service entry can be helpful to somebody who’s fiddling with USB sticks and Live distributions.