go-xcat stopped on riscv64 before it reached the package manager, so the
installer xCAT documents could not set up the management node the riscv64
packages are built for. The architecture is now accepted alongside the
others.
Signed-off-by: Vinícius Ferrão <2031761+viniciusferrao@users.noreply.github.com>
The Ubuntu driver table had no riscv64 entry, so genimage was handed an
empty list and built an image carrying no network module. A node whose NIC
is not built into the kernel then has no interface to fetch its root
filesystem with. The architecture now gets the same drivers the enterprise
Linux table lists for it, plus the overlay module every Ubuntu image needs.
Signed-off-by: Vinícius Ferrão <2031761+viniciusferrao@users.noreply.github.com>
archive.ubuntu.com publishes amd64 and i386 only, so debootstrap could not
find a single package for a ppc64el or riscv64 netboot image and genimage
failed on every architecture except x86. The default mirror is now the
ports archive for those architectures. site.ubuntu_apt_mirror still
overrides it, for a local mirror that serves every architecture.
Signed-off-by: Vinícius Ferrão <2031761+viniciusferrao@users.noreply.github.com>
24.04 and 26.04 had no riscv64 package list, so a diskless image or an install
for the architecture fell back to the generic list and reached debootstrap
without a kernel or the tools the boot scripts call.
The lists hold the same packages as their x86_64 counterparts. Every one of
them is published for riscv64 in noble and resolute, main or universe.
Signed-off-by: Vinícius Ferrão <2031761+viniciusferrao@users.noreply.github.com>
The image carries the name service libraries of its architecture, and riscv64
matched neither the x86_64 nor the ppc64el branch. It fell through to the
generic path, which looks for lib/libnss_dns.so.2, so a riscv64 image shipped
without a resolver and the node could not resolve any name.
Ubuntu keeps them in lib/riscv64-linux-gnu, confirmed in the 24.04.4 riscv64
server filesystem.
Signed-off-by: Vinícius Ferrão <2031761+viniciusferrao@users.noreply.github.com>
The go-xcat shell behavior tests were written as Perl harnesses, which made the shell assertions harder to read and kept shell-specific setup outside a native shell test framework.
Add BATS to the GitHub Actions dependency set, run BATS tests from the same preserved source tree as the Perl unit suite, and move the go-xcat repository checks into xCAT-test/autotest/bats.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Both copies refused to run unless /usr/sbin/tcpdump existed. Debian and Ubuntu
install it as /usr/bin/tcpdump, so the rogue DHCP detector never ran there and
the probe reported its tcpdump check as failed.
Resolve tcpdump through PATH and the standard system directories with
CommandUtils::find_executable, run the resolved path, and match that path when
the capture process is killed at the end.
The shared Ubuntu lists serve every release and architecture without a list
of its own, and ospkgs hands the whole list to one apt-get install, so one
unknown name loses every package on it. ntp and ntpdate are gone from 26.04.
libodbc1 is the unixODBC runtime name up to 22.04. libvirt-bin is gone from
20.04 on and qemu-kvm from 22.04 on.
The shared lists keep ntp and ntpdate, so releases up to 24.04 keep the
daemon they had. 26.04 gets release lists that carry chrony. unixodbc
replaces libodbc1 on every release, and the odbcsetup postscript keeps its
runtime. The service lists add libdbd-pg-perl beside libdbd-mysql-perl, as a
service node may run the xCAT database on PostgreSQL. libvirt-daemon-system
with libvirt-clients replaces libvirt-bin from 18.04 on; 12.04, 14.04 and
16.04 keep kvm lists with the old names.
qemu-kvm was a transitional name for the emulator of the host architecture,
and no current release has one name for that. Per-architecture kvm lists
name the native one: qemu-system-x86 on x86_64, qemu-system-ppc on ppc64el,
qemu-system-misc on 24.04 riscv64, with ppc64le linked to ppc64el as the
other lists do. The shared kvm lists fall back to
qemu-system, which carries every emulator, so an architecture without a list
of its own still gets one. On 26.04 riscv64 libvirt-daemon-system depends on
qemu-kvm or qemu-system and nothing provides qemu-kvm, so apt installs that
fallback there whatever the list names. Every kvm list names qemu-utils:
ospkgs installs without recommends, and libvirt needs qemu-img for the qcow2
volumes kvm.pm creates.
The check ran on EL9 only, and only when the version carried a minor number,
so CentOS Stream was never checked. On EL10 a management node without EPEL
or CRB failed inside dnf install with a dependency error instead of the
message that names the missing repository. The CRB message proposed a CentOS
Stream repository file with signature checks disabled, on every
distribution. The probe used dnf list, which an installed copy of the probe
package satisfies with the repository disabled, and which reports a failed
query as a missing repository.
Check EL9 and EL10, with or without a minor version. Probe the enabled
repositories with repoquery for the host architecture and noarch, so a
source repository does not stand in for the binary one, and stop with the
package manager's own error when the query fails. Name the EPEL release
package of the running major version. For CRB, name crb enable from a
current epel-release, which handles Red Hat Enterprise Linux under both
subscription management and RHUI, Rocky Linux, AlmaLinux and CentOS Stream,
and the dnf config-manager command for Oracle Linux.
genimage translated one architecture for debootstrap, x86_64 to amd64, and
compared against a bareword rather than a string, which only resolves because
the script does not enable strict subs.
Read the name from xCAT::Utils, which genimage already loads. Every
architecture reaches debootstrap with the name it does today.
The boot flip in compute.subiquity.tmpl addressed port 3002. xcatd's install
monitor listens on site.xcatiport, so a cluster that moves the port loses the
flip and every node PXE-loops back into the installer. The flip now reads
site.xcatiport and keeps 3002 as the default. TABLEBLANKOKAY, because the key is
optional and a plain TABLE lookup of an absent key fails the whole template.
The flip also counted any reply as an accepted request. It now requires the
monitor's "ready" greeting before it sends "next", and "done" afterwards, so a
different service on that port is not read as a flipped node.
subiquity_nfsroot_server in debian.pm called getipaddr without a family. A
dual-stack management node answers with its IPv6 address, and casper takes
everything after the first colon in nfsroot= as the path, so the live filesystem
never mounts. It now asks for IPv4, as dhcp.pm and mknb.pm do.
The DNS setup wrote the xcatmaster name as a nameserver when getent found no
address, which is the case the step exists to prevent. It now keeps the
resolv.conf DHCP gave the live installer.
ubuntu_subiquity_boot_flip.t, debian_subiquity_boot_params.t and
ubuntu_resolvconf_ip.t fail on the parent commit and pass here.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Add xCAT::NTP::Backend, a selector for the NTP daemon xCAT configures, in the same
spirit as xCAT::DHCP::Backend. It honours site.ntpbackend, defaults per distro family
(EL7+/SLES15+ chrony, older ntpd, Ubuntu/Debian chrony), and downgrades to whichever
of chrony/ntpd is actually installed rather than installing a second daemon. makentp
selects through it instead of probing /usr/sbin/chronyd directly, so the choice is one
unit-tested code path.
Guarantee the daemon at install time: the xcat metapackage now Depends on
"chrony | ntp" and the xCAT rpm Requires "(chrony or ntp)". Both sit beside the
existing service dependencies the metapackage already declares -- isc-dhcp-server|kea,
apache2, nfs-kernel-server -- because an MN that cannot serve time cannot serve its
compute nodes, and Ubuntu's default systemd-timesyncd is a client only.
Stop requiring hwclock in setupntp. It only persists the already-stepped system clock
to the RTC, and Ubuntu 24.04 moved it to util-linux-extra, absent on minimal images --
so a fatal check_exec_or_exit aborted the entire NTP setup, including the clock step
that does not use it. Use it when present, log and continue when not, and pull
util-linux-extra through Recommends and the diskless pkglist so it usually is.
Disable systemd-timesyncd there too. It ships as part of systemd rather than a
time-daemon package, so nothing displaces it, and it keeps disciplining the clock
against the daemon being configured.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
EL10 defines no default crash kernel reservation for riscv64, so the
installer's kdump add-on falls back to writing the literal
"crashkernel=auto" into the boot loader arguments of the installed
system. EL10 kernels dropped support for that value: nothing is
reserved, but the string is on the command line, so kdump.service passes
its condition and then fails on every installed riscv64 node.
Turn the add-on off in the riscv64 templates. Nodes come up with kdump
inactive instead of failed, and a node that should take crash dumps gets
a real reservation the usual way, through linuximage.addkcmdline or
bootparams.addkcmdline.
The EL10 anaconda has no RISC-V EFI platform: on riscv64 it asks for the
x86 UEFI boot loader packages (grub2-efi-x64, shim-x64), which do not
exist, and registers the UEFI boot entry as \EFI\<distro>\shimx64.efi,
so a kickstart install stops at the missing packages and, once tolerated,
leaves a system the firmware cannot boot.
Add riscv64 templates for the rocky10/rhels10 compute and service
profiles that are the shared templates plus %packages --ignoremissing and
a %post fix-up, riscv64 package lists that add grub2-efi-riscv64 and
efibootmgr to the shared lists, and the fix-up itself
(post.rhels10.riscv64): it copies \EFI\<distro>\grubriscv64.efi to the
removable-media path \EFI\BOOT\BOOTRISCV64.EFI and re-points the UEFI
boot entry at grubriscv64.efi, so the installed node boots from disk with
or without usable NVRAM. Reinstalling a node replaces that entry instead
of adding another one.
The %post of a kickstart is a single shell script, into which xCAT
splices every #INCLUDE, and post.rhels10/post.rhels8 end it with
"exit 0"; the fix-up is therefore included ahead of them. The shared
templates and other architectures are unchanged.
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.
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.
Resolve optional Mellanox network drivers against the target image's selected kernel. Keep real mlx_en modules, fall back to mlx4_en, include available mlx5_core, and omit missing defaults without changing explicitly requested netdrivers.
Two ways the Subiquity install could fail without saying anything useful.
The boot flip read from the install monitor with no timeout. A monitor that accepts the
connection and then never answers -- which #7759 shows is a state it gets into -- blocked the read
forever, and with it the Subiquity late-command and the install. The retry loop could not help:
it never reached the retry. Both reads now take -t 10, so five attempts are bounded at roughly two
minutes and end in the failure that is already logged. The regression test stands up a listener
that accepts and holds the connection; removing the timeouts fails it.
mkinstall resolved the install server for nfsroot and fell back to the name when that failed:
"getipaddr($instserver) || $instserver". The name is the original defect -- klibc's nfsmount
cannot resolve one -- so the node panicked "can't parse IP address" at boot, on the node, with
nothing reported on the management node. The management node knows at template time, so it says
so there and skips the node, as the other unrecoverable per-node conditions in this routine do.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
The comment blamed mawk: updateflag.awk needs gawk's |& and Ubuntu's /usr/bin/awk is mawk. That
is wrong on this path -- compute.subiquity.tmpl has installed gawk in the target since Ubuntu
20.04 support was added, so updateflag.awk would have found it.
The flip was going unanswered because xcatd's install monitor, which serves port 3002, dies and
is never re-forked. That is fixed in #7759. The /dev/tcp exchange here is hardening: it retries
and reports, rather than reinstalling in silence.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Three passes of the same reasoning had accumulated: in the code, in the POD of the routines the
previous commit extracted, and again in the test headers. Say each once, where the reader needs it.
The POD blocks were the worst of it -- extracting subiquity_kcmdline() and
defer_syncfiles_to_postboot() moved the essays out of the routines but did not shorten them. The
toram paragraph ran eleven lines for one kernel argument; the exact systemd-shutdown message and
the size of the 24.04 layers are colour, not reasoning.
The template's two comments and the apt-sources pair are trimmed the same way: the sources.list
explanation lives in Template.pm, and the test says which case it is checking and points there.
That the tests still pass after rewriting the template is the point of the previous commit -- a
test matching its text would have broken here.
47 comment and POD lines removed, no behaviour change.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Treating an empty noderes.installnic as "mac" skipped noderes.primarynic: a node
that configures only primarynic was installed with a netplan matching on mac.mac
that never renamed the interface, and a primarynic holding a MAC address was
ignored. The order xCAT uses everywhere else is installnic -> primarynic ->
mac.mac, with either attribute allowed to hold an interface name or a MAC
address, and xCAT::NetworkUtils::gen_net_boot_params already implements it for
the netboot kernel parameters.
Resolve it in Perl and hand the template the answer:
- xCAT::Template::subiquity_install_netcfg() delegates the order to
gen_net_boot_params and returns the netplan set-name (empty when the device is
matched by MAC alone) and the address to match on, with mac.mac parsed by
xCAT::Utils::parseMacTabEntry so |-separated, !hostname-suffixed entries
resolve to THIS node rather than to whichever entry came first.
- #SUBIQUITYINSTALLNIC# / #SUBIQUITYINSTALLMAC# render those two values.
installnic and primarynic are read blank-okay -- a node that sets neither is
normal, and is exactly what "match on mac.mac" means -- while mac.mac stays a
required lookup, as it was when the template read it directly.
- compute.subiquity.tmpl consumes the resolved values. No part of the fallback,
and no mac.mac parsing, is left in shell: it only chooses whether to emit
set-name, based on whether a name was resolved.
ubuntu_subiquity_installnic.t now passes: the six resolution cases, multi-entry
mac.mac, and the netplan the template's own late-command writes for a resolved
name and for none. ubuntu_subiquity_template.t asserts the template no longer
reads installnic/primarynic or parses MACs itself.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Promote bind9 from Recommends to Depends on the xcat and xcatsn metapackages. bind9 is
required by makedns, so it must be a hard dependency regardless of the system's APT
recommendation policy -- xCAT manages the cluster DNS through makedns/named, which
makes a DNS server as essential to a management or a service node as the DHCP backend
already declared beside it ("isc-dhcp-server | kea"). As a Recommends it was installed
only while that policy asked for it: an Ubuntu 26.04 management node came up with no
/usr/sbin/named and makedns failing with "failed to start named".
Strip only a trailing third component when deriving the debootstrap suite in the
Ubuntu netboot genimage. The previous s/\.\d+$// also removed the minor from a
two-part osvers, so an initial release with no point-release ISO -- ubuntu26.04, but
equally an initial-release 18.04/20.04/22.04 -- reached debootstrap as a bare major.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Boot the live installer correctly. Add boot=casper so casper actually processes
netboot=nfs instead of scanning local disks and panicking, resolve the install server
to a literal IP because casper mounts the live filesystem with klibc's nfsmount which
has no resolver, and add toram so casper copies the squashfs into RAM and unmounts the
NFS source. That last one is what lets the node reboot at all: with the NFS root still
mounted, systemd-shutdown waits forever on an lvm/pvscan wedged in uninterruptible I/O
on it and the node never power-cycles into the disk it just installed. casper has no
cmdline knob for NFS mount options -- it parses only nfsroot= and takes the whole value
as the path -- so toram is its supported way to avoid a network root.
Write the installer's resolv.conf nameserver as an IP. glibc's resolver discards a
hostname given on a nameserver line, so the xcatmaster name left the installer, and
the in-target apt that inherits the file, with no DNS at all.
Add the online archive through apt `sources:` on classic-sources releases, where
Subiquity renders the target sources.list from the install media alone and in-target
apt cannot find packages the ISO does not carry. Deb822 releases are excluded: their
primary mirror already lands in ubuntu.sources, so legacy .list files would configure
the same suites twice.
Flip the node to local-disk boot from the live installer over bash's /dev/tcp instead
of relying on updateflag.awk, which needs gawk's |& coprocess while Ubuntu's
/usr/bin/awk is mawk. The exchange is checked, and a failure is recorded in the
install log rather than silently PXE-looping into another install.
Defer syncfiles to the postbootscripts on the diskful install path, so it runs on the
booted node with sshd up rather than inside the in-target chroot where the MN cannot
reach it.
Make the test harness's provision wait overridable through WAIT_FOR_PROVISION; the
default stays short so a boot loop still fails fast.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Resolve installnic with the non-fatal #TABLEBLANKOKAY# token so an absent
noderes.installnic renders blank instead of aborting xnba generation, and treat an
empty installnic exactly like "mac": match the interface by its boot MAC address and
do not rename it. That is the same default EL and SLES already get, since their
statefull templates never reference installnic at all.
Nodes that do set noderes.installnic are unaffected -- the set-name branch is
unchanged. The diskless/netboot path never referenced installnic and is untouched.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
The scan wrote each disk into a file named after the identifier it
reported, wwn, path or neither, and read back the groups of one such
file only. Two disks that reported different identifiers therefore
never competed on their driver group: a disk without a WWN was dropped
as soon as another disk reported one, and when the last disk scanned
reported a WWN the readback opened the WWN files alone. A direct
attached boot disk that reports no WWN thus lost to a RAID volume that
reports one, which is the case the driver groups exist to decide.
Write every disk into the file of its driver group and keep the
identifier as the sort key inside that group, ranked so that a WWN
sorts ahead of a path and a path ahead of no identifier. The driver
group now decides first for every disk, the identifier still decides
between disks of one group, and no disk is dropped from the scan.
The device filter accepted sd, hd, vd and nvme names, so the xvd names
that a Xen guest presents never entered the scan. On such a guest the
whole detection ran on an empty list and the script fell through to the
xvda fallback, which takes the first Xen disk without looking at any of
them.
Accept the xvd names in the filter. A Xen disk now goes through the
same classification, kernel search and driver sort as any other disk,
so a guest with more than one disk gets a chosen disk rather than the
first one. The fallback stays for the case where the scan still finds
nothing.
The nvme branch of the filter is anchored at the same time, so a name
only matches when it starts with nvme.
The RHEL 10 support added a second copy of the script. The copy carries
the Xen fallback and a failure log that the common script does not, and
the common script carries the Intel RSTe/VROC fallback that the copy
does not. A RHEL 10 node whose OS disk is a VROC volume therefore fell
back to /dev/sda, and every later fix to disk selection had to be
written twice to reach both.
Fold the Xen fallback and the failure log into the common script and
delete the copy. The RHEL 10 installer includes the common script, as
the other installers already do. The failure log runs only when the
including script defines msgutil_r, because the subiquity path does
not.
The driver sort put the ahci and ata_piix controllers in the same
choice group as the PMC MaxRAID and megaraid_sas RAID controllers. On a
server with both, the sort could select a RAID data volume as the OS
install disk.
Move the RAID controllers to the second choice group. The direct
attached controllers hold the likely boot volume, and a server with
only RAID volumes still selects them from the second group. The SAS
host adapters move to the third group and every other driver to a new
fourth group, so the relative order of the remaining drivers does not
change. The RHEL 10 installer includes its own copy of the script, so
both carry the change.
Recovered from the lenovobuild branch.
PR #7677 added xCAT-server/share/xcat/netboot/rh/compute.rhels9.ppc64le.pkglist
with a stray empty line at the end of the file. The reviewer asked for it to be
removed before merge, but it slipped through. A trailing blank line in a pkglist
is meaningless and inconsistent with the rest of the netboot package lists, so
remove it.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Vinícius Ferrão
Vinícius Ferrão
Daniel Hilst
Vinícius Ferrão