> AIUI, the root of the problem is that stage1 doesn't have enough space to encode a filesystem driver to actually properly find the file on an FS; that's what

> AIUI, the root of the problem is that stage1 doesn't have enough space to encode a filesystem driver to actually properly find the file on an FS; that's what stage2 is. There is more than enough space to encode an EXT2 driver in a boot sector (and if you really push it, you can even parse a simple ELF file as well). You can only really fit a single filesystem driver in the boot sector though, and for something more complex than EXT2, even this can be tricky to fit in. The trouble is that GRUB supports multiple file systems, and doesn't maintain a separate boot sector for each one, so instead came up with the Stage 1.5 approach. If Stage 1.5 is installed between the MBR and first partition, then GRUB loads that and jumps to it. Stage 1.5 contains a proper filesystem driver that it then uses to load Stage 2. Stage 1.5 doesn't have the size limitations of the MBR. If Stage 1.5 is not installed, for example if the first partition starts immediately after the MBR, then, and only then, GRUB falls back to using a hard coded list of sectors. On BIOS/GPT based systems, IIRC GRUB2 uses a partition type called BIOS Boot Partition to store its equivalent to Stage 1.5/2 (I'm calling it a mix of 1.5/2, as GRUB2 also loads modules from the filesystem where it's stored as part of the boot process). > The problem today is obviated by GPT & EFI. Yep, UEFI makes things pretty convenient for the OS developer! When writing a bootloader these days you don't even need to write a filesystem driver if your kernel is stored on the EFI partition. You can just use SimpleFileSystemProtocol to load it into memory.