> On 30.11.2015 18:22, Mathieu Trudel-Lapierre wrote:
> > On Mon, Nov 30, 2015 at 10:01 AM, Stefan Bader <stefan.bader@canonical.
> > com
> > <mailto:stefan.bader@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.
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
