How to Downgrade RPM Packages in Linux with DNF and YUM

On current RHEL-family systems, use dnf downgrade to replace an installed package with an older version while DNF resolves dependencies from your enabled repositories.

Two forms matter in practice. sudo dnf downgrade PACKAGE selects the highest installable version that is lower than what is installed now. sudo dnf downgrade PACKAGE-VERSION-RELEASE requests one exact older build. You can also run sudo dnf install PACKAGE-VERSION-RELEASE when you want a specific available build, even if that means replacing the currently installed package with an older version.

Quick reference: downgrade RPM packages with DNF

Prefer DNF first because it resolves dependencies against enabled repositories. Use direct rpm only when you deliberately want lower-level package installation. An older build is available only if it still exists in an enabled repository or in a local RPM file you provide.

1. Check the installed and available package versions

Start with the version already on disk. This walkthrough uses jq, a small JSON tool that is safe to downgrade for demonstration:

rpm -q jq

jq-1.7.1-11.el10_2.2.x86_64

List every build DNF can see in enabled repositories:

dnf list --showduplicates jq

Installed Packages
jq.x86_64          1.7.1-11.el10_2.2             @rhel-10-for-x86_64-baseos-rpms
Available Packages
jq.x86_64          1.7.1-8.el10                  rhel-10-for-x86_64-baseos-rpms
jq.x86_64          1.7.1-8.el10_0.1              rhel-10-for-x86_64-baseos-rpms
jq.x86_64          1.7.1-11.el10                 rhel-10-for-x86_64-baseos-rpms
jq.x86_64          1.7.1-11.el10_1.0.2           rhel-10-for-x86_64-baseos-rpms
jq.x86_64          1.7.1-11.el10_2.2             rhel-10-for-x86_64-baseos-rpms

Read the columns as package name, architecture, version-release, and repository. The @ prefix marks the installed build.

When you only need the NEVRA strings, dnf repoquery is often easier to scan:

dnf repoquery jq

jq-0:1.7.1-11.el10.x86_64
jq-0:1.7.1-11.el10_1.0.2.x86_64
jq-0:1.7.1-11.el10_2.2.x86_64
jq-0:1.7.1-8.el10.x86_64
jq-0:1.7.1-8.el10_0.1.x86_64

2. Downgrade to the previous package version with DNF

dnf downgrade PACKAGE picks the highest installable version that is lower than the installed package. Review the transaction before you confirm it:

sudo dnf downgrade jq

================================================================================
Downgrading:
 jq    x86_64    1.7.1-11.el10_1.0.2    rhel-10-for-x86_64-baseos-rpms    208 k

Transaction Summary
================================================================================
Downgrade  1 Package

DNF may also change related dependencies when they must move together. Read the full transaction summary before answering y.

After the downgrade completes, confirm the installed build:

rpm -q jq

jq-1.7.1-11.el10_1.0.2.x86_64

3. Downgrade to a specific package version

When several older builds exist, list what DNF can install and pick the exact version-release you want before you run dnf downgrade:

dnf list --showduplicates jq

Installed Packages
jq.x86_64          1.7.1-11.el10_1.0.2           @rhel-10-for-x86_64-baseos-rpms
Available Packages
jq.x86_64          1.7.1-8.el10                  rhel-10-for-x86_64-baseos-rpms
jq.x86_64          1.7.1-8.el10_0.1              rhel-10-for-x86_64-baseos-rpms
jq.x86_64          1.7.1-11.el10                 rhel-10-for-x86_64-baseos-rpms
jq.x86_64          1.7.1-11.el10_1.0.2           rhel-10-for-x86_64-baseos-rpms
jq.x86_64          1.7.1-11.el10_2.2             rhel-10-for-x86_64-baseos-rpms

Choose a row from Available Packages that is older than the installed build. In this example, 1.7.1-8.el10 is lower than the installed 1.7.1-11.el10_1.0.2, so that becomes the downgrade target.

Request that exact build with PACKAGE-VERSION-RELEASE:

sudo dnf downgrade jq-1.7.1-8.el10

================================================================================
Downgrading:
 jq     x86_64     1.7.1-8.el10        rhel-10-for-x86_64-baseos-rpms     205 k

Transaction Summary
================================================================================
Downgrade  1 Package

Add the architecture when DNF needs it:

sudo dnf downgrade jq-1.7.1-8.el10.x86_64

A full RPM name is NEVRA: Name, Epoch, Version, Release, Architecture. DNF usually accepts name-version-release when the epoch is 0.

Installing the exact version with dnf install

For a normal non-installonly package, this command can also replace the installed build with the exact version you name:

sudo dnf install jq-1.7.1-11.el10

That path is useful when you already know the exact version-release you want. For broader repository and version-selection workflows, see install a specific package version with YUM/DNF.

4. Downgrade using an older local RPM file

If the older build is no longer available in your enabled repositories but you already have the RPM from a trusted source, inspect it before installation:

rpm -qp ./jq-1.7.1-8.el10.x86_64.rpm

jq-1.7.1-8.el10.x86_64

Install the local file with DNF so repository dependencies can still be resolved:

sudo dnf install ./jq-1.7.1-8.el10.x86_64.rpm

Downgraded:
  jq-1.7.1-8.el10.x86_64

For more package metadata before you install, use rpm -qpi ./jq-1.7.1-8.el10.x86_64.rpm.

If the older build is still available in a repository and you want to download a copy first, install the optional download plugin:

sudo dnf install 'dnf-command(download)'

Then fetch the RPM into the current directory:

dnf download jq-1.7.1-8.el10 --destdir .

That download path only works when DNF can find the build through enabled repository metadata. It is separate from installing an RPM you already obtained from another trusted source.

5. Downgrade with rpm --oldpackage when DNF is not appropriate

Treat direct RPM installation as a lower-level fallback. RPM does not provide DNF's repository dependency-resolution workflow.

sudo rpm -Uvh --oldpackage ./jq-1.7.1-8.el10.x86_64.rpm

Updating / installing...
jq-1.7.1-8.el10
Cleaning up / removing...
jq-1.7.1-11.el10_2.2

-U replaces the installed package, and --oldpackage allows the installed version to move backward.

Do not use rpm --force or --nodeps as a normal downgrade method. --force bypasses conflicts instead of resolving them, and --nodeps ignores dependencies the package manager would normally satisfy.

6. Fix common DNF downgrade errors

No packages marked for downgrade

This usually means DNF cannot find a lower installable build. Common causes include:

• the installed package is already the oldest version in enabled repositories
• the older build was removed from the repository
• a required repository is disabled
• a version lock or exclude rule blocks the target version

Check what DNF can still see:

dnf list --showduplicates PACKAGE

Confirm the repositories that feed those results are enabled:

dnf repolist

On this host, downgrading tree when only one build exists produces:

Package tree of lowest version already installed, cannot downgrade it.

No match for argument

The package name or NEVRA string does not match any available build:

dnf repoquery PACKAGE

Verify spelling, epoch, release, and architecture before retrying.

Dependency errors during downgrade

If DNF refuses the transaction because related packages cannot move together, inspect the proposed changes instead of forcing the install. Identify coupled packages, check whether compatible older builds exist, and downgrade them together only when required:

sudo dnf downgrade package1 package2

7. Verify the package after downgrade

Confirm the installed NEVRA:

rpm -q jq

For more detail:

rpm -qi jq

DNF's installed view is also useful:

dnf list --installed jq

If the package provides a command-line tool, run its version check too. For jq:

jq --version

8. Prevent DNF from upgrading the package again

A later dnf upgrade can reinstall the newer build unless you lock the package.

Install the versionlock plugin if dnf versionlock is not available:

sudo dnf install 'dnf-command(versionlock)'

Lock the currently installed package:

sudo dnf versionlock add jq

Adding versionlock on: jq-0:1.7.1-8.el10.*

List active locks:

sudo dnf versionlock list

jq-0:1.7.1-8.el10.*

Remove the lock when you are ready to allow upgrades again:

sudo dnf versionlock delete jq

9. YUM downgrade on older RHEL and CentOS systems

Keep YUM in the article because the slug and many search queries still use it. RHEL 8 and RHEL 9 provide yum compatibility on top of DNF, while current RHEL documentation uses DNF as the primary package-management interface. The yum compatibility command is also available on the tested RHEL 10.2 system, but the examples in this article use DNF first.

sudo yum downgrade PACKAGE

Exact version:

sudo yum downgrade PACKAGE-VERSION-RELEASE

List available versions:

yum list --showduplicates PACKAGE

Use DNF-first examples on current RHEL-family releases. Reserve the YUM command names for older systems and for readers who still search for them.

10. DNF downgrade vs history undo and rollback

These solve different problems.

Use dnf downgrade when you want to move one selected package to an older available version.

Use dnf history undo when you need to reverse the actions recorded in one previous DNF transaction.

Use dnf history rollback when you need to attempt reverting transactions after a selected history point.

Red Hat documents history undo and rollback for small package changes, not as a supported way to downgrade critical system packages or move an entire RHEL installation to an older minor release. See YUM history rollback and undo for the full workflow.

Kernel packages are different

Kernel packages are normally treated as installonly packages. Installing an older kernel usually adds another kernel package alongside existing ones rather than replacing the running kernel like a normal RPM downgrade. See remove old kernels on Linux instead of treating kernel rollback as a generic package downgrade here.

Summary

Check available versions with rpm -q and dnf list --showduplicates before you change anything. Use dnf downgrade PACKAGE when you want the next lower installable build, and name the full PACKAGE-VERSION-RELEASE when you need an exact older release.

Prefer DNF over direct rpm so dependencies can be resolved from enabled repositories. Use rpm -Uvh --oldpackage only as a deliberate lower-level fallback. Lock the package with dnf versionlock when a routine upgrade must not undo the downgrade.

References

• Managing software with the DNF tool — Red Hat documentation for package install, downgrade, and history on RHEL 10
• DNF Command Reference — upstream dnf downgrade, install, and repoquery syntax
• How to use yum/dnf to downgrade or rollback some package updates? — Red Hat guidance on downgrade limits and history-based rollback
• RPM manual — rpm -U, --oldpackage, and query options