Linux如何处理单独的/ boot分区？
Answers:
这是您所理解的问题：
我的理解是，引导加载程序GRUB2已安装到/ boot。
GRUB在启动时未“挂载”。GRUB已安装到/boot，并从主引导记录中的代码加载。这是现代启动过程的简化概述，假定使用带有MBR / BIOS（而不是GPT / UEFI）的GNU / Linux发行版：
- BIOS加载。
- BIOS加载主引导记录中的一小段代码。
- GRUB不能容纳440字节，即主引导记录的大小。因此，加载的代码实际上只是解析分区表，找到
/boot分区（我相信是在将GRUB安装到主引导记录时确定的），并解析文件系统信息。然后加载第二阶段GRUB。（这是简化的地方。） - 第2阶段GRUB加载所需的一切，包括GRUB配置，然后显示一个菜单（或不显示，取决于用户配置）。
- 选择启动顺序。这可能是由于超时，用户选择菜单项或引导命令列表引起的。
- 引导顺序开始执行。这可以做很多事情-例如，加载内核，链式加载到另一个引导程序-但让我们假设引导顺序是标准的GNU / Linux。
- GRUB加载Linux内核。
- GRUB加载初始ramdisk。
- 初始ramdisk挂载
/在其下方/new_root（可能以加密方式对其进行解锁），启动udev，启动“从交换中恢复”等。 - 初始ramdisk使用该
pivot_root实用程序将其设置/new_root为real/。 init开始。挂载分区，启动守护程序，并引导系统。
注意如何仅在步骤7加载内核。因此，直到步骤7才有安装的概念。这就是为什么/boot即使GRUB已经使用它，也必须在步骤9中再次安装它的原因。
run-init删除initramfs中的所有文件，然后将chroots放入根文件系统。
UEFI越来越受欢迎；-) @strugee
问题1
我的理解是，引导加载程序GRUB2已安装到/ boot。但是，当目录/ boot位于单独的分区sda2上时，在/实际挂载之前如何发生呢？
我认为您的理解不完全正确。从GNU GRUB Wikipedia页面：
摘抄
开启计算机后，计算机的BIOS将找到配置的主要可引导设备（通常是计算机的硬盘），并从主引导记录（MBR）中加载并执行初始引导程序。MBR是硬盘的第一个扇区，其编号为0（扇区计数从0开始）。长期以来，一个扇区的大小一直为512字节，但是自2009年以来，已经有扇区大小为4096字节的硬盘可用，称为高级格式磁盘。截至2013年10月，仍通过512e仿真在512字节扇区中访问此类硬盘。
在GRUB版本2中，发生以下情况：
摘抄
引导计算机
打开电源后，将发生以下情况：
- 硬件初始化，将CPU设置为实模式（无虚拟内存），然后跳转到固定位置0xFFFF0（在CPU电路中进行硬接线）
- 因此，将执行存储在映射到该位置的ROM或闪存中的BIOS代码。
- BIOS代码查看BIOS配置数据以查看哪个是引导设备。通常，在接通电源后，只需按一些特殊的按键顺序即可编辑BIOS配置数据，从而使BIOS配置程序运行。除其他事项外，通常可以在此处选择启动设备。
- BIOS代码将引导设备的MBR加载到RAM中。请记住，MBR仅为512字节！加载的数据当然是grub-install动态创建并在执行grub-install程序时写入其中的程序和数据。
- BIOS代码跳到加载的MBR的起始地址（即，自上电以来首次执行Grub代码）。
- Grub的MBR代码加载单个扇区，其地址被硬连线到MBR块中。然后，它在该扇区中的（地址，len）对上循环，将磁盘中的所有数据加载到内存中（即，加载文件
/boot/grub/core.img或其“嵌入”副本的内容）。然后，MBR代码跳至已加载的代码，即“执行”中的程序core.img。- 如“安装Grub”部分中所述，这种嵌入原始磁盘块地址的技巧使得可以将存储
core.img空间存储在分区之外的空间中，而该空间从未被格式化为文件系统（“嵌入”）。并且在这种情况下，如果对其core.img进行了修改，只要新版本被“嵌入”在同一位置，则不需要更新MBR代码。- 或者，也可以
core.img将其放在真实的文件系统中，并且Grub可以在core.img没有该文件系统驱动程序的情况下读取文件内容。但是，在这种情况下，如果对其core.img进行了修改，则很可能会在磁盘上为文件的第一个块赋予一个新地址；如果发生这种情况，则必须更新MBR以指向该新位置。但是，core.img通常通过运行grub-install进行更新，这通常不是问题。- 请注意，从理论上讲，如果
core.img与MBR使用的设备不在同一设备上，并且添加了新硬件，则Grub生成的MBR记录可能无法正确加载core.img文件；将在其上找到第一个扇区的设备IDcore.img硬连线到MBR中，而不进行搜索。但是，对此没有解决方案。无法将等效的Grub“搜索”命令嵌入到512字节的MBR中。但是，这个问题不太可能发生。通常，core.img它们与MBR嵌入在同一设备上。并且一旦core.img加载，它就可以使用search.mod查找所有其他/boot/grub文件，因此可以避免硬件重新安排。core.img现在，已执行的代码将初始化内置在其中的所有模块（链接到core.img）；这些模块之一是文件系统驱动程序，能够读取目录/boot/grub所在的文件系统。- 它还注册了一组内置命令：set，unset，ls，insmod。
- 如果已将“配置文件”链接到
core.img，则将其传递到一个非常简单的内置脚本解析器进行处理。配置文件中的脚本命令只能调用内置或链接的命令。简单的场景（例如，从本地驱动器启动典型的台式计算机）不需要配置文件；此功能用于通过pxe，远程nfs引导或在/boot/grubLVM设备上引导时。Core.img现在“/boot/grub/normal.mod”从磁盘动态加载文件，并跳转到其输入功能。请注意，此步骤需要设置适当的文件系统驱动程序（即内置的）。
注意：当您看到典型的GRUB2菜单，从中选择要引导的OS /内核时，此时您正在引用系统/boot/grub目录。
参考文献
Linux（内核）不在乎您有多少引导分区。从磁盘加载内核是引导加载程序（例如grub，）的工作grub2，lilo并且这些工具也不关心内核可能位于的位置数量。他们只关心特定的位置。
例如，我的引导分区是/dev/md1，这是由物理分区/dev/sde1和支持的mdadm RAID镜像/dev/sdf1。如果需要，我可以单独安装它们，因此从技术上讲，这应该算是具有两个引导分区，尽管它们应该包含相同的数据。
对我来说/ boot有两个分区是一个可用性问题，但它们可能同样是/ boot分区。下一步是引导程序如何知道？方法如下：
menuentry 'Linux 3.10.17 (sde) kernel-3.10.17-g' {
root=hd0,1
linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
initrd /boot/initrd-3.10.17-g
}
menuentry 'Linux 3.10.17 (sdf) kernel-3.10.17-g' {
root=hd1,1
linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
initrd /boot/initrd-3.10.17-g
}
这是从grub2配置中摘录的内容，您会注意到，唯一的区别是root=hd0,1和root=hd1,1哪个确定了该条目引用的引导分区。
现在引导您穿靴子，这样您就可以了解这里发生了什么。
- BIOS从引导卷中读取MBR并跳转到引导加载程序
- 引导加载程序（例如
grub2）配置为知道哪个设备和分区包含您的内核。Grub2直接访问该分区并将内核加载到内存中。 - 然后，引导程序会跳入内核，内核会引导您的计算机。
引导加载程序并不关心您有多少个引导分区，它只关心它们所在的位置，您必须告知该信息。
内核并不在乎您有多少启动分区，因为它根本不需要查看它们（例如，您只需要使其可用即可添加新内核）。
/boot不是指根分区上安装的目录吗？