Mirrorlist repo name mismatch?

Hi, I’m working on a new install of Rocky 8.8

And I’m having issues when I hit the default mirrorlist, in that the reponame in the .repo file doesnt seem to be indexed by the mirrorlist.

.repo has:
[root@zcc1lt01rocky8 yum.repos.d]# cat Rocky-AppStream.repo | grep AppStream
#name=Rocky Linux $releasever - AppStream


hitting that mirrorlist gives me this error

repo = AppStream-8.6 arch = x86_64 error: invalid repo or arch

since it’s looking for:


rather than just AppStream

this is from the ‘stock’ official Azure image.

cc @neil

From my perspective, $releasever is a major number, not major and minor. This means: arch evaluating to x86_64 and releasever evaluating to 8 works as expected here: https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=AppStream-8

Are you setting releasever to be 8.6 instead of just 8? If you are, this is where you’re likely having issues.

i think ‘releasever’ is OK

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

I’m concluding this from the data the mirrorlist returns when we hit the URL in the repo:

repo = AppStream-8.6 arch = x86_64 error: invalid repo or arch
following repositories are available:
repo=FIXME: repomap.py&arch=aarch64
repo=FIXME: repomap.py&arch=source

here’s what my yum.conf looks like:


am I missing some defaults that should be in there?

yum/vars has the following:

[root@zcc1lt01rocky8 vars]# ls -la
total 8
drwxr-xr-x. 2 root root 37 May 13 2019 .
drwxr-xr-x. 8 root root 151 Jun 10 21:18 …
-rw-r–r–. 1 root root 10 Mar 30 00:02 contentdir
-rw-r–r–. 1 root root 6 May 17 00:59 infra
[root@zcc1lt01rocky8 vars]# cat contentdir
[root@zcc1lt01rocky8 vars]# cat infra
[root@zcc1lt01rocky8 vars]#

it -does- work if I force releasever to 8

[root@zcc1lt01rocky8 vars]# cat releasever
[root@zcc1lt01rocky8 vars]#

[root@zcc1lt01rocky8 vars]# yum repolist
Rocky Linux 8 - AppStream 6.4 kB/s | 4.8 kB 00:00
Rocky Linux 8 - BaseOS 91 kB/s | 4.3 kB 00:00
Rocky Linux 8 - Extras 72 kB/s | 3.5 kB 00:00

name=Rocky Linux $releasever - AppStream

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.

Could you please run the following command?

python -c 'import dnf, json; db = dnf.dnf.Base(); print(json.dumps(db.conf.substitutions, indent=2))'

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?

[root@zcc1lt01rocky8 ~]# python3 -c ‘import dnf, json; db = dnf.dnf.Base(); print(json.dumps(db.conf.substitutions, indent=2))’
“arch”: “x86_64”,
“basearch”: “x86_64”,
“releasever”: “8.6”
[root@zcc1lt01rocky8 ~]#

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:

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.

1 Like

This may be a problem with the azure image itself. I’m investigating

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

[root@zcc1lt01rocky8 ~]# cat /etc/yum/vars/releasever

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.

1 Like