> (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.
> 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.
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".
GRUB2 has some similarities but I still preferred to use the Stage 1 sector as a "downstream" VBR rather than MBR. I wanted to keep the original DOS or Windows MBR in place on sector 0, since it reliably jumps to the VBR ("boot sector") of whichever primary partition is marked Active at the time.
Each of the partitions can then contain a different OS completely independently, accessible from any bootmenu you "install" to any of the possible primary partitions. Or even on the primary partitions you could just put the OS's alone without any boot files, like is done on the logical (non-primary) partitions, in that case the boot loader, boot files, and boot menu themselves could be on a separate drive like a floppy.
Using GRUB Stage 1 as an MBR was mainly for overcoming difficulties when wrestling absolute boot control from a DOS-based PC since the standard DOS/Windows MBR jumped directly to the active partition's VBR and a DOS/Windows9x VBR would not boot Linux.
Alternatively with an NT5 VBR/bootloader you can boot Linux since you have boot.ini and other than booting directly to an NT5 system, you can configure boot.ini to jump to a file on a FAT or NTFS filesystem and the file can be a copy of a DOS VBR (usually named bootsect.dos), which would then allow an NT system to boot back to DOS or W9x residing on a FAT filesystem somewhere accessible. Then when Grub Stage 1 (or more) is present on the FAT or NTFS filesystem in the form of a file itself (call it bootsect.lin) it could be put on the boot.ini bootmenu right next to the DOS & NT(ARC) boot options, and it boots Linux from the partition having the grub VBR which had been captured as bootsect.lin.
Grub Stage 1 either proceeds to the very next sector or jumps directly to the defined location of its next stage and then proceeds until it displays (or not if there is not more than one OS) its routine bootmenu showing the OS's that it has been configured to boot from using the particular grub.cfg file being accessed at the time.
Up until UEFI you have been able to boot Linux from an NT bootloader, even up to Windows 10 when it's installed on an MBR/BIOS HDD layout, so I preferred to use a Windows bootloader for everything. Now with the UEFI/GPT approach the NT6 bootloader will not boot Linux so something other than Windows (like GRUB2) needs to be the bootloader which can boot Linux as well as Windows.
Similarly, the kernel of Xenix used letters A to Z to indicate which stage of the initialization it had reached: https://www.scosales.com/ta/kb/105420.html
Helpful for debugging issues.
If you don't multi-boot it is generally easier to use efistub. As long as you put your kernel image in the same place you just need to add an UEFI boot entry once and that's it.
What I like about Refind is that it tries to actively scan for bootable systems. So if I slide in a bootable flash drive, I get a new icon I can select, rather than having to mash keys to get into the setup program and bypass the default boot order.
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.