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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b96e6b4.80...@stammed.net
