Problem with epel repositores if locking minor version

I am using the rockylinux:9.1 docker image (Actually a nvidia cuda image based on rockylinux 9 [9.1]). The problem is that I need to install some packages from the epel repository.

Using the following commands to update and prepare the environment to use the epel repository:

dnf update -y --releasever=9.1 # work
dnf install --releasever=9.1 -y dnf-plugins-core # work
dnf config-manager --set-enabled crb # work
dnf install --releasever=9.1 -y epel-release # also works
dnf update -y --releasever=9.1 # always fails with the following message (the ip changes between runs)
Extra Packages for Enterprise Linux 9.1 - x86_64                                                                                             7.5 kB/s | 108 kB     00:14    
Errors during downloading metadata for repository 'epel':
  - Status code: 404 for (IP:
  - Status code: 404 for (IP:
  - Status code: 404 for (IP:
Error: Failed to download metadata for repo 'epel': Cannot prepare internal mirrorlist: Status code: 404 for (IP:

The latest version of the rocky linux image (9.2) work without issues.


epel doesn’t have a “9.1” directory. It’s just 9.

So this will solve your problem.

dnf upgrade
dnf install

On completion you will have a fully updated Rocky 9.2 and epel to match.

Do you know what ‘dnf’ does with that option?

Definition of a repo may have mirrorlist. The value is an URL. The dnf contacts that URL and receives a list of URLs to repository servers.

The EPEL’s mirrorlist looks like
That is, connect to and supply parameters:


The does not return anything with that, because it has no repo=epel-9.1. It does return data for repo=epel-9.

If you look at the files /etc/yum.repos.d/*.repo, none of them has 9.1 or x86_64.
You do probably find epel-$releasever. The value of variable releasever is injected by dnf into the URL string.

Your commands set the value of releasever to 9.1. It’s default value on Rocky 9 is 9.

Rocky’s mirrorlist server apparently does return something for repo=epel-9.

The first commands “work”, because you have not yet defined repos that do not understand repo=epel-9.
The install epel-release defines such repo.
All dnf commands after that, which do (try to) access repos and where you set the --releasever=9.1 do fail. You could try dnf install --releasever=9.1 -y epel-release and it will error out. Not because you already have the package, but because you have different repos than on previous time.

It is right and proper that EPEL does not offer packages for “el9.1”. That does not exist any more. RHEL 9.1 did cease to exist last month (as supported distro), when RHEL 9.2 was released. Same for Rocky.
See Red Hat Enterprise Linux Life Cycle - Red Hat Customer Portal