为什么大多数发行版都将UEFI和grub链接在一起？

大多数发行版在UEFI系统上安装了额外的引导加载程序。UEFI本身是一个引导程序，它提供菜单来选择不同的操作系统或单个内核。此外，UEFI设置可以使用诸如的用户空间工具轻松更改efibootmgr。

从3.3开始，内核支持EFI_STUB，这意味着可以直接从UEFI加载内核。发行版本决定使用其他引导加载程序的原因是什么？关于Linux / UEFI的大多数教程主要关注如何设置附加的引导加载程序（rEFInd，grub2，ELILO等），而不是使用EFI_STUB引导Linux。

发行版中唯一缺少的是支持。由于大多数发行版都链接了第二个引导加载程序，因此不会将内核添加到UEFI引导菜单，也不会将其复制到EFI系统分区。

三个脚本足以完成所有任务。将initramfs复制到ESP的一种。第二个将内核复制到ESP，并在UEFI引导菜单中创建一个新条目。第三个脚本从ESP中删除了旧内核和initramfs，并删除了UEFI引导菜单项。这允许完全自动化的内核/ initramfs更新/清除，而无需用户交互。我使用这种方法已经有一年多了，而且效果一直很好。

为什么大多数发行版都使用grub而不是EFI_STUB？

链接：

• 如何重新创建EFI引导分区？

编辑：我并不是在说完全删除grub支持，而是为出于各种原因想要使用它的人提供选择。发行版可以为grub-efi想要链接UEFI和grub的用户提供一个程序包，以及一个efistub-boot包含我上面提到的脚本的程序包。

鉴于UEFI只是在2005年定义的，所以有很多不支持该规范的旧设备。要将UEFI添加到标准发行版中，将需要测试两个代码路径而不是一个，并且众所周知，引导代码不仅挑剔，而且是测试代码中最耗时的代码之一。

发行版的资源有限，除此之外可能没有任何其他原因。它可能相当简单和安全，但是无论它需要进行哪些维护工作，因为grub选项必须维护（如果仅适用于非UEFI系统）。

我确信每个人都有他们希望看到发行版采用的功能和选项的列表（大声笑，我会给你几页），毫无疑问，其中许多都是“坦率地说，完全没有麻烦。 ..”。但是，没有无数的工时来实施它们。当面对这样的决策时（“我们是否将功能投入到此功能中，还是其他功能？”），主要问题应该是：

• 有必要吗？（这里的答案是否定的）。
• 多少人将从中受益，多少？（IMO：几个，但不多）
• 有没有一种合理的选择，用户无需我们做任何事情就能适应他/她的自我？（显然有。）

人们完全使用发行版的原因是因为每个人都受到资源限制（否则，只需雇用一个团队，为他们购买一些空间和设备，然后让他们按照自己的意愿为您做所有事情）。因此现实是发行版反映了用户的普遍需求。

就是说，我确实认为这将及时被采纳为一种选择，我对此问题表示赞同。

除grub之外，针对UEFI引导程序也将使质量控制和支持复杂化。发行版的目标是grub而不是UEFI规范，因为grub是免费软件，可入侵，更灵活且质量更高。您仍然可以通过遵循教程并在上挂载UEFI分区来获得纯UEFI引导/boot，因为如果这样做，维护工作就在您身上。

真正的问题是人们不了解它是如何工作的。例如，在您的问题中，您提到三个脚本是必需的，而这里的大多数答案都是关于使其工作所需的全部/任何其他维护的，但是事实是您不需要这些脚本或任何其他工作。

您所需/boot要做的就是绑定挂载ESP或在希望保留内核的任何地方进行绑定，您只需在其中输入一行即可/etc/fstab。这样做，所有当前的内核更新脚本将继续正常工作。

我的`/ etc / fstab'看起来像：

LABEL=ESP /esp vfat defaults 0 2
#
#^ i like a separate mount point - not necessary though
#
/esp/EFI/arch_root /boot none bind,defaults 0 2
#
#^ i keep separate installations in separate directories
#

不过，这里有一个关于制造商特定设置的要点。UEFI 明确并不能指定一个启动菜单界面。这是要争夺的机会，并且机器之间的不一致。这很烦人，但事实如此。

因此，而装载机如grub实际只为让更多的工作，一个菜单应用程序-如rEFInd -均衡的差异，并简化了一切。

他们将UEFI和GRUB链接为一个临时实施解决方案。

随着UEFI支持和随之而来的问题（例如安全启动）得到解决，越来越多的发行版将直接使用它。同时，这仍然是很新的：Google趋势的采用率非常有限：http : //www.google.com/trends/explore? q=cannot+boot+uefi#q=uefi%2C%20%20efi% 2C ％20％20bios＆cmpt = q

其他人都提到了寻求纯UEFI解决方案和/或同时支持非UEFI和纯UEFI系统的潜在陷阱。UEFI内核可能在非UEFY系统上工作，但是内核更新工具需要更新GRUB菜单或UEFI引导菜单，或者两者都更新，等等。

确实涉及到如上所述的质量控制：重要的是，此代码的问题会产生很大的影响：当计算机无法引导新用户时，即潜在的Linux转换，将其丢弃为垃圾并返回“安全”状态。

但是正如我所说，随着技术的广泛采用，它将成为标准。

要解决固件错误，需要额外的代码

如果不链接grub，则发行版将更多地依赖固件来正确引导。由于任何软件都会出现问题，因此固件也很容易出现此问题。现在，Linux发行版也必须编写解决这些固件错误的方法。

以现实生活中的案例为例。Asrock H81 pro BTC P1.80主板允许使用来创建启动菜单项efibootmgr。可以创建多个引导菜单项，并且可以使用更改引导顺序，efibootmgr --bootorder XXXX,YYYY,ZZZZ或者可以使用设置下一个临时引导选项efibootmgr --bootnext XXXX。这两个命令都返回输出，例如，它们使您知道引导顺序已更改或下次引导将运行BootNext: XXXX。但是，在重新引导时，顽固的固件只会忽略新请求的引导选项，并重新引导至先前的BootCurrent:值。永久启动顺序更改只能通过固件设置实用程序进行。非永久性更改根本不可用。

我认为，如果仅由EFI进行引导，而我们删除了引导加载程序，则对于硬件供应商和操作系统制造商都将很困难。硬件供应商将有更多内核要测试，而对于制造操作系统的公司来说，这就像他们的内核是否由不同的固件加载一样。

此外，通过从EFI直接启动内核，安全启动在堆栈中的哪个位置合适？在当前情况下，一旦控制权交给OS引导加载程序，则引导加载程序将检查内核是否正确签名。如果我们直接从EFI加载内核，那么我认为它只会造成混乱，因为整个堆栈都会受到干扰。从我的理解来看只是一个意见。