grub / grub2 conflicts

[Doug Ledford]

----- Original Message -----
> 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.

The "minimal code" you need to do what I suggested is the grub binary itself.  Shouldn't need grub-install or any of the other support files, but as the grub binary is in the base package, you need the grub package in addition to the grub2 package.

> > > 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,

This is incorrect.  The whole reason the stage1.5 portion is an fs compatible reader is so that you can update the stage2 file and it will pick the changes up without needing to be reinstalled.  This is also born out by the fact that on package update, there is no %post action in the spec to reinstall the mbr and stage 1.5 files even though the stage2 file likely just changed.

> 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.

Like I said, not true.  The grub package is designed to be updateable without requiring an mbr reinstall.  What's more is I had a look at the stage1.[hS] files in the grub shipped in FC-1 and RHEL-5, and just like I said, they are indeed binary compatible.  So even if the grub user space application pulls its MBR from a statically linked copy of the MBR, it will still work with pretty much any stage1.5 or stage2 you find in a guest.