Add riscv64 to the xCAT and xCATsn build paths, keep the unavailable legacy Genesis dependency conditional, collect the architecture RPMs, and document the forcearch mock target.
Add the riscv64 page to the cluster management guide (UEFI + grub2 boot
path, discovery through mknb's grub2 network configurations, stateful and
stateless provisioning, the dependency picture for a management node on
riscv64, limitations), list riscv64 in the node object attributes and in
the support matrices, add the architecture to the cross-build page for
stateless images, extend the grub2 install guide (and fix its swapped
x86_64/aarch64 file names), the uninstall package lists, the DHCP backend
validation matrix and the mknb/genimage man pages, and carry the riscv64
schema values into the generated nodetype, osimage, noderes, node and
group references.
Resolve the rocky10/rhels10 point releases through
imgutils::get_profile_def_filename with the OS search list emulated, and
assert the riscv64 files exist, win the lookup, match the x86_64 package
lists and point service images at the riscv64 dependency repository.
Provide the compute and service profiles for rocky10 and rhels10 on
riscv64: netboot pkglist/exlist/postinstall files and the service
otherpkgs lists for netboot and install. They mirror the x86_64 profiles
(every package resolves in the Rocky 10 riscv64 BaseOS/AppStream/CRB
repositories and the minimal-environment group exists there), with the
kbd keymap exclude spelled correctly, the duplicate man exclude dropped,
and goconserver pulled from the rh10/riscv64 dependency repository.
Pin the riscv64 installer kernel lookup in anaconda.pm and
geninitrd.pm, and evaluate the rh/genimage default driver and resolver
library blocks for riscv64 and the existing architectures.
Add an autotest nodeset case with bogus riscv64 grub2 nodes and a
rhels10.99 riscv64 osimage, checking the per-node grub2 files, the
grub2.riscv64 loader link and the hex-ip/mac links.
EL riscv64 media lay out the installer kernel and initrd under
images/pxeboot exactly like x86 and aarch64 media, but anaconda.pm only
looked there for those two families and geninitrd.pm refused riscv64
outright ("unknow arch"). Treat riscv64 like x86/aarch64 in both
places and recognise riscv64 kernels when a driver disk updates the
installer kernel. There is no riscv64 SUSE media, so geninitrd keeps the
unsupported-architecture error for sles/suse rather than reading the x86
SUSE layout.
Diskless images get a riscv64 default network driver list (virtio,
Intel, Realtek, Broadcom and Mellanox) and take the resolver libraries
from lib64, which is where riscv64 EL puts them.
Drive mknb riscv64 --configfileonly through the existing stubs and
assert the grub2 network configuration: name, cpu guard, kernel, initrd,
xcatd endpoint, serial console, lzma preference, no PXELINUX/xNBA/
petitboot output, removal without artifacts and for :noboot interfaces.
Also install a riscv64 Genesis export and reject it for another
architecture.
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.
Exercise _default_netboot() with the database-backed modules stubbed:
riscv64 defaults to grub2 and keeps any grub2 variant, the x86, PowerNV,
ppc, onie and aarch64 outcomes are unchanged, and undefined inputs do
not warn.
Discovery left noderes.netboot untouched for any architecture outside
x86, ppc and armv7l, so a discovered riscv64 node had no boot method and
nodeset failed to find a plugin for it.
Move the default-netboot ladder into _default_netboot(), which returns
the method to set or undef, and teach it that riscv64 nodes boot through
UEFI and grub2. The existing x86, PowerNV, ppc and onie rules are
unchanged; aarch64 is deliberately left as it was. The platform of the
discovery request is only read when the request carries it, so a node
that reports none does not gain the key, which would end up stored as
discovery data.
Assert the Kea xcat-riscv64 class (architecture 0x001b only, grub2
boot file, present with and without xNBA loaders) and pin the ISC
subnet block so the riscv64 branch stays ahead of the /yaboot
fallback that would otherwise shadow it.
RISC-V 64-bit UEFI firmware identifies itself with DHCP option 93
client-system-architecture 27 (0x001b, IANA processor architecture
types). Neither DHCP backend knew the value: Kea handed such clients no
boot file and ISC dhcpd fell through to the /yaboot catch-all.
Add an xcat-riscv64 Kea client class and an ISC subnet branch that send
them boot/grub2/grub2.riscv64, the same shape as the aarch64 entries.
The UEFI HTTP boot id (0x001c) is left alone: it needs a URL boot file
and the HTTPClient vendor class, which is a separate change.
Pin lookupNetboot, the profiled-node netboot rule table and the schema
descriptions for riscv64 without loading the database-backed modules:
the shipped subroutines are extracted from the source and evaluated
directly, so the test runs without DBI.
riscv64 nodes boot through UEFI and grub2 only, like ppc64le PowerKVM
guests and aarch64. Teach the three places that declare which
noderes.netboot methods an architecture accepts about it:
- xCAT::Utils::lookupNetboot returns grub2,grub2-tftp,grub2-http for
riscv64 so nodeset and rinstall accept those methods.
- the profiled-node rule table in xCAT::ProfiledNodeUtils defaults
riscv64 nodes to grub2.
- the nodetype.arch, osimage.osarch and noderes.netboot schema
descriptions document riscv64.
The arch token is riscv64 everywhere (rpm, dpkg and uname -m agree), so
no alias handling is added.
The IMM pending_build_id property is not guaranteed to identify the primary UEFI bank. Keep it out of the active version value and expose it as a separate firmware inventory record.
Recovered from original commit b79c005061 by Jarrod Johnson.
Co-authored-by: Jarrod Johnson <jarrod.b.johnson@gmail.com>
Vinícius Ferrão
Daniel Hilst