Xenial/grub2: Changes for Xen

[Ian Campbell]

On Tue, 2015-12-01 at 09:49 +0100, Stefan Bader wrote:
> On 30.11.2015 18:22, Mathieu Trudel-Lapierre wrote:
> > On Mon, Nov 30, 2015 at 10:01 AM, Stefan Bader <stefan.bader at canonical.
> > com
> > <mailto:stefan.bader at canonical.com>> wrote:
> > [...]
> > 
> >     Currently I do a /etc/grub.d/xen.cfg which, apart from adding a
> > nicely separated
> >     place for Xen specific grub options (which I think is worth
> > keeping), adds an
> >     override string to boot into Xen by default. A better way for that
> > long term
> >     seems to be to simply change the order of the generator script
> >     (/etc/grub.d/20_linux_xen). This only generates a real section if
> > there is a Xen
> >     hypervisor installed and doing that a user likely also wants that
> > to become the
> >     default. So the question is whether it sounds reasonable to rename
> > 20_linux_xen
> >     into something like 09_xen?
> > 
> > 
> > I'm not opposed to that, but it's worth checking with the Debian GRUB
> > maintainers too, since we usually try to keep grub in sync.
> 
> Fair point. I added Colin and Ian. Actually Ian may remember some of the details
> about multiboot that I forgot. And maybe it makes sense to reach out to
> pkg-xen-devel and if a similar list exists for grub2 to that as well.

I've long thought that reordering 10_linux and 20_linux_xen would make
sense as an upstream fix even, I just never got around to doing anything
about it (IIRC).

> >     The the other thing probably needs more change than only grub: For a while now
> >     xen-hypervisor ships a version that is normally used from grub (using multiboot)
> >     and an EFI executable. The normal version cannot be used on UEFI systems because
> >     multiboot protocol has some shortcomings and there is no way to transfer control
> >     in a way to allow to get the memory layout (as one example).
> >     Currently 20_linux_xen generates two grub entries, one for xen-*.gz and one for
> >     xen-*.efi. The latter plainly is wrong and has only gone unnoticed because the
> >     former is selected by default. But I would propose the following change:
> > 
> > 
> > We most likely don't want to use the .efi image at all, if we want to maintain
> > the behavior of simply booting via grub for both methods. One use of the .efi
> > image is probably because you can more easily enforce the signature on that EFI
> > binary, but it doesn't seem to me like something we'd go out of our way to sign
> > anyway.
> 
> I agree. Its also simpler to find the choice between Xen and normal boot there.
> So I, too, would prefer any solution that keeps grub as the integration point.

You currently can't boot xen.efi via grub in the normal way, you have to
chainload and provide (somehow) a xen.cfg per http://xenbits.xen.org/docs/u
nstable/misc/efi.html otherwise all sorts of things fail. I think most
people just register xen.efi with the firmware rather than laundering via
grub, although with chainloading I think both are supposed to work equally
well.

Daniel Kiper from Oracle is working with upstream grub2 and Xen to make
"normal" booting work properly, by defining a multiboot handover mechanism
for EFI apps (I've not been keeping up with the specifics).

Probably all of this is best discussed on either pkg-grub-devel and/or the
upstream xen/grub devel lists.

Ian.