我一直在阅读关于Grub遗留引导加载程序的文章。让我印象深刻的是Grub处理文件系统的方式。Grub支持大量的文件系统子集。我的疑问是，Grub如何识别这些文件系统?即使它们被识别，它们是如何被处理的?每个文件系统都有自己的实现。Grub是否从磁盘加载运行时库?
我知道这个问题太宽泛了。但请给我一些建议，让我开始吧。谢谢。
典型的设置是GRUB阶段1(它是1扇区二进制)知道阶段2的位置并加载它。这个位置通过安装命令(setup或install)写入到阶段1。(更准确地说，第2阶段文件的开始被更新为其他文件部件的物理位置列表;阶段1加载阶段2的起始扇区，阶段2继续此引导与阶段2的其余部分。如果阶段1没有使用实际的阶段2设置进行更新，它将在阶段1之后的扇区中预期阶段2(例如GRUB磁盘的变体)。
一旦加载stage 2，它就可以执行以下所有操作。阶段2为所有支持的fse嵌入一组只读驱动程序;这样的驱动程序比全功能驱动程序小得多。安装过程还包括将引导驱动器和分区编码到阶段2，因此，在引导后，它知道在哪里可以找到有效的配置(此版本的[/boot]/grub/menu.lst)。突然间，FS类型没有在stage 2配置区编码。FS类型检测在*_mount()函数(文件集stage2/fsys_*.c)中完成;每个分区都尽力检测它是否适合自己，包括分区表中的签名检查和分区类型检查。我不知道为什么选择这种风格，但似乎他们希望FS型检测是岩石稳定的。
由于阶段2已加载，并提供了适当的内部配置(设备，分区)并打开了其FS，因此它能够加载菜单并继续执行更高级别的逻辑。
(此描述不包括stage1.5，因为后者在相当特定的情况下使用)
那么，回答你的具体问题，
Grub如何识别这些文件系统?
签名和分区类型(DOS, BSD…)
Grub是否从磁盘加载运行库?
不，它使用自己的只读驱动。
但是请给我一些建议让我开始。
如果你能读C，最好的方法是克隆它的存储库，签出grub-legacy分支并读它的源代码。
FS检测:分区前4B的幻数，或者类似的签名检测，我想。
FS处理:Stage1加载嵌入在分区表和第一个分区开始处之间的空间中的stage1.5。这包含一个只读驱动程序，用于至少包含/boot的文件系统，它可以从。
如果没有一个stage1.5的空间，你就会被困在嵌入整个stage2的扇区地址，就像Netch描述的那样。这可能会在升级到GRUB时发生变化，或者只是复制/boot中的文件，因此不建议这样做。
Grub Wikipedia文章描述了Grub -legacy的操作，它可能也记录在Grub -legacy文档中。
在我还在用的一台老式Debian机器上，它启动GRUB 0.97, /boot/grub包含:
-rw-r--r-- 1 root root 197 2008-08-29 23:57 default
-rw-r--r-- 1 root root 46 2008-08-29 23:57 device.map
-rw-r--r-- 1 root root 31 2008-08-29 23:57 device.map~
-rw-r--r-- 1 root root 7552 2008-08-29 23:57 e2fs_stage1_5
-rw-r--r-- 1 root root 7424 2008-08-29 23:57 fat_stage1_5
-rw-r--r-- 1 root root 8192 2008-08-29 23:57 jfs_stage1_5
-rw-r--r-- 1 root root 3377 2012-04-19 20:41 menu.lst
-rw-r--r-- 1 root root 3377 2012-04-19 20:41 menu.lst~
-rw-r--r-- 1 root root 6848 2008-08-29 23:57 minix_stage1_5
-rw-r--r-- 1 root root 9248 2008-08-29 23:57 reiserfs_stage1_5
-rw-r--r-- 1 root root 512 2008-08-29 23:57 stage1
-rw-r--r-- 1 root root 108328 2008-08-29 23:57 stage2
-rw-r--r-- 1 root root 8872 2008-08-29 23:57 xfs_stage1_5
fs特定的stage1_5文件不是在引导时从那里读取的:需要读取/boot的文件由grub-install嵌入。