我一直在阅读有关Grub传统启动加载程序的信息。令我印象深刻的是Grub如何处理文件系统。 Grub支持大量文件系统。 我怀疑的是，Grub如何识别这些文件系统？ 即使他们被认可，他们是如何处理的？像每个文件系统都有自己的实现。 Grub是否从磁盘加载运行时库？
我知道这个问题太宽泛了。但请给我一些启动的提示。
感谢。
答案 0 :(得分：4)
典型的设置是GRUB阶段1（1扇区二进制）知道阶段2的位置并加载它。此位置通过安装命令（setup或install）写入阶段1。 （更准确地说，第2阶段文件的开始用其他文件部分的物理位置列表更新;第1阶段加载第2阶段的起始扇区，第2阶段继续第2阶段的其余部分的引导。）如果阶段1不是通过真实的第2阶段设置更新，它预计在第1阶段后的扇区中的第2阶段（例如GRUB软盘的变体）。
加载第2阶段后，它可以执行以下所有操作。第2阶段为所有支持的FS嵌入一组只读驱动程序;这些驱动程序比全功能驱动程序小得多。安装过程还包括启动驱动器和分区到第2阶段的编码，因此，在启动后它知道在哪里可以找到有效配置（此版本为[/boot]/grub/menu.lst）。突然，FS类型未在第2阶段配置aread中编码。 FS类型的检测在*_mount()函数（文件集stage2/fsys_*.c）中完成;每个人都尽力检测它是否适合它，包括签名检查和分区表中的分区类型检查。我不知道为什么选择这种风格，但似乎他们期望FS类型检测能够稳定。
由于第2阶段已加载，通过适当的内部配置（设备，分区）并打开其FS，它可以加载菜单并继续使用更高级别的逻辑。
（此描述不包括stage1.5，因为后者在相当具体的情况下使用。）
所以，回答你的具体问题，
Grub如何识别这些文件系统？
两者都有签名和分区类型（DOS，BSD ......）
Grub是否从磁盘加载运行时库？
不，它使用自己的只读驱动程序。
但请给我一些启动的提示。
如果您可以阅读C，最好的方法是克隆其repository，结帐grub-legacy分支并阅读其来源。
答案 1 :(得分：2)
FS检测：分区的前4B中的幻数，或类似的签名检测，我假设。
FS处理：
stage1加载嵌入在分区表和第一个分区的开头之间的空间中的stage1.5。这包含至少包含/boot的文件系统的只读驱动程序，它可以从中加载stage2。
如果没有舞台1.5的空间，你就会陷入嵌入整个舞台2的扇区地址，就像Netch描述的那样。这可以在升级到GRUB时更改，或者只是复制/ boot中的文件，因此不是首选。
Grub Wikipedia文章描述了the operation of 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文件 ：读取/启动所需的文件是通过grub-install嵌入的。