在哪里可以找到 /dev/sda1 分区上的 VBR？

Question

我有一个内置硬盘/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 的二进制代码，那会在哪里呢？

Answer 1

它通常不会安装在那里。大多数时候，GRUB（阶段1）被安装在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 的 stage 1.5 数据。这样，它就不会移动了，你可以给它足够的空间。

你真的应该阅读维基百科的 GRUB 文章，我在那里得到了大部分信息。

Answer 2

实际上，GRUB2 通常不会安装到 VBR。它建议反对这种做法。

就像那里没有足够的空间来为 /boot 捆绑文件系统模块。从历史上看，MBR 磁盘为此类引导代码提供 62 个“保留”扇区。（因为第一个分区从柱面边界开始。现在我们忽略柱面，但它会对齐到整兆字节，以支持 4K 扇区驱动器，帮助 SSD / RAID 等）。您无法从 VBR 获得如此好的保证。

GRUB2 给您的消息解释了 VBR（分区）安装必须依赖于保存模块的块号，例如文件系统驱动程序。这不太可靠；这意味着GRUB有当这些模块文件被更新，重新安装。