Thanks for the explanation. I have a question. You said:
When you install the bootloader (eg GRUB) into the partitions boot section, then yes, the MBR has to find the bootloader. If you install it into the MBR, however, it's this (simplified) scheme
- Load the bootloader (GRUB/LILO/...)
- Select the OS you want to boot & that the bootloader knows about
- The bootloader then loads the usual startup code from the partitions bootsector
How does GRUB "install itself into" the MBR?
Do you mean it replaces the existing MBR with it's own implementation? If I understand correctly MBR's are not all the same. Different OS may write it differently. And if I reinstall the OS on my first partition, and it's e.g. Windows, it's going to write its own version of an MBR, correct?
This is good IMO if GRUB gets into the boot prcess at the "MBR stage".
Because, as you say, and as I read in an old Microsoft technet article, at this stage the OS is unaware. It cannot cause problems.
Controlling the choice of OS at the "MBR stage" (i.e. not trying to use an OS's bootloader to boot other OS's) is I think a key to avoiding troubles with multi-booting. And that's why I do it by changing the boot flags.
I need more technical doc on GRUB. The manual over at GNU is being rewritten I guess and is "unifinished".
I have this feeling that what I'm doing with the boot flags is not much different than what GRUB does, except GRUB offers a "boot time menu": it can identify filesystems by their respective ID flags and it changes the boot flags DURING reboot; whereas I'm choosing my next OS choice BEFORE I reboot. In other words, GRUB is also a partition identifier and MBR editor just like the tools I'm using, it's just doing the editing at a different time.