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

Question

我已经安装了 Ubuntu 19 64bit 和 Windows 10 64bit，我发现我在不同的位置有 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 记忆棒，你应该放置一个 shimEFI\boot\bootx64.efi的副本和一个 GRUB 的副本 as EFI\boot\grubx64.efi，因为 shim 引导加载程序将在 shim 引导加载程序所在的同一目录中查找grubx64.efi 。

永久安装的操作系统的引导加载程序路径

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

• 保存引导加载程序的 EFI 系统分区 (ESP) 上的引导加载程序路径名
• ESP 分区的 GUID
• 此特定引导加载程序实例的描述性（人性化）名称
• 可选，引导加载程序的一些数据

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

对于 Ubuntu，\EFI\Ubuntu\grubx64.efi如果您不需要安全启动支持，或者\EFI\Ubuntu\shimx64.efi如果使用了安全启动垫片，则路径名应该是。描述性名称只是“ubuntu”，不使用可选数据。

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

UEFI 规范有一个标准约定，即每个供应商都应该将永久安装的操作系统的引导加载程序放置在\EFI\<vendor name>ESP的路径中，因此实际上支持多个 UEFI 引导加载程序在同一个 ESP 上共存，并且应该比经典 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系统分区，并通过加入UEFI NVRAM引导设置之前grub-install. /boot/grub/x86_64-efi/*.efi在启动过程中根本不会使用copy in ，但如果 ESP 因任何原因损坏，它可能会很有用。

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

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

安全启动要求引导加载程序必须由包含在系统安全引导 NVRAM 变量中的证书签名db，或者引导加载程序的 SHA256 哈希值必须在同一 NVRAM 变量中列入白名单。SHA256 哈希仅匹配特定引导加载程序的特定版本，因此除非固件变量也更新，否则无法进行更新。所以证书是要走的路。

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

Microsoft 为任何人提供 UEFI 引导加载程序签名服务，但至少最初签名的周转时间很长，因此直接签署每个 GRUB 版本的要求会导致引导加载程序更新出现无法接受的延迟。为了解决这个问题，开发了 shim 引导加载程序：它基本上是最简单合理的 UEFI 程序，它将一个或多个证书添加到安全启动接受列表中。简单性有望减少更新 shim 本身的需要，因此开源操作系统发行版（Linux 和其他）可以只获得 Microsoft 签署的 shim 版本，然后使用自己的证书签署任何版本的 GRUB，其公共部分嵌入在 shim 中，并允许 Secure Boot 接受发行版的 GRUB。