"EFI\boot\bootx64.efi“vs "EFI\ubuntu\grubx64.efi”和"/boot/grub/x86_64-efi/grub.efi“vs "C:\Windows\Boot\EFI\*”

Question

我在Windows 10 64位旁边安装了Ubuntu 19 64位，我发现在不同的位置有3个不同的EFI文件：

• EFI\boot\bootx64.efi
• EFI\ubuntu\grubx64.efi
• /boot/grub/x86_64-efi/grub.efi

这三个文件之间有什么区别？

Answer 1

EFI\boot\bootx64.efi：回退引导加载程序路径

这是64位X86系统上的UEFI固件在没有任何预先存在的NVRAM引导设置的情况下寻找的唯一引导加载程序路径名，因此这是您希望在可移动媒体上使用的。

Windows将自动将其引导加载程序的副本安装到此路径；在安装GRUB时，如果grub-install (或grub2-install依赖于Linux发行版)命令还可以在这里放置相应引导加载程序的副本(如果该副本还不存在)。如果需要，可以使用grub-install --removable告诉它安装到回退引导路径，或者使用grub-install --force-extra-removable覆盖回退路径中的任何现有引导加载程序，并将其替换为GRUB。

如果您想为UEFI创建一个安全的与引导兼容的USB接口，那么您应该将shim的副本放置为EFI\boot\bootx64.efi，并将GRUB的副本放置为EFI\boot\grubx64.efi，因为shim引导加载程序将在shim加载程序所在的同一个目录中查找grubx64.efi。

永久安装OS的K211引导程序路径

当操作系统永久安装到UEFI系统时，在经典的BIOS中绝对不存在一个新的步骤。在安装引导加载程序时，有四项内容被写入保存固件设置的NVRAM内存：

• 包含引导加载器的EFI系统分区(ESP)上的引导加载程序路径名(S)
• ESP分区的GUID
• 这个特定引导程序实例的描述性(对人友好的)名称。
• 还可以选择引导加载程序的一些数据。

对于Windows，用于Windows引导过程的标准UEFI路径名将是\EFI\Microsoft\Boot\bootmgfw.efi，描述性名称将是"Windows“。可选数据似乎包含对Windows引导程序的BCD配置文件中某些内容的GUID引用。

对于Ubuntu，路径名应该是\EFI\Ubuntu\grubx64.efi (如果不需要安全引导支持)，或者如果使用安全引导( Secure )，则为\EFI\Ubuntu\shimx64.efi。描述性名称只是"ubuntu“，并且不使用可选数据。

在Ubuntu中，可以使用sudo efibootmgr -v命令查看这些UEFI引导设置；在Windows中，您可以以管理员身份启动命令提示符，然后使用bcdedit /enum firmware命令查看设置。

UEFI规范有一个标准约定，即每个供应商应该将永久安装的操作系统的引导加载器放在ESP上的path \EFI\中，因此实际上支持在同一个ESP上共存多个UEFI引导加载器，并且应该比使用每个磁盘都有一个主引导记录的经典BIOS更容易。

/boot/grub/x86_64-efi/grub.efi：grub-install

的临时文件

当使用grub-install时，它将首先使用grub-mkimage实用程序创建GRUB核心映像:在UEFI系统上，该文件将保存在/boot/grub/x86_64-efi/grub.efi和/或.../core.efi中，然后复制到EFI系统分区，并由grub-install添加到UEFI引导设置。/boot/grub/x86_64-efi/*.efi中的副本在引导过程中根本不会使用，但如果ESP因任何原因而损坏，则可能会很有用。

注：在Debian/Ubuntu上，生成的GRUB核心映像将包含对包含/boot目录的任何文件系统的烘烤UUID引用，因此您将不能只从ESP复制/boot/grub/x86_64-efi/grub.efi或grubx64.efi并将其移植到可移动的媒体:它只是尝试查找/boot文件系统的唯一UUID，如果找不到它就会降到救援模式。如果我没记错的话，RedHat/CentOS/Fedora的GRUB应该更适合移植到可移动媒体。

安全启动：shimx64.efi及其原因

安全引导要求引导加载程序必须由系统的安全引导NVRAM变量db中包含的证书签名，或者引导加载程序的SHA256哈希必须在同一个NVRAM变量中白化。SHA256哈希将只匹配特定引导加载程序的特定版本，因此，除非固件变量也被更新，否则更新是不可能的。所以证书是可行的。

不幸的是，许多系统供应商将只向他们的产品提供一些安全启动证书:通常只有供应商自己的证书(用于固件更新和硬件调试/OEM配置工具)和Microsoft的安全启动证书。有些系统将允许通过固件设置(="BIOS设置“)编辑安全启动证书列表，但其他系统则不允许，因此需要一个独立的解决方案。

Microsoft为任何人提供UEFI引导加载器签名服务，但至少在一开始，签名的周转时间相当长，因此直接对GRUB的每个版本进行签名的要求将导致引导加载程序更新中不可接受的延迟。为了解决这个问题，开发了shim引导加载程序:它基本上是最简单的、合理的UEFI程序，它将向安全引导程序列表中添加一个或多个证书。这种简单性有望减少更新shim本身的需要，因此开源OS发行版(Linux和其他发行版)只需获得微软签署的shim版本，然后使用自己的证书签署任何版本的GRUB，其公共部分嵌入到shim中，并允许安全启动接受发行版的GRUB版本的GRUB。