I've been reading the GRUB2 manual in an attempt to understand GRUB better, but it seems to contain some contradictions.

My understanding is that the MBR of a DOS disk consists of 1 sector (512 bytes) and that it contains the partition table and some space at the end, which is where the bootloader goes. The need to reserve space for the bootloader explains why the partition table can't contain more than 4 entries.

Now the GRUB manual (in the section called "Bios Boot") says that the first stage of GRUB does not go into the MBR itself but is embedded in the area between the MBR and the beginning of the first partition, called by various names, such as the "boot track", "MBR gap", or "embedding area", and which is usually at least 31 KiB in size and often much larger.

Yet further down, under "Grub Images", it says that the first stage (called boot.img) "is written to the master boot record (MBR) or to the boot sector of a partition. Because a PC boot sector is 512 bytes, the size of this image is exactly 512 bytes."

If that were true, GRUB would overwrite the partition table. And in any case it contradicts what is written earlier.

Can anyone explain this to me?

MBR is 446 bytes, rest is partition table. Stage 1.5 goes to empty space before first partition, if it is needed at all.

I think stage 1.5 is part of GRUB-legacy, not GRUB2. GRUB2 has boot.img, which goes into (or maybe just after) the MBR, and core.img, which is the actual grub kernel and goes in /boot/grub. Apparently boot.img has the physical address of core.img coded into it, much like LILO has the physical addresses of the Linux kernels it needs to boot. But I still can't see where boot.img actually goes. Or how the MBR has room for a 512-byte core.img and a partition table.

I'm giving up. I do not like Grub2, I do not need Grub2, I do not use Grub2. Period.

I've never really seen this adequately explained, at least to my understanding. Since the space for boot code in the MBR is only 64 bytes and the Grub Legacy stage 1 file and the Grub2 boot.img file are both exactly 512 bytes, that won't work. I think you're probably right about these files being in sectors immediately after the MBR. The link below has a fairly decent description of this if you scroll down to a section headed 'Grub' although it doesn't actually answer your original question.

http://unix.stackexchange.com/questi...s-load-stage-2

grub-install works out where to install the loader - it's not just a matter of slapping 512 byte multiples wherever.
Things that may effect this is where the boot device is, whether it is gpt, whether it is BIOS or UEFI (and yes, you can boot gpt on BIOS systems), and whether the later stages are to be loaded from the same device.
I haven't looked at the code for grub2, but playing on various systems you see the different requirements it has.

This article is more about uefi booting, but has a pretty concise mbr boot explanation. https://www.happyassassin.net/2014/0...lly-work-then/

One of the advantages of uefi is that it clearly defines the location of bootloader code.

I absolutely second that! I don't use GRUB on any of my systems. But that is irrelevant to this post, because I don't want to use GRUB, I just want to understand how it works.

Syg00 mentioned UEFI and GPT. Actually I can sort of understand how GRUB works in those systems. With a UEFI chip, you don't actually need boot.img and I suspect it doesn't even get installed. core.img goes in the Efi System Partition under some such name as linux\grubx64.efi or grub\bootx64.efi and the UEFI will pick it up by name because the ESP is formatted with FAT32 and all UEFI chips have a built-in reader for that.

With a GPT disk under BIOS, it's more complicated. You need a separate grub partition for core.img with the type "bios-boot" and no filesystem. I assume that boot.img still goes in sector 1 because that's the only place that a BIOS would look for it. But it wouldn't matter if it overwrote the whole 512 bytes of sector 1, partition table and all, because that partition table is just a dummy. The real partition table is in the following sectors which must be preserved; hence the need for a separate partition to put core.img.

Which leaves the classic arrangement of BIOS plus DOS-MBR disk. Here I assume boot.img goes in the MBR and it must be less that 512 bytes so as to preserve the partition table, whatever the GRUB manual says to the contrary. And core.img must be the bit that goes into the empty space after the MBR.

I don't think you need anything like GRUB-legacy's Stage 1.5 because GRUB2's core.img is self-loading. The first sector contains the addresses of all the others, so no knowledge of filesystems is required. Once core.img is loaded, it can load its own filesystem drivers.

Well, that's my take on it but I admit I haven't yet read all the links provided in this thread. That's my project for this afternoon.