GRUB 的多个 EFI 可执行文件的引导行为



安装 Ubuntu 后,EFI 系统分区的/efi/UBUNTU/中有几个 *.efi文件:

  • GRUBX64。电喷
  • 莫克马纳格。电喷
  • SHIMX64。电喷
  • mmx64.efi
  • fwupx64.efi

但是UEFI规范2.7在">13.3.1.3目录结构"一节中说:

每个映像也只能有一个可执行的 EFI 映像每个供应商子目录中支持的处理器体系结构。这 保证只能有一个图像可以从 EFI 引导管理器的供应商子目录。如果不止一个 存在可执行的 EFI 映像,则 系统不会确定性的

我会明确 GRUB 的 5 个 EFI 可执行文件的引导行为。

UEFI 固件通常会在/boot/efi/EFI/BOOT/文件夹中查找相应的 EFI 可执行文件。它查找的可执行文件的名称取决于系统的体系结构。对于x86_64体系结构,该文件BOOTX64.EFI

此文件实际上是位于/boot/efi/EFI/ubuntu/文件夹中的 EFI 可执行文件之一的副本。就我而言,/boot/efi/EFI/BOOT/BOOTX64.EFI/boot/efi/EFI/ubuntu/shimx64.efi的副本。

请参阅 UEFI 引导:它实际上是如何工作的呢?和 EFI 系统分区和默认引导行为 以获得更详细的说明。

要了解为什么/boot/efi/EFI/ubuntu/中有所有这些其他EFI可执行文件,请参阅ubuntu wiki上的SecureBoot。

  1. 我对UEFI规范的了解不足以回答为什么的问题。但是根据我对UEFI启动如何工作的了解,我根本不明白为什么应该有这个限制。鉴于UEFI的力量,这似乎没有必要。

  2. \
  3. EFI\BOOT\BOOTX64 中的二进制文件。EFI 是在找不到其他任何内容时使用的回退。通常,如果你想制作一个可以从PC携带到PC的USB记忆棒,你会这样做。当然BOOTX64。EFI 可以是任何有效引导加载程序的副本。早期的PC会在那里放一个MS引导加载程序的副本。Ubuntu 安装可能会在那里放置其填充程序的副本。等。

  4. 如果安全启动处于打开状态,则 UEFI 将拒绝运行未正确签名的 .efi 二进制文件。在您提供的二进制文件中,我希望只有 SHIM 会正确签名,因此其他二进制文件不会运行。

  5. UEFI 尝试按引导顺序引导事物。引导顺序指定以什么顺序尝试 NVRAM UEFI 变量 Boot0000、Boot0001 等(并非所有变量都必须存在(因此 BootOrder 变量将包含一个列表,例如 07 0002 0004 000F。 这告诉 UEFI 尝试 Boot0007,然后返回(如果成功启动操作系统,则不应该返回(旁边的尝试 Boot0002 等。 "Try Boot####"表示查看该变量的内容并运行相关代码。"相关代码"将取决于引导是通过网络、从 BIOS MBR 磁盘、从 CD 还是从 ESP。 如果来自 ESP,则有问题的变量可能包含一个路径名,该路径名将准确指定要运行的 .efi 文件。在你的情况下,它会说运行\ubuntu\shimx64.efi 然后,shim 将从启动它的同一目录(此处为 \ubuntu(运行 grubx64.efi,grubx64.efi 将显示一个菜单或在硬盘驱动器中搜索要加载和运行的 vmlinuz(或其他(操作系统内核。

鉴于 UEFI 可以做所有这些事情,我不明白为什么规范会将 ESP 上目录的内容限制为只有一个 EFI 文件。这样做似乎会导致许多不必要的目录和子目录。

相关内容

  • 没有找到相关文章

最新更新