SRY*_*ZDN 43 fhs partition boot-loader
我正在阅读有关 Linux 分区和文件系统的相对较旧的文本（LPIC 1 Certification Bible）。它说：
某些版本的 Linux 引导加载程序无法访问磁盘上前 1024 个柱面之外的内核。通过将 /boot 分区放在驱动器的开头，您可以确保在启动时访问内核时不会出现问题。这个问题最常出现在双引导 Linux 以及第一个分区上的另一个操作系统的情况下。
为什么引导加载程序“无法访问磁盘上前 1024 个柱面之外的内核”？
另外，“将 /boot 分区放在驱动器的开头”是什么意思？
Gra*_*eme 37
这是由于拥有非常旧的 BIOS 和引导加载程序而不是 Linux 本身而造成的限制。BIOS 只能访问磁盘的前 1024 个柱面（有关柱面/磁头/扇区是什么的更多信息，请参见此处）。这种限制将扩展到引导加载程序，由于其简单的性质，它们没有自己的磁盘驱动程序，并且会使用 BIOS 服务来访问磁盘。
这意味着引导加载程序和内核（因为加载它是引导加载程序的工作）都必须在具有此限制的系统上的前 1024 个柱面内。一个简单的方法是创建一个/boot包含内核的单独分区，并将其放在驱动器的开头（通常只是将其设为第一个分区）。这意味着它会在物理上驻留在前 1024 个柱面中，当然前提是分区不是太大。
该限制不再是问题，因为它仅适用于旧的 BIOS。此外，许多现代引导加载程序（例如 GRUB）都有自己的磁盘驱动程序，因此不需要依赖 BIOS 服务。现代引导加载程序可能/boot用于其他目的，但不再需要在单独的分区上和前 1024 个柱面内（尽管在许多情况下需要/boot在单独的分区上）。
Gil*_*il' 26
/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为单独的分区是没有用的。但是它们影响了足够多的人，以至于大多数发行版都支持它。
mik*_*erv 19
启动……嗯……这真的是最难的部分。每次计算机启动时，它基本上都会重新认识自己。它熟悉它的各个部分，并且每遇到一个它就会获得能力。但是它必须通过自己的引导程序将自己拉起来，可以说，每次都从第一个开始。
在设计启动过程时，诀窍是分阶段启动机器。您的引导必须快速和可靠的，并且必须是两件事在完全陌生的环境，每一次。我什至不会冒险进入真实/受保护模式的对话（这并不是说我什至可以），但是启动时有很多事情要做。随着计算机每次以渐进的步骤同化它的各种组件。其中最关键的可能是从执行板载代码转移到执行磁盘代码，或者换句话说 - 内核执行。这是固件（表面上）向操作系统投降的时候。
许多年前，情况并非如此。它曾经是 BIOS 真正的基本输入/输出 - 常规程序会调用固件以进行诸如绘制屏幕和访问磁盘之类的事情。这些被称为中断——旧帽子可能最能记住它们，因为他们经常在为新的点阵或 USR 分配 IRQ 时感到兴奋。
它是BIOS 提供的中断（或INT汇编行话）13H系列函数作为磁盘访问服务。这些甚至今天仍然用于引导过程中的 BIOS 系统，以实现从固件到磁盘的跳转。
BIOS 系统将检查它找到的每个磁盘的前几个字节，并寻找它识别为主引导记录（或MBR）的模式。这是一个已有数十年历史的事实上的标准，包括一些写入磁盘磁头的原始可执行二进制文件。MBR 将 BIOS 磁盘标记为可引导。当它找到一个时，它会停止检查，所以实际上，如果没有一些聪明的技巧，你就会得到一个。当它确实找到一个时，它会将它映射到内存并执行它（在实模式下，但我仍然没有去那里）。
执行的 MBR 几乎肯定不是您的系统内核 - 512 字节（给予或接受）在该部门中将毫无用处。这可能是一个引导加载程序——一个专为克服BIOS 的许多寻址限制之一而设计的程序——特别是它根本不了解任何类型的文件系统。
当引导加载程序读入实际内核并在内存中执行它时（我们都祈祷每次都会这样做），它可能会通过INT13H中断调用询问 BIOS 来执行此操作。如果没有——许多更高级的引导加载程序会以传统的方式挂载文件系统并以另一种方式执行代码——那么引导加载程序在没有一INT13H两个的情况下变得如此花哨的可能性很小。通常引导加载程序必须自己链式加载 - 或者它们自己的各个阶段- 因为首先分配给它们的 512 字节甚至不适合它们的需要。
所有这些都是讨论磁盘的一种迂回方式，我知道，但此时应该非常清楚，主要问题 - 可以称之为鸡和蛋类型 - 是访问包含程序指令的磁盘关于如何访问磁盘。这个问题的关键是固件——即使在 EFI 系统上也仍然以非常不同的方式存在——而且，无论最弱与否，固件是引导链中最重要的环节。
您会看到，一旦内核执行，并且所有用于访问和控制硬件的无数例程启动，所有这些问题都会消失（或者至少有所改变），因为现代操作系统完全控制了系统，但在他们这样做之前，系统的限制只会扩展到固件允许的范围内。这说明了很多 - BIOS 自INT13H8086以来没有太大变化。调用的是 8086 原始版本。是的，当然有（无数）扩展和黑客攻击，但创新......？
对 BIOS 的大多数更改充其量只是绷带。它曾经是一个必须物理映射的硬盘——当数据存储到它或从中检索时，它的几何形状的各个和特定方面都会被引用。最终，传统硬盘增长到了禁止这种情况的大小。即使只是抽象映射，BIOS 也无法处理太多信息。由于它只能在实模式下运行，因此 BIOS 每个内存寄存器限制为 1 MB。将柱面图膨胀到任何更大的范围，或者使其任何一个属性大于可以在这么多位中寻址的范围，并且 BIOS 确实丢失了 - 超出了范围。
这个障碍已经得到满足，并打破许多倍。每次地图都以某种更新、聪明且不太准确的方式进行抽象和编码。所以现在，BIOS 几乎不可能准确地映射驱动器。逻辑块寻址现在是事实上的标准，尽管仍然需要一些柱面/磁头/扇区（或 CHS）转换。主板固件在准确性/责任方面的缺失，这些扩展已经抽象并添加到磁盘固件职责中以填补空白。
您的问题中提到了这个猫捉老鼠的游戏。当 BIOS 由于其庞大的大小而无法理解超过某个点的磁盘时，那么您可能希望它在启动时为您检索的任何数据 - 例如引导加载程序或内核 - 最好不要位于该点之外。这是从哪里来的/boot。
谢天谢地，如今这些事情都因 BIOS 的消亡而变得无关紧要。它已经 30 年了，但在过去几年中，它已在很大程度上被UEFI （或 EFI 2.0）标准所取代。UEFI从一分钟开始就提供一个挂载，它在保护模式下初始化，它包含自己的引导加载程序，它提供重启持久性闪存变量存储，它被规范为每个磁盘处理一些无数 zetabytes 或任何东西......等等别的。它远非完美，但与它的前身相比有了巨大的改进。
当您考虑到所有这些无论如何都必须由操作系统内核处理时，即使涉及磁盘加密或分层文件系统的专用引导加载程序的论点也无济于事，并且如果您在启动时提供了一个挂载，您总是很清楚-执行它（特别是考虑到 Linux 内核，在其默认配置下，是一个 EFI 可执行文件）。
因此，一个单独的/boot分区可能不会让您过分担心，如果您使用的是 EFI 系统，那么无论如何您可能已经在 EFI 系统分区中获得了一个模拟分区，因为这是启动 EFI 模式的要求。
有一个/boot目录是历史确定的，并从那里“固定”在Filesystem Hierarchy Standard 中。拥有这样的标准允许程序（和系统管理员）在某些位置期望某些文件。在这种情况下，与引导过程相关的文件。
/boot对于无法在可用驱动器的全部范围内索引块/扇区的较旧 BIOS 而言，在磁盘开头设置分区是有意义的。因此，应该加载的信息应该在一个可以被索引的扇区上，因此一个单独的分区（具有低扇区号），/bootBIOS 可以从中加载额外的数据/程序（反过来能够寻址完整的不使用 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 备份。看看跟踪内核是多么容易？（现在，所有备份都使用相同的内核）。
这不是 Linux 发行版的限制，而是旧 BIOS 的限制。在那个年代，为了确保 Linux 可以启动，所有与启动相关的文件都放在自己的分区中，该分区是硬盘驱动器上的第一个分区，以确保引导加载程序位于前 1024 个柱面内。创建一个小于 1024 个柱面（因硬盘驱动器而异）中的任何大小的分区。但是，如果您创建的第一个分区大于此边界，则引导加载程序文件有可能位于 1024 个柱面之外，并且 BIOS 将无法加载它们。
您也可以通过创建两个小分区来实现相同的效果，这两个分区都位于前 1024 个柱面内，并将所有引导加载程序文件放在第二个柱面中。
尽管在现代系统上，文件的扇区可以在磁盘上的任何位置访问，但将引导材料限制在它们自己的引导分区仍然是有意义的，仅仅从“不要把所有的鸡蛋放在一个篮子里”的原则出发。
假设主文件系统以某种方式损坏，以至于某些较低阶段的引导加载程序无法正确读取下一个阶段。如果引导加载程序材料在它们自己的分区中，那么内核可以通过 fsck 来正确处理损坏的根分区。它本身可以在它自己的分区中。
引导分区可以为您提供“救援”选项，例如安装替代的根分区。另外，如果您在不同分区中多重引导不同的操作系统怎么办？那么引导材料不属于这些系统中的任何一个。它有自己的分区是合理的。您可以用不同的操作系统替换任何操作系统分区，但能够引导剩余的操作系统。
另外，如果您想为引导加载程序根本不理解的主分区使用文件系统怎么办？或者，例如，引导加载程序端支持只是实验性的？在这种情况下，如果有扇区映射，引导时文件仍然可以使用（并且引导加载程序支持这样的事情：好的旧 Linux 引导加载程序 LILO 使用扇区映射，因此不必了解文件系统结构）。但是扇区图本质上是片状的。如果文件系统被重组，扇区会四处移动，因此扇区映射变得不正确，必须重新生成，否则系统无法重新启动。
最后，有一个组织原则，即使您没有实际的分区，所有引导内容至少都在/boot.
| 归档时间： |
|
| 查看次数： |
24561 次 |
| 最近记录： |