grub / grub2 conflicts

Matthew Garrett mjg59 at srcf.ucam.org
Mon Sep 19 17:07:52 UTC 2011


On Mon, Sep 19, 2011 at 12:44:58PM -0400, Doug Ledford wrote:
> OK, technically it install the 1.5 or the 2.0 if you don't use a 1.5 
> (if you install both the 1.5 and 2.0, then it patches the name of the 
> 2.0 into the 1.5 that it installs and the 1.5 reads the filesystem to 
> find the 2.0 so that it isn't subject to breaking boot if the 2.0 
> moves due to an updated version or some such).  However, it installs 
> them from the files you list to the install command as I listed in my 
> previous email.  So, they are still compatible with the guest vm grub 
> if you follow a procedure like I listed.  I haven't looked to see if 
> the 512 byte MBR is hard coded in grub or if it grabs it from 
> /boot/grub and installs what it finds there, so I can't speak to that.

Sure. If you're installing the files from the guest then there's no 
problem. But in that case you only need enough code in the host to be 
able to write the new images, whereas what Richard's been telling us is 
that the host-side grub binaries are required.

> > Even if it
> > didn't, I'm not convinced it's guaranteed that an arbitrary grub
> > stage 1
> > can launch an arbitrary grub stage 1.5 since there are assumptions
> > about
> > register and stack state - see start.S.
> 

> And I'm sure those assumptions haven't changed probably in the last 5 
> years or more.  But, I can look through the old grub CVS versions if 
> it would help settle your concerns.  Those sorts of hard coded 
> constants tend not to change much, especially if the coders have any 
> sort of clue what so ever about compatibility issues.

Given that you're always supposed to install the stage 1.5/stage 2 along 
with the mbr, I don't see where compatibility issues come into it. If 
you're using the code as you're meant to use the code then you'll always 
be safe. If you're not, it's not guaranteed to be safe.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org


More information about the devel mailing list