EFI Shell not available

[Colin Watson]

If I attempt to boot my own hard disk in an emulator using this command, which uses a self-built OVMF from a while ago:

  qemu-system-x86_64 -enable-kvm -bios ~/src/ubuntu/edk2/sb/bios.bin -monitor stdio -m 1024 -snapshot -hda /dev/sda

... then it fails to boot from any of the available drives but falls back to an EFI Shell. This is fine - I can boot manually from there. However, the same thing with the packaged emulator (ovmf 0~20121205.edae8d2d-1 on saucy amd64):

  qemu-system-x86_64 -enable-kvm -bios /usr/share/ovmf/OVMF.fd -monitor stdio -m 1024 -snapshot -hda /dev/sda

... goes through the available devices as before:

  Boot Failed. EFI DVD/CDROM
  Boot Failed. EFI Floppy
  Boot Failed. EFI Floppy 1
  Boot Failed. EFI Hard Drive

... and then hangs without giving me an EFI Shell. This seems rather less useful, and it seems from debian/rules as though the Shell is *supposed* to be built in.

[Steve Langasek (vorlon)]

From the look of things in testing here, the shell *is* present - if I pull up the Boot Manager menu in firmware, it's listed as an option. But if I choose this option, I get a blank screen with a fixed cursor. Is this the same symptom you're seeing?

Do you have a pointer to how you built your ovmf locally before? There are a number of binaries that are checked into the upstream repository that don't get rebuilt as part of a normal build, which have been stripped out for the Debian packaging; it's possible this explains the failure, or it's possible that I'm just building with different options.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jason Gerard DeRose (jderose)]

Colin, Steve, any recommendations on how to build ovmf in the way needed to work around this?

System76 is working toward switching all our products to UEFI, but we use qemu for our golden image mastering and maintenance (something I'm not keen on giving up as it's proven to be totally awesome).

I'm pretty sure I'm now stuck at this same bug. I can (seemingly) successfully complete an install, but for the life of me, I can't then boot from the disk image. I've tried with qemu 1.5 on Saucy, and qemu 1.6 on Trusty (using the pre-built ovmf Ubuntu package). I've also tried with random ovmf builds from around the net, still no luck.

Also, I spun my wheels for a while till I realized that ovmf doesn't currently work with virtio... so future readers take note:
OVMF + virtio == you're gonna have a bad time

;)

[Jason Gerard DeRose (jderose)]

Screenshot to clarify where I'm getting stuck

[Steve Langasek (vorlon)]

On Mon, Dec 02, 2013 at 11:07:40PM -0000, Jason Gerard DeRose wrote:
> Colin, Steve, any recommendations on how to build ovmf in the way needed
> to work around this?

> System76 is working toward switching all our products to UEFI, but we
> use qemu for our golden image mastering and maintenance (something I'm
> not keen on giving up as it's proven to be totally awesome).

> I'm pretty sure I'm now stuck at this same bug. I can (seemingly)
> successfully complete an install, but for the life of me, I can't then
> boot from the disk image. I've tried with qemu 1.5 on Saucy, and qemu
> 1.6 on Trusty (using the pre-built ovmf Ubuntu package). I've also tried
> with random ovmf builds from around the net, still no luck.

That doesn't sound to me like it has anything to do with the shell support.
Rather, it's probably because ovmf doesn't support persistence of nvram, so
you've lost the information about the EFI boot options which is stored
there.

You should be able to manually browse the firmware menu to boot by filename
(/efi/ubuntu/bootx64.efi), but that's probably not a very maintainable
solution.

[Launchpad Janitor (janitor)]

This bug was fixed in the package edk2 - 0~20131029.2f34e065-1

---------------
edk2 (0~20131029.2f34e065-1) unstable; urgency=medium

  * New upstream release. Closes: #714463.
    - update debian/rules to pull a new version of the shell.
    - drop debian/patches/enum-handling, fixed upstream.
    - drop debian/patches/mismatched-enums, fixed upstream.
    - fixes breakage with the EFI shell. LP: #1223413.
  * debian/patches/enable-nvme: enable the NVMe driver.
    Closes LP: #1267816.
  * debian/post-patches/setup.diff: drop gcc4.7 handling, which is
    sorted upstream.
  * Update debian/copyright

 -- Steve Langasek <email address hidden> Sat, 11 Jan 2014 23:34:25 +0000

[Jason Gerard DeRose (jderose)]

Totally awesome that this is fixed!

Note that with edk2_0~20131112.2590861a-1, virtio also seems to be working fine. So now future readers take note:

OVFM (edk2_0~20131112.2590861a-1) + virtio == you're in the clear

The only downside is I still can't successfully install a Saucy UEFI guest, but I'm not too worried about that. The important thing is that a Trusty UEFI guest works on a Trusty host.