Where can I find old RPM versions?


Where can I found old versions of the RPMs for Rocky Linux 9? I can only seem to find the latest and greatest under Index of /pub/rocky/9.0/

I am setting up a project where I will build a kernel module and package it in an RPM. Since kernel versions change, I want to install the kernel-devel package that corresponds to the 9.0 version (and later also for 9.1, 9.2, etc.). We are adapting from a similar setup that was running on CentOS 7, where we installed all base kernel-devel packages for the 7.x versions. To be able to target a base 9.0 release I want to install the base 9.0 kernel-devel RPM (5.14.0-70.13.1), but I am unable to locate this anywhere.


Well so far there is only 9.0 release. But anyway, when 9.1 is released, then 9.0 will move to the vault here: Index of /vault/rocky/

Yes, but I can only find 5.14.0-70.30.1.el9_0 on the download site, not the 5.14.0-70.26.1.el9_0 I got when I installed my dev VM a couple of weeks ago, nor the 5.14.0-70.13.1 version that Wikipedia lists as the one that came with the initial 9.0 release.

I am looking for a stable download URL that I can get the specific version from, now and later when I set up build machines. CentOS 7 had a basic “os” directory that contained the initial release version, with all updates in “updates” (and older releases in “vault”).

Hi @nafmo,

this is currently an open issue for Peridot (the build system which is used for Rocky Linux 9):

So, the packages are actually still available in Peridots internal repos, but only accessable by directly accessing the files, which means finding them is a matter of a SQL query,
this should of course change in the future :slight_smile:


For that there is apparently a solution.
dnf looks (and you probably did browse) into 9.0/BaseOS/x86_64/os/Packages
Browse to 9.0/BaseOS/x86_64/kickstart/Packages

That, AFAIK, is the initial point release.

In CentOS 7 the initial point release content was in base and updates were dropped into updates.
In el8 and el9 ${repoid}/${arch}/os and ${repoid}/${arch}/kickstart start identical, and updates are dropped into */os
(“Drop” as in replace, rather than add, currently in Rocky.)

1 Like

I would also suggest to build your kernel module to not be completely tied to kernel version, but rather the general release of that kernel (meaning the -XXX portion). There shouldn’t be a reason to tie your kmod packages to every released kernel version in a point release in any Enterprise Linux version. A rebuild is generally necessary when a new point release comes out (for example, 9.1 and thus new kernel release), but for 6 months, you shouldn’t have to unless the driver itself has an update.

For example, if you build a package for the module for 4.18.0-425.3.1.el8, that same kmod should work on 4.18.0-425.10.1.el8_7 when it comes out. And then when 4.18.0-5XX.el8 comes around, you rebuild the driver against that and you shouldn’t have to build again unless the driver has an update.

I would check out this elrepo example. This would eliminate the constant rebuilds.


Yes, I probably have to go for something like that with the current situation where I cannot get the correct RPM versions directly. It does complicate build server setup and replication and the build script setup, as the exact versions installed will vary between hosts, and I am trying to achieve reproducible builds and as identical build environments as possible.

This is something Satellite does well. You can specify a package level, and patch all machines to that level, and you can also go back to old package versions.