3 ms·

> (lots of text about stage2 and the "first track") stage2 has to naturally follow the MBR; there's … nowhere else to put it, really. IIRC … and this seems to

> (lots of text about stage2 and the "first track") stage2 has to naturally follow the MBR; there's … nowhere else to put it, really. IIRC … and this seems to be what the article is advocating … there was some idiocy where some people would put the sector number of where stage2 was inside an ext2fs or so. This requires several things that ext2 (nor really any FS guarantees): that the file is contiguous, and that its data is pinned to that physical on-disk location. 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. Adding it in the gap between the MBR & the first partition is an easy enough solution. It then isn't in any FS, and so cannot be inadvertently moved accidentally. The problem today is obviated by GPT & EFI.

chungy 3y ago
GRUB2 combined with GPT made this whole thing way better. You make a partition with a certain type (0xef02 in gdisk's shortened codes) and that's where the GRUB stage2 code goes; the stage1 finds the partition and loads it. It certainly eases my mind of "well, let's hope nothing decides to overwrite this 'unused' part of disk".
messe 3y ago
> 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.
- nicman23 3y ago
  i wish uefi had ext2-4 built in and did not require vfat
garaetjjte 3y ago
Why not put stage2 into its own separate partition? Though probably it wasn't done because of only 4 partition limit.

chungy 3y ago

GRUB2 combined with GPT made this whole thing way better. You make a partition with a certain type (0xef02 in gdisk's shortened codes) and that's where the GRUB stage2 code goes; the stage1 finds the partition and loads it. It certainly eases my mind of "well, let's hope nothing decides to overwrite this 'unused' part of disk".

messe 3y ago

> 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.

nicman23 3y ago
i wish uefi had ext2-4 built in and did not require vfat

garaetjjte 3y ago

Why not put stage2 into its own separate partition? Though probably it wasn't done because of only 4 partition limit.