''EFI 启动分区'' 和 ''biosgrub'' 分区

Question 1

有四种情况（BIOS 与 EFI 和 MBR 与 GPT），但其中两种具有相同的需求（其中一种极为罕见）：

在具有传统 MBR 分区表的传统 BIOS 计算机上，GRUB 的可执行代码会像婴儿扔的意大利面条一样四处散落。其中一些位于 MBR 的引导代码部分，一些位于正式未分配的后 MBR 扇区，一些位于 Linux 分区中/boot。这真是一团糟，它之所以有效，只是因为开发人员花了几十年的时间来创建巧妙的黑客技术并解决（几乎）所有问题。
在具有新 GUID 分区表 (GPT) 的传统基于 BIOS 的计算机上，GRUB 代码与前面的情况类似；但是，紧跟 MBR 之后的扇区并非未分配；它们由 GPT 本身使用。GPT 没有为 GRUB 提供类似的劫持位置，因此 GRUB 的开发人员选择了BIOS 启动分区（GParted 并parted通过bios_grub标志进行标识）用于保存 MBR 磁盘上后 MBR 扇区中的代码。这实际上比 MBR 方法更安全、更干净，因为它可以保护 GRUB 代码免受可能尝试使用未分配空间的其他程序的影响。
在具有较新的 EFI 而非 BIOS 的计算机上，引导加载程序不存储在 MBR、官方未分配的后 MBR 扇区或 BIOS 引导分区中；相反，引导加载程序作为普通文件驻留在称为EFI 系统分区 (ESP)。（令人困惑的是，Debian 和 Ubuntu 安装程序将 ESP 称为“EFI 启动分区”，但这个名称是非标准的。GParted 并将partedESP 标识为已boot设置其“标志”，尽管该术语在 MBR 磁盘上的含义完全不同。）ESP 可以存在于 GPT 磁盘或 MBR 磁盘上，但前者在基于 EFI 的计算机上更为常见。EFI 方法比 BIOS 方法更安全、更灵活，因为它不会将原始代码藏在奇怪的地方；引导加载程序驻留在文件中，就像操作系统级程序一样。这使得它们更容易识别和操作。（另一方面，EFI 还将引导加载程序上的数据存储在 NVRAM 中，这会在引导过程中造成第二个故障点。EFI 的新颖性也意味着它没有经过充分测试，这导致了许多 EFI 特定的问题。）

GhostMotleyX，您对 LiveWireBT 的回复的评论认为“最佳”安装方式是 BIOS/MBR。当然，这是主观的，但我不同意这种评价。BIOS/MBR 方法是至少安全和最多在我刚刚概述的三种方法中，GPT 是最笨拙的。EFI 方法是最安全和最灵活的方法。我怀疑您纠结于 GRUB/GPT 和 EFI 方法需要单独分区这一事实，但这不是什么大问题。除了设置系统或进行分区维护时，这些分区对您来说几乎是不可见的，它们为您提供了很大的灵活性。与 MBR 不同，GPT 不限于四个主分区，因此您不必像妖精囤积黄金一样囤积主分区。

Answer

有四种情况（BIOS 与 EFI 和 MBR 与 GPT），但其中两种具有相同的需求（其中一种极为罕见）：

在具有传统 MBR 分区表的传统 BIOS 计算机上，GRUB 的可执行代码会像婴儿扔的意大利面条一样四处散落。其中一些位于 MBR 的引导代码部分，一些位于正式未分配的后 MBR 扇区，一些位于 Linux 分区中/boot。这真是一团糟，它之所以有效，只是因为开发人员花了几十年的时间来创建巧妙的黑客技术并解决（几乎）所有问题。
在具有新 GUID 分区表 (GPT) 的传统基于 BIOS 的计算机上，GRUB 代码与前面的情况类似；但是，紧跟 MBR 之后的扇区并非未分配；它们由 GPT 本身使用。GPT 没有为 GRUB 提供类似的劫持位置，因此 GRUB 的开发人员选择了BIOS 启动分区（GParted 并parted通过bios_grub标志进行标识）用于保存 MBR 磁盘上后 MBR 扇区中的代码。这实际上比 MBR 方法更安全、更干净，因为它可以保护 GRUB 代码免受可能尝试使用未分配空间的其他程序的影响。
在具有较新的 EFI 而非 BIOS 的计算机上，引导加载程序不存储在 MBR、官方未分配的后 MBR 扇区或 BIOS 引导分区中；相反，引导加载程序作为普通文件驻留在称为EFI 系统分区 (ESP)。（令人困惑的是，Debian 和 Ubuntu 安装程序将 ESP 称为“EFI 启动分区”，但这个名称是非标准的。GParted 并将partedESP 标识为已boot设置其“标志”，尽管该术语在 MBR 磁盘上的含义完全不同。）ESP 可以存在于 GPT 磁盘或 MBR 磁盘上，但前者在基于 EFI 的计算机上更为常见。EFI 方法比 BIOS 方法更安全、更灵活，因为它不会将原始代码藏在奇怪的地方；引导加载程序驻留在文件中，就像操作系统级程序一样。这使得它们更容易识别和操作。（另一方面，EFI 还将引导加载程序上的数据存储在 NVRAM 中，这会在引导过程中造成第二个故障点。EFI 的新颖性也意味着它没有经过充分测试，这导致了许多 EFI 特定的问题。）

GhostMotleyX，您对 LiveWireBT 的回复的评论认为“最佳”安装方式是 BIOS/MBR。当然，这是主观的，但我不同意这种评价。BIOS/MBR 方法是至少安全和最多在我刚刚概述的三种方法中，GPT 是最笨拙的。EFI 方法是最安全和最灵活的方法。我怀疑您纠结于 GRUB/GPT 和 EFI 方法需要单独分区这一事实，但这不是什么大问题。除了设置系统或进行分区维护时，这些分区对您来说几乎是不可见的，它们为您提供了很大的灵活性。与 MBR 不同，GPT 不限于四个主分区，因此您不必像妖精囤积黄金一样囤积主分区。

Question 2

您需要创建一个biosgrub 分区在GPT 分区磁盘设置传统启动或EFI 启动分区（对于 GPT 或 MBR 分区磁盘）设置 UEFI 启动时。

GRUB 需要 BIOS 系统中的 BIOS 启动分区（2 MiB，无文件系统，EF02在 gdisk 中键入代码或 GNU Parted 中的 bios_grub 标志）来嵌入其core.img文件由于 GPT 磁盘中缺少 MBR 嵌入间隙。 [...]

^{https://wiki.archlinux.org/index.php/GPT#Bootloader_Support}

Answer

您需要创建一个biosgrub 分区在GPT 分区磁盘设置传统启动或EFI 启动分区（对于 GPT 或 MBR 分区磁盘）设置 UEFI 启动时。

GRUB 需要 BIOS 系统中的 BIOS 启动分区（2 MiB，无文件系统，EF02在 gdisk 中键入代码或 GNU Parted 中的 bios_grub 标志）来嵌入其core.img文件由于 GPT 磁盘中缺少 MBR 嵌入间隙。 [...]

^{https://wiki.archlinux.org/index.php/GPT#Bootloader_Support}

Question 3

我将为同时拥有 EFI 和 BIOS grub 给出一个额外的点/动机。

USB 棒用于从 Grub2 启动 Live SystemRescueCD.iso 循环。

为什么？答案很简单：它可以在很多电脑上启动，有些电脑有 UEFI，有些电脑只有 32 位旧 BIOS，等等。

真正复杂的动机：如果可能的话，使用先进的硬件（UEFI）。

真实使用示例：

具有四个分区的 USB 棒（以 GPT 模式格式化）
NTFS 上的第一个分区（可在 Windows 7 及更高版本中看到），其余分区与 USB 驱动器的大小相同
第二个分区用于 Grub2 和 SystemRescueCD.iso 文件，至少有 1GiB（最好是 2GiB，这样你就可以同时携带两个版本的 SystemRescueCD.iso，只是为了在替换旧版本之前测试新版本），我通常使用 Ext4 文件系统
第三个分区为 EFI（Windows 称之为 ESP），格式为 Fat32，至少有 512MiB（我见过一些 PC，如果使用较少的空间，它们不会显示 USB 记忆棒作为可启动媒体）
第四个分区为 BIOS_Grub（未格式化，但创建时已清除）

重要的事情一件：我见过一个 8GiB LG USB stric（我拥有的一个），如果分区未与圆柱体对齐，则拒绝在物理 UEFI PC 启动上列出，但可以在其他 UEFI PC 上看到，也可以在激活了 UEFI 启动模式的 VirtualBOX 上看到...在对其进行分区时，如果与 MiB 对齐，它确实会使用所有空间，最后没有接近 1MiB 的未分区空间，但是当与圆柱体对齐时，最后一个不完整的 MiB 不会被使用...如果我考虑到这一点进行 MiB 分区（换句话说，我进行手动圆柱体对齐）它可以工作，但正如我所说，它仍然是圆柱体对齐的（我是手动执行的，而不是让分区工具为您执行此操作）。

如何获得如此出色的 USB 恢复棒（有两个技巧）：

将分区与柱面对齐（与 MiB 对齐具有更好的兼容性）
执行 grub-install --target=i386-pc，然后在同一个 grub 分区上执行另一个 grub-install --target=x86_64-efi，这样两种启动模式仅使用一个 grub.cfg

如何启动：

a) 从旧 BIOS 启动，将加载 MBR，然后从 BIOS_grub 分区加载 grub 的第 2 阶段，然后从 Grub2 分区加载 core.img
b) 从 UEFI 兼容启动，将从 ESP 分区加载 .efi 文件
读取 grub.cfg（如果存在于 grub2 分区上）
然后显示 grub2 菜单
然后我选择从循环 SystemRescueCD.iso 启动（带有 dochace 参数），我在 grub.cfg 上设置了两个选项，一个用于 32 位，一个用于 64 位（我实际上有四个选项，因为我设置了两个 dostartx 参数以直接在 GUI 上启动）。
启动后，我可以弹出 USB 驱动器（由于这样的 docache，整个 Live Linux 都在 ramdrive 中），无需输入任何命令，pendrive 未安装（再次感谢 docache 参数）。

使用此棒，我可以启动 32 位或 64 位的旧 PC（如果它们允许从 USB 启动），但以 BIOS 模式启动（如果它们允许从 USB 启动）。

使用此棒，我还可以以 32 位和 64 位启动新 PC（如果它们允许从 USB 启动），但以 UEFI 模式启动（啊，是的，它可以在 UEFI 模式下启动，然后只需以 32 位模式和 64 位模式启动 Linux Live SystemRescueCD）。

所以我拥有一体化 USB 恢复启动介质，能够在几乎所有 PC 上启动，无论是现代的还是旧的（只需要 USB 启动支持），无论是 32 位还是 64 位、BIOS 还是 UEFI 等... 我可以选择想要运行 32 位还是 64 位。

另外，我曾在一台拒绝安装 Windows 64 位（旧的 32 位处理器）的 PC 上进行过测试，但能够运行 64 位 Linux Live（因为该处理器存在 PAE 功能）。

附注：NTFS 这样的首个分区用于保存可与 Windows 7 及更高版本共享的数据（XP 看不到它，因为不支持 GPT 分区）...它必须是第一个，不需要位于磁盘的初始部分，可以位于任何您想要的位置，但必须作为分区表上的第一个条目，这是由可憎的 Windows 模式导致的，用于在可移动设备上安装分区，它具有专门编程的代码以避免访问超过第一个分区，因此您不能同时安装其他分区。

Windows 和 USB 分区的额外功能：如果您在分区表上交换分区条目，换句话说，您将想要访问的分区作为表中的第一个分区，Windows 将允许您访问它（如果它的格式是可以理解的，直接是 fat32 和 NTFS，带有特殊驱动程序的 ext2 等），但只允许访问位于分区表第一个条目上的那个...有一个工具（称为 BootICEx86.exe）可以在 Windows 上完成这样的工作，甚至不需要拔下 USB 记忆棒。

超级额外：还有一些 U 盘（我很幸运拥有一个，索尼 16GiB），可以用特殊工具进行更改（我使用 lexar 的工具），因此它们在 Windows 中显示为 USB HDD 而不是 USB 记忆棒，进行此更改后，所有 Windows 都会允许您删除、创建和管理其上的分区，也可以同时安装多个分区，每个分区都有自己的字母。

Linux 用户不必担心这一点，因为 Linux 将其视为可分区的块设备，并且没有像 Windows 那样实现特殊代码来阻止安装分区等。

哦，是的，最后这几段话是为了以防万一 M$ 上的某个人读到它们，以致他们脸色大变，我正在尝试（永远不会明白，我知道这是一个失败的目标）从 Windows 中删除这些丑陋的代码，并让用户以本机方式在 USB 驱动器上进行分区。

Answer