ipxe-qemu is missing support for devices since qemu 2.7

Bug #1737211 reported by Nathan Rennie-Waldock
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ipxe (Ubuntu)
Fix Released
Medium
Christian Ehrhardt 

Bug Description

The PXE roms for devices that qemu (since 2.7) now supports PXE on are missing:
$ qemu-system-x86_64 -netdev user,id=hostnet0 -device e1000e,netdev=hostnet0,id=net0 -nographic
qemu-system-x86_64: -device e1000e,netdev=hostnet0,id=net0: failed to find romfile "efi-e1000e.rom"

$ qemu-system-x86_64 -netdev user,id=hostnet0 -device vmxnet3,netdev=hostnet0,id=net0 -nographic
qemu-system-x86_64: -device vmxnet3,netdev=hostnet0,id=net0: failed to find romfile "efi-vmxnet3.rom"

This affects all supported Ubuntu versions with qemu 2.7 or higher.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "enable-vmxnet3.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Changed in ipxe (Ubuntu):
assignee: nobody → ChristianEhrhardt (paelzer)
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Nathan I'll take a look at that in the scope of the 18.04 virt stack.
That will take a while as we wait for qemu/libvirt to finalize the versions we want to pick.

Since this is more a feature than a regression I'd plan to only add that in 18.04.
Thanks a lot for the fix!

There are two more things you can help me do:
1. to eventually drop this from being a Delta to Debian it would be great if you could report that to Debian as well and report the bug number you got here.
2. If you'd have a nice and short list of steps how to most easily reproduce the issue with vmxnet that would be nice as well.

tags: added: ipxe-18.04
description: updated
description: updated
summary: - efi-vmxnet3.rom is missing
+ ipxe-qemu is missing support for devices since qemu 2.7
Revision history for this message
Nathan Rennie-Waldock (nathan-renniewaldock) wrote :

Someone has already submitted it to Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868124

This isn't exactly a feature request, it should have been added when qemu was updated to 2.8. The prebuilt PXE roms bundled with qemu were removed in favour of building them all from source (this package). Which isn't very helpful if this package is going to lag quite a bit behind qemu.

The package description says "This package provides boot code for the qemu emulated network cards in as boot ROMs."
Which should mean all network cards qemu supports, not just some of them. Right now there's actually vmxnet3 and e1000e missing.

$ qemu-system-x86_64 -netdev user,id=hostnet0 -device e1000e,netdev=hostnet0,id=net0 -nographic
qemu-system-x86_64: -device e1000e,netdev=hostnet0,id=net0: failed to find romfile "efi-e1000e.rom"

$ qemu-system-x86_64 -netdev user,id=hostnet0 -device vmxnet3,netdev=hostnet0,id=net0 -nographic
qemu-system-x86_64: -device vmxnet3,netdev=hostnet0,id=net0: failed to find romfile "efi-vmxnet3.rom"

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Nathan,
I highly appreciate you coming up with the change proposed here as I can include it when working on this set of packages anyway.
IMHO it is an actual feature request, even thou the reasons to have missed to add the feature earlier lie in the past - I want you to understand why, so I added a bit of background below.

In general you have to understand the reason for "prebuilt PXE roms bundled with qemu were removed in favour of building them all from source" - the reason for that is [1].
TL;DR - blobs are of unknown source, can be impossible to fix and critical if a lawyer comes by, so they have to be built from source wherever possible.

Then on top of that there was an issue with ipxe-qemu that I started to tackle about 2 months ago [2] and will be fixed in the 18.04 cycle - this one caused the Ubuntu ipxe roms to stay behind upstream for too long. The TL;DR of it is that new builds break migration as well as suspend/resume across versions. I have a POC that works to fix it while being able to update to the latest roms.

None of the above changes anything, but you should know that these roms were not just forgotten, but instead all of the misses you found had real reasons.

[1]: https://wiki.debian.org/DFSGLicenses
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881263

Changed in ipxe (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Nathan Rennie-Waldock (nathan-renniewaldock) wrote :

I'm already of why the prebuilt ones were removed, but that doesnt't actually answer how they were missed when updating qemu to 2.7 (vmxnet3 PXE is mentioned in the changelog). Part of the problem is that on updating, all the PXE roms are blindly removed without checking for any new ones since the last release.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote : Re: [Bug 1737211] Re: ipxe-qemu is missing support for devices since qemu 2.7

> I'm already of why the prebuilt ones were removed,

great

> but that doesnt't
> actually answer how they were missed when updating qemu to 2.7 (vmxnet3
> PXE is mentioned in the changelog).

Updating qemu is distinct from updating ipxe.
So when we moved what was I think qemu 2.6.1 -> 2.8 that did not
affect ipxe at all.
And at least I didn't catch the vmxnet3 change to take action on it.

IPXE only recently got to my attention to be so outdated by not being
a sync as I'd have thought.
Which triggered all my tests finding the migration issues, so we
wouldn't have been able to "just update" the last cycles anyway.

> Part of the problem is that on
> updating, all the PXE roms are blindly removed without checking for any
> new ones since the last release.

It is an explicit packaging, new built artifacts/binaries when moving
to a newer source are not automatically included in the package.
This is rather common approach in many packages - although usually
there are warnings that you have to explicitly ignore.
I didn't check the details on the Debian package build why this didn't
trigger there, but our reasons was that we were too outdated.

TL;DR you are right with everything you suggest to add and I hope to
address it when doing the coming qemu/libvirt move - this time
ensuring ipxe (and other roms as well actually) have a better match.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

I was looking into that and it seems vmxnet3 is totally fine.
But e1000e has build issues.
I think I have seen this kind of issue on rom builds in the past but couldn't get it working reliably. OTOH e1000e is only the emulated card and vmxnet3 probably way more important.
So better to add this than nothing.

FYI: the error boils down to:
make -j1 V=1 NO_WERROR=1 VERSION=1.0.0 bin-x86_64-efi/e1000e.efirom
gcc -DARCH=x86_64 -DPLATFORM=efi -DSECUREBOOT=0 -fstrength-reduce -fomit-frame-pointer -falign-jumps=1 -falign-loops=1 -falign-functions=1 -m64 -fshort-wchar -Ui386 -Ulinux -DNVALGRIND -fpie -mno-red-zone -Iinclude -I. -Iarch/x86/include -Iarch/x86_64/include -Iarch/x86_64/include/efi -Os -g -ffreestanding -Wall -W -Wformat-nonliteral -fno-stack-protector -fno-dwarf2-cfi-asm -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -Wno-address -ffunction-sections -fdata-sections -include include/compiler.h -DASM_TCHAR='@' -DASM_TCHAR_OPS='@' -DOBJECT=version -DBUILD_NAME="\"e1000e.efidrv\"" \
        -DVERSION_MAJOR=1 \
        -DVERSION_MINOR=0 \
        -DVERSION_PATCH=0 \
        -DVERSION="\"1.0.0\"" \
        -c core/version.c -o bin-x86_64-efi/version.e1000e.efidrv.o
In file included from ./config/general.h:202:0,
                 from core/version.c:35:
./config/local/general.h:1:0: warning: "ROM_BANNER_TIMEOUT" redefined
 #define ROM_BANNER_TIMEOUT 0

In file included from core/version.c:35:0:
./config/general.h:30:0: note: this is the location of the previous definition
 #define ROM_BANNER_TIMEOUT ( 2 * BANNER_TIMEOUT )

ld -m elf_x86_64 -q -S --gc-sections -static -T scripts/efi.lds -u _efidrv_start --defsym check__efidrv_start=_efidrv_start -u obj_e1000e --defsym check_obj_e1000e=obj_e1000e -u obj_config --defsym check_obj_config=obj_config -u obj_config_efi --defsym check_obj_config_efi=obj_config_efi --defsym pci_vendor_id=0 --defsym pci_device_id=0 -e _efidrv_start bin-x86_64-efi/version.e1000e.efidrv.o bin-x86_64-efi/blib.a -o bin-x86_64-efi/e1000e.efidrv.tmp \
        --defsym _build_id=`perl -e 'printf "0x%08x", int ( rand ( 0xffffffff ) );'` \
        --defsym _build_timestamp=1516878800 \
        -Map bin-x86_64-efi/e1000e.efidrv.tmp.map
--defsym:2: undefined symbol `obj_e1000e' referenced in expression
Makefile.housekeeping:1179: recipe for target 'bin-x86_64-efi/e1000e.efidrv.tmp' failed
make: *** [bin-x86_64-efi/e1000e.efidrv.tmp] Error 1
rm bin-x86_64-efi/version.e1000e.efidrv.o

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ipxe - 1.0.0+git-20180124.fbe8c52d-0ubuntu2

---------------
ipxe (1.0.0+git-20180124.fbe8c52d-0ubuntu2) bionic; urgency=medium

  * debian/copyright: update copyright information to satisfy lintian
    dep5 checks (LP: #1747071)
  * d/p/enable-https.patch: adding proper dep3 header

 -- Christian Ehrhardt <email address hidden> Mon, 05 Feb 2018 15:09:28 +0100

Changed in ipxe (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
Lukas Humbel (lukas-humbel) wrote :

Hi

I have installed the ipxe package (1.0.0+git-20180124.fbe8c52d-0ubuntu2) on ubuntu 18.04. However, there is no efi-e1000e.rom, and hence qemu does not work with a e1000e device. I'm trying to run the following command:

qemu-system-x86_64 -netdev user,id=network0 -device e1000e,netdev=network0 -nographic

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Lukas,
Yeah we only fixed vmxnet3 and gave up on e1000e, see the first section on comment #8.

e1000e had issues but was considered not too important to make this a big thing.
If there is a super-special really-hard-need-e1000e use-case then please file a new bug to discuss there.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.