/ boot分区的真正作用是什么？

我正在阅读有关Linux分区和文件系统的相对较旧的文章（《LPIC 1认证圣经》）。它说：

某些版本的Linux引导加载程序无法访问磁盘上前1024个柱面之外的内核。通过将/ boot分区放在驱动器的开头，可以确保在引导时访问内核时不会出现问题。在双重引导Linux以及第一个分区上的另一个操作系统的情况下，此问题最容易显示。

为什么引导加载程序“ 在磁盘上的前1024个柱面之外无法访问内核 ”？

另外，“ 将/ boot分区放在驱动器的开头 ”是什么意思？

这是由于BIOS和引导加载程序非常旧而不是Linux本身而造成的限制。BIOS将只能访问磁盘的前1024个柱面（有关什么是柱面/磁头/扇区，请参见此处）。此限制将扩展到引导加载程序，由于其简单的性质，它们将没有自己的磁盘驱动程序，并会使用BIOS服务访问磁盘。

这意味着自举程序和内核（由于是自举程序的工作）都必须在具有此限制的系统上的前1024个柱面以内。一种简单的方法是创建一个/boot包含内核的单独分区，并将其放在驱动器的开头（通常只是将其设为第一个分区）。这意味着它将物理上驻留在前1024个柱面中，当然前提是该分区不会太大。

该限制不再是一个问题，因为它仅适用于旧的BIOS。同样，许多现代的引导加载程序（例如GRUB）都有自己的磁盘驱动程序，因此不需要依赖BIOS服务。现代的引导加载程序可以/boot用于其他目的，但是不再需要同时位于单独的分区和前1024个柱面内（尽管在许多情况下，必须具有/boot单独的分区）。

历史

/boot包含操作系统不使用的文件，而是操作系统的bootloader。您会找到引导加载程序本身的文件（例如，/boot/grub/*对于Grub而言）和Linux内核（/boot/vmlinuz*），并且常常会找到相关的initrd或initramfs。

在具有旧版BIOS的PC上（与在最新计算机上发现的较新UEFI相反），ROM中的软件将引导磁盘的前512个字节加载到内存（引导扇区）中。只有512个字节（并非所有字节甚至都包含代码：其中一些包含分区表之类的数据），这些代码不能做很多事情—那里没有真正的磁盘驱动器。在如此有限的空间内，所有可以做的就是使用BIOS接口加载更多代码。该接口提供了一个命令，用于在磁盘上加载第N个扇区-N的大小受到限制，因此只能以这种方式访问​​磁盘的开头。

在过去的三十年中，BIOS接口已经有所发展，但是其大小限制一直难以跟上磁盘大小，导致较旧的BIOS和引导加载程序的容量分别为32MB，512MB，2GB，8GB（可能还有）其他我不记得的阈值）。引导加载程序需要能够使用BIOS接口来加载直接访问磁盘驱动器所需的所有组件。引导加载程序通常并不包含用于所有磁盘控制器的驱动程序，因此，加载Linux内核（以及initrd / initramfs）之前的所有操作都必须使用BIOS接口，因此必须适合磁盘的开头。

请注意，这是BIOS或引导加载程序的限制，而不是Linux本身或发行版的限制。

/boot今天分开

在具有最新BIOS和最新引导程序的系统上，或者在具有UEFI的系统上，大小限制不再相关：磁盘大小现在需要很长时间才能赶上。但是，还有其他一些使单独的/boot分区有用的用例。它允许主系统位于引导加载程序不支持的RAID设备上，或者位于引导加载程序不支持的文件系统类型上。它允许主系统位于加密的设备上，Linux可以解密该设备，而引导加载程序则不能。

如果这些限制和用例都不适合您，那么将其保留/boot为单独的分区将无济于事。但是他们影响了足够的人，大多数发行人都支持它。

提到的BIOS问题旁边的另一个原因是，单独的/boot分区允许将文件系统用于/引导加载程序无法理解的卷（而不是像那样仅限于阻止列表加载lilo）。

射门很难

引导...好吧...这确实是最难的部分。每次启动计算机时，它基本上都会重新适应。它熟悉其各个部分，并且满足每个部分都具有功能。但可以说，它每次都要从自己的引导程序中拉起自己。

在设计启动过程时，技巧是逐步启动计算机。您的启动必须快速且可靠，并且每次都必须处于完全未知的环境中。我什至不会冒险进行实模式/保护模式的对话（这并不是说我什至可以），但是启动时还有很多事情要做。每次计算机将其各种组件同化时，它就会分步进行。其中最关键的一点可能是从执行板载代码到执行磁盘上代码，换句话说，就是内核exec。这是固件（表面上）投降到操作系统的时间。

很多年前情况并非如此。它曾经是BIOS，实际上是Basic In / Out（基本输入/输出）-常规程序会调用固件来进行诸如绘制屏幕和访问磁盘之类的操作。这些被称为中断 -旧帽子可能会为他们为新的点矩阵或USR分配IRQ时经常发现的快感而记住得最好。

INT13H

BIOS作为磁盘访问服务提供的是中断（或称为INT汇编语言）13H系列功能。今天，它们甚至在引导过程中仍用于BIOS系统，以实现从固件到磁盘的跳转。

BIOS系统将检查找到的每个磁盘的前几个字节，并寻找它识别为主引导记录（或MBR）的模式。这是已有数十年历史的事实上的标准，包括一些写入磁盘头的原始可执行二进制文件。MBR将BIOS磁盘标记为可引导。当找到一个时，它将停止检查，因此实际上，您所获得的就是没有一些狡猾的诡计。当它找到一个时，它将其映射到内存并执行它（在实模式下，但我仍然不去那里）。

执行的MBR几乎绝对不是您的系统内核- 在该部门中512字节（给定或获取）将毫无用处。这可能是一个引导加载程序 -一种专门为克服BIOS许多寻址限制之一而设计的程序-特别是它根本不了解任何类型的文件系统。

当引导加载程序读入实际内核并在内存中执行它时（正如我们所有人每次祈祷的那样），引导加载程序可能会通过INT13H中断调用来询问BIOS 。如果不是这样，那么许多高级引导加载程序都将以传统的方式挂载文件系统并以另一种方式执行代码-那么，如果没有一INT13H两个引导加载程序的话，这种引导加载程序的可能性就很小。引导加载程序通常必须对自身（或自身的各个阶段）进行链加载，因为首先分配给它们的512字节甚至不适合其需求。

鸡肉和鸡蛋

我知道，所有这些都是讨论磁盘的一种round回方式，但是到此为止，应该已经很清楚地认识到，主要问题（可能称为“ 鸡与蛋”类型）正在访问包含程序指令的磁盘。关于如何访问磁盘。解决此问题的关键是固件 -甚至在EFI系统上固件也将以截然不同的方式存在-固件是否是引导链中最重要的环节，无论是否脆弱。

您会看到，一旦内核执行完毕，并且启动了用于访问和控制硬件的所有无数例程，所有这些问题都会消失（或者至少会有所改变），因为现代OS可以完全控制系统，但是直到它们执行该操作为止，系统的限制才扩展到固件允许的范围。这说明了很多-自INT13H8086 以来，BIOS并没有太大变化。该调用是8086的原始版本。是的，有（无数）种扩展，当然还有hack，但是创新……？

越来越好

BIOS的大多数更改充其量只是绷带。它曾经是一个硬盘，必须进行物理映射- 在将数据存储到其中或从中检索数据时，会参考其几何结构的各个方面。最终，常规硬盘的大小增长到了无法承受的程度。甚至只是抽象映射对于BIOS 来说也包含太多信息。由于它只能在实模式下运行，因此每个内存寄存器的BIOS限制为1 MB。膨胀柱形图要大得多，或者使它的任何一个属性都比可以解决的位数大很多，BIOS就会字面上丢失-越界。

这个障碍已经被克服和打破了很多次。每次地图以某种更新，聪明，不太准确的方式进行抽象和编码时。因此，如今，BIOS实际上不可能精确地映射驱动器。现在，逻辑块寻址已成为事实上的标准，尽管某些圆柱体/头部/扇区（或CHS）转换仍然是必需的。主板固件失去了准确性/责任感，这些扩展已经抽象化并添加到磁盘固件职责中以填补空白。

您的问题中引用的就是这种猫猫游戏。当BIOS由于其绝对大小而无法理解某个点之外的磁盘时，那么您可能希望其在引导时为您检索的任何数据（如引导加载程序或内核）最好不要位于该点之外。这是哪里/boot来的。

可能实际上更好

幸运的是，这些天来这些事情与BIOS的淘汰无关。它已经过去了30年，但在过去几年中已被UEFI （或EFI 2.0）标准大大取代。UEFI 从一开始就提供挂载，它在保护模式下初始化，它结合了自己的引导加载程序，它提供了可重新启动的持久性闪存变量存储，它可以处理一些zetabyte或每个磁盘的内容……其他。它远非完美，但相对于其前身而言是一个巨大的改进。

当您考虑到所有这些都必须由OS内核来处理时，甚至涉及磁盘加密或分层文件系统的专用引导程序的参数也变得平坦，并且如果在引导时提供了挂载，则您总是很清楚-着手执行（特别是考虑到Linux内核，在其默认配置下，其自身是EFI可执行的）。

因此，一个单独的/boot分区可能不会引起您的过多关注，如果您使用的是EFI系统，则无论如何，您可能已经在EFI系统分区中有了一个模拟，因为这是引导EFI模式的必要条件。

/boot历史上确定存在目录，然后从那里“固定” 文件系统层次结构标准。拥有这样的标准允许程序（和系统管理员）在某些位置期望某些文件。在这种情况下，与引导过程关联的文件。

在/boot较早的BIOS上，在光盘的开头有一个分区很有意义，因为这些BIOS无法索引可用驱动器的全部范围内的块/扇区。因此，应该加载的信息应该位于可以索引的扇区上，因此/boot，BIOS可以从其上加载其他数据/程序的单独分区（具有较低的扇区号）（进而可以处理全部数据/程序）。光盘范围而不使用BIOS）。

拥有一个单独的/ boot分区也可能非常有序。在我的机器上，我有许多发行版和备份，每个发行版和备份都在各自的分区中，但是它们共享相同的/ boot分区，所有操作系统的所有内核都驻留在该分区中。另外，所有发行版都指向我的一个唯一的lilo.conf副本，该副本也位于/ boot中，因此，我不必猜测添加内核，添加发行版时的情况。这是我的lilo.conf中的一个片段：

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y5--5-Debian1"
label  = y5:D1:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y8--5-Debian2"
label  = y8:D2:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=y11-5-Debian3"
label  = y11:D3:16.0-4

image  = /boot/vmlinuz-3.16.0-4-686-pae
initrd = /boot/initrd.img-3.16.0-4-686-pae
root   = "LABEL=w5--5-Debian1"
label  = w5:D1:16.0-4

...这只是我在两张磁盘上的Debian备份。看到跟踪内核有多么容易？（现在，所有备份都使用相同的内核）。

尽管在现代系统上，可以在磁盘上的任何位置访问文件的扇区，但仅出于“不要将所有鸡蛋都放在一个篮子里”的原理，将引导材料限制在它们自己的引导分区中还是有意义的。

假设主文件系统已损坏，导致某些较低级的引导加载程序无法正确读取下一级。如果引导加载程序材料位于它们自己的分区中，则内核可以启动并通过fsck正确处理损坏的根分区。那本身可以在自己的分区中。

引导分区可以为您提供“救援”的选项，例如安装备用根分区。另外，如果您在不同分区中多次引导不同的操作系统怎么办？然后，引导材料不属于这些系统中的任何一个。拥有自己的分区是合理的。您可以用其他操作系统替换任何操作系统分区，但仍可以引导其余的操作系统。

另外，如果您想对引导加载程序根本无法理解的主分区使用文件系统，该怎么办？或者说，引导加载程序侧的支持仅是实验性的？在这种情况下，如果存在扇区映射，则仍可以使用引导时文件（并且引导加载程序支持这样的事情：老式的Linux引导加载程序LILO使用了扇区映射，因此不必了解文件系统结构）。但是，部门地图天生就不稳定。如果重组了文件系统，则扇区将四处移动，因此扇区映射将变得不正确，必须重新生成，否则系统将无法重新引导。

最后，有一个组织原则，即使您没有实际的分区，所有引导内容至少都位于/boot，而不是分散在其他任何地方，这仍然是一个好主意。

这不是Linux发行版的限制，而是旧版BIOS的限制。那时，为了确保Linux可以启动，所有与启动相关的文件都放置在自己的分区中，该分区成为硬盘驱动器上的第一个分区，以确保启动加载程序位于前1024个柱面中。创建一个小于在1024个柱面中发现的任何大小的分区（因硬盘而异）。但是，如果创建的第一个分区大于此边界，则引导加载程序文件可能位于1024个柱面之外，BIOS则无法加载它们。

您还可以通过创建两个小分区来实现相同的效果，这两个小分区都位于前1024个柱面中，并将所有引导加载程序文件放在第二个中。

这些天进行引导分区的另一个原因是：

• 从NFS或NBD引导
• 加密的根分区
• / boot共享不同的发行版