Bug 1298313 - ipxe: rebase for ipv6 support
Summary: ipxe: rebase for ipv6 support
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipxe
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Miroslav Rezanina
QA Contact: Amit Ugol
Yehuda Zimmerman
Depends On:
Blocks: 1267030 1300702 1300704 1335964 1350167
TreeView+ depends on / blocked
Reported: 2016-01-13 18:17 UTC by Jeff Nelson
Modified: 2016-11-04 00:37 UTC (History)
21 users (show)

Fixed In Version: ipxe-20160127-1.git6366fa7a.el7
Doc Type: Rebase: Enhancements Only
Doc Text:
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.
Clone Of:
Last Closed: 2016-11-04 00:37:53 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2214 0 normal SHIPPED_LIVE ipxe bug fix and enhancement update 2016-11-03 13:24:33 UTC

Description Jeff Nelson 2016-01-13 18:17:58 UTC
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

Comment 17 Laszlo Ersek 2016-01-21 02:54:39 UTC
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).

Comment 19 Laszlo Ersek 2016-01-21 18:26:58 UTC
(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=...
<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
                separate end-targets?
<robinsmidsrod> lersek: you shouldn't need make veryclean when CONFIG=
<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!

Comment 20 Laszlo Ersek 2016-01-21 22:15:50 UTC
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
  "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):




  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.

Comment 25 Laszlo Ersek 2016-02-23 17:10:14 UTC
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.

Comment 45 Sean O'Keeffe 2016-09-14 14:32:20 UTC
Does this include working UEFI support? We UEFI for Satellite 6 to support UEFI Host bootdisks.

Comment 46 Laszlo Ersek 2016-09-14 14:42:24 UTC

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


Comment 51 errata-xmlrpc 2016-11-04 00:37:53 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.