查看“Broken UEFI implementations”的源代码

本页面用于记录UEFI机器上不正确的系统固件的任何方面的信息，尤其是与UEFI本身直接相关的信息。

= El Torito boot =

UEFI从CD引导使用CD头中的El Torito引导记录进行控制。 有些机器弄错了。  特别是，一组常见的已知问题源于早期的CSM包，这些包无法正确解释多个El Torito引导目录条目。  最常见的故障是CSM的解析器无法识别0xEF平台ID，当有多个引导条目时，一些版本不会正确地将“我不知道这个平台ID”解释为“这不适合我的平台”，而是会向您显示一个菜单：<pre>1.
2.
Select CD-ROM boot type:</pre>
它表示引导目录条目 (巧妙地未标记)。  在一些平台上（包括一些苹果笔记本电脑等），这种情况在没有设置任何键盘控制器的情况下发生，然后你就会被卡住。

= BGRT Table =
* BGRT是一个ACPI表，用于告诉我们UEFI固件是否以及在何处在屏幕上绘制了其徽标。  从技术上讲，BGRT是一个ACPI 5表，但它的使用与UEFI 2.4部署相对应， 它与EFI图形输出协议和ESRT+UEFI UpdateCapsule以及[[https://msdn.microsoft.com/en-us/library/dn917814%28v=vs.85%29.aspx Microsoft's firmware update graphics capsule]]协作。  理论上，“uint16_t版本”(偏移量0x24)应始终为1，而设置为0x1的“uint8_t状态”(偏移量为0x26)表示“有效数据” - 即，如果固件显示启动图形，则设置表中的值并将状态设置为1；否则，状态应为0。

以下是一些示例条目。  这些都是来自真实的机器，但这些问题在许多供应商的许多硬件中都很常见：
=== Lenovo X1 Carbon (1st gen, 346035U) ===
<blockquote><pre>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                           |........|</pre></blockquote>
它的VERSION=0x0000和STATUS=0x01很有用，即某个不存在的版本，但该表声称其信息是有效的。

=== Intel strawberry mountain (DQ67SW) ===
<blockquote><pre>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...|</pre></blockquote>
这个特定的固件说它是版本1，但数据是无效的； 此实现/始终/表示数据无效，无论它是否显示徽标。

=联想ThinkCentre M92p可能还有一些相关产品：

联想ThinkCentre M92p曾经附带了一个固件，它只允许您选择引导项，其中引导变量标签为 “微软视窗” 或 “红帽企业Linux”。  这可能已在固件版本9SKT61A/9SJT61A中修复，该版本说明：<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
-修复了安装Redhat 6.3的问题。
-修复了文本模式下有时无法全屏显示的问题</pre>
这可能就是“Red Hat Enterprise Linux”被添加到列表中的时候。

= Apple =

苹果固件有一些时髦独特的事情正在发生

===在BDS中混合了额外的UI===

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.

Instead, Apple requires a HFS+ filesystem to be present to use as the ESP, and it has to be set up in a particular way:
# Your bootloader has to exist as /EFI/${vendor}/whatever.efi and has to be blessed with hfs-bless.
# there needs to be a pixmap of the text label you want, named /EFI/${vendor}/.disk_label
# There needs to be a pixmap of the logo you want as /.VolumeIcon.icns .
# You need /System/Library/CoreServices/SystemVersion.plist to exist and describe your OS.
# /mach_kernel must exist.

The [http://www.codon.org.uk/~mjg59/mactel-boot/ mactel-boot] utility can be used to set up these things.

=== 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]]