Broken UEFI implementations

This page serves as a repository of information about any aspect of the system firmware which is broken on UEFI machines, but especially those directly related to UEFI itself.

El Torito boot

UEFI boot from CD is controlled using El Torito boot records in the CD headers. Some machines get this wrong. In particular, one common set of known issues stem from early CSM packages which don't correctly interpret multiple El Torito boot catalog entries. The most common failure is the CSM's parser not recognizing the 0xEF platform ID, and instead of interpreting "I don't know this platform ID" correctly as "This is not for my platform" when there are multiple boot entries, some versions present you with a menu:

1.
2.
Select CD-ROM boot type:

Which represents the boot catalog entries (cleverly unlabeled). On some platforms (including some Apple laptops, among others) this happens without setting up any keyboard controller, and you are now stuck.

BGRT Table

• BGRT is an ACPI table to tell us if and where UEFI firmware has drawn its logo on the screen. Technically, the BGRT is an ACPI 5 table, but its use corresponds with UEFI 2.4 deployments, and it goes hand in hand with the EFI Graphics Output Protocol and ESRT + UEFI UpdateCapsule and [Microsoft's firmware update graphics capsule]. In theory, "uint16_t version" (offset 0x24) should always be 1, and "uint8_t status" (offset 0x26) with 0x1 set means "valid data" - that is, if the firmware displayed a splash graphic, it sets the values in the table and sets status to 1; if not, status should be 0.

Here are some sample entries. These are from real machines, but the problems are common across lots of hardware from lots of vendors:

Lenovo X1 Carbon (1st gen, 346035U)

00000000  42 47 52 54 38 00 00 00  00 00 4c 45 4e 4f 56 4f  |BGRT8.....LENOVO|
00000010  54 50 2d 47 36 20 20 20  00 27 00 00 50 54 4c 20  |TP-G6   .'..PTL |
00000020  02 00 00 00 00 00 01 00  18 b0 7e d3 00 00 00 00  |..........~.....|
00000030  0f 02 00 00 b4 00 00 00                           |........|

This helpfully has version=0x0000 and status=0x01 i.e. some version that doesn't exist but the table claims its information is valid.

Intel strawberry mountain (DQ67SW)

00000000  42 47 52 54 38 00 00 00  01 fe 49 4e 53 59 44 45  |BGRT8.....INSYDE|
00000010  4d 48 42 20 43 52 42 20  01 00 00 00 41 43 50 49  |MHB CRB ....ACPI|
00000020  00 00 04 00 01 00 00 00  00 d0 fd a7 00 00 00 00  |................|
00000030  fa 00 00 00 4f 00 00 00                           |....O...|

This particular firmware says it's version 1 but that the data is invalid; this implementation /always/ says the data is invalid, whether it displays the logo or not.

The Lenovo ThinkCentre M92p and maybe some related products

The Lenovo ThinkCentre M92p once shipped with a firmware which would only let you select boot entries where the Boot#### variable label was "Microsoft Windows" or "Red Hat Enterprise Linux". This may have been fixed in firmware version 9SKT61A/9SJT61A , which says:

CHANGES for 9SKT61A/9SJT61A
- Fixes some Linux secure boot issues.
- Updates Microcode M12306A9 to V17.  

Also the changelog says:

CHANGES for 9SKT51A/9SJT51A
- Fixes the issue of installing Redhat 6.3.
- Fixes the issue that sometimes the display cannot be full screen in text mode.

Which was probably when "Red Hat Enterprise Linux" was added to the list.

Apple

Apple firmwares have a couple of funky things going on

There's additional UI presented mixed in with BDS

The "option key" boot screen and such are basically between BootNext/BootOrder and any other BDS menus and such. In effect they are the BDS menus, but they do a lot of non-BDS things. So basically BootNext and BootOrder can override the normal boot selection from that menu without you ever seeing it, but the things that show up in that menu aren't strictly governed by Boot#### variables.

The "option" menu shows files in the following locations on both FAT32 and HFS+ partitions:

- /EFI/BOOT/BOOTX64.EFI (or BOOTIA32.EFI on Macs made from 2006-2007)

- /System/Library/CoreServices/boot.efi

Some machines will also find EFI boot loaders in other locations, but the first two are the only reliable locations.

These files can be placed on any FAT32 or HFS+ partition on USB flash drives or the internal hard drive. However, they will appear in the option menu as "EFI Boot" and do not use the name given by BDS.

CDs are wild and crazy

CDs can be booted through the option key menu if they're set up properly. There are also some caveats.

1. On some machines, they need to be Apple Partition Map formatted.
2. This also means to make a disc that works on EFI+Apple+BIOS as both an ISO image /and/ an image on a USB stick, you need to actually /execute/ the APM header signature on BIOS machines. Thankfully that's pretty safe, but it's a little squicky in your head. syslinux]'s "isohybrid" utility has had this ability to build this sort of image since version 4.05 .
3. On some machines, there needs to be a special El Torito image for an HFS+ formatted ESP that conforms to what's above in There's additional UI presented mixed in with BDS in order to have it show your UEFI-bootable image as anything other than "Windows". This means there are /three/ El Torito entries - the "Validation Entry" of type 0x00 (80x86), which holds the BIOS code, and then *two* entries of type 0xef - the HFS+ and then the FAT one. The HFS+ one needs to be last one. Tools like mkisofs can make ISOs with multiple images with the several boot images using the "-eltorito-alt-boot" and "-e" options. There's some examples here.
4. The menus will show the BIOS image as "Windows"
5. Unfortunately the menus will also show the FAT-based UEFI image as "Windows".
6. Some machines will not correctly boot the FAT-based UEFI image. This means you need to tell your users that when they're trying to boot a CD or USB stick of your product, they need to pick the left-most correctly labeled one with an icon.

It's pretty easy to orchestrate getting all this correct with tools like Lorax, which has scripts for doing it on RHEL and Fedora, and can be taught to do it on other things without excessive work.

GIGABYTE Hybrid EFI

These motherboards claim to support other os, however it is not possible to use efibootmgr to write to nvram. Further, fdisk gpt partitioned drives with the standard efi system partition type and all known good default names will not be able to find a stub kernel image. Strangely they are able to find the /efi/boot/bootx64.efi image when it is located on a MBR formatted disk (which is how it was possible to run efibootmgr in the first place). These issues may be related to issues described here: http://www.rodsbooks.com/gb-hybrid-efi/.

Another commenter adds: "Hybrid EFI" is gigabyte's name for running an x64 uefi emulator on top of bios, which does not work at all well. Some boards with Hybrid EFI offer a beta real EFI upgrade as a firmware download, which fixes most of the serious issues, but not all. See http://www.gigabyte.com/products/product-page.aspx?pid=3979#ov for an example of such a board. Version F7 is "Hybrid Efi" and doesn't work, U1G is the real thing but is marked beta.

Piles and piles of Acer hardware

Acer for some reason don't honor the BootOrder variable under most conditions. This has been an ongoing issue forever, chronicled most recently here: https://github.com/rhinstaller/efibootmgr/issues/19

Typical example (Acer Travelmate B116-M, Insyde BIOS V1.20)

Boots fine from USB UEFI formatted devices, once you disable Secure boot, which can only be done once you've set a bios password. Installing a Linux-only system shows no errors (including from efibootmgr), but then fails to boot at all. The BIOS shows no boot entries. Restoring the original windows EFI System Partition from backups "fixes" the problem, on next boot we have a new automagic entry called "Windows Boot Manager". Creating new EFI boot entries after that using efibootmgr silently fails, the system ignores them. The only way to get it to boot something else is to replace \EFI\Microsoft\Boot\bootmgfw.efi with the distro-provided grubx64.efi.

MSI motherboards with AMI firmware

Some users have reported that on the MSI GE62 2QD Apache Pro (board model: MS-16J2) with AMI firmware, variables set with efibootmgr aren't persistent across reboots.

Dell Wyse 3040

This thin client will only boot /EFI/BOOT/BOOTX64.efi and ignores which efi file is actually selected in the graphical firmware setup.

Runtime services accessing boot services memory

Many UEFI firmwares have the issue of runtime services accessing boot services memory. There is a series of patches at https://lkml.org/lkml/2014/9/13/103 to detect these bugs without breaking systems. (Trivia: https://lkml.org/lkml/2013/11/11/653, which uses a different approach, is written by HP that also locked access to firmware updates to paid customers not long afterwards)