bug: latest xcat-dep/rh9/x86_64 repodata is missing RPMs present on disk (breaks go-xcat install on EL9)

[viniciusferrao]

A fresh go-xcat install of xCAT 2.18.0 on an EL9 x86_64 management node fails because several
packages in the default GO_XCAT_INSTALL_LIST don't resolve from the latest online xcat-dep
repo. install_packages_dnf() installs the whole list in one dnf install transaction, and dnf
on EL9 is strict by default, so a few unresolvable names take down the entire install.

Environment

• Management node: EL9-family, x86_64
• Repos: online latest, http://xcat.org/files/xcat/repos/yum/latest/ (xcat-core 2.18.0 + xcat-dep rh9/x86_64)
• Install method: go-xcat install

Root cause: repodata in latest/xcat-dep/rh9/x86_64 is missing packages

The RPMs are physically in the directory, but the published repodata doesn't index them. I
confirmed this by decompressing the primary metadata (*-primary.xml.zst, repomd timestamp
2026-07-07) and listing the indexed package names. Only these two relevant packages show up:

xCAT-genesis-base-x86_64
xCAT-genesis-scripts-x86_64

Everything else go-xcat asks for on the POWER side, plus yaboot-xcat, is absent from the
metadata even though the files sit on disk:

Requested by go-xcat	RPM on disk	In repodata
xCAT-genesis-base-x86_64	genesis-base-x86_64-2.18.0-snap202606291947.noarch	yes
xCAT-genesis-scripts-x86_64	present	yes
xCAT-genesis-base-ppc64	genesis-base-ppc64-2.16.3-snap202110141642.noarch	no
xCAT-genesis-scripts-ppc64	present	no
yaboot-xcat	yaboot-xcat-1.3.17-rc1.noarch	no

So this isn't a naming mismatch: yaboot-xcat's filename already matches the name go-xcat
requests, and it's still missing from the index. The one explanation that fits all of it is that
the createrepo run for this directory indexed only a subset of the RPMs present. Installing by
direct URL works because it skips the repodata:

yum install http://xcat.org/files/xcat/repos/yum/latest/xcat-dep/rh9/x86_64/yaboot-xcat-1.3.17-rc1.noarch.rpm

Workaround

1. Install yaboot-xcat from the URL above.
2. Drop the ppc64 genesis packages from GO_XCAT_INSTALL_LIST in go-xcat:

GO_XCAT_INSTALL_LIST=(perl-xCAT xCAT-client xCAT xCAT-buildkit
        xCAT-genesis-scripts-x86_64 xCAT-server
        elilo-xcat grub2-xcat ipmitool-xcat syslinux-xcat
        xCAT-genesis-base-x86_64 xnba-undi yaboot-xcat)

After that, go-xcat install finished and the MN provisioned CentOS 7 and Rocky 9 nodes, so the
2.18.0 builds themselves are fine.

Expected behavior

go-xcat install completes with the default package list on a supported EL9 x86_64 MN.

Fix

Primary, server side: re-run createrepo_c over latest/xcat-dep/rh9/x86_64 so every RPM in the
directory gets indexed, then check that each name in GO_XCAT_INSTALL_LIST resolves
(dnf repoquery --whatprovides <name>). A post-publish check that every default package resolves
against the live repo would keep this from shipping silently again.

Secondary, ppc64: xCAT-genesis-base-ppc64 is xCAT's umbrella name for all POWER. mknb folds
ppc64le into ppc64 (mknb.pm: "using ppc64 instead"), and the genesis spec collapses
ppc/ppc64/ppc64le into tarch=ppc64, so there's no separate LE package by design. The
on-disk RPM is a stale 2021 2.16.3 build and needs a fresh 2.18.0 rebuild on a ppc64le/OpenPOWER
host so the payload matches modern POWER8/9/10 hardware. Worth checking the endianness of the
current artifact with readelf -h on its payload kernel; if it's big-endian it won't boot LE
nodes at all.

go-xcat hardening, independent of the repo fix: because the install is one dnf transaction, a
single unresolvable arch-specific package kills an otherwise healthy install. go-xcat could
pre-check resolvability and warn-and-skip instead of hard-failing.

Reproduce / verify

BASE=https://xcat.org/files/xcat/repos/yum/latest/xcat-dep/rh9/x86_64
for n in yaboot-xcat xCAT-genesis-base-ppc64 xCAT-genesis-base-x86_64; do
  echo -n "$n -> "
  dnf repoquery --repofrompath=xdep,$BASE --repoid=xdep --disablerepo='*' \
    --enablerepo=xdep --whatprovides "$n" -q 2>/dev/null | tr '\n' ' '; echo
done

[viniciusferrao]

@ChrisPJames

[ChrisPJames]

excellent - many thanks.