Going GRUB-less with UEFI

[SteveRiley]

Yesterday, Phoronix posted an article about Ubuntu switching back to GRUB2 for UEFI secure boot. In the comments, Kano (a Kanotix developer) floated the idea of not using GRUB on a UEFI system. I mentioned that's something I plan to learn; Kano replied with instructions on how to set it up.

I tested it, and can report that it works perfectly on Quantal. My T520 has a UEFI NVRAM variable pointing directly to the kernel. I created a second one, with the recovery kernel boot option, because it seemed like a good idea. Here is a dump of my EFI boot manager:

steve@t520:~$ [B]sudo efibootmgr -v[/B]
BootCurrent: 001B
Timeout: 0 seconds
BootOrder: 001B,001A,0019,0006,000C,0007,000A,0008,000D,000E,000F,000B,0009,0011,0012,0010,0013
---
Boot0019* Ubuntu recovery mode
          HD(1,28,100000,35a3de7a-7015-4855-b882-1c8e9432b8fe)
          File(\EFI\ubuntu\linux.efi)
          root=UUID=fc16861b-bbd1-4c97-8d70-49839f97db83
          ro nox2apic noop nomodeset recovery
          initrd=EFI\ubuntu\initrd.img
Boot001A* Ubuntu direct with initrd
          HD(1,28,100000,35a3de7a-7015-4855-b882-1c8e9432b8fe)
          File(\EFI\ubuntu\linux.efi)
          root=UUID=fc16861b-bbd1-4c97-8d70-49839f97db83
          ro nox2apic noop acpi_osi=Linux pcie_aspm=force raid=noautodetect
          initrd=EFI\ubuntu\initrd.img
Boot001B* Ubuntu direct
          HD(1,28,100000,35a3de7a-7015-4855-b882-1c8e9432b8fe)
          File(\EFI\ubuntu\linux.efi)
          root=PARTUUID=5d630312-d283-4812-94f9-d6ca92b966f5
          ro nox2apic noop acpi_osi=Linux pcie_aspm=force raid=noautodetect

(I've taken some liberties with the formatting: I removed the variables that reference the UEFI's internal menu options, I've added line breaks in the variables, and I've deleted the periods that normally sit between each letter in the boot parameters -- a Unicode artifact.)

Boot001B boots the kernel from the EFI partition and the initrd from the root file system. Boot001A boots both the kernel and the initrd from the EFI partition; it takes about one second longer. I've asked for clarification why. Boot0019 is recovery mode. The default is Boot001B; to choose one of the others, I press [F12] during startup to see the UEFI boot manager menu.

It's nice not having to mess with GRUB! GRUB is certainly overkill for a single-OS machine. It'll be interesting to see what happens when a kernel update comes down the 'tubes. There appear to be no configuration scripts for this kind of setup, so I'll need to manually copy the newer vmlinuz and initrd from /boot to /boot/efi/EFI/ubuntu. And yes, I've purged all of GRUB from my computer.

I'll update this thread with any new developments.

[notabug]

This is some scary stuff for us simple, non-professional IT hobbyists. I hope my 3 year old computer keeps on chugging for a long, long time or something more understandable is developed in the not to far future. This whole UEFI business is so far over my head.

[Qqmike]

notabug, you have a 3-year-old PC? Lucky you! Actually, me, too, built in 2009. I also have one that's 7 years old, I built it in 2005, (I'm using it now, with Kubuntu 8.04.3). You needn't worry for a very long time.

" I hope ... something more understandable is developed in the not to far future." I suspect that will happen, too.

Unified Extensible Firmware Interface
http://en.wikipedia.org/wiki/UEFI

I wouldn't worry as this thing shakes out fully. Although I 'was' a GRUB Legacy expert, I'm also a bit behind here with these recent developments, as I'm sure many people are. And, fact is, notabug, you can simply continue using GRUB 2.
GRUB 2: A Guide for Users
http://www.kubuntuforums.net/showthr...uide-for-Users

[notabug]

Thank you Qqmike. Your reply is very reassuring. The ability for me to control my machine is very important. And thanks for the links.

[jpenguin]

I built my comp about 2 year ago and my lappy id about a year old. Both bave BIOS, guess I won't need to deal with EFI for awhile. I kinda wanna try it out though...

Sent from my GT-I9000 using Tapatalk 2

[vinnywright]

It's nice not having to mess with GRUB! It's certainly overkill for a single-OS machine. It'll be interesting to see what happens when a kernel update comes down the 'tubes. There appear to be no configuration scripts for this kind of setup, so I'll need to manually copy the newer vmlinuz and initrd from /boot to /boot/efi/EFI/ubuntu. And yes, I've purged all of GRUB from my computer.

I'll update this thread with any new developments.

is their no way to point to the 2 system links in / vmlinuz & initrd.img that always point to the newest kernel and initrd?

[SteveRiley]

This is some scary stuff for us simple, non-professional IT hobbyists. I hope my 3 year old computer keeps on chugging for a long, long time or something more understandable is developed in the not to far future. This whole UEFI business is so far over my head.

For the majority of people, UEFI is invisible. Any machine purchased in the last couple years is likely to have it. My posts throughout KFN regarding UEFI reflect my desire to understand the intimate details of how this thing works. Partly just to satisfy my thirst for knowledge, and partly because I hope to be able to coach folks through installing Linux once computers start arriving with secure boot enabled and we all have to deal with signed bootloaders.

Regarding the specifics of my experiment, I feel that eliminating GRUB greatly simplifies the work required to maintain even a multi-boot computer. All UEFI implementations already have a boot manager, so why not just use that instead of some extra piece of software? The only thing required to automate what I've done is to implement some scripts that copy the kernel into the EFI partition and create the NVRAM variable that points the boot manager to the kernel. This is trivial, especially when compared to all the OS probing that GRUB encumbers itself with. Of course, however, only UEFI-capable operating systems can play here, but this list includes most recent Linux distros, Windows Vista and above, and Mac.

[SteveRiley]

is their no way to point to the 2 system links in / vmlinuz & initrd.img that always point to the newest kernel and initrd?

Answering this requires a brief explanation.

A UEFI-capable operating system requires two things:

• A boot loader
• An entry in the EFI boot manager

The UEFI specification states that all boot loaders must reside on a dedicated EFI system partition. I've set mine to be 512 MiB. This partition contains one directory: EFI. Within this partition is a separate subdirectory for each operating system. Within each subdirectory is the operating system's boot loader.

Here is a partial list of the contents of my EFI partition:

steve@t520:/boot/efi$ [B]ll -R EFI[/B]
EFI:
total 16
drwxr-xr-x 4 root root 4096 Sep 16 22:59 ./
drwxr-xr-x 3 root root 4096 Dec 31  1969 ../
drwxr-xr-x 2 root root 4096 Sep 23 14:15 ubuntu/

EFI/ubuntu:
total 27272
drwxr-xr-x 2 root root     4096 Sep 23 14:15 ./
drwxr-xr-x 4 root root     4096 Sep 16 22:59 ../
-rwxr-xr-x 1 root root  5128128 Sep 22 21:02 linux.efi*

Typically, to make this partition easy to manage, it's useful to mount it into your file system. Here are the relevant lines from my /etc/fstab:

steve@t520:~$ [B]cat /etc/fstab[/B]
# / was on /dev/sda2 during installation
UUID=fc16861b-bbd1-4c97-8d70-49839f97db83  /  ext4  noatime,discard,data=writeback  0 1
# /boot/efi was on /dev/sda1 during installation
UUID=0B73-BB16  /boot/efi  vfat  defaults  0 1

I've learned in my experiments is that it's very handy to keep a copy of the UEFI Shell on your computer. This is a miniature operating system that provides important control over your UEFI environment. It's one of the many attributes that make UEFI superior to BIOS -- you really can do more with this new type of firmware.

Here is a more complete list of the contents of my EFI partition:

steve@t520:/boot/efi$ [B]ll -R EFI[/B]
EFI:
total 16
drwxr-xr-x 4 root root 4096 Sep 16 22:59 ./
drwxr-xr-x 3 root root 4096 Dec 31  1969 ../
drwxr-xr-x 2 root root 4096 May 19 20:58 boot/
drwxr-xr-x 2 root root 4096 Sep 23 14:15 ubuntu/

EFI/boot:
total 756
drwxr-xr-x 2 root root   4096 May 19 20:58 ./
drwxr-xr-x 4 root root   4096 Sep 16 22:59 ../
-rwxr-xr-x 1 root root 763360 May 19 20:58 bootx64.efi*

EFI/ubuntu:
total 27272
drwxr-xr-x 2 root root     4096 Sep 23 14:15 ./
drwxr-xr-x 4 root root     4096 Sep 16 22:59 ../
-rwxr-xr-x 1 root root  5128128 Sep 22 21:02 linux.efi*

EFI/boot/bootx64.efi is the UEFI shell. To run it, I simply press [F12] to invoke the boot manager during startup, and I select it from the menu. EFI/ubuntu/linux.efi is my Linux kernel, and is currently the default "boot loader" chosen when I don't interrupt the startup with [F12].

Now, why did I type "boot loader" in quotes? Ubuntu kernels are now compiled to appear as UEFI images, and can therefore boot Ubuntu without the need of a separate utility like GRUB or ELILO. But since UEFI requires the boot loaders to be physically present on the EFI system partition, it's necessary to copy the kernel image from the root partition to the EFI system partition. The kernel hasn't yet loaded at this stage in the boot process, so only the EFI system partition is visible. That's why you can't simply symlink to vmlinuz.

Another feature Ubuntu adds to their UEFI-capable kernels is compiled-in file system support. After the boot loader portion of the kernel completes, all of the file systems on your computer become visible (except RAID). This is why it isn't strictly required that you place the initrd on the EFI system partition. UEFI does allow this, however, and since I wanted to compare the differences, I also copied my initrd there and created an NVRAM boot variable for it.

Therefore, here's my complete EFI partition:

steve@t520:/boot/efi$ [B]ll -R EFI[/B]
EFI:
total 16
drwxr-xr-x 4 root root 4096 Sep 16 22:59 ./
drwxr-xr-x 3 root root 4096 Dec 31  1969 ../
drwxr-xr-x 2 root root 4096 May 19 20:58 boot/
drwxr-xr-x 2 root root 4096 Sep 23 14:15 ubuntu/

EFI/boot:
total 756
drwxr-xr-x 2 root root   4096 May 19 20:58 ./
drwxr-xr-x 4 root root   4096 Sep 16 22:59 ../
-rwxr-xr-x 1 root root 763360 May 19 20:58 bootx64.efi*

EFI/ubuntu:
total 27272
drwxr-xr-x 2 root root     4096 Sep 23 14:15 ./
drwxr-xr-x 4 root root     4096 Sep 16 22:59 ../
-rwxr-xr-x 1 root root 22788838 Sep 22 21:44 initrd.img*
-rwxr-xr-x 1 root root  5128128 Sep 22 21:02 linux.efi*

You'll note in my earlier post that the first item in the BootOrder list is 001B. This is the entry that loads the kernel from the EFI system partition and the initrd from the root partition. The second variable, 001A, is the entry that loads both the kernel and the initrd from the EFI system partition. For reasons I don't yet understand, booting the computer with this method is slightly slower (slight = 1 second).

Hope this is clear.

[sithlord48]

very cool if had UEFI on this (and not the server) i would try it, one question however doesn't this also need to be updated manually on kernel upgrades? maybe a tool to do this is needed in the future.

[SteveRiley]

very cool if had UEFI on this (and not the server) i would try it, one question however doesn't this also need to be updated manually on kernel upgrades? maybe a tool to do this is needed in the future.

Yep, that's the script-fu automation I was mentioning earlier. It's really just two commands. It could even go in the debconfs for the kernel.

[GreyGeek]

That is COOL, Steve!

It reminds me somewhat of my first Linux distro, RH5.0. Kernel "upgrades" were nothing more than downloading the boot files and manually installing them, then updating the LILO boot loader and rebooting.

This EUFI madness appears to be disappearing like the dew on the grass on a hot summer morning.

[SteveRiley]

Kernel update today. It was a minor one, so the file name didn't change. Nevertheless, I thought I'd use something more descriptive than linux.efi. After the upgrade, when I copied the kernel image to the EFI partition, I used the full name: vmlinuz-3.5.0-15-generic and appended the .efi filename extension. Then I deleted the NVRAM variable and recreated it, using the new name:

sudo efibootmgr -c -d /dev/sda -p -1 -l '\EFI\ubuntu\vmlinuz-3.5.0-15-generic.efi' -L 'Ubuntu direct' -u 'root=PARTUUID={blah} {my-usual-parameters}

Then when I rebooted, I got dumped to the EFI Shell! Uh oh, must have done something wrong. I displayed the variable:

dmpstore boot001a

and noticed the following tidbit in the output:

File(\EFI\ubuntu\vmlinuz-3.5.0-15-generic.ef)

Notice what's missing? The letter "i" at the end of the filename! Apparently, there's a hard-coded maximum length of 39 characters. (Stupid design decision!) Now what? I have to fix this now, it's my work computer.

Since I haven't mastered the intricacies of the EFI Shell yet, I booted the alternate install USB I always keep handy. (Why not the "recovery" entry I created? Because, moron that I am, I modified that one, too. Stupid user decision!)

I started a shell on /dev/sda2. I mounted /dev/sda1 into /boot/efi. I shortened the name of the kernel to vmlinuz-3.5.0-15.efi. I deleted the malformed variable and created a new one once more.

I rebooted and -- yay! -- normalcy had returned.

Of course, when all your stuff works, you can never be truly happy, right? So I downloaded today's -rc7 build of kernel 3.6. After installing it, I copied the image to my EFI partition, being mindful of the 39-character path limit:

sudo cp /boot/vmlinuz-3.6.0-030600rc7-generic /boot/efi/EFI/ubuntu/vmlinuz-3.6.0-rc7.efi

And I added the requisite NVRAM boot variable:

sudo efibootmgr -c -d /dev/sda -p -1 -l '\EFI\ubuntu\vmlinuz-3.6.0-rc7.efi' -L 'Ubuntu direct 3.6-rc7' -u 'root=PARTUUID={blah} {my-usual-parameters}

Rebooted once more, interrupted the boot with [F12], and chose Ubuntu direct 3.6-rc7. Voila! Unicorns had farted rainbows across the land.

One question remained: how do I know whether the two kernels installed will pick their correct initrd? I've opted to stop placing the initrd in the EFI partition. So now I have two initrds in /boot, one for each kernel. One last time to the reboot, this time selecting the prior entry that pointed to the older kernel. Sure enough, it booted without problem. It appears that the kernel knows which initrd to choose.

There is some brittleness to this. One time in bandcamp, I left off the -u switch in front of the boot parameter string. The result was that the parameters were stored in the NVRAM varible in ASCII rather than Unicode. This doesn't work: the kernel fails to locate the root partition.

I may try to cobble together some basic scripts to simplify this somewhat. Perhaps even contribute that back, who knows?

[GreyGeek]

"Awesome and clever", I say, while genuflecting in your direction!:cool:

[SteveRiley]

"Awesome and clever", I say, while genuflecting in your direction!:cool:

*blush*

Sometimes it feels like I'm fumbling in the dark with a flashlight, documenting what I find along the way for later travelers