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.

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?

Having an use for UEFI: Windows 7 as a second OS

This is not your average Linux-focused post, I’ m sorry if you were expecting one.

As I said lately, I’m now in Los Angeles, and while my dayjob involves working with a Gentoo-based firmware (and a Flash-written interface), I also have to complete a few tasks for customers at home, one of which requires me to use Windows 7 and Visual Studio 2008, both of which I own a license of … but in Italy.

While my original plan was to use TeamViewer (of which I also have a license — no kidding I know the value of Free Software, given how much I must spend on proprietary software to perform the task that FLOSS is unable to), but unfortunately the same router crash that caused Yamato’s unavailability has caused me to lose access to the laptop I used for this task.

This became even more troublesome considering that while my Dell laptop came with a Windows 7 Professional license, I decided to not install it back last time I decided to repartition it, and even more importantly, when I came here to the US I replaced the 250GB SATA hard drive with a 64GB SSD which is entirely dedicated to my Gentoo installation.

How to solve this situation? Well, seems like I did set me up with the single component to handle this properly: an eSATAp-to-SATA cable, a passive adapter, which can be used in combined eSATA/USB ports, which my laptop has (incidentally, that works just fine if you boot the system with it connected; it also works fine if you resume with it connected… but Linux seems not to have a way to rescan the bus properly, making it unsuitable for hotplug), The other part to this task is of course having the product keys (the Windows 7 one is under my battery, the Visual Studio one is on my NAS, which means a friend of mine can access it), and the discs… luckily, Microsoft’s official ISO files are available, even though you have to hunt for the Windows 7 ones, as they are not public. Visual Studio 2008 and the SP1 are available as downloads, the first as a 90 days convertible trial, which is fine.

My idea was to hope for the best, install Windows on the secondary disk, and then re-install grub2, through SysRescue, to be able to boot from the external drive. Well, it turns out it was much more easy than that. For whatever reason, my laptop can keep booting UEFI and non-UEFI modes without having to reconfigure the firmware every time, just by using F12 to choose the different boot device. So I started the Windows installation in UEFI mode, and watched it progress (I already knew that the firmware can easily boot from the external harddrive, as the eSATA interface only shows it on a different AHCI host, but it’s initialized the same way as the internal one).

After the first installation step was completed, I was honestly surprised to find out that… Windows didn’t even touch grub2! Instead, what it did was create its own EFI boot partition on the secondary harddrive, leaving the main harddrive totally clean… I just have to select “Windows Boot Manager” from the F12 menu, and Windows 7 boots and doesn’t give anything about being on a physically external drive. Even their performance score system is not showing any difference from having it internal (although I’m sure it would show the difference if it was Windows on the SSD).

Of course this is not to say that Microsoft’s software is not the usual stinking stuff… but at least they can leverage UEFI, with all its faults, to make for something… and luckily, they no longer want to be the sole owners of my laptop to just let me use their stuff for one job.