[Bug 1624096] Re: yakkety: backport (or rebase to) fix eliminating a double-close in shim

[Jason Gerard DeRose]

@Laszlo - darn, no luck. Following your recommendations, PXE booting is
no longer attempted, but I still end up at Shell> and the installer
doesn't launch.

I'm attaching the isolated test script I'm using ATM. If I try it with
the latest Yakkety desktop daily ISO, I hit the above hardware exception
(as expected because of the issue in `shim`). However, if I try it with
the same ISO modified to include /EFI/BOOT/fallback.efi, it goes
directly to Shell> rather than launching the installer.

Please let me know if you spot any goofs in my script or can think of
anything else to try.

(Note: my test script doesn't have any -net devices at all, but my image
mastering tools do, so that's why I know that PXE booting wasn't being
tried any more.)

@Mathieu - under the assumption that there is more to this than just the
issue in `shim`, or at least that the presence of fallback.efi can't
fully work-around it, do you have any suggestions as to where I should
go looking for other things that have changed between the Yakkety and
Xenial ISOs, things that might be interacting with the `shim` bug in odd
ways?

Also, I should make it clear why this bug is critical to System76: our
imaging mastering tools use QEMU + OVMF to create our UEFI images, so
this is something we absolutely need to find some solution for in order
to ship 16.10. Because (most likely) we'll need 16.10 to initially ship
Kaby Lake :D

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to debian-cd in Ubuntu.
https://bugs.launchpad.net/bugs/1624096

Title:
  yakkety: backport (or rebase to) fix eliminating a double-close in
  shim

Status in debian-cd package in Ubuntu:
  Triaged
Status in grub2 package in Ubuntu:
  New
Status in shim package in Ubuntu:
  Triaged

Bug description:
  Sometime after August 25th (or so) something changed in the Yakkety
  ISOs that make them no longer boot under QEMU in UEFI mode. However,
  the ISOs do work fine still on the physical UEFI hardware I've tested
  (3 different systems). I'm not sure about other VM solutions like
  Virtual Box, etc., as I haven't tested under anything other than QEMU.
  But under QEMU, UEFI mode installs are definitely broken.

  You get stuck in the OVMF firmware with the following text on the
  screen (see attached screenshot):

  Boot Failed. EFI Floppy
  Boot Failed. EFI Floppy 1

  Thus far I've only tested with a Xenial host, so I'm not sure whether
  this problem exists with a Yakkety host + Yakkety guest.

  This problem also doesn't seem to be the result of any changes in QEMU
  (and related) in Xenial. With a Xenial host, you can still do UEFI
  mode installs fine under QEMU when the guest is using the 16.04.1
  ISOs, and likewise when the guest is using the latest Xenial daily
  (16.04.2 WIP) ISOs. So the problem seems to be only when using a
  Yakkety guest in UEFI mode.

  Note this problem effects both Yakkety desktop and server ISOs (when
  installing under QEMU in UEFI mode).

  Finally, on the off chance it might be helpful to anyone who comes
  across this bug report, I wrote a blog post a while back on how to use
  QEMU in UEFI mode on a Xenial (or newer) host:

  http://blog.system76.com/post/139138591598/howto-qemu-w-ubuntu-xenial-
  host-uefi-guest

  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-cd/+bug/1624096/+subscriptions