[Bug 1789319] Re: Unable to load shimx64.efi using iPXE over UEFI

Wed Sep 5 22:28:38 UTC 2018

I may be able to provide some information here, about iPXE. (Corrections
welcome, obviously!)

iPXE can be built in a number of ways. Two of those are: (1) as a UEFI
*driver* that is presented in a NIC's PCI ROM BAR (i.e., as part of a
PCI expansion ROM), (2) as a UEFI *application* that can be loaded from
optical media / an ISO image, or a USB flash drive, or chain-loaded over
the network with the platform firmware's built-in netboot capabilities.

Independently of that dimension (i.e., build target), iPXE can be built
with different features enabled (through feature test macros). One of
those feature macros is "EFI_DOWNGRADE_UX". You can read about it e.g.
in iPXE commit a15c0d7e868a ("[efi] Allow user experience to be
downgraded", 2015-07-22).

I'll spare you the technical details; the point is that without
"EFI_DOWNGRADE_UX" (that is, in the default case), iPXE sort of takes
over the entire UEFI netboot process, supplanting most of the edk2
network stack (which is built into OVMF).

It is widely agreed upon that this behavior is appropriate for build
type (2) above, i.e. when iPXE is launched as a UEFI *application*.

Opinions differ whether this behavior is approprite for build type (1),
that is, when iPXE is built as a UEFI *driver*, to be included in a
specific NIC's PCI ROM BAR / expansion ROM image.

In my personal opinion, which some others (but definitely not all)
share, for build type (1), the "take-over" behavior of iPXE is not
desirable, and iPXE should only provide the lowest level hardware driver
for the NIC. (And then the rest of the UEFI network stack will come from
the edk2 modules -- this is precisely the situation that Steve describes
in comment#1.) In other words, for build type (1), the
"EFI_DOWNGRADE_UX" feature test macro should be defined -- in my
opinion. And, since iPXE commit a200ad462e69 ("[build] Add named
configuration for qemu", 2015-07-22), this is easily achievable by
passing the "CONFIG=qemu" macro definition to "make", when the "bin-
x86_64-efi/*.efidrv" files are built.

>From the pics attached earlier (e.g. comment#3), I'm nearly 100% sure
that the iPXE UEFI drivers in question -- build type (1) --  had been
built *without* EFI_DOWNGRADE_UX. While more recent iPXE commit
3376fa520b0c ("[efi] Implement the EFI_PXE_BASE_CODE_PROTOCOL",
2015-09-02) suggests this should function OK, I would still suggest
rebuilding the iPXE UEFI drivers (the PCI oproms) with "CONFIG=qemu",
and retrying.

"CONFIG=qemu" is certainly what we use in RHEL and Fedora, in the ipxe-
roms-qemu package. It's easy to refer to the Fedora spec file:

https://koji.fedoraproject.org/koji/packageinfo?packageID=13673

One more addition: from comment #2, I see that the NIC device model is
virtio. For a virtio NIC, you don't even need that "lowest level
hardware driver" to come from iPXE -- OVMF has a built-in (= native to
edk2) driver for virtio-net. It's located under OvmfPkg/VirtioNetDxe.
This means that, if you want to, you can netboot entirely without iPXE.
(Note I'm not saying you "should" boot without iPXE, just that you
"can", *if* you want to.) This is how:

As explained in OvmfPkg/README (see "Network Support"), if you use a
virtio NIC, and do not prevent QEMU (through the libvirt domain config)
from loading the iPXE oprom for the NIC, then iPXE's UEFI driver will
take precedence (regardless of whether it was built with or without
CONFIG=qemu) over OVMF's built-in driver. Using modern libvirt, you can
disable oprom loading (thereby opt for the built-in virtio-net driver)
by adding "rom enabled='no'/" under the "interface" element. Using less
recent libvirt, "rom bar='off'/" works somewhat similarly, although
technically it's quite different, and it won't work if you try to add it
to multiple "interface" elements. (Refer to RHBZ#1425058 for details.)

(I'm sorry for not including actual XML fragments -- I don't know if
Launchpad gets confused by unescaped angle brackets in comments.)

Summary:

- *If* you think this use case -- i.e., build type (1) -- is worth
testing with an iPXE oprom limited to the lowest level hardware driver
feature, then I suggest rebuilding iPXE (just the efidrv files) with
"CONFIG=qemu" passed on the "make" command line.

- *If* you think this use case -- i.e., build type (1) -- is worth
testing with iPXE entirely absent, then I suggest (a) sticking with the
virtio NIC, and (b) disabling oprom loading in the libvirt domain XML,
preferably with "rom enabled='no'", and less preferably with "rom
bar='off'".

(In either of the above two cases, it's still possible to use the super-
advanced features of a full-blown iPXE build. For that, build iPXE
without CONFIG=qemu (which is the default) for build target (2), i.e.,
as a UEFI application ("ipxe.efi"), and chain-load that over the
network.)

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

Title:
  Unable to load shimx64.efi using iPXE over UEFI

Status in MAAS:
  Triaged
Status in grub2 package in Ubuntu:
  Confirmed
Status in shim package in Ubuntu:
  Triaged

Bug description:
  libvirt supports creating virtual machines running in UEFI mode and
  uses iPXE to enable network booting. When MAAS gives shimx64.efi, as
  it does on all UEFI systems, to iPXE it chainloads grub but fails to
  the grub prompt. If I modify MAAS to give grubx64.efi instead of
  shimx64.efi UEFI booting works.

  Ideally iPXE would be modified to properly chainload the shim however
  MAAS could also check the user-agent when returning the boot file as
  follows.

  if option arch = 00:00 {
      # pxe
      filename "lpxelinux.0";
  } elsif option arch = 00:07 and exists user-class and option user-class = "iPXE" {
      # iPXE uefi_amd64
      filename "grubx64.efi";
  } elsif option arch = 00:07 {
      # uefi_amd64
      filename "bootx64.efi";
  } elsif option arch = 00:09 and exists user-class and option user-class = "iPXE" {
      # iPXE uefi_amd64
      filename "grubx64.efi";
  } elsif option arch = 00:09 {
      # uefi_amd64
      filename "bootx64.efi";
  } elsif option arch = 00:0B {
      # uefi_arm64
      filename "grubaa64.efi";
  } elsif option arch = 00:0C {
      # open-firmware_ppc64el
      filename "bootppc64.bin";
  } elsif option arch = 00:0E {
      # powernv
      filename "pxelinux.0";
      option path-prefix "ppc64el/";
  } elsif option arch = 00:1F {
      # s390x
      filename "boots390x.bin";
      option path-prefix "s390x/";
  } else {
      # pxe
      filename "lpxelinux.0";
  }

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1789319/+subscriptions