"ubuntu-device-flash core" images can't boot with UEFI

[Daniel van Vugt]

"ubuntu-device-flash core" images can't boot with UEFI. You presently have to disable UEFI in your BIOS and force legacy mode to get Ubuntu Core to boot. On some systems, that still doesn't work (see bug 1425367).

Supporting UEFI is rather important. It's the default mode (and now sometimes the only mode) supported by modern PC BIOSes. If Ubuntu Core can't boot on them then we can't easily build x86-based appliances.

[Steve Langasek (vorlon)]

Correct. The infrastructure is in place to allow these images to be BIOS+UEFI bootable in the future, but we are not currently installing the UEFI bootloader.

[Thomas B. Rücker (thomas-ruecker)]

I just tried to boot ubuntu-15.04-snappy-amd64-generic.img on a MinnowboardMax and ran into this bug.
What makes it even harder to understand is that the disk geometry and everything is in place. All that seems to be missing is the grubx64.efi bits.

I tried copying them over from a 15.04 server install, but had no luck.

If there is no plan to support x86_64 embedded systems (which most come without legacy BIOS), then please at least document a workaround how an image can be modified or rebuilt to gain EFI support.

[Steve Langasek (vorlon)]

Hi Thomas,

On Thu, Apr 30, 2015 at 06:47:01AM -0000, Thomas B. Rücker wrote:

> I just tried to boot ubuntu-15.04-snappy-amd64-generic.img on a
> MinnowboardMax and ran into this bug.

> What makes it even harder to understand is that the disk geometry and
> everything is in place. All that seems to be missing is the grubx64.efi
> bits.

> I tried copying them over from a 15.04 server install, but had no luck.

> If there is no plan to support x86_64 embedded systems (which most come
> without legacy BIOS), then please at least document a workaround how an
> image can be modified or rebuilt to gain EFI support.

Support for EFI boot is in progress; see
<https://code.launchpad.net/~vorlon/goget-ubuntu-touch/uefi/+merge/256869>,
which we hope will land soon in the development version of
ubuntu-device-flash.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Ricardo Salveti (rsalveti)]

If you are running vivid at your host, mind trying the latest goget-ubuntu-touch packages in https://launchpad.net/~snappy-dev/+archive/ubuntu/tools?field.series_filter=vivid ? That has the MR done by slangasek.

[Thomas B. Rücker (thomas-ruecker)]

Minor improvement, but still not fully there yet IMHO.

Fresh Vivid install, added PPA:
  deb http://ppa.launchpad.net/snappy-dev/tools/ubuntu vivid main
Installed:
  ubuntu-device-flash 0.21-1+173~ubuntu1 amd64
Generated image:
  sudo ubuntu-device-flash core rolling --output /mnt/amd64.img --developer-mode --channel edge
Created new virtual machine in virt-manager with firmware set to UEFI and disk image'amd64.img'.
  Boot failed. EFI floppy
  Boot failed. EFI floppy I
[... iPXE attempt, wait for keypress, etc]
  Shell>
So it's stuck in the EFI shell.
Now I can do this:
  fs0:\EFI\BOOT\BOOTX64.EFI
Then the image will actually boot.

cf. The Vivid server install in the same type of qemu-kvm with UEFI boots just fine without manual intervention.

[Steve Langasek (vorlon)]

On Wed, May 13, 2015 at 07:26:56AM -0000, Thomas B. Rücker wrote:
> Created new virtual machine in virt-manager with firmware set to UEFI and
> disk image'amd64.img'.
> Boot failed. EFI floppy
> Boot failed. EFI floppy I
> [... iPXE attempt, wait for keypress, etc]
> Shell>
> So it's stuck in the EFI shell.
> Now I can do this:
> fs0:\EFI\BOOT\BOOTX64.EFI
> Then the image will actually boot.

This is not reproducible for me. I'm running snappy images under
virt-manager with UEFI, and they boot fine without intervention. Can you
please attach your libvirt xml for this VM? (/etc/libvirt/qemu/??.xml)

[Thomas B. Rücker (thomas-ruecker)]

I looked a bit deeper into things. I currently see several ways to address this:

- User is forced to figure out and to go into UEFI firmware and configure system to prioritize booting from disk over EFI shell
- Set the boot order using "efibootmgr", requires us to first boot /somehow/ /something/ (this is what most distros, including ubuntu, do)
- Utilize the startup.nsh fallback, either every time or for a first boot and then set things straight with efibootmgr
- some other option that I'm currently not aware of

I see this as a general issue. Not only does the default setup as created by virt-manager exhibit this behaviour, it's also the default firmware behaviour for x86_64 embedded systems like the MinowboardMax, Minnowboard and FRI2.
While you can set the boot priority on those through the firmware menu, it will reset itself, at least on the Max, if it ever boots without the boot media.

I'd personaly suggest the option of using "efibootmgr" and resolving the first boot situation by falling back to a startup.nsh to execute bootx64.efi. This should make the image boot out of the box on most, if not all, hardware.

The script allows for variables, so it is possible to make it start the right binary without knowing the filesystem identifier or UUID in advance.

[Steve Langasek (vorlon)]

On Mon, May 18, 2015 at 11:08:25AM -0000, Thomas B. Rücker wrote:

> ** Attachment added: "Default machine config created by virt-manager on
> ** 14.04"
> https://bugs.launchpad.net/snappy-ubuntu/+bug/1425370/+attachment/4399386/+files/snappy-efi-test5.xml

This image config looks fine. The problem is still not reproducible for me.
This looks like a bug in the version of OVMF.fd that you're using. Are you
using the ovmf package from Ubuntu or did you build your own?

> I'd personaly suggest the option of using "efibootmgr" and resolving the
> first boot situation by falling back to a startup.nsh to execute
> bootx64.efi. This should make the image boot out of the box on most, if
> not all, hardware.

That's not necessary or appropriate. You should write snappy to a boot
disk. Your hardware should be configured to try to boot from that disk.
How this happens is defined in the UEFI spec, and does not require any
configuration of firmware variables to point to a specific path on disk - it
will automatically boot from \EFI\BOOT\BOOTX64.efi, which is exactly the
path we have written our bootloader to. If you're having problems getting
this to work on a system that supports 64-bit UEFI, either your system's
firmware is buggy, or you're installing snappy to a disk that is not
configured in the firmware to be a boot disk. In the first case the
firmware should be fixed to comply with the UEFI spec. In the second case,
the firmware isn't looking at the disk, so making other changes to that
disks contents (such as startup.nsh) won't have any effect on the system's
boot behavior.

[Thomas B. Rücker (thomas-ruecker)]

As noted earlier on IRC:
qemu is 2.0.0+dfsg-2ubuntu1.10 and ovmf 0~20131112.2590861a-2
As present in 14.04

I'll comment later on why your assumptions on the second part are rather wrong, don't have the time now.

[Steve Langasek (vorlon)]

On Mon, May 18, 2015 at 03:51:10PM -0000, Thomas B. Rücker wrote:
> As noted earlier on IRC:
> qemu is 2.0.0+dfsg-2ubuntu1.10 and ovmf 0~20131112.2590861a-2
> As present in 14.04

Ok. I've just tested with this version of ovmf and can confirm this
behavior. Sorry, I previously had version 0~20150106.5c2d456b-1 installed
locally. That version of ovmf behaves correctly; so the problem you're
seeing is a bug in the trusty version of ovmf, which does not detect the
snappy image as a candidate boot disk.

Under the latest version of ovmf, the disk shows up in the firmware "Boot
Option Menu" as "EFI Misc Device". I'm not sure if the "misc device" is
indicative of a problem.

I also see that if I load an image under ovmf 20131112, and then upgrade
ovmf, it continues to fail to boot. This is because of something in the
NvVars file written to the ESP. Upgrading ovmf and removing this file is
sufficient to let it boot automatically.

[Steve Langasek (vorlon)]

Per the last comment, I'm considering this bug "fix released". The only confirmed case of failing to boot under UEFI with this version of udf is with buggy firmware (old versions of ovmf - yes it's the version that's current in trusty, but it nonetheless appears to be buggy).

If there are identifiable bugs with the device setup that make these images not UEFI-compliant, then please let us know.