Booting with UEFI

17 08 | 2011

Written by Tanguy

I have just bought a new motherboard, a ASRock E350M1/USB3 with and embedded AMD E350 processor. I was mostly interested in trying the embedded GPU and the UEFI firmware (UEFI is simply the name of EFI 2).

According to ASRock's marketing, the main benefit of that UEFI is its graphical interface that allows to use the mouse to configure the board. I cannot agree with that, because I think it is perfectly possible to implement that with a BIOS (and I think some BIOSes actually do it), and it is pointless anyway. For me, the main benefits are a faster and cleaner boot (no idea why it should be faster, but it is).

The EFI boot process

EFI seems to suffer from some (many?) design errors, but I find its boot process more clean and flexible than the old BIOS one:

It starts with a boot manager which is similar to the temporary boot device selection menu of most recent BIOSes.
When you have selected the device to boot from, it looks into its EFI System partition, identified by its type GUID, as FAT file system, and executes a boot loader from a file at a specific path: /efi/boot/bootx64.efi (on amd64 platforms) by default, specially for removable devices.
Once the boot loader is loaded, the boot process continues as usual and is no longer specific to EFI (although the ABI used by the boot loader is specific, of course).

It is worth mentioning that the boot manager configuration, which lies in the EFI NVRAM, can be accessed and modified from an operating system, to add random entries for loading a boot loader at any path accessible from the boot manager (you will not be able to load a file from an Ext4 file system, for instance).

GRUB on EFI

To be able to install GRUB on EFI you need an EFI System partition, formatted in FAT and mounted on /boot/efi. GRUB will simply install itself on /boot/efi/efi/debian/grubx64.efi (on Debian) according to the EFI Specification, and use efibootmgr to create a new boot manager entry called “debian” and pointing to it.

Tricks

Well, for me, it did not work. The “debian” boot option failed, saying that this was not a bootable disk. I managed to get an EFI Shell, by putting Tianocore's shell into a FAT-formatted USB stick as /boot/efi/efi/boot/bootx64.efi.

Using this DOS-smelling shell, I found that the directory /efi was unusable: it was listed, but any command trying to access to it failed. The reason was quite tricky, caused by a broken FAT implementation. With FAT, the file system label is stored both in the file system header and as a bogus root directory entry (yes, this sounds completely crazy). As I labelled my EFI System partition as “EFI”, there was such a bogus entry for this name: I think ASUS' implementation of FAT was taking it for the /efi directory. It took me hours to finally find the cause of this problem and fix it be re-formatting the partition with a new label (re-labelling may have been sufficient but I wanted to be safe).

Tags : ASRock, EFI, BIOS, FAT, boot, GRUB, Debian

11 comments

wednesday 17 august 2011 à 23:13 mirabilos said : #1

BIOSes did that in 80486 times. Sent me screaming, that. Damn GUIs.

wednesday 17 august 2011 à 23:19 Tanguy said : #2

@mirabilos :
BIOSes did what, take a FAT volume label for a file? Were they supposed to read FAT at that time? Current BIOSes do not do that…

Or do you refer to GUI configuration tools?

thursday 18 august 2011 à 00:36 Paul Menzel said : #3

1. There is a typo in the model number: s/E150M1/E350M1/.

2. You are lucky to be able to try something even better: coreboot (<http://www.coreboot.org/>). ;-)

a) Demo with your board and XBMC <http://www.xbmc.org/>: <http://www.youtube.com/watch?v=IntsDeX_s1M>
b) For trying it out, it is recommended to buy one or two flash chips as backup. The flash chips are socketed and can therefore be replaced by pulling one chip out and the other back in (even when the system is running).

Then get a test image <http://www.coreboot.org/pipermail/coreboot/2011-August/066179.html> or build coreboot (just hardware initialization) with a payload (for example SeaBIOS) yourself.

AMD recently announced to support coreboot for all their future chipsets and processors and some folks are currently trying to weed out the last glitches with the E350M1{,/USB3}. But as far as I heard and witnessed it is working fine already.

I am looking forward to read a blog post about that experience. ;-)

thursday 18 august 2011 à 04:05 Ben Hutchings said : #4

"I cannot agree with that, because I think it is perfectly possible to implement that with a BIOS..."

Indeed, AMI's WinBIOS did this in 1994.

thursday 18 august 2011 à 08:44 Tanguy said : #5

@Paul Menzel :
1. Corrected, thank you.

2. That would be great indeed. I shall contact you to get more information, like: where to buy flash chips (I already saw it was socketed, by the way).

thursday 18 august 2011 à 10:54 mirabilos said : #6

I was referring to the GUIs.

thursday 18 august 2011 à 20:56 Camelek said : #7

On Amiga you could use mouse too :]
http://www.amigahistory.co.uk/earlystart.html

Dunno when it started, with that Early Startup Screen, but it is on A500 (1987), A1200 (1992). I don't know how about A1000 (1985) :]

friday 19 august 2011 à 11:58 nobody said : #8

Could you write up a how-to with regard to the steps and tools needed to get EFI boot going? Is it a simple matter of (apt-get) installing the EFI version of grub. The last time I tried (with grub-efi-amd64) I got as far as the grub rescue prompt. I'm now back to grub-pc.

friday 19 august 2011 à 13:22 Tanguy said : #9

@nobody :
Writing a howto was not my point, but anyway, except for the volume label issue, the process was rather easy:
1. Create a small GPT partition, of type “EFI System Partition” (this is “set boot on” with parted). It must be able to hold GRUB's core image that weights 30 kiB; I use 1 MiB to be at ease.
2. Format it as FAT (12, 16 or 32 bits, it does not matter so leave the automatic choice of mkdosfs) and, if you want to label it, choose another name than “EFI”!
3. Mount it under /boot/efi (and make that permanent by adding an entry to your fstab).
4. Install grub-efi-amd64.
5. Run install-grub: this will generate the appropriate core image (using grub-mkimage), put it in the appropriate place on your EFI partition, and add a “debian” entry to the EFI boot manager menu, pointing to that GRUB code image (using efibootmgr).
6. Run update-grub: this will generate the appropriate GRUB configuration file, which is important because your old one was adapted for GRUB PC, not for GRUB EFI which uses different modules, for instance to get a graphical output.

When you get the GRUB rescue prompt, it means that GRUB's core was loaded, but unable to access to its modules (stored in your regular /boot/grub) which are needed to get a normal prompt. There can be several reasons for that, for instance: if your mother board does not detect the EFI partition (see the last section of my post), it will boot in BIOS mode, and it may then find your old GRUB PC, which will not find its modules since you have replaced them with GRUB EFI's ones!

friday 20 april 2012 à 23:19 disponibilité noms de domaine said : #10

Could you write up a how-to with regard to the steps and tools needed to get EFI boot going? Is it a simple matter of (apt-get) installing the EFI version of grub. The last time I tried (with grub-efi-amd64) I got as far as the grub rescue prompt. I'm now back to grub-pc.
I couldn’t agree more.

wednesday 27 march 2013 à 20:34 Gavin said : #11

Thanks so much for this! I did exactly the same thing (gave my system partition the label 'EFI') and couldn't boot. I would never have suspected that as the issue.

Rss feed of the article's comments

Tanguy Ortolo