This is messier than I thought; CONFIG=qemu is likely not appropriate for the sub-packages "bootimgs" and "roms". I think the binaries for those packges will have to be built first, without CONFIG=qemu, then stashed. Then "make veryclean", and build the roms for QEMU with CONFIG=qemu.

%install will have to copy files from two places, the stash (for non-qemu ROMs), and src/bin as before (for QEMU ROMs).

(In reply to Laszlo Ersek from comment #17)
> This is messier than I thought; CONFIG=qemu is likely not appropriate for
> the sub-packages "bootimgs" and "roms". I think the binaries for those
> packges will have to be built first, without CONFIG=qemu, then stashed. Then
> "make veryclean", and build the roms for QEMU with CONFIG=qemu.
> 
> %install will have to copy files from two places, the stash (for non-qemu
> ROMs), and src/bin as before (for QEMU ROMs).

"make veryclean" is not necessary; I asked on #ipxe and it was confirmed:

<lersek_>       mcb30, I'd like to ask you a question about the new, nice
                named config build system
<lersek_>       mcb30, assume we'd like to build some binaries under src/bin
                with CONFIG=qemu
<lersek_>       mcb30, but some other binaries *without* any CONFIG=...
                setting
<lersek_>       we'd name the needed targets explicitly on the command line
<lersek_>       the question is, if we should run "make veryclean" between
                these
<lersek_>       or will the build system notice that the CONFIG=... setting
                changed from last time around
<lersek_>       and will it rebuild object files that are shared between the
                separate end-targets?
<robinsmidsrod> lersek: you shouldn't need make veryclean when CONFIG=
                changes
<robinsmidsrod> (unless you're using NFS and has some issues with timestamps
                confusing make)
<lersek>        robinsmidsrod, thanks!
<lersek>        not using NFS
<mcb30>         lersek: I can confirm that the build system will pick up the
                CONFIG= change (along with DEBUG=, EMBED= etc) and rebuild
                as necessary
<mcb30>         FWIW, I almost never run "make clean" or similar
<mcb30>         unless I'm testing intrusive changes to the Makefile itself
<mcb30>         and even then, what gets committed is intended to never
                require "make clean" when moving between git commits or
                changing build options
<lersek>        mcb30, awesome, thank you
<lersek>        very robust!

I'm taking this BZ -- I hope it's alright with you, Miroslav.

Ultimately, after a lot of churn, the changes are minimal. Only CONFIG=qemu
had to be added to the "make" commands in the spec file that build the
QEMU-oriented drivers (= the files collected in the ipxe-roms-qemu
subpackage).

Quite a bit of thinking and testing went into this from various sides:

- CONFIG=qemu is necessary in order to utilize upstream iPXE commit a200ad46
  ("[build] Add named configuration for qemu"). This is also what upstream
  QEMU commit cf2b4b5b77a7 does.

- CONFIG=qemu does not obviate our downstream commit 2ba75377 ("Customize
  ROM banner timeout"). (The commit hash I'm referring to here is from our
  most recent downstream branch, rhel7/master-4e03af8e.)

  Although upstream iPXE commit a200ad46 ("[build] Add named configuration
  for qemu", see above) also sets ROM_BANNER_TIMEOUT to 0, our spec file
  will use CONFIG=qemu only for the binaries that go into "ipxe-roms-qemu".
  Whereas downstream commit 2ba75377 modifies "src/config/local/general.h",
  thereby affecting all subpackages. Dropping downstream 2ba75377 would not
  break the "ipxe-roms-qemu" subpackage, but might regress the other
  subpackages.

  (It is not a problem that with CONFIG=qemu, the same setting is present in
  two different places. See upstream iPXE commit c801cb29, "[build] Allow
  for named configurations at build time")

- CONFIG=qemu does not obviate our downstream commit f21528e7 ("Use spec
  compliant timeouts") -- this patch has no counterpart in upstream, so we
  continue to need it.

- (See comment 19:) I asked on IRC, and got confirmation, that adding
  CONFIG=qemu will rebuild everything that depends on the changed
  configuration. This means we can avoid making "clean" or "veryclean"
  between building binaries for the "ipxe-bootimgs" plus "ipxe-roms"
  subpackages (where CONFIG=qemu would be harmful), *and* for the
  "ipxe-roms-qemu" subpackage (where CONFIG=qemu is required).

  Cleaning the tree between those steps would have been a huge mess,
  requiring us to stash the build outputs for "ipxe-bootimgs" and
  "ipxe-roms" temporarily.

- In order to verify the previous bullet, I implemented the CONFIG=qemu
  change for the "ipxe-roms-qemu" subpackage, and then compared the
  following pairs of RPMs with rpmdiff (the first component of each pair is
  our latest official build, from the rhel7/master-4e03af8e branch, while
  the second component of each pair was built with my patch on top):

  ipxe-bootimgs-20150821-1.git4e03af8e.el7.noarch.rpm
  ipxe-bootimgs-20150821-1.git4e03af8e.el7.rebase73_bz1298313.noarch.rpm

  ipxe-roms-20150821-1.git4e03af8e.el7.noarch.rpm
  ipxe-roms-20150821-1.git4e03af8e.el7.rebase73_bz1298313.noarch.rpm

  ipxe-roms-qemu-20150821-1.git4e03af8e.el7.noarch.rpm
  ipxe-roms-qemu-20150821-1.git4e03af8e.el7.rebase73_bz1298313.noarch.rpm

  rpmdiff only reported mtime and md5sum changes (no size changes).

  Then I picked, from each subpackage pair, one binary that rpmdiff reported
  different across the pair. I compared those variants with "vbindiff".

  For "ipxe-bootimgs" and "ipxe-roms", the differences were minimal and
  completely local (they looked like timestamps and such at the exact same
  offsets).

  From "ipxe-roms-qemu", I picked the virtio-net oprom. It was totally
  different without vs. with my CONFIG=qemu patch in place.

  This proves that the patch I'm about to post does not affect the
  ipxe-bootimgs and ipxe-roms subpackages, and affects the ipxe-roms-qemu
  subpackage.

- I also did functional testing. I reproduced bug 1181980 with
  "ipxe-roms-qemu-20150821-1.git4e03af8e.el7", and I confirmed that
  "ipxe-roms-qemu-20150821-1.git4e03af8e.el7.rebase73_bz1298313" fixed it.

Since this bug focuses on IPv6 enablement solely, and bug 1181980 has regained its role as tracking the iPXE-on-OVMF use case, and me too as its assignee, I'm unassigning myself here.

Does this include working UEFI support? We UEFI for Satellite 6 to support UEFI Host bootdisks.

Sean,

I think you mean bug 1295673. That one has been fixed.

Thanks
Laszlo

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2214.html