Announcement

Collapse
No announcement yet.

How I (sort of) conquered UEFI

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    How I (sort of) conquered UEFI

    (The following Article was penned by SteveRiley on 2012/02/10)

    Since UEFI will be the future, I figured I needed to quit my bitching and set about getting to know this unholy beast. For several hours this weekend I've read way too much, installed Ubuntu way too many times, and even managed to temporarily kill a portion of my UEFI's NVRAM!

    UEFI is so new and different that it can appear very daunting. You can permanently ruin a UEFI if you aren't careful. But if you take the time to master it, you'll discover that its framework eases the burden of installing and maintaining operating systems. The old concept of burying a boot loader in some unused drive sectors is history, as is the need to worry about primary-vs-extended partitions and remembering which one is active. Partition #1, formatted FAT-32, stores all UEFI-related information in /boot/efi. Each operating system places its own boot loader in a subdirectory beneath this head -- in the case of Ubuntu, it's EFI/ubuntu. I'm happy to report that I now have today's build of Precise running in UEFI mode on my ThinkPad X1.

    The journey was tortuous and at times I nearly gave up. But BIOS+MBR is on the way out, so undertaking this knowledge adventure was necessary. First step: partition my SSD. I'm picky about this, I like to ensure proper alignment. Since Ubuntu's Partman tool can't offer that much flexibility, I booted with a USB containing GParted Live. My X1 has a 128 GB SSD. With gdisk running in a console, I partitioned the drive thusly:
    • Extra menu ... Zap all existing GPT structures
    • Main menu ... New GPT (GUID partition table)
    • Extra menu ... Sector alignment ... 8 sectors (which maps to my SSD's 4kB sectors)
    • Main menu ... New partition (#1) ... default start (changed by alignment config from 34 to 40), size +512M, type EF00 (EFI system)
    • New partition (#2) ... default start, size +30G, type 8300 (Linux filesystem)
    • New partition (#3) ... default start, size +80G, type 8300 (Linux filesystem)
    • New partition (#4) ... default start, size [see below], type 8200 (Linux swap)
      • Want partition alignment to end correctly
      • (last usable sector - default start) / 8
      • toss fraction, multiply result by 8, enter this as number of sectors
    • Write partition table and exit
    Now it's time to install. The first thing I learned: my usual method of building a PC, from the netboot boot.img.gz, doesn't work! That installer lacks UEFI support. I'd install, but find no /boot/efi. Of course I didn't realize this until after a couple hours of futzing around...only when I configured the UEFI not to automatically fall back to legacy mode. Once I made that change, and the USB drive failed to boot, I realized what was going on. So I downloaded the alternate installer instead.

    After reading a lot of stuff, and based on the experiences of others, I first tried to get ELILO working as the boot loader for Ubuntu. UEFI duplicates a lot of what GRUB does anyway, and ELILO is simpler, so this seemed a natural choice. But no matter how many variations of configurations I attempted, the kernel simply wouldn't boot. The initrd loaded without error, but the computer would reboot every time the kernel was about six seconds into its loading process. I couldn't find any logs anywhere, and cranking up ELILO's verbosity mode didn't reveal anything. The ELILO setup process is a bit opaque, and once while using efibootmgr to examine the UEFI's NVRAM, I accidentally deleted the item in variable Boot0004. Whoops! Oh crap, did I just destroy this $1200 laptop?

    Turns out that's the Intel Management Engine, which I had already disabled. But again since I'm picky, and I don't like broken stuff, I had to divert and learn about the EFI Shell. Here's where I began to realize that UEFI's maintenance is simpler once you get over the learning curve. I formatted a USB drive as FAT32, created the directory hierarchy /boot/efi, and copied the EFI Shell file into that as bootx64.efi. Reboot and voila, the EFI Shell. Some tips if you're following along:
    • Enter mode to find out what text modes UEFI can accommodate on your PC
    • Enter mode num num to obtain the densest font you can
    • help is your friend; learn more with help command
    • Follow every command that displays something with -b to view the output one page at a time
    Since I happen to have another ThinkPad handy (the T520, on which I'm typing this post) with the same UEFI, I booted into that one and copied the contents of Boot0004 onto the USB. Each of the below is a command typed at the prompt:
    • fs0:
    • dmpstore boot0004 -s b4var
    The first command switches the "context" to the USB drive. The colon is required, it's part of the device's name. The second command dumps the contents of the boot variable; the switch means save to a file, and I called the file b4var. It landed in the root of my USB drive. I exited the shell on the T520, moved the USB drive to the X1, and booted the shell. Then I restored the missing variable with these commands:
    • fs1:
    • dmpstore boot0004 -l b4var
    The shell identified my SSD as permissible for UEFI functions because of its GPT and therefore assigned a different device ID to the USB drive. So first I had to switch to its context. Then I used the same command as before (yeah, "dump" is a bit silly here, but it is what it is) with a different switch, this time indicating a load.

    Aside: during my first attempt at this, I hadn't realized that the device names would be different on the X1. fs0: didn't have the file! Oh no, is there some hidden digital signature that prevents the X1 from seeing a variable dumped from the T520? I double-checked the drive on another PC, and yeah, b4var was present. Then I discovered the map command, which lists all devices and their names. When I saw two "fs" devices, I knew what to do. After switching to fs1:, and issuing an ls command, I saw the file. So let this sink in for moment, and I believe you'll see why I'm beginning to think that UEFI is kind of cool. Everything's a file. There's a shell. I can view parts. I can move parts around. I can recover from a mistake. Arguably, it ought to be more difficult to delete variables that can't be regenerated, and that's a major design flaw. But I'm impressed with what I've learned here, and can understand how UEFI simplifies maintenance tasks -- once you get over the tortuous educational process.

    So anyway...eager to verify that my recovery worked, I booted the Ubuntu alternate installer into rescue mode, ran efibootmgr, and indeed -- Boot0004 was back!

    Alright. So now let's try yet another install, and allow GRUB. The installer has always detected partition #1 and correctly marked it as the EFI system partition. When it came time, near the end, to install a boot loader, rather than skipping that, I just decided to let the installer automatically set up GRUB. And to my surprise, it worked perfectly. Contrary to what I've read elsewhere, Ubuntu's setup scripts appear to have shed their bugs. grub-efi, not grub-pc, was downloaded and configured. And all in one step: unlike BIOS+MBR, with UEFI+GPT we know that boot loaders always go in whatever partition is type EF00 and in subdirectory /boot/efi. Gone is the chore of telling your installer where your boot partition is.

    Time for first boot! And it's exactly what I expect. Everything is as it should be. I've completed my pre-KDE steps and...yep, kde-standard has just finished installing. Time for some pruning and grafting, then one last reboot and I'll be back into my favorite desktop on what's rapidly becoming my favorite laptop. See y'all in a bit.
    Using Kubuntu Linux since March 23, 2007
    "It is a capital mistake to theorize before one has data." - Sherlock Holmes
Working...
X