-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBCgAGBQJWXGTfAAoJEOhnXe7L7s6j1UAQAKbEPAcTpzyLKfw7LxC8SUs9
Vp6Llawcb4Ixo0kP5S+qCg/MQ1a2LSq7C6BSL/YFGN807XLepTI4NhRjW74g+DYO
8TMel5y7ODqCvyPqmp/FPmor4L/iToXPtmriXoV5SlkVpbzVl9eGMPTZKniMkPFW
RzUlbqyeTruIcuy+AMXiI2I+L+Ll1UBEEcBIJ2YRRMQ1aH3sO1wFiexo6ij5MChU
FeayRA48ytkm9Ga8OuJfd6k4BZpOoDROVWWecKpSxsQyI/1XT1UcxD/hhe5uAkbW
jtTEixIKwzDejKdY8/Nul9LXSyHvRVHK0urA4WmaEaDl0Stb5BYXLATN5pEuEbLB
IIa4ZTI+Xsix5VYLILgmcl2+ltYL+XwI0PlanK2kMcGyHWeAf0OqRvB6bgasqEiH
unkGgBt6HLkil3LUaggqLEUopdaIJLOghxQv47At26nutiNKECa8yX3AIlDXoGg/
JrEbIPPWhbF8Yv2QUrivheUUO/TA4q7bjIxlmWcVRsr6xtoPRtCW/WEyK48elZGY
gELch/27xq267tO24RWq1gykmApNvmFtpEfSfjAn/goGJr6btWQqcAh17J5mv/dQ
fEKCfh7Ljlqpcq7w7pRC9kK+8xXfGF1DOUjLWzjCi6rLdzteMGYOQiPihkkYMsXW
Wr+khEfZ4NntaNZdm62I
=Z+vF
-----END PGP SIGNATURE-----
Not sure who currently is doing grub2... A long while ago (I think the last time
when there was a Xen version bump, which was iirc vivid) Adam and I had a
discussion about this but then things were forgotten. With Xenial there will be
another bump (to Xen-4.6) so might as well talk about this again.
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?
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:
20_linux_xen:
xen_list=`for i in /boot/xen*; do
+ if echo "$i" | grep -q '\.efi$'; then continue; fi
if grub_file_is_not_garbage "$i" && file_is_not_sym "$i" ; then echo -n
"$i " ; fi
done`
As for the question on how to handle UEFI boot, I don't know what can be done
about that. The *.efi executable likely needs to be rather loaded directly from
the shim layer, and then sooner than later also needs to become signed. Or
alternatively there had been attempts to improve the multiboot protocol in a way
that would allow using the normal grub2->xen chain for the UEFI boot case. But I
am not sure there is an outtcome, yet. So I guess for now the primary target
would be to ignore the *.efi file when generating the grub.cfg.
-Stefan
