Fix broken dnf, yum and rpm after a failed or interrupted update

Updated November 2026

Most dnf failures after an interrupted or bad update come down to four things: stale metadata, a damaged rpm database, package conflicts from mixed repositories, or duplicate packages left by a transaction that never finished. Each has a safe fix, and dnf's transaction history lets you undo the change that caused it.

Do this first.

Make sure no other dnf, yum, rpm or PackageKit process is still running. Wait for it rather than killing it.
Check free space with df -h / /boot /var. Free space before anything else.
Before rebuilding the rpm database, copy it (step 3). Never delete files in the rpm database directory by hand.
Don't reboot until dnf check is clean if the kernel, glibc or systemd were in the failed transaction.

Know which dnf you have

Commands differ slightly between DNF 4 and DNF5. Fedora switched the dnf command to DNF5 in Fedora 41. RHEL 10 still uses DNF 4 (it ships dnf-plugins-core 4.7), as do RHEL 8 and 9 and rebuilds such as Rocky Linux and AlmaLinux. On RHEL 8 and later, yum is DNF 4 under the old name. Check:

dnf --version

Differences that matter in an emergency: DNF5 needs a subcommand for history (dnf history list, not plain dnf history), its history undo and rollback accept --ignore-extras and --ignore-installed, and it has a history redo that its manual says “is useful to finish interrupted transactions”. Options such as --allowerasing must come after the command name. The commands below work on both unless noted.

Symptoms

“Error: Failed to download metadata for repo” or checksum errors on metadata.
“error: rpmdb open failed”, “cannot open Packages database”, or dnf and rpm hang on every command.
“file /usr/... from install of A conflicts with file from package B”, or “nothing provides libfoo.so needed by ...”.
rpm -q PACKAGE lists two versions of a package that should only exist once (kernels are allowed to have several).

Step 1: Check what is running

ps -ef | grep -E '[d]nf|[y]um|[r]pm|[p]ackagekit'
systemctl list-timers 'dnf*'

dnf-automatic or PackageKit may be running an update in the background. Let it finish. If a process has truly hung (no CPU, no disk activity, no progress for a long time), stop it with sudo kill PID and only use kill -9 if that fails.

Step 2: Clear the cache

Bad or half-downloaded metadata causes many errors. Cleaning is always safe; it only deletes downloaded data, which dnf fetches again:

sudo dnf clean all
sudo dnf makecache

On DNF5, makecache avoids downloading when it can; add --refresh to force fresh metadata. If one repository still fails, check its URL and your network or proxy, or skip it for now with --disablerepo=REPO_ID.

Step 3: Repair the rpm database

The rpm database records every installed package. Back it up, then rebuild its indexes from the installed package headers:

sudo cp -a "$(rpm --eval '%{_dbpath}')" /root/rpmdb-backup-$(date +%F)
sudo rpm --rebuilddb
rpm -qa | wc -l

rpm --eval '%{_dbpath}' prints where the database lives on your release, so the copy always goes to the right place. The package count after the rebuild should be close to what you expect (hundreds on a minimal server, not zero). sudo rpm --verifydb runs a low-level integrity check if you want a second opinion.

If rpm -qa returns nothing after a rebuild, stop. Don't install or remove anything; restore the backup copy and get help. Reinstalling packages on top of an empty database causes far bigger problems.

Step 4: Check and fix dependencies

sudo dnf check

dnf check examines the local package database and reports missing dependencies, conflicts, duplicates and obsoleted packages. Work through the list:

Duplicate packages

An interrupted update can leave both the old and the new version of a package installed. Remove the older copies:

sudo dnf remove --duplicates

Both DNF 4 and DNF5 remove the older versions and reinstall the newest to keep files intact. Kernels and other “install-only” packages are meant to have several versions and aren't touched. Read the transaction summary before you confirm.

On DNF5, if the history shows the last transaction was cut off, sudo dnf history redo ID (with that transaction's ID) is another way to complete it.

Conflicts

Most conflicts come from third-party repositories that replace distribution packages, or from enabling repositories for the wrong major release. Find where each package came from:

dnf repolist
dnf list installed PACKAGE

Then choose the least risky fix:

Exclude the problem package for one run: sudo dnf upgrade --exclude=PACKAGE.
Disable a misbehaving repository: sudo dnf upgrade --disablerepo=REPO_ID.
--skip-broken leaves out packages that cause depsolve problems. Remember that skipped packages might include security fixes.
--allowerasing lets dnf remove installed packages to resolve dependencies. Read every package listed under “Removing” before you answer y.

Step 5: Undo the bad transaction

dnf records each transaction. Find the one that caused the trouble:

sudo dnf history list
sudo dnf history info 42

Then either reverse just that transaction, or roll back everything after a known-good one:

sudo dnf history undo 42
sudo dnf history rollback 41

undo performs the opposite of every action in transaction 42. rollback 41 undoes all transactions after 41 and leaves 41 itself in place. Both need the old package versions to be available in an enabled repository; Red Hat's documentation notes that the downgrade fails if they are not. On DNF5, add --skip-unavailable to skip actions that can't be done, and check what was skipped.

Red Hat does not support downgrading core system packages such as the kernel, glibc or SELinux packages. For a bad kernel, boot the previous kernel instead (kernel boot failure). Undoing an update also brings back the vulnerabilities it fixed; see roll back a bad update.

Confirm it is fixed

sudo dnf check prints nothing.
sudo dnf makecache refreshes every enabled repository without errors.
sudo dnf upgrade either has nothing to do or shows a clean transaction.
Services you care about are running: systemctl --failed shows no failed units.
Check whether a reboot is needed: see restart after updates.

Prevent it next time

Run updates inside tmux or screen so a dropped connection doesn't stop dnf mid-transaction.
Keep free space on /, /var and /boot. dnf keeps installonly_limit kernels (default 3); sudo dnf remove --oldinstallonly removes extras but always keeps the running kernel.
Use as few third-party repositories as possible, and only ones built for your major release.
Note the transaction ID before and after each maintenance window, so history rollback is quick if you need it.
Use automatic updates for security fixes, and snapshots before major changes.

When to get help

Get your hosting provider, your vendor's support (if you have a subscription) or an experienced administrator involved if the rpm database can't be rebuilt, rpm -qa is empty, glibc or rpm itself is half-updated, or the system no longer boots. If you find packages, repositories or GPG keys (rpm -q gpg-pubkey) that nobody added, treat it as a possible compromise: see signs of compromise.