How to Downgrade and Lock Packages With dnf in RHEL Systems

You ran dnf update, and now something has stopped working. Instead of spending hours troubleshooting, you just want to go back to the package version that was working before.

Taking a minute to check these first can save you from creating even more dependency problems later.
After downgrading a package, the next dnf update will try to install the latest available version again. If you want to keep the package at its current version, use the versionlock plugin.
dnf list –showduplicates nginx

Fix it by downgrading the dependency too:

TecMint Weekly Newsletter
Get the Learn Linux 7 Days Crash Course free when you join 34,000+ Linux professionals reading every Thursday.
Check your email for a magic link to get started.
Something went wrong. Please try again.

How DNF Handles Downgrades

sudo dnf history undo 12

First, check whether the package is still available in DNF’s local cache:
dnf info nginx

sudo dnf versionlock list

If you want more information about the installed package, including the repository it came from, use:

  • Is the version you want compatible with the packages currently installed on your system?
  • Is the older version still available in one of your enabled repositories or in your local package cache?

First, view your recent DNF transactions:

Check What Versions Are Available

From DNF’s point of view, everything installed successfully, but that doesn’t always mean your applications will continue to work as expected.
Before you start downgrading packages, it’s useful to understand what DNF does behind the scenes.
sudo dnf install /var/cache/dnf/appstream-3f8c21a9d4b72e01/packages/nginx-1.24.0-4.el10.x86_64.rpm

This happens more often than most Linux administrators would like to admit. Maybe a new Nginx release introduced a default configuration change that broke your virtual hosts. A Python library update changed an API that your internal scripts rely on. Or perhaps a kernel update no longer works with a third-party driver.
sudo dnf versionlock delete nginx

Tip: Another way to prevent updates is to add exclude=nginx to /etc/dnf/dnf.conf. However, exclude blocks all future updates for that package until you remove the setting.

Downgrade From a Local RPM File

To list all available versions of a package, run:
After the transaction finishes, verify the installed version:
sudo dnf check

When you’re ready to receive updates again, remove the lock:

If you want to go deeper on dnf package management and repo configuration, the 100+ Essential Linux Commands course on Pro TecMint covers it end to end.

Downgrade to the Previous Version

If you simply want to go back to the previous version of a package, use the dnf downgrade command:
If you still have the older RPM file, you can install it directly.
If you downloaded the RPM from another system or an external source, verify its signature before installing it:
rpm –checksig nginx-1.24.0-4.el10.x86_64.rpm

Use DNF History to Roll Back an Entire Transaction

Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Downgrading:
nginx x86_64 1:1.24.0-4.el10 appstream 42 k

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

Total download size: 42 k
Is this ok [y/N]: y

nginx -v

/var/cache/dnf/appstream-3f8c21a9d4b72e01/packages/nginx-1.24.0-4.el10.x86_64.rpm

Downgrading a package on RHEL-based distributions is easy when it’s an independent package, but things become more challenging when other packages depend on the newer version, because DNF may also need to downgrade related dependencies to keep the system consistent.
sudo dnf install python3-dnf-plugins-core

Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Downgrading:
nginx x86_64 1:1.24.0-4.el10 appstream 42 k

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

Total download size: 42 k
Is this ok [y/N]: y
Downloading Packages:
nginx-1.24.0-4.el10.x86_64.rpm 42 kB/s | 42 kB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Downgrading : nginx-1:1.24.0-4.el10.x86_64 1/2
Cleanup : nginx-1:1.26.2-2.el10.x86_64 2/2
Verifying : nginx-1:1.24.0-4.el10.x86_64 1/2
Verifying : nginx-1:1.26.2-2.el10.x86_64 2/2

Downgraded:
nginx-1:1.24.0-4.el10.x86_64

Complete!

sudo dnf downgrade nginx-1.24.0-4.el10

To see exactly what changed during a transaction, run:

Lock the Package Version with versionlock

To undo that transaction, run:
sudo dnf history undo last

Handle Broken Dependencies After a Downgrade

ID | Command line | Date and time | Action(s) | Altered
——————————————————————————-
12 | update nginx | 2026-06-29 09:14 | Update | 1
11 | install httpd | 2026-06-28 14:22 | Install | 3
10 | update | 2026-06-27 08:00 | Update | 47
9 | install python3-flask | 2026-06-26 16:44 | Install | 5

The Available Packages section lists every version that your enabled repositories currently provide. If the version you want appears here, you can downgrade to it.
sudo dnf downgrade nginx

If you need to downgrade to a version that’s more than one release behind, specify the package name followed by the target version:
Every time you install, update, remove, or downgrade a package, DNF records the operation as a transaction in its history database. This history makes it possible to review previous changes and, in many cases, roll back an entire transaction instead of manually fixing individual packages.
Installed Packages
Name : nginx
Epoch : 1
Version : 1.26.2
Release : 2.el10
Architecture : x86_64
Size : 1.7 M
Source : nginx-1.26.2-2.el10.src.rpm
Repository : @System
From repo : appstream
Summary : A high performance web server and reverse proxy server
License : BSD
Description : Nginx is a web server and a reverse proxy server for HTTP, SMTP,
: POP3 and IMAP protocols, with a strong focus on high concurrency,
: efficiency and low memory footprint.

sudo dnf history list

Once the downgrade is complete, verify that the expected version is installed:
When you run a package downgrade, DNF doesn’t simply replace the newer package with an older one. It first checks whether the older version is compatible with the rest of the packages currently installed on your system.
nginx version: nginx/1.24.0

nginx-1:1.24.0-4.el10.x86_64 requires nginx-filesystem = 1:1.24.0-4.el10
nginx-filesystem-1:1.26.2-2.el10.x86_64 is a newer version

That’s why it’s worth answering two questions before running a downgrade:
Last metadata expiration check: 0:02:31 ago on Mon Jun 29 11:14:08 2026.
nginx-1:1.24.0-4.el10.*

Have you used dnf history undo to recover from a bad update, or found a faster way to track down the right version when the repo no longer carries it? Share it in the comments below.
sudo dnf versionlock add nginx

If you simply want to undo the most recent DNF transaction, you don’t need to look up its ID:
Transaction ID : 12
Begin time : Sun Jun 29 09:14:22 2026
Begin rpmdb : 847:f3a2c…
End time : Sun Jun 29 09:14:38 2026 (16 seconds)
End rpmdb : 847:9b14d…
User : root
Return-Code : Success
Command Line : update nginx
Transaction performed with:
Installed rpm-4.19.1-1.el10.x86_64
Installed dnf-4.18.0-1.el10.noarch
Packages Altered:
Upgrade nginx-1:1.26.2-2.el10.x86_64 @appstream
nginx-1:1.24.0-4.el10.x86_64 @System

If it doesn’t, the repository no longer carries that package version. Don’t worry, we’ll cover how to recover older packages from the local RPM cache later in this guide.
In this guide, you’ll learn how to check which package versions are available, safely downgrade a package, prevent it from being updated again, recover an older package from the local RPM cache, and even roll back an entire DNF transaction if an update caused problems.
sudo dnf history info 12

sudo dnf downgrade nginx-filesystem

find /var/cache/dnf -name “nginx*.rpm”

nginx -v

Installed Packages
nginx.x86_64 1:1.26.2-2.el10 @appstream

Available Packages
nginx.x86_64 1:1.24.0-4.el10 appstream
nginx.x86_64 1:1.26.2-2.el10 appstream

Before downgrading a package, check which version is currently installed and whether the older version is still available in your enabled repositories.
sudo dnf check

The dnf downgrade command automatically selects the highest available version that is older than the one currently installed. Review the transaction summary, and if everything looks correct, press y to continue.
If another package depends on the newer version, DNF will detect the conflict depending on the situation, it may:
Examining /var/cache/dnf/appstream-3f8c21a9d4b72e01/packages/nginx-1.24.0-4.el10.x86_64.rpm: 1:nginx-1.24.0-4.el10.x86_64
Marking nginx-1.24.0-4.el10.x86_64.rpm as an update to 1:nginx-1.26.2-2.el10.x86_64
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Downgrading:
nginx x86_64 1:1.24.0-4.el10 @commandline 42 k

Transaction Summary
================================================================================
Downgrade 1 Package
Is this ok [y/N]: y

Complete!

Even though you’re installing an RPM file manually, DNF recognizes that the package is older than the installed version and performs a downgrade instead of a normal installation. It also checks dependencies just as it would when installing from a repository.

If this article helped, with someone on your team.
TecMint Weekly Newsletter
Get the Learn Linux 7 Days Crash Course free when you join 34,000+ Linux professionals reading every Thursday.
Check your email for a magic link to get started.
Something went wrong. Please try again.

Similar Posts