iPXE packages rebased to support IPv6 on physical computers
The _ipxe-bootimgs_ and _ipxe-roms_ packages have been rebased to upstream commit 6366fa7a to support network booting over IPv6 on physical installations of Red Hat Enterprise Linux 7.
Description of problem:
Rebase ipxe to a current upstream release. This is needed for ipv6 support.
The last rebase occurred on 17-May-2013.
The last baseline git hash: c4bce43c3c4d3c5ebb2d926b58ad16dc9642c19d
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
<lersek_> mcb30, but some other binaries *without* any CONFIG=...
<lersek_> we'd name the needed targets explicitly on the command line
<lersek_> the question is, if we should run "make veryclean" between
<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
<robinsmidsrod> lersek: you shouldn't need make veryclean when CONFIG=
<robinsmidsrod> (unless you're using NFS and has some issues with timestamps
<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
<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
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
(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
- 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):
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
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
- 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.
I think you mean bug 1295673. That one has been fixed.
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.