On 28/01/13 20:09, Frank Griffin wrote:
...this is where we disagree slightly ;)
Chainloading into grub2 is not the best way, due to the block lists
problem people keep mentioning and complaining about.
Could you please explain why ? The whole MBR/PBR design was set up so
that whatever gets loaded and receives control doesn't know which way it
happened. How does grub2 break this ?
My limited understanding is that the code in the 512 byte PBR has to use
block lists to find the core image in /boot, since it is too small to
understand filesystems. This is fragile in that filesystems and file
utilities may move files around on disk invalidating the block lists,
and for this reason the method is discouraged.
A far as I know the same potential problem exists with grub legacy.
Whether the same fragility applies to the multiboot approach I am not
sure, as documentation is sparse, however grub2 developers agree that it
is a valid method.
Chanloading is un-necessary
I don't claim that it's necessary, just that it's more desirable than
requiring the MBR code to go poking around in partitons other than the
one from which it was installed. If you're interested in keeping
partitions functionally as separate as they can be, it just makes sense
to have them booted by their own bootloaders.
The MBR code cannot go poking around. It points to one location only. In
the case of grub2 this is normally a copy of core.img located in the
'MBR-gap' of around 31kB (or larger depending on partitioning) below the
start of the first sector. This then launches the boot menu for the
system that created it, or a dedicated grub installation.
If the intention is to put the bootloader in the root partition by
whatever method, then it has no relation to the MBR. The intention is to
boot into the system's bootloader from another primary bootloader.
The bootloader built into the core.img in the system root *is* it's own,
just as would be the case with chainloading, so I don't really see the
distinction.
Barry
