Repository navigation
Conversation
…h it iPXE ships NET_PROTO_IPV6 off: src/config/general.h of xnba-1.21.1 comments the define out, and xnba-1.20.1 undefines it. The loader therefore has no IPv6 at all. A node that netboots over IPv6 reaches xNBA and stops at "No configuration methods succeeded" without ever sending a DHCPv6 solicit, while iPXE 2.0.0 on the same network solicits and configures. config/local/general.h is included after the defaults, so it is where the protocol is turned on. The guard keeps it out of undionly.kkpxe: a BIOS PXE ROM has a size limit, and BIOS PXE has no IPv6 form to use it with. Measured with the preprocessor: PLATFORM_efi enables it, PLATFORM_pcbios does not. Built and booted on an IPv6-only alma10.1 node. The rebuilt loader reports "Configuring (net0 ...) ok" and "net0: 2001:db8:149::1002/64 gw fe80::...", and the DHCPv6 server logs a solicit from xNBA's own DUID beside the firmware's. The loader it replaces logged only the firmware's. This changes the compile recipe alone. mockbuild.pl writes its own spec and packages the checked-in binary/xnba.efi, so the shipped loader is unaffected until that binary is rebuilt. That binary reports xNBA 1.20.1+ while this spec builds 1.21.1, so rebuilding it also moves the loader a release, which is a separate decision. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
This reverts the override added in df0d056. iPXE 1.21.1 enables the protocol for EFI in config/defaults/efi.h, which general.h includes before the line that comments NET_PROTO_IPV6 out, so an EFI build already has IPv6. Building undionly.kkpxe and snponly.efi with and without the override gives byte identical images: 67789 and 187904 either way. The real defect is that the loader the package ships is not the one this spec builds. binary/xnba.efi reports xNBA 1.20.1+, and 1.20.1 carries no NET_PROTO_IPV6 in config/defaults/efi.h at all, which is why an IPv6 node reaches xNBA and stops at "No configuration methods succeeded" without ever sending a DHCPv6 solicit. Rebuilding the binary from the source this spec already names is the whole fix: the rebuilt loader configures over IPv6 and solicits with its own DUID, measured on an IPv6-only alma10.1 node. That rebuild replaces a checked-in artifact used by every xnba node and moves the loader a release, so it is recorded rather than made here. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
binary/xnba.efi reported xNBA 1.20.1+ while xnba-undi.spec builds 1.21.1, so the package shipped a loader its own recipe does not produce. 1.20.1 carries no NET_PROTO_IPV6 in config/defaults/efi.h, and 1.21.1 does, so the stale binary is why an IPv6 node reaches xNBA and stops at "No configuration methods succeeded" without ever sending a DHCPv6 solicit. Both loaders are rebuilt from xnba-1.21.1.tar.bz2 with the six patches the spec applies, on an alma10 host with the BuildRequires the spec names. The EFI loader gains IPv6 and grows from 155520 to 187904 bytes. The BIOS loader grows from 66899 to 67789, which is the release difference and not the protocol: built with and without an explicit NET_PROTO_IPV6 override, undionly.kkpxe is byte identical at 67789, because config/defaults/efi.h reaches only the EFI build. Measured on an IPv6-only alma10.1 node with the DHCPv6 boot file pointed at xnba.efi. The shipped loader logged only the firmware DUID and stopped. The rebuilt loader reports "Configuring (net0 ...) ok" and "net0: 2001:db8:149::1002/64 gw fe80::4054:ff:fec9:95d3", and the server logs a solicit from xNBA's own DUID beside the firmware's. xnba stays out of the DHCPv6 boot file gate in xcat-core until this loader ships, because a node offered a boot file its loader cannot use waits for a timeout it cannot diagnose. Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Contributor
Author
|
Closing in favour of netboot=ipxe for IPv6 on x86_64. The rebuilt xnba.efi does speak DHCPv6, but xCAT gives xnba nodes no DHCPv6 boot file. Over v6 xNBA also sends user class iPXE, not xNBA, so the second stage never matches and the loader would chainload itself. ipxe runs the same xnba.pm scripts and already has IPv6 and Secure Boot. The stale binary/ against the 1.21.1 spec is still real, and it's worth fixing on its own by building from the spec. |
Member
I agree. iPXE will be the way forward and we shouuld estimulate it's usage. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The xnba loader cannot netboot a node over IPv6. The node reaches xNBA and stops at
"No configuration methods succeeded" without ever sending a DHCPv6 solicit, so its firmware
releases the address and gives up.
The cause is that the package ships a loader its own spec does not build.
binary/xnba.efireports
xNBA 1.20.1+whilexnba-undi.specbuilds 1.21.1, and 1.20.1 carries noNET_PROTO_IPV6inconfig/defaults/efi.h. 1.21.1 does, so rebuilding the binary from thesource the spec already names is the whole fix.
Both loaders are rebuilt from
xnba-1.21.1.tar.bz2with the six patches the spec applies. TheEFI loader grows from 155520 to 187904 bytes and gains IPv6. The BIOS loader grows from 66899
to 67789, which is the release difference and not the protocol: built with and without an
explicit
NET_PROTO_IPV6override,undionly.kkpxeis byte identical at 67789, becauseconfig/defaults/efi.hreaches only the EFI build.Measured on an IPv6-only AlmaLinux 10.1 node with the DHCPv6 boot file pointed at
xnba.efi.The shipped loader logged only the firmware DUID and stopped. The rebuilt loader reports
Configuring (net0 ...) okandnet0: 2001:db8:149::1002/64 gw fe80::4054:ff:fec9:95d3, andthe DHCPv6 server logs a solicit from xNBA's own DUID beside the firmware's.
The branch carries a first attempt and its revert. That attempt added a
config/local/general.hoverride, which the byte identical builds above show does nothing