Anonymous user
Broken UEFI implementations: Difference between revisions
→There's additional UI presented mixed in with BDS
| [unchecked revision] | [unchecked revision] |
| (12 intermediate revisions by 9 users not shown) | |||
Line 1:
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.
▲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:<pre>1.
2.
Select CD-ROM boot type:</pre>
Line 10 ⟶ 9:
= 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 [[https://msdn.microsoft.com/en-us/library/dn917814%28v=vs.85%29.aspx 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:
Line 46 ⟶ 45:
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 ===
Line 93:
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)
== Runtime services accessing boot services memory ==▼
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.
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)
[[Category:UEFI]]
| |||