Bug#759018: [PATCH RFC] Provide prebuilt grub-xen binaries for host (dom0) use

[Ian Campbell]

On Mon, 2014-08-25 at 22:46 +0100, Colin Watson wrote:
> On Sat, Aug 23, 2014 at 09:38:07PM +0100, Ian Campbell wrote:
> > I'm attaching a new version with a grub.cfg which is tested and seems to
> > work. I've also taken the liberty of filing this into a wishlist bug
> > (keeping entire quoted text below for the bug).
> 
> This generally looks good to me, thanks!  As you said in a follow-up,
> there is the matter of establishing this as a boot protocol upstream,
> which I hope I can leave up to you to sort out.

Ack.

> For the information of pkg-grub-devel: I have given Ian commit access to
> pkg-grub, on the basis that he is much more familiar with Xen than I am
> and can start maintaining the Xen-related bits himself.  Welcome!

Thanks.

Is there a policy regarding using e.g. people/foo branches in the main
grub.git or shall I go create myself a gitorious repo for WIP stuff?

I've attached a little mini series which addresses the issues you raised
and switches to the proposed /boot/xen naming scheme.

I've also added some new patches.

The first causes grub-xen to actually produce things under /boot/xen,
I'm not entirely sure about it though -- it
places /boot/xen/pvboot-x86_64.elf as required but grubdir (e.g. all the
modules etc) are still under /boot/grub. I wasn't sure if it was better
to actually move grubdir to /boot/xen too. The implementation is a bit
unsatisfactory since grub-mkimage doesn't let you change only the output
file without moving grubdir (AFAICT), so it generates and then moves it.

Lastly I made grub-xen not conflict with the other grub-* package.
grub-xen is a bit of a special case since you can have a filesystem
which is bootable both as PV (grub-xen) or HVM (grub-pc or grub-efi).

> > I needed to do a little hack which is to rmmod memdisk before searching
> > for /boot/grub/grub.cfg or else it just loops infinitely finding the
> > grub.cfg in the memdisk. I have a feeling that the same thing might
> > apply to debian/grub-firmware-qemu_grub.cfg.
> 
> This is what
> https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00185.html and
> subthread was about, but that never reached a clear conclusion, although
> Andrey's patch seemed fairly reasonable to me.  The rmmod hack is OK for
> now.

Switching to using "normal" made this go away in the end, since the
bootstrap.cfg doesn't need to use /boot/grub/grub.cfg as it's next
stage, so there is no conflict.

Ian.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-EXTRA_PACKAGES-to-debian-rules-which-for-now-con.patch
Type: text/x-patch
Size: 1786 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20140830/95b3854f/attachment-0012.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Provide-prebuilt-grub-xen-binaries-for-host-use-in-a.patch
Type: text/x-patch
Size: 7691 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20140830/95b3854f/attachment-0013.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Build-Install-binaries-into-boot-xen-when-installing.patch
Type: text/x-patch
Size: 2162 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20140830/95b3854f/attachment-0014.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Allow-grub-xen-to-be-coinstallable-with-other-grub.patch
Type: text/x-patch
Size: 5702 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20140830/95b3854f/attachment-0015.bin>