There are two places to get EPEL on Oracle Linux, and only one of them is built and signed by Oracle. Oracle ships oracle-epel-release-el10 and oracle-epel-release-el9 in BaseOS, so one dnf install adds the Oracle Linux EPEL channel using the Oracle key your system already trusts. Fedora’s epel-release RPM installs too, but it brings its own signing key, and on Oracle Linux 10 it follows the CentOS Stream branch of EPEL instead of your release.
We’d use Oracle’s package on both releases, so that’s the path you’ll follow here: install it, read what it adds, fix the CodeReady Builder errors some EPEL packages hit, then switch the repo off or remove it. The Fedora route is covered too. Commands quoted only from documentation say so, and every command block below was run on Oracle Linux 10.1 and 9.8 with SELinux enforcing in October 2026.
Check what Oracle Linux enables by default
A fresh Oracle Linux install has no EPEL repo file at all. The images we used enabled three repositories (BaseOS, AppStream and the UEK kernel channel) and left the rest configured but switched off. All you need to follow along is a user with sudo and outbound HTTPS to yum.oracle.com, so start by listing every repository dnf knows about, enabled or not.
sudo dnf repolist --allOur 10.1 image listed ten entries, and only three are enabled. Read the status column rather than the names, because several disabled repos look as if they belong in a normal install.
repo id repo name status
ol10_RDMA Oracle Linux 10 (x86_64) RDMA disabled
ol10_UEKR8 Oracle Linux 10 UEK Release 8 (x86_64) enabled
ol10_addons Oracle Linux 10 Addons (x86_64) disabled
ol10_appstream Oracle Linux 10 Application Stream Packages (x86 enabled
ol10_baseos_latest Oracle Linux 10 BaseOS Latest (x86_64) enabled
ol10_codeready_builder Oracle Linux 10 CodeReady Builder (x86_64) - (Un disabled
ol10_distro_builder Oracle Linux 10 Distro Builder (x86_64) - (Unsup disabled
ol10_kvm_utils Oracle Linux 10 KVM Utilities (x86_64) disabled
ol10_u0_baseos_base Oracle Linux 10 BaseOS GA (x86_64) disabled
ol10_u1_baseos_base Oracle Linux 10.1 BaseOS GA (x86_64) disabledNothing in the list mentions EPEL. You’ll also see ol10_codeready_builder present but disabled, with Oracle’s own “(Unsupported)” label in its name (the column cuts it off), and it matters later because a few EPEL packages need it. A host already updated to 10.2 lists one more entry, ol10_u2_baseos_base, which the current oraclelinux-release-el10 package in BaseOS defines.
The 9 list looks similar, with ol9_ prefixes, a few extra disabled repos such as ol9_UEKR7 and ol9_MODRHCK, and point-release BaseOS repos from ol9_u0_baseos_base to ol9_u8_baseos_base. The commands in this guide differ between the two releases only in the release number and the EPEL repo ID, which the next step explains.
Enable Oracle Linux EPEL with oracle-epel-release
Update the host before you add EPEL. Oracle Linux 10.2 is the current update (Oracle’s repository page lists BaseOS 10.2 as the latest), and Oracle’s EPEL channel includes builds tagged el10_2 that can need 10.2 libraries. Our lab image was still on 10.1, so on your own server run sudo dnf upgrade -y first and start the install below from a current system.
Install oracle-epel-release-el10 on Oracle Linux 10. It comes from the BaseOS channel that is already enabled, so there’s no RPM URL to fetch and no new key for you to accept.
sudo dnf install -y oracle-epel-release-el10On Oracle Linux 9, the package name ends in el9 instead. Everything else in this step is the same.
sudo dnf install -y oracle-epel-release-el9The Oracle Linux 10 transaction pulls exactly two packages, the release package and yum-utils as its only dependency. Both come from ol10_baseos_latest, so nothing outside Oracle’s own channels is involved yet.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
oracle-epel-release-el10 x86_64 1.0-7.el10 ol10_baseos_latest 15 k
Installing dependencies:
yum-utils noarch 4.7.0-9.0.1.el10 ol10_baseos_latest 93 k
Transaction Summary
================================================================================
Install 2 PackagesThe whole run took 17.4 seconds on Oracle Linux 10, and most of that was the first metadata download (78 MB for BaseOS, 38 MB for UEK). The same step took 59.7 seconds on Oracle Linux 9, almost all of it CPU time spent processing metadata, so a slow first install on a small VM is normal. The package itself carries nothing except /etc/yum.repos.d/oracle-epel-ol10.repo and a license file. Read that repo file, because the ID inside is what you’ll pass to dnf later.
cat /etc/yum.repos.d/oracle-epel-ol10.repoIt holds a single repo section. You want the ID in brackets and the path inside the baseurl.
[ol10_u2_developer_EPEL]
name=Oracle Linux $releasever.2 EPEL Packages for Development ($basearch)
baseurl=https://yum$ociregion.$ocidomain/repo/OracleLinux/OL10/2/developer/EPEL/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1The repo ID is ol10_u2_developer_EPEL and the baseurl points at OL10/2, because Oracle publishes the Oracle Linux 10 EPEL channel per minor release. The release package is hard-coded to the current minor rather than to your host’s, which is why our 10.1 image was handed the 10.2 channel. The gpgkey line points at RPM-GPG-KEY-oracle, which Oracle Linux already has imported, so packages from this channel install without a key prompt.
The ID also changes on the same host over time. We unpacked three builds of oracle-epel-release-el10 from Oracle’s BaseOS repository: 1.0-2 defines ol10_u0_developer_EPEL, 1.0-5 defines ol10_u1_developer_EPEL and 1.0-7 defines ol10_u2_developer_EPEL, with changelog entries that read “Switch to EPEL 10.1” and “Switch to EPEL 10.2”. Expect a new ID with each minor update, so read it from dnf repolist before you hard-code it in a kickstart file or an Ansible task.
Oracle Linux 9 keeps the older layout, with no minor release in the path and a stable ID of ol9_developer_EPEL. Check the file on a 9 host.
cat /etc/yum.repos.d/oracle-epel-ol9.repoCompare it with the Oracle Linux 10 file above. Only the section ID, the name and the path differ, so anything you script against one release ports to the other once you swap the ID.
[ol9_developer_EPEL]
name=Oracle Linux $releasever EPEL Packages for Development ($basearch)
baseurl=https://yum$ociregion.$ocidomain/repo/OracleLinux/OL9/developer/EPEL/$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1Older guides, the previous version of this one included, wrote these files by hand with tee. There is no reason to do that now. The package is in BaseOS on both releases, it writes the correct ID for your release, and removing it later takes the file with it, so a hand-written file only gives you one more thing to keep in sync.
The word “developer” in the path is deliberate. Oracle’s Oracle Linux 10 repository page lists EPEL in a section whose contents are for development purposes only, and says Oracle suggests not using those channels in production. From my own experience EPEL is a great repository and I’ve never recorded a bug I could blame on it. Still, on hosts where Oracle support terms matter, keep EPEL to tools you could live without, such as monitors and admin utilities, rather than the service the box exists to run. If the host is held to the DISA STIG for Oracle Linux 9, rule OL09-00-000105 (linked in the removal step below) makes any repository with epel in its name a finding, so EPEL is off the table there.
Verify the EPEL repository
Refresh the metadata once so dnf downloads the EPEL index. On our Oracle Linux 10 box the EPEL index was 7.6 MB against a few kilobytes for each stock repo, and the refresh finished in 3.6 seconds. Oracle Linux 9 took 10.9 seconds, so give it a moment on a small VM.
sudo dnf makecacheThen check that dnf lists the new repo among the enabled ones:
sudo dnf repolistYou should see a fourth line under the three stock repos. If it is missing, the release package did not install, so go back to the previous step before trying any EPEL package.
repo id repo name
ol10_UEKR8 Oracle Linux 10 UEK Release 8 (x86_64)
ol10_appstream Oracle Linux 10 Application Stream Packages (x86_64)
ol10_baseos_latest Oracle Linux 10 BaseOS Latest (x86_64)
ol10_u2_developer_EPEL Oracle Linux 10.2 EPEL Packages for Development (x86_64)For the details, query the repo by its ID:
dnf repoinfo ol10_u2_developer_EPELThe fields to look at are the status, the package count and the baseurl. Repo-expire of 172,800 seconds means dnf rechecks this channel’s metadata every 48 hours unless you refresh it yourself.
Repo-id : ol10_u2_developer_EPEL
Repo-name : Oracle Linux 10.2 EPEL Packages for Development (x86_64)
Repo-status : enabled
Repo-revision : 1792030008
Repo-updated : Thu 15 Oct 2026 02:06:52 AM UTC
Repo-pkgs : 35,221
Repo-available-pkgs: 35,221
Repo-size : 61 G
Repo-baseurl : https://yum.oracle.com/repo/OracleLinux/OL10/2/developer/EPEL/x86_64/
Repo-expire : 172,800 second(s) (last: Thu 15 Oct 2026 07:04:39 AM UTC)
Repo-filename : /etc/yum.repos.d/oracle-epel-ol10.repo
Total packages: 35,221A healthy result shows Repo-status: enabled and a baseurl on yum.oracle.com with the release and architecture filled in. Do not compare Repo-pkgs with other EPEL mirrors at face value, though, because it counts every package file in the channel. Source packages such as fastfetch.src sit next to the binaries, and older versions stay listed too (Oracle’s package index carries two btop builds, for example). That is why dnf list --available, which shows only the newest of each, counted 31,182 entries against the 35,221 here. Counting unique package names gives 27,488, and that still includes names that exist only as source packages. Oracle Linux 9 reports 42,267 for ol9_developer_EPEL on the same basis. Repo-size is the combined size of every package in the channel, not something dnf downloads.
Install packages from EPEL
Once the repo is enabled, EPEL packages install like anything from BaseOS or AppStream. To test it, install three admin tools the stock repositories don’t carry: htop, the btop process monitor and ncdu.
sudo dnf install -y htop btop ncdudnf takes the three tools from the EPEL channel and fills in their libraries from BaseOS and AppStream, so only the tools themselves come from EPEL. The transaction was seven packages and 3.2 MB, done in 2.2 seconds.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
btop x86_64 1.4.7-1.el10_2 ol10_u2_developer_EPEL 681 k
htop x86_64 3.3.0-5.el10_0 ol10_u2_developer_EPEL 214 k
ncdu x86_64 1.22-1.el10_1 ol10_u2_developer_EPEL 72 k
Installing dependencies:
hicolor-icon-theme noarch 0.17-20.el10 ol10_appstream 69 k
hwloc-libs x86_64 2.11.1-4.el10 ol10_baseos_latest 2.1 M
libpciaccess x86_64 0.16-16.el10 ol10_baseos_latest 27 k
ocl-icd x86_64 2.3.2-8.el10 ol10_baseos_latest 72 k
Transaction Summary
================================================================================
Install 7 PackagesTo prove where each package came from, check the From repo field. It names the repository that supplied the installed copy, so it also catches a stray third-party repo that got there first.
dnf info --installed htop btop ncdu | grep -E "^(Name|Version|Release|From repo)"The capture below shows the repo list and that check on our Oracle Linux 10 host. Each package should name the EPEL repo ID on its From repo line.
Every package reports ol10_u2_developer_EPEL. The release tags are worth reading too: htop is an el10_0 build, ncdu el10_1 and btop el10_2, so the u2 in the repo ID describes the channel, not every package in it. On Oracle Linux 9 the same check shows ol9_developer_EPEL, and that install also took the_silver_searcher in 5.0 seconds. If you’re cleaning up a full disk next, our ncdu walkthrough covers the key bindings and scripted scans.
Error: Unable to find a match: the_silver_searcher
Our first attempt on Oracle Linux 10 asked for the_silver_searcher along with the other three tools.
sudo dnf install -y htop btop ncdu the_silver_searcherdnf refused the whole request. It printed two lines and exited with code 1.
No match for argument: the_silver_searcher
Error: Unable to find a match: the_silver_searcherOne missing name fails the entire transaction. dnf installed nothing, not even the three packages that exist, and htop --version still returned command not found afterwards. This is not an Oracle gap, because Fedora’s EPEL 10 doesn’t have the package either, and the same is true of a few other names EPEL 9 still carries as packages of their own:
- inxi
- neofetch
- the_silver_searcher (the
agcommand) - p7zip (no package by that name)
Drop those names and the install goes through. If neofetch was in your build scripts, fastfetch is in EPEL 10 and fills the same role. p7zip is a different case. Oracle’s EPEL 10 package index lists 7zip packages, and 7zip-standalone carries a p7zip Provides. A request for p7zip can therefore still resolve to it, even though repoquery by name prints NOT FOUND. We did not install either in the lab. Before you install from a long list, check every name first, because a single miss costs you the whole transaction. This loop prints the newest build and its repo for each name, or NOT FOUND.
for p in inxi fastfetch neofetch the_silver_searcher fail2ban nethogs iftop byobu certbot screen moreutils pwgen sshpass p7zip ansible-core ansible; do printf "%-20s " $p; dnf repoquery --latest-limit 1 --qf "%{name}-%{version}-%{release} %{repoid}" $p 2>/dev/null | head -1 | grep . || echo "NOT FOUND"; doneOracle Linux 10 with Oracle’s EPEL channel enabled answered like this. The last column tells you which repo each match came from.
inxi NOT FOUND
fastfetch fastfetch-2.68.1-1.el10_2 ol10_u2_developer_EPEL
neofetch NOT FOUND
the_silver_searcher NOT FOUND
fail2ban fail2ban-1.1.0-6.el10_0 ol10_u2_developer_EPEL
nethogs nethogs-0.8.8-1.el10_1 ol10_u2_developer_EPEL
iftop iftop-1.0-0.34.pre4.el10_0 ol10_u2_developer_EPEL
byobu byobu-6.14-1.el10_2 ol10_u2_developer_EPEL
certbot certbot-4.2.0-1.el10_2 ol10_u2_developer_EPEL
screen screen-5.0.1-6.el10_2 ol10_u2_developer_EPEL
moreutils moreutils-0.68-3.el10_0 ol10_u2_developer_EPEL
pwgen pwgen-2.08-17.el10_1 ol10_u2_developer_EPEL
sshpass sshpass-1.09-9.el10_0 ol10_appstream
p7zip NOT FOUND
ansible-core ansible-core-2.16.16-2.0.1.el10_2.1 ol10_appstream
ansible NOT FOUNDRead the repo column as well as the NOT FOUND lines. sshpass and ansible-core resolve from ol10_appstream, so Oracle Linux 10 does not need EPEL for them at all. No repo here provides a package named plain ansible, either. fail2ban and certbot are both in Oracle’s channel, so the package our Fail2ban setup for EL10 installs is there on Oracle Linux 10 too. If an old runbook of yours pulls inxi or ag from EPEL, change the tool or keep that workload on Oracle Linux 9 for now.
One caution before you reuse the loop. Oracle publishes source packages in the same repos, and repoquery matches every architecture unless you filter it. A name whose binary lives only in CodeReady Builder can therefore still print a line from BaseOS, which carries its source package. texinfo, which comes up in the next section, is exactly that case. Add --arch $(uname -m),noarch to the repoquery call when you check your own list, the way the texinfo query below filters by architecture.
Enable CodeReady Builder for missing dependencies
Some EPEL packages depend on packages Oracle ships only in CodeReady Builder, and until that repo is on, dnf stops with a “nothing provides” error. It is not common. We dry-ran about 30 popular EPEL packages on Oracle Linux 10 with CodeReady Builder off, and only octave failed, on texinfo; repoquery shows gnulib-devel requires texinfo too. The same kind of sweep on Oracle Linux 9 failed on octave, gnulib-devel and ffmpeg-free. Since Oracle labels the repo Unsupported and most EPEL tools never touch it, we’d leave it off and follow this routine when an install fails:
- Note the package named after “nothing provides”.
- Query it with CodeReady Builder enabled for that one command.
- Enable CodeReady Builder if that’s where the package lives.
- Re-run the original install.
Oracle Linux 10 still ships dnf 4 (4.20 on our box), so the dnf config-manager --set-enabled syntax below works as written. Guides written for dnf 5 use a different config-manager syntax, so do not copy those onto Oracle Linux. The same repository has other IDs on RHEL, Rocky Linux and AlmaLinux, and our CRB guide for RHEL and Rocky Linux lists them per distro.
Error: nothing provides texinfo needed by octave
A dry run of octave on Oracle Linux 10 shows the error. The --assumeno flag resolves the transaction and then stops, so you can test a package without installing anything.
sudo dnf install --assumeno octave 2>&1 | tail -5The package that dnf can’t find is texinfo, and the last line suggests --skip-broken. Ignore that hint, because skipping octave is not what you asked for.
Last metadata expiration check: 0:02:13 ago on Thu 15 Oct 2026 07:04:37 AM UTC.
Error:
Problem: conflicting requests
- nothing provides texinfo needed by octave-6:11.1.0-2.el10_2.x86_64 from ol10_u2_developer_EPEL
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)BaseOS lists texinfo only as a source package, so ask dnf where the binary lives, with CodeReady Builder switched on for this one query:
dnf repoquery --enablerepo ol10_codeready_builder --arch x86_64,noarch --qf "%{name}-%{version}-%{release} %{repoid}" texinfoThere is one match, and it sits in CodeReady Builder. The repo ID in the second column is what you enable next. Our lab hosts were x86_64, hence the --arch x86_64,noarch filter; on an aarch64 host use --arch $(uname -m),noarch, and keep some filter in place, because without one the source package in BaseOS can match as well.
Last metadata expiration check: 0:00:32 ago on Thu 15 Oct 2026 07:06:19 AM UTC.
texinfo-7.1-6.el10 ol10_codeready_builderEnable that repository for good. dnf writes the change into the repo file, so it holds for every later dnf run.
sudo dnf config-manager --set-enabled ol10_codeready_builderThis capture from the same host shows the error, the fix and dnf repolist with CodeReady Builder now listed next to the EPEL channel.
With the repo on, the same dry run resolves. This filter keeps only the lines that show where octave and texinfo come from and how big the transaction is.
sudo dnf install --assumeno octave 2>&1 | grep -E "^ (octave|texinfo) |^Install|^Total download|^Installed size|Operation aborted"octave now comes from EPEL and texinfo from CodeReady Builder. The closing Operation aborted is expected, because --assumeno answers no at the prompt.
Installing:
octave x86_64 6:11.1.0-2.el10_2 ol10_u2_developer_EPEL 20 M
Installing dependencies:
texinfo x86_64 7.1-6.el10 ol10_codeready_builder 1.4 M
Installing weak dependencies:
Install 389 Packages
Total download size: 493 M
Installed size: 1.4 G
Operation aborted.We stopped at the dry run because 389 packages and 1.4 G on disk is a lot to install just to prove a dependency. The resolution is the point: once texinfo has a source, the error is gone. repoquery shows gnulib-devel also requires texinfo, so it needs the same repo.
Error: nothing provides ladspa needed by rubberband
The realistic Oracle Linux 9 case is ffmpeg-free, the FFmpeg build that EPEL ships. The error names a package three levels below the one you asked for, which is why it confuses people.
sudo dnf install --assumeno ffmpeg-free 2>&1 | tail -6dnf prints the whole chain, top down. Only the last line names the real problem.
- package ffmpeg-free-7.1.5-3.el9.x86_64 from ol9_developer_EPEL requires libavfilter.so.10(LIBAVFILTER_10)(64bit), but none of the providers can be installed
- package ffmpeg-free-7.1.5-3.el9.x86_64 from ol9_developer_EPEL requires libavfilter-free(x86-64) = 7.1.5-3.el9, but none of the providers can be installed
- package libavfilter-free-7.1.5-3.el9.x86_64 from ol9_developer_EPEL requires librubberband.so.2()(64bit), but none of the providers can be installed
- conflicting requests
- nothing provides ladspa needed by rubberband-3.1.3-2.el9.x86_64 from ol9_developer_EPEL
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)Read it from the bottom up and you find the real gap. ffmpeg-free needs libavfilter-free, which needs the rubberband library, which needs ladspa, and ladspa is in ol9_codeready_builder. Every line above the last one is a consequence of that single gap, so enable the repo and install.
sudo dnf config-manager --set-enabled ol9_codeready_builder
sudo dnf install -y ffmpeg-freeThe transaction ran 151 packages in 28 seconds, and ffmpeg -version worked straight after. These are the lines that matter, with ladspa now coming from CodeReady Builder:
ffmpeg-free x86_64 7.1.5-3.el9 ol9_developer_EPEL 1.9 M
ladspa x86_64 1.13-28.el9 ol9_codeready_builder 57 k
rubberband x86_64 3.1.3-2.el9 ol9_developer_EPEL 379 k
Install 151 Packages
Total download size: 114 M
Installed size: 371 M
Complete!That is 371 M on disk for one media tool, which is fine on a transcoding box and wasteful on a web server, so check the size line before you confirm on a small host. If you want the RPM Fusion build of FFmpeg instead, our FFmpeg guide for Rocky, AlmaLinux and Oracle Linux 9 installs it on top of EPEL and CodeReady Builder. Skip its first repository block, including the crb line, because Oracle’s channel and ol9_codeready_builder are already enabled at this point, and expect that its RPM Fusion step may need --allowerasing.
Disable or remove EPEL
You can switch the channel off without uninstalling anything. That suits a server where you want EPEL for one install but not on every dnf upgrade. It has one cost. dnf stops reading the repo, so EPEL packages you already installed only get updates when you name the repo on the command line.
sudo dnf config-manager --set-disabled ol10_u2_developer_EPELCheck the result with a filtered repo list. The grep keeps the EPEL and CodeReady Builder lines and drops the rest.
dnf repolist --all | grep -E "EPEL|codeready"The repo stays configured but reads disabled. We had switched CodeReady Builder back off before this step, so it shows disabled as well; yours stays enabled if you turned it on above.
ol10_codeready_builder Oracle Linux 10 CodeReady Builder (x86_64) - (Un disabled
ol10_u2_developer_EPEL Oracle Linux 10.2 EPEL Packages for Development disabledFor a one-off install or lookup while the repo is off, add --enablerepo to that single command. The flag lasts for that command only and leaves the repo file untouched.
dnf --enablerepo=ol10_u2_developer_EPEL list --available fastfetchfastfetch shows up even though the channel is disabled. The .src line is the source package Oracle publishes in the same channel, which is why Repo-pkgs read high earlier.
fastfetch.src 2.68.1-1.el10_2 ol10_u2_developer_EPEL
fastfetch.x86_64 2.68.1-1.el10_2 ol10_u2_developer_EPELWith the repo excluded, the same kind of lookup returned Error: No matching Packages to list, so in a lookup, a missing --enablerepo looks the same as a package that doesn’t exist. Turn the repo back on with the matching command.
sudo dnf config-manager --set-enabled ol10_u2_developer_EPELLeaving the repo disabled on Oracle Linux 10 has a catch at the next minor update. The repo file is packaged as %config(noreplace), and config-manager rewrites it when you disable the repo, so when a new release package arrives with the next ID, RPM keeps your edited file and saves the new one as oracle-epel-ol10.repo.rpmnew. Your host keeps pointing at the old channel, and old channels stop moving: Oracle’s OL10/1 EPEL metadata was last updated on June 4, 2026, while OL10/2 updated on October 15. After each minor upgrade, run the filtered repo list above and look for a .rpmnew file in /etc/yum.repos.d.
If ls /etc/yum.repos.d/*.rpmnew lists oracle-epel-ol10.repo.rpmnew, move it over the old file with sudo mv /etc/yum.repos.d/oracle-epel-ol10.repo.rpmnew /etc/yum.repos.d/oracle-epel-ol10.repo. The new file arrives with enabled=1, so if you want the channel off, disable it again with config-manager under its new ID. We did not hit a minor update in the lab, so these two commands were not run there.
Once any .rpmnew is merged, a glob saves you from tracking the ID in one-off commands. dnf’s command reference accepts a glob of repo IDs, so --enablerepo='ol10_*_developer_EPEL' picks up whichever ID the current file defines. Before the merge, the glob only matches the old ID and its frozen channel, so merge first. We used the literal ID in the lab and did not run the glob form.
To take EPEL off the system completely, remove the release package. It takes the repo file and the yum-utils dependency with it.
sudo dnf remove -y oracle-epel-release-el10Two packages go, and /etc/yum.repos.d is back to Oracle’s three stock files afterwards. The packages you installed from EPEL are not on the list.
Removing:
oracle-epel-release-el10 x86_64 1.0-7.el10 @ol10_baseos_latest 18 k
Removing unused dependencies:
yum-utils noarch 4.7.0-9.0.1.el10 @ol10_baseos_latest 21 kRemoving the repo does not uninstall what came from it. rpm -q htop btop ncdu still listed all three packages afterwards. They get no further updates until EPEL comes back, so remove them by name if you want them gone. To remove everything that came from EPEL in one step, the DISA STIG fix text for Oracle Linux 9 uses sudo dnf repository-packages ol9_developer_EPEL remove. It needs the repo to still be defined, so run it before you remove the release package; we did not run it in the lab.
That command only catches packages installed under the ID you name, and it refuses an ID that no repo file defines any more. On Oracle Linux 10 the ID rotates with each minor update, so htop installed under ol10_u1_developer_EPEL is neither removed by a run against ol10_u2_developer_EPEL nor reachable by its old ID once the repo file moves on. A wildcard does not help either: dnf compares the recorded repo name exactly. The repo column of dnf list --installed shows which ID each package came from, so remove the older ones by name.
On Oracle Linux 9 the same commands work with ol9_developer_EPEL and oracle-epel-release-el9, and we ran the disable, enable and remove steps there with the same results. The 9 repo file keeps one ID, so the .rpmnew check above matters less there.
Use Fedora’s epel-release RPM instead
Fedora’s epel-release RPM installs and works on Oracle Linux. Fedora’s EPEL getting-started page gives it to other RHEL-compatible distributions for EL9, after enabling their CodeReady Builder equivalent, while for EL10 the page only covers RHEL and CentOS Stream. We’d only reach for it when your Oracle Linux hosts must match a fleet of RHEL, Rocky or AlmaLinux machines that already use it. Even then, remove Oracle’s release package first, because running both gives you two copies of every package the channels share. On Oracle Linux 10:
sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpmFor Oracle Linux 9, use the EPEL 9 release RPM. It’s the same RPM family our EPEL guide for RHEL 10 and CentOS Stream 10 uses on Red Hat’s own systems.
sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpmBoth finished in a few seconds (2.2 on Oracle Linux 10, 6.4 on Oracle Linux 9) and ended with the same advice from the package scriptlet. Because it is a direct URL install, dnf lists the repository as @commandline in the transaction.
Many EPEL packages require the CodeReady Builder (CRB) repository.
It is recommended that you run /usr/bin/crb enable to enable the CRB repository.Oracle’s package drops one repo file. Fedora’s adds a testing repo, its own signing key and the helper that message refers to, so you have more to clean up if you switch back later. These are the files it placed on Oracle Linux 10:
- /etc/yum.repos.d/epel.repo
- /etc/yum.repos.d/epel-testing.repo
- /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-10
- /usr/bin/crb
The crb script knows Oracle’s repo naming, so you do not have to look up the CodeReady Builder ID yourself. Run it as root.
sudo crb enableIt found and enabled ol10_codeready_builder, the same repo the dnf config-manager command enabled earlier, so either path ends in the same state.
Enabling CRB repo
CRB repo is enabled and named: ol10_codeready_builderThe helper only runs as root, and forgetting sudo gives an error that doesn’t say so.
Error: /usr/bin/crb: Permission denied
Running crb status as a normal user returned bash: line 1: /usr/bin/crb: Permission denied in our session, even though a status check changes nothing. An interactive login shell prints the same error as -bash: /usr/bin/crb: Permission denied. The script ships with mode -rwxr--r--, readable by everyone but executable only by root, so prefix every crb call with sudo, the status check included.
Check which EPEL branch Oracle Linux 10 uses
The bigger surprise on Oracle Linux 10 is the branch this repo file selects. It builds the branch name from dnf variables, so read its first section.
sed -n "1,12p" /etc/yum.repos.d/epel.repoThe metalink line is the one to study. Its value depends on two dnf variables, releasever and releasever_minor.
[epel]
name=Extra Packages for Enterprise Linux $releasever - $basearch
# It is much more secure to use the metalink, but if you wish to use a local mirror
# place its address here.
#baseurl=https://download.example/pub/epel/$releasever${releasever_minor:+z}/Everything/$basearch/
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever&arch=$basearch
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major
gpgcheck=1
repo_gpgcheck=0
metadata_expire=24h
countme=1
enabled=1When releasever_minor has a value, the metalink asks for an epel-z branch tied to that minor release. Oracle Linux 10 leaves it empty, and its release package provides a plain releasever of 10.
rpm -q --provides oraclelinux-release | grep -i -E "system-release|releasever"The first line has the full minor version (10.1 on our image). dnf takes its releasever from the second one, which is just 10.
system-release = 10.1-1.0.6.el10
system-release(releasever) = 10So the metalink requests epel-10, the branch EPEL builds against CentOS Stream 10. You can confirm it from the repo details.
dnf repoinfo epel 2>&1 | grep -E "Repo-(id|name|pkgs|baseurl|metalink|updated)|Total"Look at the metalink and the path in the baseurl. Mirrors served the 10.3 tree to our 10.1 system.
Repo-id : epel
Repo-name : Extra Packages for Enterprise Linux 10 - x86_64
Repo-updated : Thu 15 Oct 2026 12:54:23 AM UTC
Repo-pkgs : 25,993
Repo-metalink : https://mirrors.fedoraproject.org/metalink?repo=epel-10&arch=x86_64
Repo-baseurl : http://ftp-stud.hs-esslingen.de/pub/epel/10.3/Everything/x86_64/ (77 more)
Total packages: 25,993Recent builds on that branch carry el10_3 tags (fastfetch and btop here), while packages that haven’t been rebuilt keep older ones, which is why nethogs arrived as el10_1. Fedora’s EPEL branch documentation describes epel10 as the branch built against CentOS Stream 10, which runs ahead of every released minor. The 10.3 mirror path fits that, since 10.2 is the newest Oracle Linux release, while Oracle’s channel follows the current Oracle Linux minor.
fastfetch and nethogs installed cleanly from Fedora’s branch in our test and fastfetch ran, so nothing broke. On a server, though, we’d rather take packages built for the release we run, and that is the main reason to stay with Oracle’s channel. Oracle Linux 9 has no such wrinkle, because its file asks for a plain epel-9 and mirrors serve the EPEL 9 tree.
Your first install from Fedora’s repo also imports Fedora’s EPEL key. We installed two tools to trigger it.
sudo dnf install -y fastfetch nethogsThe key import appears after the packages download and before anything installs. The fingerprint line is the one you check.
Importing GPG key 0xE37ED158:
Userid : "Fedora (epel10) <[email protected]>"
Fingerprint: 7D8D 15CB FC4E 6268 8591 FB26 33D9 8517 E37E D158
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-10
Key imported successfullyWith -y, dnf accepts the key without asking, so if you script this, compare the fingerprint with the one Fedora publishes before the first install. On Oracle Linux 9 the key is 0x3228467C, “Fedora (epel9)”. Oracle’s channel never shows this step because it reuses the Oracle key.
Installing Oracle’s release package on top of Fedora’s does not fail, and that’s the trap. Both repos stay enabled, and every package that exists in both channels appears twice.
dnf list --showduplicates btop 2>/dev/null | tail -3btop now has a build from each source. The upstream version is identical, and only the release tag differs.
btop.src 1.4.7-1.el10_2 ol10_u2_developer_EPEL
btop.x86_64 1.4.7-1.el10_2 ol10_u2_developer_EPEL
btop.x86_64 1.4.7-1.el10_3 epel Fedora’s el10_3 sorts above Oracle’s el10_2, so the next dnf upgrade would quietly move btop to Fedora’s package. Keep one source. To drop the Fedora one:
sudo dnf remove -y epel-releaseAfter that, dnf repolist showed ol10_u2_developer_EPEL as the only EPEL repo, and /etc/yum.repos.d held Oracle’s files again. Two things stay behind. Removing epel-release does not remove Fedora’s key, which stays in the RPM database as gpg-pubkey-e37ed158-65785fa9, and anything you installed from Fedora’s repo stays installed. A Fedora build such as fastfetch el10_3 sorts above Oracle’s el10_2, so it gets no updates from Oracle’s channel until Oracle ships a newer version.
Compare EPEL on Oracle Linux 10 and 9
Most of the differences between the two releases are names and paths, but the package set has shifted too. This is what the lab showed side by side.
| Item | Oracle Linux 10 | Oracle Linux 9 |
|---|---|---|
| Release package | oracle-epel-release-el10 | oracle-epel-release-el9 |
| EPEL repo ID | ol10_u2_developer_EPEL | ol9_developer_EPEL |
| Channel path | OL10/2/developer/EPEL (per minor release) | OL9/developer/EPEL |
| Repo ID changes with minor updates | Yes (u0, u1, u2 so far) | No |
| CodeReady Builder repo ID | ol10_codeready_builder | ol9_codeready_builder |
| Repo-pkgs in Oracle’s channel (sources included) | 35,221 | 42,267 |
| dnf version | 4.20 | 4.14 |
| Fedora epel-release metalink | epel-10 (CentOS Stream 10 branch) | epel-9 |
| Fedora EPEL signing key | 0xE37ED158 | 0x3228467C |
| Present in EPEL (tested) | htop, btop, ncdu, fastfetch, fail2ban, certbot | htop, btop, ncdu, fastfetch, fail2ban, certbot |
| Missing from EPEL | inxi, neofetch, the_silver_searcher (p7zip only as a Provides of 7zip-standalone) | None of those: all four are separate packages |
| Needs CodeReady Builder | octave (texinfo); repoquery shows gnulib-devel also requires texinfo | octave, gnulib-devel (texinfo), ffmpeg-free (ladspa) |
Use the table as a pre-flight check before you move a workload from 9 to 10. Run your package list through the repoquery loop above and look at the missing row first, because one missing name fails the whole dnf transaction. On either release, install Oracle’s release package and read the repo ID from dnf repolist instead of hard-coding it. On 10, check for a .rpmnew repo file after each minor update, and on both, turn on CodeReady Builder only when a “nothing provides” error points at it.
Thank you so much for writing this article.
You are welcome. We are glad it was of help to you.