Anonymous user
Broken UEFI implementations: Difference between revisions
→There's additional UI presented mixed in with BDS
| [unchecked revision] | [unchecked revision] |
| (29 intermediate revisions by 10 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. 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>
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 [[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 18 ⟶ 25:
00000030 fa 00 00 00 4f 00 00 00 |....O...|</pre></blockquote>
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:<pre>CHANGES for 9SKT61A/9SJT61A
- Fixes some Linux secure boot issues.
- Updates Microcode M12306A9 to V17. </pre>
Also the changelog says:
<pre>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.</pre>
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.
# On some machines, they need to be Apple Partition Map formatted.
# 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. [http://www.syslinux.org/wiki/index.php/The_Syslinux_Project syslinux]]'s "isohybrid" utility has had this ability to build this sort of image since version 4.05 .
# On some machines, there needs to be a special El Torito image for an HFS+ formatted ESP that conforms to what's above in [http://wiki.osdev.org/index.php?title=Broken_UEFI_implementations#There.27s_additional_UI_presented_mixed_in_with_BDS 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 [https://fedoraproject.org/wiki/User:Pjones/BootableCDsForBIOSAndUEFI here].
# The menus will show the BIOS image as "Windows"
# Unfortunately the menus will also show the FAT-based UEFI image as "Windows".
# 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 [https://github.com/rhinstaller/lorax 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)
[[Category:UEFI]]
| |||