I was able to implement almalinux 10.0 into my existing kickstart processeeees without much effort…
I was then able to install 10.0 on a test system without issue, BUT, when I attempted to perform package updates, I encountered these issues:
reposync did NOT download all of the RPM’s available in the mirrored repositories…
I found ‘that’ out when I performed the ‘update’ using my ‘local’ repositories (which I constructed from the reposync’s)
Mainly, the samba-*.rpm packages were missing, which I then manually downloaded from the /almalinux/10.0/BaseOS/x86_64_v2/os/ remote location…
BUT, when I then re-attempted the update, 1 more package was required, WHICH DOES NOT EXIST in the remote repos… (but apparently IS in the remote repodata indexes…)
You can see all of the past (and current) versions of each Samba package in the repos, except for “samba-client” which doesn’t exist on ANY of the mirror sites…
The original version for Alma 10.x does exist in the original installation media…
Such that, Samba cannot be updated since that 1 package is missing…
SO, ‘yes’, most of the “samba” packages are in the AppStream repository, though ‘I’ am referencing the ones for “10.0” (not the basic “10” directories), but I checked again (in “Index of /almalinux/10.0/AppStream/x86_64_v2/os/Packages/”) and found the files…
After manually downloading them and rebuilding the local “repodata”, I was able to perform the update on the test system without issue…
BUT, what’s obviously still an issue, is that ‘reposync’ is NOT downloading all of the packages from the ‘mirrors’. I don’t use ‘rsync’ since I only want the newest release of each package (and not the ever-growing mass of all the previous versions…)
I’m cringing at the thought of going thru the entire remote repo to see what I’m still missing, and not knowing if future releases will not be identified and downloaded by ‘reposync’.
There IS a possibility that the version of reposync I’m using is no longer compatible with the lastest ‘repodata’ files (though it works for CentOS 7.9, Rocky 9.6), so I’ll setup the configuration on the alma 10.0 system and see if ‘that’ works…
AND, the answer is… The ‘v2’ rpm packages are outside the knowledge of the “reposync” command…
In that ‘reposync’ by default will download all of the ‘default’ naming architectures of the packages (i.e. i386, x86_64, noarch ) but has no knowledge of “x86_64_v2”, so it was ignoring them…
I figured it out, when I noticed that the RPM package files that DID download, were all the “noarch” versions…
Such that, I have to perform a reposync for ‘default’ package names (basically the “noarch” ones) and then again, specifying the ‘v2’ ones…
I have updated my ‘wrapper script’ (which calls the “reposync” command) to add a ‘package filter’ option ( ‘-f’) to specify the package architecture to download (translating to the --arch= argument to ‘reposync’)…
Below is ‘todays’ retrieval of updates from the “AppStream” repository, showing the download of ‘non V2’ packages (reposync’s default package naming list)
The modification to the ‘wrapper script’ is shown below, with the addition of the $ARCH_FILTER argument to “reposync” (which would have the value of “–arch=x86_64_v2” if provided with the ‘-f’ option to the script…
NOTE that this was executed on a CentOS 7.9 system (still works) which uses the “$ALLOW_REPO_RELOCATION” option (“”–allow-path-traversal") now deprecated…
178c186,191
< /usr/bin/reposync $TEST_ONLY --config=$YUM_CONFIG_FILE --repoid=$YUM_REPO_ID --download_path=$DOWNLOAD_DIR $ALLOW_REPO_RELOCATION $NO_REPO_PATH_ID $NO_HASHES $NEWEST_RPMS_ONLY $GPG_VERIFICATION 2>&1 | tee -a $DOWNLOAD_LOG
---
>
> /usr/bin/reposync $TEST_ONLY --config=$YUM_CONFIG_FILE --repoid=$YUM_REPO_ID --download_path=$DOWNLOAD_DIR $ALLOW_REPO_RELOCATION $NO_REPO_PATH_ID $NO_HASHES $NEWEST_RPMS_ONLY $GPG_VERIFICATION $ARCH_FILTER 2>&1 | tee -a $DOWNLOAD_LOG