Add a unit test for the entry decision of the blade preprocessor. The test
lifts the entry out of the plugin source and drives it, because the plugin
needs a management node to load in full.
The test gives the entry the request that a booting node sends, which names
no node, and shows that the entry hands it on and answers no error. It also
shows that a request for another command without a noderange is still
refused.
A node that boots sends a findme request to say that it is there. That
request names no node, because the node is what the request asks xCAT to
find. The preprocessor of the blade plugin asks for a noderange for every
command, so it answers "Missing Noderange" with an error code and gives back
no request. The daemon then has nothing to give to the handler, and the
findme handler of the plugin does not run.
The plugin therefore answers each discovery request with an error, and blade
discovery does not happen. The check that asks for a noderange is older than
the findme handler.
Hand a findme request to the handler, as the switch plugin does for the
commands that it does not preprocess. Every other command keeps the check.
The preprocessor also held a test that removed a node from a findme request
when the hardware type was not blade. A findme request now returns above that
test, and it named a noderange that a findme request never carries, so the
test could not run. Remove it.
Add a unit test for the routine that selects the blades. The test lifts the
routine out of the plugin source, because the plugin needs a management node
to load.
The test gives the routine the row shapes that the writers of the mp table
make: a management module and its blades from xCAT::PPCdb::add_systemX and
the shipped mp template, a chassis that gives its hardware type, and one row
for each hardware type that lsslp writes. It also shows that the handler
reads the chassis attribute and that it stops before the arp table when the
mp table holds no blades.
The findme handler of the blade plugin makes an inventory request for each
node in the mp table. That table holds more than the blades of a chassis.
lsslp writes a row for a Power BMC, for an FSP, for a BPA, for an HMC and for
other hardware, and xCAT::PPCdb::add_systemX writes a row for a management
module. None of that hardware answers a blade inventory.
Keep a row that gives blade as its hardware type. Keep also a row that gives
no hardware type but names a different node as its mpa, when that other node
is a management module. The mp template in xCAT/templates/e1350 leaves the
hardware type of a blade empty, so a test of the hardware type alone loses
the blades of a chassis.
Return when the table holds no blades. The work below the filter reads the
arp table of the management node, and a site that has no chassis must not pay
for that on each discovery request.
Recovered from the lenovobuild branch, which tested the hardware type only.
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>
Two independent defects stop xCAT working on Ubuntu 26.04 (resolute).
bind9 is only a Recommends on the xcat and xcatsn metapackages. xCAT manages the
cluster DNS through makedns/named, so a DNS server is essential to a management or a
service node -- but a Recommends is installed only while the system's APT
recommendation policy asks for it, so nothing guarantees named is on the node. On an
Ubuntu 26.04 management node it was not there: no /usr/sbin/named, and makedns failed
with "failed to start named".
The Ubuntu netboot genimage reduces an osimage's osvers to a debootstrap suite with a
bare s/\.\d+$//. That also strips the minor from a two-part osvers -- an initial
release with no point-release ISO -- so ubuntu26.04 becomes "26" and debootstrap dies
with "E: No such script: /usr/share/debootstrap/scripts/26". It is not 26.04-specific:
an initial-release 18.04/20.04/22.04 ISO hits it too.
Assert bind9 is a hard Depends on both metapackages, and drive genimage's real
codename derivation over a table of osvers. Both fail today.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
xCAT resolves the provisioning interface as installnic -> primarynic -> mac.mac,
and either attribute may hold an interface NAME or a MAC address;
xCAT::NetworkUtils::gen_net_boot_params owns that order for the netboot kernel
parameters. The Subiquity template short-circuits it: an empty installnic is
treated as "mac" straight away, so a node that configures only primarynic is
installed with a netplan that matches on mac.mac and never renames the
interface, and a primarynic holding a MAC address is ignored entirely.
Assert the full order against a resolver in xCAT::Template -- installnic as a
name, installnic as a MAC, installnic empty with primarynic as a name, empty
with primarynic as a MAC, both empty, and the literal "mac" -- plus multi-entry
mac.mac resolution, and then run the template's own netplan late-command with
the resolved values and compare the file it writes. These fail on the current
template, which carries the resolution in shell and has no resolver to call.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Pin the configuration symbols that let the riscv64 Genesis kernel describe
its hardware on firmware that publishes ACPI tables and no device tree, and
the EFI stub grub2 boots it through. Without them the image dies before the
console exists and the node goes silent instead of discovering.
The riscv64 kernel was built without ACPI. Firmware that publishes ACPI
tables and no device tree - server-class RISC-V boards, and edk2 with
acpi=on - therefore left the kernel with no hardware description: it died
before console initialisation, so a node handed the image by grub2 went
silent at ExitBootServices and never reached the discovery action.
Enable ACPI, its error interfaces and the EFI stub the image is already
booted through. Rebuilt with these options, the same image on the same
firmware parses the RSDP, XSDT, FACP, DSDT, APIC, RHCT and SPCR tables,
reaches multi-user and starts discovering, and the kernel now also sees
the SMBIOS entry point the firmware exports.
Vinícius Ferrão
Vinícius Ferrão
Daniel Hilst