grub / grub2 conflicts

[Doug Ledford]

On 9/15/2011 12:01 PM, Matthew Garrett wrote:
> On Thu, Sep 15, 2011 at 04:56:43PM +0100, Richard W.M. Jones wrote:
> 
>> For grub1 guests, it has turned out not to matter which specific
>> version of grub [as long as it was grub1] was used, as apparently
>> grub-install updates all files needed in /boot/grub as appropriate.
>> Or at least we haven't come across a guest where this hasn't worked
>> (yet -- we could be in for a surprise).
> 
> The most obvious case where it can fail involves grub being effectively 
> unmaintained, and so various vendors have extended it in different ways. 
> You may end up with valid configuration files for one distribution that 
> can't be parsed by the grub for another. The assumption you're making is 
> fragile. It's even worse for grub2, since it has a built-in module 
> loader. Modules built for one version of grub aren't guaranteed (or even 
> really expected) to work when loaded into another.

No it's not.  Grub doesn't install the 1.5 stage or the 2nd stage
loaders, it uses the ones present in the root filesystem defined by the
install command.  In this case, that's going to be the modules in the
guest vm filesystem.  As such, anything valid in the guest vm's copy of
grub will work in the guest vm even if the grub used to install the
master boot record comes from the host.

The mistake here is in thinking that grub "installs" the later stage
boot modules.  It doesn't.  It installs the master boot record only (and
that's a dirt simply 512 byte assembly block that probably hasn't
changed since so long ago you would be hard pressed to find any version
of it that isn't byte for byte identical).  It then patches in the
logical block address of the stage 1.5 boot loader into the MBR.  It
then patches in the location/name of the stage 2 boot loader into the
stage 1.5 boot loader.  It then patches in the location/name of the
config file into the stage 2 loader.  The MBR loader just starts a chain
loading process, all the other work happens in the other loaders.  These
other loaders are present in the guest /boot/grub directory and hence
will always be in sync with what the guest vm expects.

>> I'm very interested in how to reinstall bootloaders *without* invoking
>> guest code.  Also in how to not break the bootloader when moving or
>> aligning the boot partition, which sometimes happens for reasons we
>> don't understand (but not on all grub1 guests, only on RHEL 5 era
>> grub1).
> 
> You're asking for the impossible. The only supportable bootloader for a 
> specific guest is the bootloader that matches the installed OS. If you 
> want to support grub2 on Ubuntu, for instance, you'll need Ubuntu's 
> grub2 - not Fedora's. The binary interface may have changed between 
> them.

Poppycock.  Although I can't speak for grub2, the grub install command
in the grub shell does not install anything other than that very static
512 byte MBR that I mentioned, the rest is all chaining of files in
/boot/grub and so will match the OS expectations even if the installer
is from a different version/os than the guest.

The real trick is simply getting everything set up properly.  First, I
wouldn't use grub-install, it makes too many assumptions.  Second, you
mount the guest block device on the host, this should give you the
partitions, then you mount the guest vm's /boot partition on the host so
you can access the files, then you then run the grub shell and issue
these commands (assuming that the first partition is the boot partition
in the guest vm's block device):

(loopback or whatever mount guest vm's block dev)
mount /dev/<vm_block_dev>1 /mnt/vm_boot
grub
grub> device (hd0) /dev/vm_block_dev
grub> root (hd0,0)
grub> install --stage2=/mnt/vm_boot/grub/stage2 (hd0)
/mnt/vm_boot/grub/e2fs_stage1_5 /mnt/vm_boot/grub/stage2
/mnt/vm_boot/grub/grub.conf
grub> exit
umount /dev/<vm_block_dev>1
losetup -d /dev/<vm_block_dev>

Now, I would imagine grub2 can be similarly directed to use the various
boot files from the guest.

Of course, if you are doing all this, it does beg the question of why
libguestfs couldn't simply mount both the root and boot partitions of
the guest vm, chroot into the root fs, then issue all the above grub
commands using the guest vm's copy of grub (I'm assuming grub is
installed, after all, it isn't guaranteed to be able to boot in the
future if you uninstall the grub rpm package after guest installation).
 Of course, the virtual block devices in the guest would not be the same
as they would under the host with the guest block device mounted, so
there would need to be some fiddling with device names and such.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
	      http://people.redhat.com/dledford

Infiniband specific RPMs available at
	      http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20110916/6f86c7dd/attachment.bin