i think it’s that the mirrorlist wants rocky-Appstream-$release and we’re asking for just Appstream-$release in the .repo file rather than rocky-Appstream-$release
This is the default appstream configuration. If I run my dnf commands, it works as intended.
[root@router yum.repos.d]# history | tail -n 2
1007 dnf clean all
1008 dnf update
[root@router yum.repos.d]# dnf history info last
Transaction ID : 238
Begin time : Fri 10 Jun 2022 04:23:29 PM MST
Begin rpmdb : 1180:7fb2567f9b12c339b973ec2c6f16a7bc8aef9270
End time : Fri 10 Jun 2022 04:25:41 PM MST (132 seconds)
End rpmdb : 1201:a517be73f096a0a8a118e1025b118e5508dc8472
User : nazu <nazu>
Return-Code : Success
Releasever : 8
Command Line : update
Comment :
Packages Altered:
Install ansible-core-2.12.2-3.1.el8.x86_64 @appstream
. . .
[root@router yum.repos.d]# dnf repolist
repo id repo name
appstream Rocky Linux 8 - AppStream
baseos Rocky Linux 8 - BaseOS
epel Extra Packages for Enterprise Linux 8 - x86_64
epel-modular Extra Packages for Enterprise Linux Modular 8 - x86_64
extras Rocky Linux 8 - Extras
powertools Rocky Linux 8 - PowerTools
[root@router yum.repos.d]# ls /etc/dnf/vars/
contentdir sigcontentdir
I’m not sure if this azure image or the azure infrastructure is messing with the query or how dnf is operating. But it seems as though it is, because AppStream-8.6 is not valid. AppStream-8 is always valid and symlinks to rocky-AppStream-8.X, X being whatever current minor version is available at the time.
I think this is what’s happening here and i’d love to see this being possible. E.g. Alma Linux (https://mirrors.almalinux.org/mirrorlist/8.5/baseos) has this possibility.
A major disadvantage of this is that I may want to deliberately not upgrade and pin my release to - say - 8.5. If I use the Rocky Linux 8.5 Docker image, it’ll upgrade to 8.6 with the next dnf upgrade, even though I explicitly ran the 8.5 image. A workaround is to use the baseurl instead of mirrorlist, but the mirrors already store the 8.5 data, so why not enable the mirrorlist to use that?
so I dont believe I’ve specifcally overidden releasever to major.minor myself. I’m under the impression that it’s autodiscovery that’s using major.minor.
i DID make some changes to yum.conf but nothing that should specifically set major.minor.
yum.conf currently contains:
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
http_caching=packages
The reason we do not do this is because the Major version always points to the latest release. If users install with different ReleaseVer, their upgrades will break when Rocky moves to the next Major point release.
To be clear, I am intending to support previous version urls in the mirrorlist service, but they have no support from the community as we only focus on supporting the latest point release during a major version cycle. However, hard coding point releases to a specific point release runs counter the the direction of the Rocky project supporting the latest releases.
Thanks neil; I wasnt able to determine -where- that major.minor version is getting set; but in the interim I’m forcing the var to 8 by creating this file
and that’s working with unmodified yum repo files.
I do agree with the person who suggests there should be a way to force major.minor with the released yum .repo files. There’s a ton of commertial software that will only certify against a given minor version of RHEL/CentOS so it’d be nice to have a reasonably ‘stock’ solution for that.