On 01/28/2013 06:44 PM, Barry Jackson wrote:
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.
OK, we've come full circle. This is why I was used to rerunning
install.sh, because historically this has been true of most
bootloaders. They all have to fit in 512 bytes, and they all have to
load the next stage of the boot without support for filesystems.
That's why I stick with chainloading. PBRs don't move around at the
whim of a filesystem, and if you do something to a root partition that
repositions something critical, you just rebuild the PBR as part of it.
I wasn't aware of the MBR gap. I guess you're saying that the core.img
that fits in it *is* filesystem-aware ? Otherwise, it seems like you've
just pushed the locate-the-next-stage vulnerability from the MBR to the
MBR gap, as chainloading pushes it from the MBR to the PBR.
Anyway, my point still stands: for anyone who just wants to have grub
and grub2 partitons coexist on the same disk with either one in the MBR,
chainloading will accomplish this without any downside that isn't
already present in grub legacy. Grub2 may be the way of the future, but
to *require* it to own the MBR is just misleading.
