我有一个内置硬盘，/dev/sda如下所示：
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders, total 312581808 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00042134
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 293048319 146523136 83 Linux
/dev/sda2 293050366 312580095 9764865 5 Extended
/dev/sda5 293050368 312580095 9764864 82 Linux swap / Solaris
现在我可以很容易地找到MBR xxd /dev/sda | less，它位于第一个扇区。根据维基百科在我的例子中，VBR 必须位于第一个可启动分区的第一个扇区中/dev/sda1。但在第一个扇区中，/dev/sda1当我执行 时，我只看到零xxd /dev/sda1 | less。
我其实想在那里找到GRUB的二进制代码，那它会在哪里呢？
答案1
它通常不安装在那里。大多数时候，GRUB（第一阶段）安装在 MBR 中仅有的，在 Linux 上。
虽然 GRUB 版本 1 总是会在 MBR（阶段 1.5，即文件系统驱动程序）之后的 30 kB 中稍微溢出，但是对于 GRUB 版本 2，安装在 MBR 中的代码可以通过原始读取加载一些其他更大的代码（阶段 1.5）磁盘中的任何扇区（但通常会遵循 GRUB 1 行为——即从 MBR 之后的 30 kB 加载代码）。
这 30 kB 通常是可用的未分区“空闲”磁盘空间，因为历史原因磁盘的第一个分区在扇区 63 之前启动的情况非常罕见，这在 MBR 之后至少留下 512*62 = 31 kiB。
然后，它通常从 加载一些文件，/boot例如菜单（menu.lst或grub.cfg）、更多文件系统驱动程序等。这是阶段 2。
之后，就足以启动操作系统了。
至于现在的VBR， 它在Linux分区上不常用，因为它不够可靠，但 MS Windows 通常将其安装在系统 (C:\) 分区的开头。如果你想启动 Windows，GRUB 就会执行它。这个过程称为链式加载：一个引导加载程序启动另一个引导加载程序。这也意味着那里使用的文件系统必须保持分区的开头不变，因为否则可能会覆盖 VBR！可用的“未触及”空间量取决于文件系统，因此没有很好的保证：它很可能非常小......
关于从“不寻常”的地方加载阶段 1.5正如我所说，GRUB 2 可以从磁盘上的任何扇区加载其阶段 1.5。它可能来自一个文件，但这可能很危险，因为文件系统可以决定随时将该文件移动到磁盘上的其他扇区（或者更糟糕的是，将其碎片化！），并且 GRUB 需要更新文件中的新扇区号。每次MBR...
一个有趣的案例是GUID 分区表（GPT）。它们太大，无法确保始终有足够的空间 (30 kB) 可用于阶段 1.5。在这种情况下，推荐的解决方案是使用专用的“引导加载程序分区”（这不是问题，因为 GPT 可以支持 128 个分区），该分区不会托管文件系统，而是托管 GRUB 的第 1.5 阶段数据。这样，它就不会移动，你可以给它足够的空间。
你真的应该阅读维基百科的 GRUB 文章我从哪里获得了大部分信息。
答案2
实际上GRUB2通常不会安装到VBR。它建议反对这种做法。
这就像没有足够的空间来捆绑 /boot 的文件系统模块。从历史上看，MBR 磁盘为此类引导代码提供了 62 个“保留”扇区。 （因为第一个分区从柱面边界开始。现在我们忽略柱面，但它与整个兆字节对齐，以支持 4K 扇区驱动器，帮助 SSD/RAID 等）。您无法从 VBR 获得如此好的保证。
GRUB2 给您的消息解释了 VBR（分区）安装必须依赖于保存模块（例如文件系统驱动程序）的块号。这不太可靠；这意味着grub有当这些模块文件更新时要重新安装。