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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1789319
Title:
Unable to load shimx64.efi using iPXE over UEFI
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1789319/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
