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