"EFI引导分区"和"biosgrub"分区

Question

为什么我需要这些？我已经在非UEFI（主引导记录）下安装了Ubuntu，并且没有安装'biosgrub'，它运行得很好，而其他时候我被要求创建一个'biosgrub'分区。我不知道为什么有时候我需要它，有时候又不需要（这两次都是在同一台系统上）。

当我使用UEFI（GUID分区表）时，情况也是一样的。唯一的区别是我被要求创建一个“EFI引导分区”，但就像“biosgrub”一样，有时候我被要求创建它，有时候又不需要。

对于我的当前安装，我被要求创建一个，但我没有创建，我的系统运行正常。系统没有任何变化，硬件、BIOS等都是相同的...有人能解释一下吗？

- GhostMotleyX

---

你需要在启动时保持一致。只有在UEFI启动模式下，你才需要EFI分区；只有在BIOS启动模式下使用GPT分区时，你才需要bios_grub分区。如果你正在使用UEFI，但在BIOS模式下启动Boot-Repair并尝试在BIOS模式下安装grub，则会要求你创建一个bios_grub分区。 - oldfred

Answer 1

有四个条件（BIOS vs. EFI 和 MBR vs. GPT），但其中两个具有相同的需求（其中一个极为罕见）：

在传统的基于BIOS的计算机上，使用传统的MBR分区表，GRUB的可执行代码像婴儿扔出的意面一样散落在各处。其中一部分位于MBR的引导代码部分，一部分位于官方未分配的后MBR扇区，还有一部分位于Linux的/boot分区中。这真是一团糟，只能因为开发人员花了几十年时间来创建巧妙的黑客技巧并解决（几乎）所有问题。

在传统的基于BIOS的计算机上，使用新的GUID分区表（GPT），GRUB的代码与前一种情况类似；然而，紧随MBR之后的扇区不是未分配的；它们被GPT本身使用。GPT没有类似的地方供GRUB劫持，因此GRUB的开发人员选择了BIOS Boot Partition（由GParted和parted通过标志进行识别）来保存将放在MBR磁盘上的后MBR扇区中的代码。实际上，这比MBR方法更安全和更清洁，因为它可以保护GRUB代码免受其他可能尝试使用该未分配空间的程序的影响。

在使用新型EFI而不是BIOS的计算机上，引导加载程序不存储在MBR、官方未分配的后MBR扇区或BIOS引导分区中；相反，引导加载程序作为普通文件存在于一个名为EFI系统分区（ESP）的FAT分区上。（令人困惑的是，Debian和Ubuntu安装程序将ESP称为“EFI引导分区”，但这个名称是非标准的。GParted和parted通过设置其“boot”标志来识别ESP，尽管在MBR磁盘上这个术语意味着完全不同的东西。）ESP可以存在于GPT磁盘或MBR磁盘上，但在基于EFI的计算机上，前者更常见。与BIOS方法相比，EFI方法更安全、更灵活，因为它不会将原始代码隐藏在奇怪的地方；引导加载程序就像操作系统级别的程序一样存在于文件中。这使得它们更容易识别和操作。（另一方面，EFI还将引导加载程序的数据存储在NVRAM中，这在引导过程中创建了第二个故障点。EFI的新颖性也意味着它没有经过充分测试，这解释了许多特定于EFI的问题。）

GhostMotleyX，您对LiveWireBT的回复 表示安装的“最佳”方式是使用BIOS/MBR。当然这是主观的，但我不同意这个评估。BIOS/MBR方法是三种方法中最不安全、最笨拙的。EFI方法是最安全和最灵活的方法。我猜你对于GRUB/GPT和EFI方法需要单独分区这一事实感到困扰，但这并不是什么大问题。除非在系统设置或分区维护时，这些分区对您来说几乎是看不见的，并且它们给您带来了很多灵活性。与MBR不同，GPT不限制为四个主分区，所以您不必像小矮人囤积他的黄金那样囤积您的主分区。

- Rod Smith

---

感谢所有回复的人，提供了非常有帮助的信息；特别是Rod Smith。 - GhostMotleyX

在EFI引导系统上，你仍然只需要一个小分区吗？MBR引导扇区和gdisk-EF02分区的内容（或等效内容）可以存储在FAT格式的EFI系统分区中的文件中（使用gdisk类型EF00）吗？ - Peter Cordes

彼得，是的，基本上是正确的；EFI引导加载程序是存储在ESP上的文件，而不是存储在磁盘或分区引导扇区中。 - Rod Smith

如果我想同时支持UEFI引导和BIOS引导，该怎么办呢？那我是不是需要在EFI系统分区和BIOS引导分区各放一份grub的副本呢？ - Hello World

你好世界，你需要一个EFI模式和一个BIOS模式的引导加载程序。它们不必都是GRUB。实际上，我建议至少其中一个不要使用GRUB，因为那可能会非常令人困惑。对于启动单个操作系统来说，这样的配置是相当无意义的。但在某些双启动场景下可能是必要的——比如，如果一个操作系统缺乏EFI模式的引导加载程序，而另一个操作系统由于某种原因需要以EFI模式启动（比如，如果是Windows并且您的磁盘超过2TiB，那么您需要GPT来支持其完整大小）。 - Rod Smith

我无法给这个答案点赞足够了。Ubuntu的官方网站上应该有一个包含这些信息的页面。 - Nehal J Wani

@RodSmith，也许你不介意看一下这个有些相关的问题。 - Frank N

可能还需要的是，如果您制作了一个既可以在EFI计算机上启动，又可以在BIOS计算机上启动的外部硬盘。这就是我的情况，我已经浏览了数十个教程，似乎没有任何方法能够解决问题。在EFI计算机上可以正常启动，但在BIOS计算机上却无法启动。 - Mutos

Answer 2

你需要在设置传统引导时，在 GPT 分区磁盘上创建一个 biosgrub 分区，或者在设置 UEFI 引导时，在 GPT 或 MBR 分区磁盘上创建一个 EFI 引导分区（EFI boot partition）。

GRUB 在 BIOS 系统中需要一个 BIOS 引导分区（2 MiB，无文件系统，在 gdisk 中的 EF02 类型代码或在 GNU Parted 中的 bios_grub 标志），以嵌入其 core.img 文件，因为 GPT 磁盘中不存在 MBR 后嵌入间隙。

来源：https://wiki.archlinux.org/index.php/GPT#Bootloader_Support

- LiveWireBT

---

谢谢，我现在明白了；如果我在MBR磁盘上安装非UEFI的Ubuntu，就不需要biosgrub。如果我在GPT磁盘上以UEFI方式安装Ubuntu，则需要创建一个EFI分区。而我遇到的不一致之处是当我在GPT磁盘上安装非UEFI的Ubuntu，同时还有以MBR方式安装UEFI时。因此，在理论上，最佳的安装Ubuntu的方式是使用非UEFI与MBR分区表，或者使用UEFI与GPT分区表。 - GhostMotleyX

@GhostMotleyX 这是正确的。 - LiveWireBT

即使是1MiB也已经足够了。我喜欢将它放在第一个“正常”的1MiB对齐的分区之前，正如我在最后一段中解释的那样（我刚刚编辑的）。我还没有决定是否愿意使用gdisk的sort命令按照起始扇区的顺序重新编号分区，或者我是否想保留sdc4或其他。可能按顺序排序会比较常规，这样我的grub分区将始终为sdX1。 - Peter Cordes

Answer 3

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

通过Grub2从USB驱动器启动Live SystemRescueCD.iso循环。

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

真正复杂的动机是：尽可能使用先进的硬件（UEFI）。

实际生活中的使用示例：

- USB驱动器（以GPT模式格式化）有四个分区 - 第一个分区（可以在Windows 7及以上版本中看到）是NTFS格式，占用USB驱动器剩余大小的空间 - 第二个分区用于Grub2和SystemRescueCD.iso文件，至少需要1GiB（最好是2GiB，这样你可以同时携带两个版本的SystemRescueCD.iso，只是为了测试新版本以替换旧版本），我通常使用Ext4文件系统 - 第三个分区用于EFI（Windows称之为ESP），格式化为FAT32，至少需要512MiB（我见过一些电脑如果使用更小的容量，则不将USB驱动器显示为可启动介质） - 第四个分区用于BIOS_Grub（无需格式化，但创建时要清除）

一件重要的事情：我见过一个8GiB的LG USB启动盘（我自己拥有的），如果分区不对齐到柱面，它将无法在物理UEFI PC上引导，但可以在其他UEFI PC和启用UEFI引导模式的VirtualBOX上看到...当按照MiB对齐进行分区时，它确实使用了所有空间，末尾没有接近1MiB未分区的空间，但是当按照柱面对齐时，最后一个不完整的MiB没有被使用...如果我考虑到这一点进行MiB分区（换句话说，我手动进行柱面对齐），它就能正常工作，但是我要说的是它仍然是柱面对齐（我手动操作而不是让分区工具为您完成）。

如何获得这样一个强大的USB恢复盘（它有两个技巧）：

1. 将分区对齐到柱面（只需对齐到MiB更兼容） 2. 在同一个grub分区上执行grub-install --target=i386-pc，然后再执行grub-install --target=x86_64-efi，这样你只需要一个grub.cfg来支持两种引导模式

它的引导方式是：

• a) 从旧的BIOS引导，会加载MBR，然后从BIOS_grub分区加载Grub的Stage2，然后从Grub2分区加载core.img
• b) 兼容UEFI引导时，会从ESP分区加载.efi文件
• 如果存在于grub2分区上，则读取grub.cfg文件
• 然后显示Grub2菜单
• 然后我选择从loop SystemRescueCD.iso引导（带有dochace参数），我在grub.cfg上设置了两个选项，一个是32位，一个是64位（实际上有四个选项，因为我在其中两个上设置了dostartx参数以直接引导到GUI）。
• 引导后，我可以弹出USB驱动器（整个Live Linux都在ramdrive中，感谢docache参数），无需输入任何命令，U盘不会被挂载（再次感谢docache参数）。

使用这个U盘，我可以在旧的PC上引导（如果它们允许从USB引导），可以选择32位或64位（如果处理器支持扩展）。但是以BIOS模式引导。

用这个U盘，我还可以在32位和64位的新电脑上启动（如果允许从USB启动），但是以UEFI模式启动（啊，是的，它可以以UEFI模式启动，然后以32位或64位模式启动Linux Live SystemRescueCD）。

所以我有一个多合一的U盘恢复引导介质，能够在几乎所有的PC上启动，无论是现代的还是旧的（只需要支持USB启动），无论是32位还是64位，BIOS还是UEFI等等...而且我可以选择我想要运行的是32位还是64位。

而且更重要的是，我已经在一台拒绝安装64位Windows的PC上进行了测试（因为它是一颗旧的32位处理器），但是却能够运行64位的Linux Live（因为该处理器具备PAE功能）。

附注：NTFS等第一个分区用于存储可以与Windows 7及更高版本共享的数据（XP无法看到它，因为不支持GPT分区）...它必须是第一个分区，不需要位于磁盘的初始部分，可以放在任何位置，但必须作为分区表中的第一个条目存在。这是由于可恶的Windows模式将分区挂载在可移动设备上，它有特别编程的代码来避免访问除第一个分区以外的其他分区，因此您无法同时挂载其他分区。

针对Windows和USB分区的额外说明：如果您在分区表中交换分区条目，换句话说，将要访问的分区放在表中的第一个位置，Windows将允许您访问它（如果其格式被理解，如FAT32和NTFS直接访问，ext2则需要特殊驱动程序等），但只允许访问位于分区表的第一个条目上的分区...有一个工具（称为BootICEx86.exe）可以在Windows上完成这样的工作，甚至不需要拔下USB设备。

超级额外信息：还有一些闪存盘（我非常幸运拥有一个索尼16GiB），可以通过特殊工具进行位更改（我的是使用来自Lexar的工具），这样它们在Windows中就会被识别为USB硬盘而不是USB闪存盘。在更改后，所有的Windows都将允许您删除、创建和管理其上的分区，并且可以同时挂载多个分区，每个分区都有自己的盘符。

Linux用户不必担心这个问题，因为Linux将其视为可分区的块设备，并且不实现阻止挂载分区等功能，就像Windows那样。

哦，是的，最后这几段文字是写给微软员工们看的，以便他们的脸色变得沉重，我正在努力（我知道这是一个无法实现的目标）让他们从Windows中删除这样丑陋的代码，并让用户能够以原生方式在USB闪存盘上创建分区。

- Claudio