UEFI booting

Last Friday (Black Friday, since I was in the US this year), I ended up buying for myself an early birthday present; I finally got the ZenBook UX31A that I was looking at since September, after seeing the older model being used by J-B of VLC fame. Today it arrived, and I decided to go the easy route: I already prepared a DVD with Sabayon, and after updating the “BIOS” from Windows (since you never know), I wiped it out and installed the new OS on it. Which couldn’t be booted.

Now before you run around screaming “conspiracy”, I ask you to watch Jo’s video (Jo did you really not have anything with a better capture? My old Nikon P50 had a better iris!) and notice that Secure Boot over there works just fine. Other than that, this “ultrabook” is not using SecureBoot because it’s not certified for Windows 8 anyway.

The problem is not that it requires Secure Boot or anything like that but much more simply, it has no legacy boot. Which is what I’m using on the other laptop (the Latitude E6510), since my first attempt at using EFI for booting failed badly. Anyway this simply meant that I had to figure out how to get this to boot.

What I knew from the previous attempt is this:

  • grub2 supports UEFI both 32- and 64-bit mode, which is good — both my systems run 64-bit EFI anyway;
  • grub2 requires efibootmgr to set up the boot environment;
  • efibootmg requires to have access to the EFI variables, so it requires a kernel with support for EFI variables;
  • but there is no way to access those variables when using legacy boot.

This chicken-and-egg problem is what blown it for me last time — I did try before the kernel added EFI Stub support anyway. So what did I do this time? Well, since Sabayon did not work out of the box I decided to scratch it and I went with good old fashioned Gentoo. And as usual to install it, I started from SysRescueCD — which to this day, as far as I can tell, still does not support booting as EFI either. It’s a good thing then that Asus actually supports legacy boot… from USB drives as well as CDs.

So I boot from SysRescueCD and partition the SSD in three parts: a 200MB, vfat EFI partition; a root-and-everything partition; and a /home partition. Note that I don’t split either /boot or /usr so I’m usually quite easy to please, in the boot process. The EFI partition I mount as /mnt/gentoo/boot/efi and inside it I create a EFI directory (it’s actually case-insensitive but I prefer keeping it uppercase anyway).

Now it’s time to configure and build the kernel — make sure to enable the EFI Stub support. Pre-configure the boot parameters in the kernel, make sure to not use any module for stuff you need during boot. This way you don’t have to care about an initrd at all. Build and install the kernel. Then copy /boot/vmlinuz-* as /boot/efi/EFI/kernel.efi — make sure to give it a .efi suffix otherwise it won’t work — the name you use now is not really important as you’ll only be using it once.

Now you need an EFI shell. The Zenbook requires the shell available somewhere, but I know that at least the device we use at work has some basic support for an internal shell in its firmware. The other Gentoo wiki has a link on where to download the file; just put it in the root of the SysRescueCD USB stick. Then you can select to boot it from the “BIOS” configuration screen, which is what you’ll get after a reboot.

At this point, you just need to execute the kernel stub: FS1:EFIkernel.efi will be enough for it to start. After the boot completed, you’re now in an EFI-capable kernel, booted in EFI mode. And the only thing that you’re left to do is grub-install --efi-directory=/boot/grub/efi. And .. you’re done!

When you reboot, grub2 will start in EFI mode, boot your kernel, and be done with it. Pretty painless, isn’t it?

Hardened and EFI aren’t buddies

For my work I store a huge amount of data in my systems, starting with a number of customers’ systems’ backups, which take the best part of 1TB of storage to preserve for the usual year or two that I usually store them (customers are very happy that way). This unfortunately means that even the 5TB of space present in Yamato is quite restrictive for my business. It’s for this reason, and others, that I ordered the components to build myself a 12TB storage server.

For said server I decided to go with an AMD Fusion board, by Sapphire, both because I’ve been disappointed by Intel’s Atom (and nVidia’s ION), and because the price was right for a board with 5 SATA ports and an eSATA one — four 3TB Western Digital Caviar Green disks, one Kingston SSD that I still had laying around, plus a WD MyBook Studio II that is currently connected to Yamato. In particular, for those asking, the fact that most of the “high end” Atoms – such as the D510 I have on my frontend – do not support CPU speed throttling is appalling; the AMD Fusion board I have do not have said problem.

Anyway, the board itself looks good and works fine — and it was curious for me to notice that it uses UEFI 2.1, rather than BIOS, as its firmware.. it’s the first desktop-class board I found with such a setup (admittedly I haven’t bought many, lately). Also, while the IOMMU feature is disabled by default, the help text for it in the configuration pages states that it is useful to translate I/O operations under Linux.. yes it explicitly mentions Linux in the help text! Kudos to them!

Out of experience with Yamato, when you have so many disks with a complex situation (RAID1 and LVM), booting can be troublesome; in Yamato’s case a bit more, as the order the disks are listed on depends among other things by the order in which they are detected by the kernel, which can change between version and version since the box uses three different controllers and three different drivers. For this reason I was hoping to use UEFI-style booting through grub2 rather than the classic old BIOS boot…

Turns out it wasn’t that good an idea; even with scarabeus’s guide, I was unable to get it to work; it seems like to set it up properly you need to boot an EFI-capable kernel (which is not the one in SysRescueCD, that I usually use to install my systems), and boot it EFI-style. If you were to boot it without EFI support, you wouldn’t be able to find the EFI variables in the /sys hierarchy anyway. I ended up discarding the whole idea of that, since at the end grub2 can make sense of the RAID devices and can find my rootfs just fine.

But there is one thing to note here that is quite important. When I configured my kernel for the first time, I enabled EFI support; then I enabled the hardened features (GRSec and Pax)… and then when I booted it the first time I went to look for the EFI variables without finding them — I didn’t yet understand that booting via PC BIOS wouldn’t have shown them anyway! Turns out that the KERNEXEC option that is so troublesome with virtualisation … is also incompatible with EFI. If you enable that option (which both the server and workstation configurations in hardened-sources enable), the EFI support in the kernel is entirely shut off.

So it appears using EFI is still too soon: we lack tools stable enough, to begin with, and documentation (I had to rely on ArchLinux’s documentation for the most part, but even that is not very clear and refers to black magic tricks; I refrain on writing documentation on the topic myself because I don’t understand all of it at all, even after reading Matthew Garret’s posts on the topic). And it seems to require the kernel to perform unsafe operations (RWX mappings), which is definitely not a good thing.

I start to understand Matthew’s feelings in regard of EFI: it might end up with a more normal boot process once the transition is complete, but between limitations with backward compatibility and no real good feature that is missing – with exception of nvram support – it doesn’t look like it’s something we should be paying much attention to, for now.