[Pkg-xen-devel] Bug#703586: Bug#703586: Bug#703586: Xen fails to boot Linux dom0 under UEFI

[John Keates]

On Wed, 10 Sep 2014 20:22:54 +0100 Ian Campbell <ijc at hellion.org.uk> wrote:
> On Sun, 2014-09-07 at 13:42 +0200, John Keates wrote:
> > 1. Rebuild the debian package with a small change
> > 
> > Do your usual apt-sourcing and build-depping, but add the pep target to debian/rules:
> > 
> > (I put it right underneath include debian/rules.defs)
> > 
> > DEB_CONFIGURE_EXTRA_FLAGS  += --enable-targets=x86_64-pep
> 
> This isn't actually necessary, the Xen build will automatically produce
> xen.efi if the tools are new enough and contain the necessary support.
> --enable-targets=x86_64-pep is actually something which needs to be
> passed to the *binutils* configure, and this is done on Debian.
> 
> > then do your usual binary run to produce the files needed.
> > You’ll find xen.efi in ./debian/build/build-hypervisor_amd64_amd64/xen/xen.efi
> 
> It turns out that the Debian build is already building xen.efi today, it
> just isn't putting it in the package!
> 
> I think it would be sensible to pickup this binary for inclusion, either
> in the existing xen-hypervisor package or into a new EFI package.
> 

Ah, okay, I didn’t notice that. In that case, including xen.efi should even be easier. Pretty much one additional line for the package maintainer right?

> > 2. Allow UEFI to find your xen.efi
> > 
> > UEFI uses your ESP to launch the efi binaries, so that’s where it needs to go.
> > Simply put (not symlink) xen.efi in /boot/efi/EFI/debian/
> 
> This should be taken care of by packaging it in the right place, I
> think, or possibly by the postinst moving it there.
> 

Yes indeed. And since the installation of Xen on an EFI platform can be detected fairly easily, this also shouldn’t take more than 4 of 5 lines for postinst.

> > 3. Configure dom0 booting
> 
> This and the rest would need a bit more infrastructure putting into
> place to do automagically, which I don't see happening for Jessie given
> the looming freeze, but at least by packaging the xen.efi binary we can
> simplify things for people who want to set this stuff up themselves.
> 
> Hopefully for Jessie+1 grub will be able to launch xen.efi itself, and
> most of this will go away.
> 
> Ian.
> 

Well, there is one more thing: If kernel 3.17 manages to get in before the kernel freeze, full-fledged Xen-EFI support will be baked into the kernel by default!
3.17 has been patched to provider hypercall support for Xen to get the efivars facility (and pretty much anything and everything else EFI) working for Dom0.

Now, I’ve seen some messages on the mailing list where three people actually want to freeze the kernel on 3.16, but since 3.17 is on RC4 already and due to be 
released really soon (like, in 4 to 5 weeks) with a bit of luck 3.17 might be decided upon instead of 3.16. Besides Xen EFI support, it brings a ton of really important updates as well that are beneficial for everyone.

Ideally we get the following:

- fix for including xen.efi in the package
- patch for postinst that detects the EFI ESP and copies xen.efi over there and adds an efibootmgr entry
- maybe a simple management script that generates xen.cfg and allows the user to set Xen as the first boot option?
- kernel 3.17 so after booting into dom0 EFI is still accessible and the efibootmgr still works

But having xen.efi in the package would be a ton of help already. Who do I stalk to make that happen?

John

> 
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4124 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20140913/0ca9d6d3/attachment.bin>