”EFI启动分区”和”biosgrub”分区

我为什么需要这些? 我已经在非UEFI(主引导记录)下安装了Ubuntu并安装了没有’biosgrub’的Ubuntu并且工作正常,而有时我被要求制作’biosgrub’分区。 我不知道为什么有时候我需要它和其他我不需要它们(这些都是在同一个系统上。当我使用UEFI(GUID分区表)时发生同样的事情只是差异是我被要求制作’EFI引导分区’但与’biosgrub’一样,有时我会被要求制作它,有时我不会被要求制作它。对于我当前的安装,我被要求制作一个,但我没有,我的系统很好。有没有改变系统,相同的硬件,BIOS等…有谁可以阐明这一点?

有四个条件(BIOS与EFI和MBR与GPT),但其中两个具有相同的需求(其中一个非常罕见):

  • 在具有传统MBR分区表的传统基于BIOS的计算机上,GRUB的可执行代码像婴儿抛出的意大利面条一样散布。 其中一些是在MBR的启动代码部分,其中一些是在MBR后的部门正式未分配,其中一些是在Linux /boot分区中。 这是一个真正的混乱,它的工作原理只是因为开发人员已经花费了数十年的时间来创建聪明的黑客并解决(几乎)所有的问题。
  • 在具有新GUID分区表(GPT)的传统基于BIOS的计算机上,GRUB代码与前面的情况类似; 然而,紧随MBR之后的部门并非未分配; 它们被GPT本身使用。 GPT没有提供GRUB劫持的类似位置,因此GRUB的开发人员决定使用BIOS引导分区 (通过bios_grub标志进行GParted和parted识别)以保存将在MBR磁盘上的MBR后扇区中的代码。 这实际上比MBR方法更安全,更清晰,因为它可以保护GRUB代码免受可能尝试使用该未分配空间的其他程序的影响。
  • 在具有较新EFI而非BIOS的计算机上,引导加载程序不存储在MBR,正式未分配的MBR后扇区或BIOS引导分区中; 相反,引导加载程序作为普通文件驻留在称为EFI系统分区(ESP)的FAT分区上。 ( 令人困惑的是, Debian和Ubuntu安装程序通过名称“EFI启动分区”引用ESP,但这个名称是非标准的.GParted和parted将ESP识别为设置了“ boot标志”,尽管该术语意味着完全不同的东西在MBR磁盘上。)ESP可以存在于GPT磁盘或MBR磁盘上,但前者在基于EFI的计算机上更常见。 EFI方法比BIOS方法更安全,更灵活,因为它不会将原始代码丢弃在奇怪的地方; 引导加载程序驻留在文件中,就像操作系统级程序一样。 这使它们更容易识别和操作。 (OTOH,EFI还将数据存储在NVRAM中的引导加载程序中,这会在引导过程中产生第二个故障点.EFI的新颖性也意味着它没有经过充分测试,这可以解决许多特定于EFI的问题。)

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

在设置UEFI引导时,在设置旧式引导或EFI引导分区 (对于GPT或MBR分区磁盘)时,需要在GPT分区磁盘上创建biosgrub分区

  • GRUB需要BIOS系统中的BIOS引导分区(2 MiB,无文件系统,gdisk中的EF02类型代码或GNU Parted中的bios_grub标志)以嵌入其core.img文件, 因为GPT磁盘中缺少MBR后嵌入间隙 。 […]

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-install –target = i386-pc然后在同一个grub分区上再做一次grub-install –target = x86_64-efi,所以你只使用一个grub.cfg用于两种启动模式

怎么靴子:

  • a)从旧BIOS启动,将加载MBR,然后grub的Stage2从BIOS_grub分区,然后从Grub2分区的core.img
  • b)引导formsUEFI兼容,将从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模式下启动。

有了这个棒,我也可以用32位和64位启动新的PC(如果他们允许从USB启动),但是在UEFI模式下启动(啊,是的,它可以在UEFI模式下启动,然后只需在32位启动Linux Live SystemRescueCD模式以及64位模式)。

所以我有一个usb棒恢复启动媒体,能够在所有PC,现代或旧(只需要USB启动支持)启动,无论是32位还是64位,BIOS或UEFI等…我可以选择我想要运行的32位或64位。

此外,我曾在拒绝安装Windows 64Bits(旧32位处理器)的PC上进行过测试,但能够运行64位Linux Live(因为该处理器上存在PAEfunction)。

旁注:像NTFS这样的第一个分区用于保存可以与Windows 7及更高版本共享的数据(XP不会看到它,因为不支持GPT分区)…它必须是第一个,不需要在初始化光盘的一部分,可以在任何你想要的地方,但是作为第一个条目驻留在分区表上,这是由可恶的Windows模式在可移动的分区上安装分区引起的,它具有特定的代码编程,以避免访问超过第一个分区,所以你无法同时安装其他人。

Windows和USB分区的额外function:如果您在分区表上交换分区条目,换句话说,您将要访问的分区作为表中的第一个分区,Windows将允许您访问它(如果其格式是可以理解的,fat32和NTFS直接,ext2与特殊驱动程序等),但只会访问位于分区表的第一个条目的那个…有一个工具(称为BootICEx86.exe)可以在Windows上执行此类工作甚至不需要拔掉usb棒。

超级额外:还有一些pendrives(我很幸运拥有一个,索尼16GiB)比使用特殊工具(我的lexar工具)可以改变它所以他们看起来像Windows作为USB硬盘而不是USB棒在更改之后,所有窗口都会让你删除,创建和管理它上面的分区,同时也可以安装多个窗口,每个窗口都有自己的字母。

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

哦,是的,最后的段落是为了万一M $上的一个人阅读它们,所以他们的面孔下降到地板,我正在尝试(不会得到它,我知道这是一个失去的目标)他们要删除这样的来自Windows的丑陋代码,让用户在原生方式上拥有usb分区。