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.
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).