正常引导 UEFI 机器

常规 UEFI 引导有多个列表。每个列表包含能够引导的多个操作系统入口条目，列表存储在 UEFI 配置变量里（通常在 NVRAM 里），引导顺序的配置变量与它们一起存储。它允许多个不同的引导选项，以及正确定义的备选引导顺序。在很多场景下，您甚至可以从系统引导菜单（类似于很多 BIOS 中实现的引导设备菜单）中列出并选择要使用的操作系统/引导加载程序。不幸的是，许多 PC UEFI 实现把这些功能都搞错了，所以不能正常工作。

从本地磁盘引导时，正确的工作方式是让引导变量指向

\EFI\$vendor\$bootloader.efi

.efi 文件在 EFI 系统分区（ESP，EFI System Partition）上。ESP 是一种特殊标记的分区，通常用FAT32格式化。

Debian 为其 efi 引导装载程序安装 grub-efi，如下所示：

架构

路径

amd64

\EFI\debian\grubx64.efi

i386

\EFI\debian\grubia32.efi

arm64

\EFI\debian\grubaa64.efi

armhf

\EFI\debian\grubarm.efi

这里 GRUB 的每个版本都包含了 GRUB 从那个点位工作所需的所有代码和配置。

通过像 \EFI\$vendor\ 这样使用独立的供应商目录，UEFI 允许供应商之间完全的互操作性。如果固件开发者有能力就好了... :-( 有些实现完全忽略了引导顺序，有些实现过滤了引导顺序，只运行自称是“Windows”的东西，等等。请参阅下面的提示，了解如何解决 UEFI 实现中的一些已知错误。

ESP 里如果没有引导变量指向引导加载程序，或者如果用户恰当的指定了系统，它也会在某些特定的路径中寻找引导加载程序。在每个设备上，它将寻找 FAT32 文件系统。在每个文件中，它将查找一个专门命名的引导加载程序文件，同样，每个体系结构有不同的名称：

架构

路径

amd64

\EFI\boot\bootx64.efi

i386

\EFI\boot\bootia32.efi

arm64

\EFI\boot\bootaa64.efi

armhf

\EFI\boot\bootarm.efi

不同的名字是有意的——它允许一个磁盘或 CD 包含多个体系结构的引导文件，而没有冲突。

在 Debian 安装介质上，这些文件中的每一个都是 grub-efi 的副本，具有足够的内置代码和配置，可以从那里找到系统的其余部分。

debian-installer 对 UEFI 的支持主要包含在两个模块中。

首先是 partman-efi 模块，如果 d-i 识别出它已经在 UEFI 模式下启动，它将自动加载。partman-efi 可以处理 MS-DOS 和 GPT 分区磁盘，但是在还没有分区的磁盘上优先使用 GPT。如果有必要，它知道如何用适当的分区类型和文件系统来设置 ESP，并且将确保它在以后被正确地挂载到已安装的系统上。如果系统已经有一个 ESP，partman-efi 将尝试使用它，而不是创建一个新的。这是为了在双引导系统中与现有操作系统的互操作性。

一旦正常的安装过程完成，支持 UEFI 的第二个主要组件开始发挥作用：grub-installer。它会将 grub-efi 引导加载程序安装到 ESP 中的正确位置，并使用 efibootmgr 向固件注册该引导加载程序。在正常工作的系统上，这应该不需要任何用户交互就能工作。这个模块会自动找到 ESP 并把它的文件安装在正确的位置，不会留下空间导致混淆引导文件保存位置（MBR/MS-DOS系统可能会发生这种情况）。

Wheezy（7.0，2013年5月发布）中增加了使 UEFI amd64 系统可以直接安装在 Debian 中的初始支持。后来为 Jessie（8.0，2015年4月发布）添加了对 i386 和arm64 系统的支持，以及许多奇怪的问题和错误解决方法。关于这些的更多细节见下文。Buster 中增加了对 armhf 的支持（10.0，2019年7月发布）。

在 Wheezy（7.0，2013年5月发布）中为 amd64 添加了对 UEFI 安装的初始支持。这适用于很多用户，但是不同的用户报告了问题。其中大部分不是 Debian 的 UEFI 支持中的直接错误，但尽管如此，我们还是添加了解决方法来帮助这些人。

相当多的早期 UEFI 系统预装了非 UEFI 安装的 Windows 7（2009年10月发布），固件设置为首先尝试 UEFI 引导，然后尝试 BIOS 引导。这对用户来说很好，但是当一个新的操作系统和 Windows 一起安装的时候，双重启动就很困难/不可能了。

debian-installer 现在会警告用户，如果它在 UEFI 模式下启动，但只能找到非 UEFI 的现有操作系统安装。它让他们可以选择从现在开始将安装程序切换到非UEFI 模式，这样他们就不会破坏潜在的双引导设置。

如前所述，很不幸，许多 UEFI 固件实现存在缺陷。引导条目和引导顺序的规范里，这东西应该如何工作虽然非常明确，但是在不遵守规范的野生场景，有很多系统会出错。一些系统简单地忽略添加新启动条目的有效请求。另一些会接受这些请求，但是却拒绝使用，除非这些请求将自己描述为“Windows”或类似的东西。还有许多其他类似的错误，这表明许多系统供应商除了“它能在 Windows 上工作吗？”之外，很少进行测试。

如上所述，在 UEFI 系统上，引导加载程序应该只安装在 EFI 系统分区（ESP）中正确的特定于供应商的目录中。但是，由于存在错误的固件实现，发行商不敢奢求自己的操作系统在所有 UEFI 固件上都能正确工作。微软已经解决了这个问题（可以说也使问题变得更糟）——Windows安装程序也安装到 ESP 中的可移动媒体路径（例如，对于 amd64/X64 系统，\EFI\boot\bootx64.efi）。因为所有固件实现都必须使用此路径才能运行操作系统安装程序。所以在所有破损的不完整的 UEFI 实现上， Windows 将始终可以工作，UEFI 系统的供应商可以“很巧合”的将不完整的 UEFI 实现运行起来。不过，这意味着，供应商移除了备选的引导路径、并且打消了你合理控制引导顺序的想法。

所有操作系统的安装程序都把东西安装到这个可移动媒体路径，互相就会形成冲突，文件会相互覆盖，这是不好的和错误的。因此，在 Debian 中我们默认不这么做。

然而，为了帮助支持那些不幸拥有这种错误 UEFI 系统的人，有一个选项可以强制将 grub-efi 安装到可移动介质路径。有一个 d-i Rescue Mode 选项可以强制实现这一点——如果你刚刚在 UEFI 系统上安装了 Debian，但之后它无法启动 Debian，这可能会为你解决这个问题。也可以在使用专家模式的正常安装运行期间选择它，或者 Preseed 用户可以在他们的配置中添加以下选项（对于amd64，调整软件包名称以适应其他体系结构）：

grub-efi-amd64  grub2/force_efi_extra_removable boolean true

您也可以通过使用 dpkg-reconfigure grub-efi-amd64 来选择它。在问的其他问题中，这是一个要寻找的问题：

如果一个可引导的 Debian 安装程序映像不可用，那么作为临时措施，使用任何可用的方法将 \EFI\debian\grubx64.efi 复制到 \EFI\boot\bootx64.efi （其他操作系统，将存储设备连接到不同的计算机，等等）。而且你应该可以进入你的系统。一旦你让它正常启动，你应该像上面一样重新配置 grub，这样你的 Debian 系统将来也会知道这样做。

警告！如果您不在这里适当地重新配置 grub，那么在将来的升级中，grub 包将不知道更新可移动介质路径中的副本。当 grub 发生变化时，这可能会使您的系统无法启动。

顾名思义，将 grub-efi 安装到可移动介质路径对于在可移动介质上安装可移植 Debian 非常有用（甚至是必要的）。

一些 UEFI 系统（如2013年前后生产的索尼VAIO系统）不允许选择引导加载程序路径。有些人声称，从救援系统的提示手动转移和替换文件成功的实现双启动。例如：

 # mkdir tmp  # mount /dev/sdaX tmp  # cd tmp/EFI/Microsoft/Boot/  # mv bootmgfw.efi bootmgfw.efi.org  # cp ../../debian/shimx64.efi bootmgfw.efi

这种安装方法对于升级来说并不可靠，最好使用传统的基于 MBR 的安装方法，或者使用如上所述的可移动介质。

《UEFI》https://wiki.debian.org/UEFI