``EFI引导分区''和``biosgrub''分区

我为什么需要这些？我已经在非UEFI（主引导记录）下安装了Ubuntu，并且没有使用“ biosgrub”安装了Ubuntu，并且运行正常，而其他时候，我被要求制作“ biosgrub”分区。我不知道为什么有时候我需要而其他我不需要（它们都在同一系统上）。

当我使用UEFI（GUID分区表）时，也会发生同样的事情。唯一的不同是，我被要求制作一个“ EFI引导分区”，但与“ biosgrub”一样，有时被要求制作它，有时不被要求制作。

在我当前的安装中，我被要求制作一个，但没有安装，我的系统还可以。系统，相同的硬件，BIOS等没有任何变化。有人可以对此进行说明吗？

有四个条件（BIOS vs. EFI和MBR vs. 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引导分区中。相反，引导加载程序作为普通文件驻留在FAT分区（称为EFI系统分区（ESP））上。（令人困惑的是， Debian和Ubuntu安装程序通过名称“ EFI引导分区”来引用ESP，但此名称是非标准的。GParted并将partedESP标识为具有“boot标记”，尽管该术语在MBR磁盘上意味着完全不同。）ESP可以存在于GPT磁盘或MBR磁盘上，但是前者在基于EFI的计算机上更为常见。EFI方法更安全，更安全。比起BIOS方法，它具有更大的灵活性，因为它不会将原始代码藏在奇怪的地方；引导加载程序像OS级程序一样驻留在文件中。这使它们更易于识别和操作。（OTOH，EFI也存储数据在NVRAM的引导加载程序中，这会在引导过程中造成第二点故障。EFI的新颖性还意味着它没有经过充分的测试，这导致了许多EFI特定的问题。）

GhostMotleyX，您对LiveWireBT响应的评论认为，“最佳”安装方式是BIOS / MBR。当然，这是主观的，但是我不同意这种评估。BIOS / MBR方法最不安全，也最安全我刚刚概述的三种方法比较笨拙。EFI方法是最安全，最灵活的方法。我怀疑您对GRUB / GPT和EFI方法需要单独的分区感到困惑，但这不是什么大问题。除了设置系统或进行分区维护外，这些分区对您几乎是不可见的，它们为您提供了很大的灵活性。与MBR不同，GPT不仅限于四个主分区，因此您不需要像妖精一样his积自己的金币来ho积主分区。

设置旧版引导时，需要在GPT分区磁盘上创建biosgrub分区；在设置UEFI引导时，需要在EFI引导分区（对于GPT或MBR分区磁盘）上创建biosgrub分区。

• GRUB要求BIOS系统中的BIOS引导分区（2 MiB，没有文件系统，EF02gdisk中没有类型的代码，GNU Parted中没有bios_grub标志），因为在GPT磁盘中缺少MBR后的嵌入间隙，因此可以将其嵌入core.img文件。[...]

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

对于EFI和BIOS grub，我将给出一个额外的观点/动机。

USB记忆棒从Grub2启动Live SystemRescueCD.iso循环。

为什么？简单的答案：它将在很多PC上启动，有些具有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恢复棒（它有两个技巧）：

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文件
• 读取grub.cfg（如果grub2分区上存在）
• 然后显示grub2菜单
• 然后我选择从SystemRescueCD.iso循环启动（带有dochace参数），我在grub.cfg上设置了两个选项，一个设置为32Bits，一个设置为64Bits（我实际上有四个选项，因为我在两个dostartx参数上设置了直接在GUI上启动）。
• 引导后，我可以弹出USB记忆棒（由于使用了此类docache，整个Live Linux都位于ramdrive中），无需键入任何命令，没有安装pendrive（再次感谢docache参数）。

我可以使用此摇杆以32位或64位（如果它们在处理器上具有扩展扩展名）引导旧PC（如果允许从USB引导），但是可以在BIOS模式下引导。

我还可以使用此摇杆以32位和64位引导新的PC（如果允许从USB引导），但是可以以UEFI模式引导（是的，它可以以UEFI模式引导，然后仅以32位引导Linux Live SystemRescueCD）模式以及64位模式）。

所以我拥有一个USB记忆棒恢复启动媒体，能够在所有现代或旧PC上启动（仅需要USB启动支持），无论32位还是64位，BIOS或UEFI等...我都可以选择我要运行32位或64位的内容。

另外，我已经在拒绝安装Windows 64位（旧的32位处理器）但可以运行64位Linux Live（因为该处理器上存在PAE功能）的PC上进行了测试。

旁注：NTFS这样的第一个分区用于保存可与Windows 7及更高版本共享的数据（XP不可见，因为它不支持GPT分区）...它必须是第一个分区，不需要在初始位置光盘的一部分，可以位于任何位置，但必须作为分区表上的第一个条目驻留，这是由可恨的Windows模式在可移动分区上安装分区引起的，它具有专门编程的代码，以避免访问第一个分区以外的内容，因此不能同时挂载其他主机。

Windows和USB分区的额外功能：如果在partitiong表上交换分区条目，换句话说，将要访问的分区放在表的第一个分区，则Windows将允许您访问它（如果可以理解它的格式，fat32和直接使用NTFS，带有特殊驱动程序的ext2等），但仅允许访问分区表第一个条目上的文件...有一个工具（称为BootICEx86.exe）可以在Windows上执行此类工作甚至不需要拔下USB记忆棒。

超级额外：还有一些笔式驱动器（我很幸运拥有一个索尼16GiB），可以用特殊工具（用lexar的工具来更换）进行手动更改，因此它们在Windows中看起来像USB HDD而不是USB记忆棒，更改之后，所有窗口将允许您删除，创建和管理其上的分区，也可以同时安装多个分区，每个分区都有自己的字母。

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

哦，是的，这最后几段是写的，以防万一M $上有人读了它们，所以他们的脸掉下来了，我正试图（永远不会得到它，我知道这是一个迷失的对象）要他们删除Windows中的丑陋代码，以天然方式让用户在USB记忆棒上有分区。