☰

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

tag-icon • tag-icon grub uefi boot-loader
“EFI\boot\bootx64.efi”与“EFI\ubuntu\grubx64.efi”与“/boot/grub/x86_64-efi/grub.efi”与“C:\Windows\Boot\EFI\*”

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

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

这三个文件有什么区别呢？

答案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 引导加载程序将查找grubx64.efi 在 shim 引导加载程序所在的同一目录中。

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

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

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

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

\EFI\Ubuntu\grubx64.efi对于 Ubuntu，如果您不需要安全启动支持，或者\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 系统上，此文件将在复制到 EFI 系统分区并通过 添加到 UEFI NVRAM 启动设置/boot/grub/x86_64-efi/grub.efi之前保存。启动过程中根本不会使用该副本，但如果 ESP 由于任何原因损坏，它可能会很有用。.../core.efigrub-install/boot/grub/x86_64-efi/*.efi

笔记：在 Debian/Ubuntu 上，生成的 GRUB 核心映像将包含对包含该目录的文件系统的内置 UUID 引用/boot，因此您无法仅从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 本身的需要，因此开源操作系统发行版（Linux 和其他）只需获得 Microsoft 签名的 shim 版本一次，然后使用自己的证书签署任何版本的 GRUB，其公共部分嵌入在 shim 中，并允许安全引导接受发行版本的 GRUB。

相关内容