The upstream iPXE loader of an unknown x86 client will fetch its Genesis
discovery script from xcat/ipxe/nets. mknb writes the same BIOS, UEFI
and elilo scripts there as under xcat/xnba/nets. xcat/xnba/nets keeps
them for a server whose DHCP configuration still names it.
mknb wrote BOOTIF=01-${netX/machyp} into the BIOS Genesis script.
machyp is an xNBA setting, and stock iPXE expands it to an empty string.
Without the boot MAC, the legacy Genesis stops with "Unable to find boot
device" after at least 10 minutes. The OpenEmbedded Genesis fails at once
with BOOT_INTERFACE_NOT_FOUND.
Use ${netX/mac:hexhyp}, as the UEFI Genesis script and xnba.pm do. xNBA
expands both settings to the same value, so boot with xNBA is unchanged.
master moved 149 commits ahead of the branch point and four files needed a
decision.
xCAT/debian/control and xCATsn/debian/control: master moved nmap and
ipmitool-xcat into Depends, raised the ipmitool version and added the s390x
OpenEmbedded Genesis recommendation. The branch made the genesis-scripts
dependency per architecture. Both are kept, so the ppc64el metapackage depends
on xcat-genesis-scripts-ppc64el and no longer on the amd64 package.
build-utils/lib/XCAT/BuildUtils.pm and xCAT-test/unit/build_utils.t: master
replaced @DEB_ARCHES plus the branch's %NO_RISCV64 exception list with
%ARCH_PACKAGES, which carries the architecture list per package.
deb_package_arches returns the same answer for every package, so master's form
is kept and %NO_RISCV64 is dropped.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
The note shown when boot/grub2/grub2.<arch> is missing told the
administrator it comes from grub2-xcat or the EL installation media. On
Ubuntu neither is true: copycd builds the loader from the grub2 package on
the media, because the image the media carry cannot boot over the network.
Signed-off-by: Vinícius Ferrão <2031761+viniciusferrao@users.noreply.github.com>
The legacy branch ran both copies and kept only the second exit status, so an unreadable
Genesis root tree left mknb exiting 0 with an initramfs built from nothing -- the node then
never boots and nothing names the cause. A failing kernel copy was reported as a failure of
the root tree, because the message was chosen from a flag set before either copy ran.
Return on the first failing copy, carrying the name of the file that could not be read.
mknb_genesis_staging.t goes from 2 failures to green on this commit.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
(cherry picked from commit d46ca3e09bf52827bf0b8fa9cb94279a9da2c97b)
mknb stages the Genesis payload before building a netboot image, and those copies are the
only point at which it learns that an installed Genesis image is unusable. The legacy branch
runs two of them and keeps only the second exit status, so an unreadable root tree is
invisible: mknb exits 0 having built an initramfs from nothing, and the node never boots
with no error naming the cause. When the kernel copy is the one that fails, the message
blames the root tree instead.
Extract the staging decision as stage_genesis_payload, preserving today's behaviour exactly,
so the outcome can be driven with an injected runner instead of a real Genesis tree.
The test fails on this commit, 2 of 10: 'an unreadable root tree fails the step' and 'the
failure names the kernel, not the root tree'.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
(cherry picked from commit 989deaa31eb1f3979a8db030d3ae8c404abda2fb)
Five comments in the discovery path explained a consequence chain or
justified the code to a reviewer rather than stating what is not visible
locally: the payload protocol the code below already shows, a rationale
for the missing boot loader message, the two Genesis compression
variants, the HTTP and TFTP entry pair, and the :noboot divergence from
the PXELINUX files. Say the non-obvious part once.
Comments only; no executable line changes.
The grub2 discovery configuration loaded the Genesis kernel and initramfs
over TFTP, a lockstep protocol that acknowledges every block and runs one
server process per client. Fetching the same 79 MiB Genesis image from a
node on the lab network took 61.5 s over TFTP and 1.2 s over HTTP, and a
whole cluster discovering at once queues on the TFTP server.
Write two entries instead. The default one sets root to the HTTP server
of the management node on that network and loads the same files from
below the TFTP root, the way nodeset does for netboot=grub2-http; the
second keeps the TFTP paths for a management node that does not serve the
TFTP root over HTTP, and "set fallback=1" moves to it when GRUB cannot
fetch the payload over HTTP. site.httpport is honoured.
mknb only knew how to publish a discovery boot configuration for x86
(PXELINUX and xNBA) and POWER (petitboot). Any other architecture got a
Genesis kernel and initramfs under /tftpboot/xcat and nothing that would
make a firmware boot them, so riscv64 discovery could not start.
riscv64 nodes boot through UEFI and grub2. Write one grub2 configuration
per network, /tftpboot/boot/grub2/grub.cfg-<network hex prefix>, using
the same network keys as the PXELINUX files. A net-booted grub2.riscv64
searches grub.cfg-01-<mac>, grub.cfg-<8 hex ip> and then shorter prefixes
of the ip, so the per-node files that nodeset writes keep priority and
the network file is only reached by clients without a node configuration.
The file is regenerated from the published Genesis artifacts (lzma
preferred over gzip), guarded by $grub_cpu so other grub2 architectures
can share it later, carries the xcatd endpoint, the serial console and
BOOTIF=$net_default_mac, and is dropped for networks served by a
:noboot interface. It is written by name rather than into an existing
file, because on a /32 network nodeset's hard link for the node carries
the same name.
Publishing a Genesis image now also drops the other compression variant
of that architecture, so a leftover genesis.fs.<arch>.lzma can no longer
be paired with a freshly published kernel by this configuration or by
--configfileonly. And since these configurations are only reachable
through grub2.<arch>, which xCAT does not build, a missing boot loader is
reported instead of leaving the nodes to time out in firmware.
xcatconfig now also runs mknb riscv64 when xCAT-genesis-base-riscv64 is
installed, and the usage text lists the architecture.
The genesis image goes into a file whose name ends with .lzma. The plugin
writes that file only when /usr/bin/lzma is there, and it falls back to gzip
when it is not.
Red Hat ships no lzma binary. On AlmaLinux 9 and on AlmaLinux 10 that test
fails, the plugin falls back to gzip, and it gives no message that says why.
The image is larger on each run of mknb. Debian and Ubuntu ship lzma as a
second name for xz, so those systems still get the smaller image.
Ask xz for the same container when lzma is absent. The command
"xz --format=lzma" writes the same bytes as "lzma", so the file keeps its
name, its container and its size. Keep the gzip fallback for a system that
has neither program.
Recovered from the lenovobuild branch, which asked xz for the xz container.
That container is not the lzma container, and the name of the file says lzma.
Boot URLs handed to nodes always carried an explicit :80 even when the HTTP
server listens on the default port. grub2.pm already omits the port when it is
80; make the xNBA, genesis and DHCP boot URLs consistent with it.
$portsuffix is empty when site.httpport is unset or 80 and ":<port>" otherwise,
so a non-default port is unchanged. Covers the ISC and Kea paths in dhcp.pm,
xnba.pm, mknb.pm, and the Kea xNBA client classes in BootPolicy.pm.
dhcp_boot_policy.t and mknb_xcatd_address.t follow the new URLs and gain cases
for a non-default and an unset port. The floating-address guard in
mknb_xcatd_address.t also drops :80 so that it keeps matching.
Recovered from the unmerged lenovobuild branch (cd61fd9d, a2f77ea9, 1035841b,
b7db0e2, 792fe6d).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
mknb writes the compressed genesis filesystem by streaming cpio output
straight onto the final path in $tftpdir/xcat (genesis.fs.$arch.lzma or .gz).
When two mknb/nodeset runs target a shared $tftpdir at once, one run reads or
overwrites the other's half-written image, producing a corrupt genesis.fs and
failed netboots.
Write each image to a uniquely-suffixed temporary file
(xCAT::Utils::genpassword(24)) and File::Copy::move() it into place. move()
within the same directory is a rename, so the final path only ever appears
complete. Both modules are already imported by mknb.pm.
Recovered from the unmerged lenovobuild branch (originals c651e7b8 and its
fix da0723f2, which switched the suffix to genpassword after the first
attempt only produced a single character). master lacks the branch's xz
path, so only the lzma and gzip paths are adjusted here.
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
The quiet kernel parameter was hardcoded in anaconda.pm and sles.pm,
making it impossible for admins to get verbose boot output without
editing plugin source code. The existing addkcmdline mechanism
(bootparams and linuximage tables) only appends to the kernel command
line, so there was no way to remove quiet.
Move quiet out of the plugin kcmdline construction and into the
linuximage.addkcmdline default set during copycds osimage creation.
Admins who want verbose boot for debugging can now remove it per
osimage:
chdef -t osimage <image> addkcmdline=""
New osimages get addkcmdline="quiet" by default. Existing osimages
with a custom addkcmdline are not overwritten on re-run of copycds.
Genesis/discovery boot (mknb.pm) is unchanged as it does not use
osimage definitions.
Addresses #6916
Previously the code which created the netboot config files was
incorrectly specifying the initrd file name in a number of places,
particularly in the xcat/xnba/nets/* files, using a hard-coded `.gz`
suffix even when a `.lzma` file had been created. This change ensures
that the initrd file name determined earlier in the code (either when
the image is created, or in the configonly case by checking the
filesystem) is used correctly when creating the netboot config files.
Vinícius Ferrão
Daniel Hilst
davidmonro
besawn
Mark Gurevich
Simon Fowler
Yuan Bai
yangsbj
GONG Jie
Jarrod Johnson
Bin Xu
ertaozh