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@canonical. > > com > > <mailto:stefan.ba...@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