A ppc64el or riscv64 management node installs the amd64 Genesis. xCAT and
xCATsn declare Architecture: amd64 ppc64el riscv64 and one unrestricted
Depends: xcat-genesis-scripts-amd64, so every architecture gets it. That
package is Architecture: all, so apt reports no error. It lays down
/opt/xcat/share/xcat/netboot/genesis/x86_64 and pulls the 128 MB
xcat-genesis-base-amd64, and the node receives no Genesis for its own
architecture. xcat-genesis-scripts-ppc64, the package that would carry it, is
uninstallable: it depends on xcat-genesis-base-ppc64, and builddeb-genesis-base
names the ppc64el base deb xcat-genesis-base-ppc64el.
xCAT/debian/control and xCATsn/debian/control now restrict the dependency by
architecture, the way xCAT.spec does with
%{?genesistarch:Requires: xCAT-genesis-scripts-%{genesistarch}}. amd64 gets
xcat-genesis-scripts-amd64, ppc64el gets xcat-genesis-scripts-ppc64el, and
riscv64 gets neither, because its Genesis is the OpenEmbedded image.
xCAT-genesis-scripts/debian/control-ppc64el builds xcat-genesis-scripts-ppc64el
and depends on xcat-genesis-base-ppc64el. It conflicts with and replaces the
old name, which shares the same files.
debian_control_arch_coverage.t asserts the genesis scripts an architecture
receives are that architecture's own, and that control-<arch> builds
xcat-genesis-scripts-<arch> against xcat-genesis-base-<arch>. Eight of its
assertions fail without this change.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
A compute node that boots the legacy Genesis image on el10 x86_64 never acquires an
address. Its serial console reports "/usr/bin/doxcat: line 293: dhclient: command not
found" and then "It seems to be taking a while to acquire an IPv4 address". The DHCP
server side is sound: Kea leases the address and the node never asks for it.
AlmaLinux 10 and EPEL 10 package no ISC dhcp-client. dracut_install reports a missing
binary and returns, so module-setup.sh named dhclient, the build kept going and the image
shipped without a client. doxcat then named dhclient at six call sites with no
alternative.
doxcat now chooses its client at run time. genesis_dhcp_command() returns the command
line for one interface and one address family, and genesis_start_dhcp() runs it and
reports when the image carries none. The ISC client keeps its command line where a
release packages it, so el8 and el9 are unchanged. Where it is absent, dhcpcd stands in:
AlmaLinux 10 baseos packages it at 236 KB, and it carries its own resolv.conf, hostname
and ntp hooks, so it needs no dhclient-script. dhcpcd on a single interface exits when
its 30 second timeout expires and de-configures the interface as it goes, so it is asked
for -t 0 and -p.
The dracut module installs whichever client the build root carries, together with the
hooks dhcpcd runs on every lease. The spec build-requires dhcpcd from rhel 10 on, and
verify-genesis-payload now requires usr/sbin/dhcpcd there, so an image that ships with no
client fails the build instead of reaching a node.
genesis_dhcp_client.t drives both routines with the clients shadowed by recording stubs.
It fails on the parent commit, and deleting the dhcpcd branch turns five of its
assertions red.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
(cherry picked from commit b9329998c80383bb0397d16a558f66a6bb9db399)
A riscv64 build of xcat-core dies at xCAT-genesis-scripts with "Cannot find/open
srpm: ...xCAT-genesis-scripts-riscv64-2.19.0-<release>.src.rpm", because the srpm
rpm produced is named xCAT-genesis-scripts-%{tarch}-2.19.0-<release>.src.rpm.
xCAT-genesis-scripts.spec and xCAT-genesis-base.spec take their package name from
%{tarch}, which an %ifarch ladder sets for x86, x86_64, ppc64 and aarch64. riscv64
is absent, so rpm leaves the macro unexpanded and builds a package whose NAME
contains it. buildrpms.pl then looks for the name it asked for and cannot find it.
Add the riscv64 branch to both specs. An arch that is still missing from the
ladder now stops the build with %{error:} instead of naming a package after a
macro.
xCAT-test/unit/genesis_spec_target_arch.t covers this: it fails on riscv64
without this change.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
(cherry picked from commit c9de89ccceaaa618f9e91568d74812b349c513ac)
Legacy Genesis excludes every secondary interface with IFF_UP, even when firmware only raised it and no address is configured. Let eligible interfaces join the existing secondary-interface DHCP path when they are physical, not enslaved, unaddressed, and not owned by the TSM or IMM management paths. Existing DOWN interfaces keep their prior path.
Recovered from the unmerged lenovobuild branch (original 9a1381f6), adapted to leave preconfigured and management-owned interfaces untouched.
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
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 small robustness fixes for bmcsetup:
- After changing the BMC network port on IBM boards (IPMIMFG 2), the BMC LAN
configuration was not yet ready; add a 15s settle before continuing. Gated
inside the IBM branch, so no other vendor is affected.
- Set a password longer than 16 characters using ipmitool's 20-byte form, but
only when the password actually exceeds 16 chars, so a BMC that supports only
16-byte passwords is never asked for a length it cannot store.
Recovered from the unmerged lenovobuild branch (949532f3, 78fa7758; the password
change adapted to use the 20-byte form only for long passwords).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
When a node boots from an InfiniBand interface, doxcat could not match BOOTIF
to the netdev, so boot-nic detection failed. Load ib_ipoib and, if the normal
Ethernet lookup finds nothing, fall back to matching the InfiniBand device by
its (shorter) IPoIB address.
modprobe ib_ipoib is harmless where there is no IB hardware (the module simply
loads no devices), and the IB lookup only runs when the Ethernet lookup fails,
so non-IB nodes are unaffected.
Not lab-validated (no InfiniBand fabric available; the SR635's Mellanox card is
in Ethernet mode).
Recovered from the unmerged lenovobuild branch (aeeebd5f).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
Intel Walker Pass (S9200WK) boards in dedicated-LAN mode use IPMI channel 3;
the auto-detect loop does not find it. Set the channel explicitly for these
boards, gated on IPMIMFG=343 && XPROD=149, and extend the existing S2600BP
channel-setaccess (343/124) to cover 149 as well.
Gated on the Intel manufacturer/product IDs, so no other BMC is affected.
Not lab-validated (no Walker Pass hardware available).
Recovered from the unmerged lenovobuild branch (2357c298).
The original Lenovo SR635/SR655 (IPMI manufacturer 19046, product 1287) use an
AMI "TSM" BMC reached over a LAN-over-USB interface, which needs OEM raw commands
to bring the interface up, select the LAN channel, and restart TSM networking
once configured. Add a dedicated vendor branch for it -- gated on the same
IPMIMFG/XPROD check the script already uses for IBM, Dell, Supermicro, OpenPOWER
and other Lenovo machines -- plus a udev rule and helper that bring up the USB
NIC (169.254.0.120) so in-band ipmitool can reach the TSM. The user-slot
auto-scan is skipped for these machines, which use a fixed slot.
Everything is behind IPMIMFG=19046 && XPROD=1287 (or the 046b:ffb0 USB device),
so no other BMC is affected.
Recovered from the unmerged lenovobuild branch (922dfe18, 42357f9d, 02da8a6b,
765e2ad3, 408cf2b3), adapted to master's bmcsetup structure. The global MD5 LAN
auth removal that rode along in 42357f9d is intentionally left out -- SR635/SR655
IPMI authentication is already handled in master by #7586 (retry cipher suite 3
on a zero RAKP2 HMAC), so dropping MD5 for all BMCs is neither needed nor wanted
here.
Not lab-validated: this targets the original SR635/SR655 (product 1287); no such
machine was available to test (an SR635 V3 reports product 1601 and uses a
different, directly-reachable BMC). The code is gated so it cannot affect other
hardware.
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
bmcsetup unconditionally re-set the BMC IP source, address, netmask, gateway
and VLAN on every run. On a re-run or re-discovery where the BMC is already
configured, that re-applies settings needlessly and can briefly churn the BMC
network. Read the current value first and only issue the set when it differs;
the VLAN check maps an "off" target to the "Disabled" the BMC reports.
Validated read-only on a Lenovo ThinkSystem SR635 (MegaRAC BMC): the address
and VLAN guards evaluate to skip when the target matches the current value.
Recovered from the unmerged lenovobuild branch (fd194005); the RD350-specific
snooze and manufacturer-ID hunks are omitted as master's vendor handling has
since diverged.
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
For each secondary NIC in NICSTOBRINGUP, doxcat backgrounds a loop that polls
`ethtool $nic` until the link reports "detected: yes" before running dhclient.
A NIC that is never connected keeps that loop (and its `sleep 5`) running for
the life of the genesis environment, leaking background shells and needlessly
churning.
Add a second exit condition so each loop also stops once /tmp/netinitted
exists, and touch that file once the boot NIC has completed network init. A
link that never appears no longer waits indefinitely.
Recovered from the unmerged lenovobuild branch (original 9ece12e4).
Co-authored-by: Jarrod Johnson <10814490+jjohnson42@users.noreply.github.com>
Requiring xCAT-genesis-base >= 2:%{version} coupled the flat xcat-core to a
matching genesis-base on every marketing-version bump: a 2.18.1 core refused
to install against the deployed 2.18.0 genesis-base. genesis-base changes
rarely and lives in the separate per-EL xcat-dep repo, so floor the requirement
at the fixed 2.18.0 baseline instead. Core version bumps no longer force a
genesis-base re-publish.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
genesis-base now ships in the per-EL xcat-dep repo while genesis-scripts ships
in the flat xcat-core. The exact "= 2:%{version}-%{release}" dependency forced
core and dep to be republished in lockstep on every core rebuild (a new snap in
core could not be installed until the exact-matching genesis-base snap was also
published to the client's dep channel -- which broke a production client).
Relax to ">= 2:%{version}": epoch 2, version >= 2.18.0, any release/snap. RPM
ignores the release when the dependency omits it, so any same-version (or newer)
genesis-base satisfies it. Routine core snaps no longer require a genesis-base
re-publish; lockstep now only matters on version bumps and the initial publish.
Signed-off-by: Daniel Hilst <392820+dhilst@users.noreply.github.com>
Replace backtick command substitutions with $(), quote variable
expansions to prevent word splitting, replace useless cat pipes with
redirections, use grep -q instead of redirecting to /dev/null, and use
bash parameter expansion for case conversion.
Based on the work from PR #6366, rebased and adapted to current master.
Shebangs already merged separately via df64bf8fe are excluded.
Co-Authored-By: Samveen <samveen@yahoo.com>
bmcsetup iterated every user slot and retried ipmitool user disable for slots that were already disabled. Lenovo XCC reports those attempts as Invalid data field in request, so discovery can spend minutes retrying no-op disables.
Read the current user table once per BMC, keep the old fallback when the table cannot be read, and disable only non-target slots whose IPMI Msg flag is true. Also use the loop's current username when resolving the target slot and keep the intended userslot 2 fallback assignment.
Fixesxcat2/xcat-core#5065
This fixes a problem where the dracut image was pulling artifacts from
the build host and not the mock image, e.g. building for EL9 in EL10.
Signed-off-by: Daniel Hilst Selli <392820+dhilst@users.noreply.github.com>
Add optional values to ipmi.bmcport to support more fine-grained
configuration for Dell servers, and mirror the `ipmitool delloem`
capabilities:
lan set <Mode>
sets the NIC Selection Mode :
dedicated, shared with lom<idx>
lan set <Shared Failover Mode>
sets the shared Failover Mode :
shared with failover lom<idx>
shared with failover all loms,
shared with failover none.
This patch introduces the possibility to provide 3 (space-separated)
values for ipmi.bmcport:
1st value: 0 = shared / 1 = dedicated
2nd value shared LOM (1-4) (0 or no value means first available LOM)
3rd value: failover LOM (1-4) (0 means no failover, no value means all LOMs)
To ensure maximum compatibility with the default 0/1 shared/dedicated
scheme, the 2nd and 3rd values are optional, and will retain the
previous behavior when not specified.
Examples:
ipmi.bmcport value BMC interface configuration
0 Shared with first available interface, failover with
all LOMs (catch-all mode)
0 1 Shared with LOM1, failover all LOMs
0 1 2 Shared with LOM1, failover LOM2
0 2 0 Shared with LOM2, no failover
1 Dedicated
* bmcsetup: revert previous meaning of bmcport for Dell servers, to
conform with other server types: 0=shared, 1=dedicated
* bmcsetup: remove dependency on `ipmitool delloem` and use raw cmds instead
ipmitool delloem may not work on all Dell server generations,
functionnality depends on ipmitool versions (see
https://github.com/ipmitool/ipmitool/issues/18).
So removing thatdependency and using raw IPMI commands seems more robust.
Daniel Hilst
Vinícius Ferrão
Vinícius Ferrão
davidmonro
Markus Hilger
Kilian Cavalotti
Abhishek S A
Kilian Cavalotti
Markus Hilger
besawn