Running sudo /usr/bin/crb enable on a fresh Rocky Linux 10 box fails. That helper script ships inside epel-release, so it doesn’t exist until EPEL is installed. Enable CRB with dnf config-manager first, then install EPEL, and you get both repos in two commands with nothing to retry. That ordering is where most post-install trouble with Rocky Linux 10 repositories starts.
This guide covers the parts of a new install that only Rocky has. That means the repositories it defines (CRB, Plus, Security, Devel and the add-ons), the SIG release packages in Extras, and the files rocky-release leaves for your scripts. The general setup path lives in our things to do after installing Rocky Linux 10 and AlmaLinux 10 guide, so it isn’t repeated here. Every command below was run on Rocky Linux 10.2 with the stock rocky-repos files in October 2026.
See which Rocky Linux 10 repositories are enabled
A new install has three repositories switched on: BaseOS, AppStream and Extras. Everything else that Rocky ships is defined in /etc/yum.repos.d/ but disabled, so the first job is knowing what is there before you turn anything on. List the active set:
dnf repolistOnly the three default repos come back. There is no separate updates repo on Rocky 10, because fixes land straight in BaseOS and AppStream.
repo id repo name
appstream Rocky Linux 10 - AppStream
baseos Rocky Linux 10 - BaseOS
extras Rocky Linux 10 - ExtrasThe rest are spread across five files owned by the rocky-repos package, which is why a grep in rocky.repo alone never finds Plus or Security. We read each file on the lab box. The table maps what is defined, where it lives and whether you should touch it. Only CRB belongs on every server.
| Repo id | File | Default | What it carries |
|---|---|---|---|
| baseos, appstream | rocky.repo | Enabled | The OS and its updates |
| crb | rocky.repo | Disabled | Build and devel libraries that EPEL packages depend on |
| extras | rocky-extras.repo | Enabled | epel-release, SIG and third-party release packages |
| plus | rocky-extras.repo | Disabled | A handful of extra packages Rocky builds itself |
| security | rocky-security.repo | Disabled | Temporary hot-fix builds for urgent CVEs |
| devel | rocky-devel.repo | Disabled | Build root for packagers, never left on |
| highavailability, nfv, rt, sap, saphana | rocky-addons.repo | Disabled | Pacemaker clustering, NFV, real-time kernel, SAP |
Each id also has -debuginfo and -source twins, all disabled. One oddity turned up while reading rocky-addons.repo in the 10.2 package. Its [nfv-debuginfo] and [nfv-source] sections point their mirrorlist at the RT repo (repo=RT-$releasever-debug and RT-$releasever-source), not at NFV. If you ever pull NFV debug symbols and get real-time kernel packages instead, that copy-paste slip in the repo file is the reason, and the commented baseurl line under each section is the way around it.
Enable CRB before installing EPEL
CRB has to be on before EPEL, and you need dnf config-manager to do it, not the crb script. We ran /usr/bin/crb enable as root before installing anything, and the shell couldn’t find it. Through sudo you get sudo’s own “command not found” line for the same path instead; this was our root shell’s version:
bash: line 1: /usr/bin/crb: No such file or directoryNothing is broken. The file belongs to a package you haven’t installed yet, so swapping the order of the two steps is all it takes. The config-manager plugin edits rocky.repo directly and needs nothing from EPEL, so turn CRB on with it instead.
sudo dnf config-manager --set-enabled crbIf dnf does not recognise config-manager, the image you started from left out dnf-plugins-core, which provides it. Our container image did, so we installed it first with sudo dnf install -y dnf-plugins-core. The command prints nothing on success, so check the repo list again rather than trusting the silence.
dnf repolistCRB now sits between BaseOS and Extras. The change is persistent, because config-manager wrote enabled=1 into the [crb] section of rocky.repo, so it survives reboots and updates.
repo id repo name
appstream Rocky Linux 10 - AppStream
baseos Rocky Linux 10 - BaseOS
crb Rocky Linux 10 - CRB
extras Rocky Linux 10 - ExtrasNow install EPEL. On Rocky you do not need the RPM URL from the Fedora docs, because epel-release is already in the Extras repo and dnf records it as coming from @extras.
sudo dnf install -y epel-releaseThe package’s install script still prints its CRB reminder even though CRB is already on. It doesn’t check first, so you can ignore it here.
Many EPEL packages require the CodeReady Builder (CRB) repository.
It is recommended that you run /usr/bin/crb enable to enable the CRB repository.
Installed:
epel-release-10-7.el10_1.noarch
Complete!Ask rpm who owns the helper script now, and the answer settles the ordering question for good:
rpm -qf /usr/bin/crbIt is epel-release, which is why /usr/bin/crb can only ever be the second step.
epel-release-10-7.el10_1.noarchFrom here sudo crb status works and reports CRB repo is enabled and named: crb, so scripts written for EPEL’s own instructions run unchanged. The CRB repository guide covers what is actually inside CRB and the RHEL subscription-manager equivalent, if you manage both.
Check which EPEL tree Rocky pulls
EPEL 10 builds against RHEL minor releases, and a Rocky box is pointed at the tree for the current RHEL minor, not at a tree matching its own point release. That matters in the weeks between a new RHEL minor and the matching Rocky release, when EPEL packages can ask for libraries Rocky hasn’t shipped yet. The metalink line in /etc/yum.repos.d/epel.repo shows how the repo is chosen:
grep '^metalink' /etc/yum.repos.d/epel.repo | head -1The ${releasever_minor:+-z} part adds -z to the repo name on RHEL-like systems, which selects EPEL’s “current RHEL minor” alias instead of the CentOS Stream tree:
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever&arch=$basearchThe file alone does not tell you which tree that alias points at today, because the mirror system decides it. Query the repo itself to see where your box landed:
dnf repoinfo epel | grep -E 'Repo-pkgs|Repo-metalink|Repo-baseurl'The box asked for epel-z-10, not a 10.2-specific repo, and the alias handed it the /epel/10.2/ tree with 24,018 packages because 10.2 is the current RHEL minor.
Last metadata expiration check: 0:04:31 ago on Tue Oct 27 17:09:45 2026.
Repo-pkgs : 24018
Repo-metalink : https://mirrors.fedoraproject.org/metalink?repo=epel-z-10&arch=x86_64
Repo-baseurl : http://mirror.23m.com/epel/10.2/Everything/x86_64/ (205 more)So EPEL follows RHEL, not your box. Every Rocky 10 server on this epel-release gets the same tree, and when Red Hat ships the next minor, the alias moves to it before the matching Rocky release exists. That gap is when EPEL installs on Rocky tend to fail with missing dependencies.
The layout is also mid-change. The EPEL steering committee’s write-up moves RHEL users to a plain epel-10 repo with RHEL 10.3. The epel-release built for 10.3 already swaps the metalink above for repo=epel-$releasever${stream:+s}, and Rocky defines a stream variable (it’s in the dnf vars list further down). On Rocky as shipped, that expands to epel-10s, the Stream tree, unless the epel-release build in Rocky’s Extras changes the line. When we checked the mirror system in October 2026, the three names pointed at three different trees:
epel-z-10to/epel/10.2/, what this box uses todayepel-10to/epel/10.3/epel-10sto/epel/10.4/, the CentOS Stream build
Re-run the dnf repoinfo epel check every time epel-release updates. If Repo-metalink ever shows epel-10s, the box has moved onto the Stream build, which runs ahead of any Rocky release, and that is worth raising on the Rocky forums before you install from it. For the same reason, an internal EPEL mirror should carry whatever tree dnf repoinfo epel reports (pub/epel/10z today), not a directory picked by name.
Install from Plus without leaving it on
Plus is small on Rocky 10, so pulling single packages from it is often simpler than enabling it for good. Check what it holds before you decide.
dnf --repo plus list --availableSeven packages came back in October 2026, all rebuilt with an el10_2 tag:
Available Packages
7zip.x86_64 25.01-2.el10_2 plus
7zip-reduced.x86_64 25.01-2.el10_2 plus
7zip-standalone.x86_64 25.01-2.el10_2 plus
7zip-standalone-all.x86_64 25.01-2.el10_2 plus
iftop.x86_64 1.0-0.34.pre4.el10_2 plus
nmon.x86_64 16q-3.el10_2 plus
valkey-compat-redis.noarch 8.0.11-1.el10_2 plusvalkey-compat-redis is the one people go looking for when old scripts still call Redis by name, and our Valkey on Rocky Linux guide covers the server itself. To grab one package without enabling the repo, pass --enablerepo for that single transaction:
sudo dnf install -y --enablerepo=plus nmonThe package installs and dnf records Plus as its origin, while dnf repolist afterwards still shows Plus as off:
Installed Packages
nmon.x86_64 16q-3.el10_2 @plusThe trade-off is updates. A plain dnf upgrade only reads enabled repos, so it won’t see a newer nmon in Plus. If a package from Plus matters to you, either add --enablerepo=plus to your update job or enable the repo permanently with sudo dnf config-manager --set-enabled plus. With seven packages in it, leaving it on costs almost nothing.
Leave the Security and Devel repos off
Two of Rocky’s repos look useful in a listing and cost you something when left enabled. The Rocky repository documentation describes Security as a place for packages seen as urgent security updates, and says the official upstream packages will always update those hot-fixes. Listing it shows what that means in practice.
dnf --repo security list --availableIt listed 46 package names, every one at the same 211.66.1.el10_2.0.2 kernel hot-fix, and fetching the metadata alone took 47 seconds for 44 MB on our link. These are the first lines:
Rocky Linux 10 - Security 947 kB/s | 44 MB 00:47
Last metadata expiration check: 0:00:04 ago on Tue Oct 27 17:08:52 2026.
Available Packages
kernel.x86_64 6.12.0-211.66.1.el10_2.0.2 security
kernel-abi-stablelists.noarch 6.12.0-211.66.1.el10_2.0.2 securityCompare that with the kernels BaseOS offers today:
dnf list --available kernel --repo baseos --showduplicates | tail -3BaseOS was already two builds past the hot-fix:
kernel.x86_64 6.12.0-211.66.1.el10_2 baseos
kernel.x86_64 6.12.0-211.67.1.el10_2 baseos
kernel.x86_64 6.12.0-211.68.1.el10_2 baseosThat is the whole life cycle of the Security repo. A fix appears there first, upstream catches up, and the hot-fix becomes dead weight. Left enabled, the repo still makes every metadata refresh fetch those 44 MB, for packages dnf will never pick because BaseOS carries a higher version. Enable it with --enablerepo=security only when a Rocky advisory tells you to, and only for that update.
Devel is blunter about it. Its repo name in rocky-devel.repo is literally Devel WARNING! FOR BUILDROOT ONLY DO NOT LEAVE ENABLED, and dnf repoinfo counted 14,936 packages in it. With it enabled, a routine dnf upgrade can pull build-root packages onto a production server. If you build RPMs, do it in a mock chroot or a throwaway VM and pass --enablerepo=devel there.
Add a SIG repo with its release package
Rocky’s Special Interest Groups publish their repositories through small *-release packages in Extras, so you never write a .repo file by hand. The same mechanism carries CentOS SIGs and two third-party repos. Find what is on offer:
dnf list --available '*-release*' --repo extrasNineteen release packages were available on Rocky 10.2:
Available Packages
centos-release-ceph-squid.noarch 1.0-2.el10 extras
centos-release-kmods.x86_64 10-14.el10 extras
centos-release-kmods-kernel.x86_64 10-5.el10 extras
centos-release-nfv-common.noarch 1-7.el10 extras
centos-release-nfv-openvswitch.noarch 1-7.el10 extras
centos-release-ovirt45.noarch 10.0-4.el10 extras
centos-release-ovirt45-testing.noarch 10.0-4.el10 extras
centos-release-samba422.noarch 1.0-1.el10 extras
centos-release-samba423.noarch 1.0-1.el10 extras
centos-release-storage-common.noarch 2-6.el10 extras
centos-release-virt-common.noarch 1-1.el10 extras
elrepo-release.noarch 10.0-1.el10 extras
rocky-release-cloud.noarch 10-1.el10 extras
rocky-release-core.noarch 10-1.el10 extras
rocky-release-fasttrack.noarch 10-1.el10 extras
rocky-release-storage-squid.noarch 10-2.el10 extras
rocky-release-storage-tentacle.noarch 10-2.el10 extras
rpmfusion-free-release.noarch 10-1 extras
rpmfusion-free-release-tainted.noarch 10-1 extrasThey fall into three groups, and the group decides who builds and supports what you install. Rocky SIGs are run by the Rocky project, CentOS SIGs are built by CentOS teams for EL10 in general, and the third-party repos answer to their own maintainers:
- Rocky SIGs:
rocky-release-cloud,-core,-fasttrackand the Ceph Squid and Tentacle storage repos - CentOS SIGs built for EL10: kmods, Ceph Squid, Samba 4.22 and 4.23, oVirt 4.5, NFV Open vSwitch, plus the storage-common and virt-common bases
- Third party:
elrepo-releaseand the two RPM Fusion free repos
Note what is missing. The Security SIG documents rocky-release-security for Rocky 8 and 9, and it isn’t in the EL10 Extras listing, so a Rocky 9 runbook that installs it will fail on 10. For a mainline kernel, ELRepo is the route that still works, and our newer kernel on Rocky Linux guide walks through it.
Installing a SIG works the same way for all of them. We used the Cloud SIG, which carries Oracle Cloud tooling:
sudo dnf install -y rocky-release-cloud
rpm -ql rocky-release-cloudThe package drops a signing key and two repo files, nothing else:
/etc/pki/rpm-gpg/RPM-GPG-KEY-Rocky-SIG-Cloud
/etc/yum.repos.d/Rocky-SIG-Cloud-Common.repo
/etc/yum.repos.d/Rocky-SIG-Cloud-Kernel.repoOnly cloud-common is enabled after the install; the kernel, candidate and testing repos stay off. Listing the enabled one shows OCI CLI and the oci-utils family, all tagged .cloud:
dnf --repo cloud-common list --availableFourteen packages, led by the OCI tools:
Available Packages
oci-cli.noarch 3.54.6-2.el10_0.cloud cloud-common
oci-utils.noarch 0.14.0-2.pre.2024120241b040d.el10_0.cloud cloud-common
oci-utils-kvm.noarch 0.14.0-2.pre.2024120241b040d.el10_0.cloud cloud-common
oci-utils-migrate.noarch 0.14.0-2.pre.2024120241b040d.el10_0.cloud cloud-common
oci-utils-oumtest.noarch 0.14.0-2.pre.2024120241b040d.el10_0.cloud cloud-common
oci-utils-outest.noarch 0.14.0-2.pre.2024120241b040d.el10_0.cloud cloud-common
python-lockfile-doc.noarch 1:0.12.2-16.el10_0.cloud cloud-common
python3-arrow.noarch 1.3.0-1 cloud-common
python3-circuitbreaker.noarch 2.0.0-1.el10_0.cloud cloud-common
python3-daemon.noarch 2.3.2-1.el10_0.cloud cloud-common
python3-lockfile.noarch 1:0.12.2-16.el10_0.cloud cloud-common
python3-oci.noarch 2.151.0-1.el10_0.cloud cloud-common
python3-sdnotify.noarch 0.3.2-1.el10_0.cloud cloud-common
python3-terminaltables.noarch 3.1.10-15.el10_0.cloud cloud-commonThe Ceph storage SIGs install the same way, with rocky-release-storage-squid or rocky-release-storage-tentacle depending on the Ceph release you want. For the cluster build itself, follow the Ceph cluster on Rocky Linux guide.
Error: “Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=rocky-sig-cloud-kernel-10”
Enabling the Cloud SIG kernel repo on Rocky 10.2 fails, because the mirror system has no rocky-sig-cloud-kernel-10 repo to hand out yet. The repo file ships in rocky-release-cloud anyway, which makes it look usable:
dnf --repo cloud-kernel list --available kerneldnf gives up on the metadata straight away:
Errors during downloading metadata for repository 'cloud-kernel':
- Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=rocky-sig-cloud-kernel-10 (IP: 146.75.122.132)
Error: Failed to download metadata for repo 'cloud-kernel': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=rocky-sig-cloud-kernel-10 (IP: 146.75.122.132)Leave cloud-kernel disabled until the mirror system serves it. If you already enabled it with config-manager, turn it off again with sudo dnf config-manager --set-disabled cloud-kernel. Rocky’s /etc/dnf/dnf.conf sets skip_if_unavailable=False, so one dead repo makes every later dnf command stop on the same error.
Read what rocky-release puts on disk
Scripts that branch on the distro should read the files rocky-release owns, not guess from the kernel or the package manager. rpm -ql rocky-release lists 27 paths, and these are the ones your tooling will actually touch:
/etc/os-releaseand/etc/rocky-release/etc/redhat-releaseand/etc/system-release-cpefor older RHEL checks/usr/lib/rpm/macros.d/macros.dist, the%disttag for RPM builds- the systemd presets under
/usr/lib/systemd/system-preset/
Because one package owns all of them, they always agree with each other, so pick the file your tool already understands. For shell scripts that is os-release:
cat /etc/os-releaseBesides the usual ID and VERSION_ID, Rocky adds its own support fields and a hard end date:
NAME="Rocky Linux"
VERSION="10.2 (Red Quartz)"
RELEASE_TYPE="stable"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="10.2"
PLATFORM_ID="platform:el10"
PRETTY_NAME="Rocky Linux 10.2 (Red Quartz)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:10::baseos"
HOME_URL="https://rockylinux.org/"
VENDOR_NAME="RESF"
VENDOR_URL="https://resf.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2035-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-10"
ROCKY_SUPPORT_PRODUCT_VERSION="10.2"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="10.2"Match on ID="rocky" when you need Rocky specifically, and on ID_LIKE containing rhel when any rebuild will do. SUPPORT_END is worth feeding into your inventory, because it’s the date this major release stops getting fixes, and it saves anyone from looking it up per host. The upstream release it tracks sits in a separate one-line file.
cat /etc/rocky-release /etc/rocky-release-upstreamThe second line names the exact RHEL minor release the box was rebuilt from, which is the answer auditors usually want.
Rocky Linux release 10.2 (Red Quartz)
Derived from Red Hat Enterprise Linux 10.2The repo URLs themselves are assembled from variables that rocky-repos ships as one-line files in /etc/dnf/vars/, and these were the values on the lab box:
contentdirset topub/rockyfor the OS repossigcontentdirset topub/sigfor every SIG repostreamset to10-streamrltypepresent but empty
Every Rocky repo file also carries a commented baseurl line built from those variables. Pointing machines at an internal mirror therefore means copying the same directory layout and swapping each mirrorlist for its baseurl, rather than rewriting the repo files from scratch. AlmaLinux is a different story. It ships its own repo files and mirror list, and there are no rocky-release-* packages there, so treat everything on this page as Rocky only and use the Rocky and AlmaLinux post-install guide for the parts the two share.
Keep dnf moving when a mirror stalls
Rocky’s mirrorlist hands each client a nearby mirror, and a slow one can hold dnf for minutes. Our first dnf install on the lab box sat for more than five minutes on a single primary.xml.gz from one mirror without failing or moving on. dnf only abandons a mirror when the transfer stays below minrate (1000 bytes per second by default) for timeout seconds (30 by default), and a mirror trickling just above that floor never trips it. Raising the floor gets dnf to move on. Open the file:
sudo vim /etc/dnf/dnf.confAdd these two lines under the existing [main] section:
timeout=15
minrate=50kWith those in place the retry completed, and over the whole session /var/log/dnf.librepo.log recorded package downloads from four different mirrors, where the stalled attempt had only ever touched one. Raise minrate on a fast link or lower it on a slow one; the point is that dnf gives up on a crawling mirror instead of waiting for it. Once the repos are sorted, carry on with the firewall, SSH and SELinux steps in the Rocky Linux 10 post-install guide, or go straight to a workload such as Docker on Rocky Linux or KVM virtualization.
nice article,it is useful to me and others to know about this items,please just keep it….