Clive McBarton wrote:
I'm not saying grub cannot do it, but I do see a reason: grub has its config in a *file*. By default anyway. Something called menu.lst which controls how the grub display looks like and so on. When grub loads, it loads this file first. There are also other files, like device.map.
This file is part of the second stage. We're now talking about grub1 exclusively.
Another reason: I read somewhere that grub is too fat to fit in the boot sector. So only half sits in it and loads the other half, which is a *file* on a file system.
Yep. In grub1, Only the stage1 fits in the boot sector. If you want, you can either:
* Go on to stage2 by hardcoding some block offsets list in stage1. This can of course be automated by the grub shell install command, which is *different* from the grub-install(8) utility.
* If the stage2 is on a filesystem which can possibly physically move the file or parts of it (fragmentation, rewrite, whatever) - which is usually the case - you can put a filesystem driver somewhere else, and use it to read the stage2 at a higher level.
Usually, the entire first cylinder of a disk drive (someone correct me if I'm wrong) formatted with a PC BIOS style partition table/label is left untouched for historical reasons. This space is large enough to hold any fs driver and will most likely not interfere with any PC BIOS partition table editor.
[little bit off topic]Note that in reality, it's a mess, Microsoft uses it for its LDM (Logical Disk Manager) - their *really* crappy equivalent of lvm/mdraid - and it causes bad conflicts. There are solutions to this, but this is off-topic. Let's drop GPT in the discussion, as the ultimate solution (sadly, no support on non-efi machines on Microsoft's side yet, for no apparent reason).
-thib