How to Fix Broken RPM Database on Fedora 44

Fedora package failures can look similar even when they come from different layers. A mirror or metadata problem belongs to DNF, while a broken RPM database affects the local record of installed packages, file ownership, installed package headers, and dependency checks. To fix a broken RPM database on Fedora Linux, first prove that RPM itself cannot query or verify the database, then back up the current database path, rebuild it with rpmdb --rebuilddb, and verify DNF before installing anything else.

These steps target normal mutable Fedora Workstation, Server, Spins, and minimal installs that use dnf and RPM directly. Fedora Atomic desktops such as Silverblue and Kinoite, plus Fedora CoreOS systems, use rpm-ostree for the system image, so treat them as separate recovery paths instead of applying mutable-host RPM database repairs blindly.

Use the Safest RPM Database Repair Order

RPM database recovery works best as an escalation path. Start with read-only proof, try the narrower DNF metadata fix when RPM itself still works, and rebuild only after you have a backup from the live RPM database path.

Phase	What it proves or protects	Typical command
Confirm the failure	Separates a real RPM database problem from a mirror, repository, or cache problem.	rpmdb --verifydb
Try DNF metadata cleanup when RPM works	Fixes stale repository metadata without touching the installed-package database.	sudo dnf clean metadata
Check for active package work	Prevents rebuilding the database while DNF, RPM, or a graphical software tool is using it.	lslocks against .rpm.lock
Back up the current database	Preserves the exact rpmdb directory before a high-risk recovery command.	sudo tar -czf
Rebuild and verify	Recreates RPM database indexes from installed package headers, then checks DNF again.	sudo rpmdb --rebuilddb

Do not start by deleting rpmdb.sqlite, rpmdb.sqlite-wal, rpmdb.sqlite-shm, or old Berkeley DB __db.* files. Current Fedora releases use a SQLite RPM database, and old BDB cleanup advice can make a recoverable problem worse.

Confirm the RPM Database Failure on Fedora

Start with read-only checks. These commands do not change packages or repository configuration, and they separate RPM database problems from ordinary DNF cache or repository errors:

rpm -qa >/dev/null
rpmdb --verifydb
dnf check

A healthy system usually returns quietly for these checks. If rpm -qa or rpmdb --verifydb reports an RPM database error, continue with the backup and rebuild workflow. If RPM checks pass but DNF reports repository metadata, mirror, checksum, or repodata problems, clear DNF metadata first instead of rebuilding the RPM database.

The important boundary is whether RPM can still read the installed package database. A DNF solver error, an unavailable mirror, a failed repository refresh, or a changed file reported by rpm --verify can look serious, but those problems do not automatically mean the local rpmdb is corrupt.

Symptom	Likely layer	First action
rpmdb, Packages, rpmdb.sqlite, or database-open errors during RPM or DNF commands	RPM database	Back up the database, then rebuild it.
repodata, metalink, mirror, timeout, or repository checksum errors while RPM still queries packages	DNF repository metadata cache	Clean DNF metadata and regenerate the cache.
rpm --verify differences for files, permissions, or configuration	Installed package files or local configuration	Inspect the package or reinstall that package; do not assume the RPM database is broken.

Find Fedora’s RPM Database Path and Backend

Do not hard-code old recovery paths before checking the live RPM configuration. Fedora moved the RPM database from /var/lib/rpm to /usr/lib/sysimage/rpm starting with Fedora 36, while keeping /var/lib/rpm as a compatibility symlink.

printf 'dbpath: %s\n' "$(rpm -E '%{_dbpath}')"
printf 'backend: %s\n' "$(rpm -E '%{_db_backend}')"
readlink -f /var/lib/rpm

Fedora 44 output uses the SQLite backend and the relocated database path:

dbpath: /usr/lib/sysimage/rpm
backend: sqlite
/usr/lib/sysimage/rpm

The Fedora change proposal for relocating the RPM database to /usr documents the compatibility symlink and the expected SQLite files. The upstream RPM database recovery documentation also recommends checking %{_dbpath} and %{_db_backend} before choosing a recovery method.

This path check matters because many older commands assume /var/lib/rpm is the real directory. On current Fedora, that path normally resolves to /usr/lib/sysimage/rpm, so backups, lock checks, and file inspection should follow the path RPM reports instead of copying legacy recovery commands unchanged.

Clear DNF Metadata Before Rebuilding RPM

If the RPM database opens cleanly but DNF fails while loading repositories, clean the DNF metadata cache and make a fresh cache. This fixes stale or damaged repository metadata without rewriting the RPM database:

Close other DNF terminals and graphical software tools before running the cache commands. If DNF reports another active transaction, wait for that package operation to finish instead of forcing a cache cleanup through a busy package manager.

sudo dnf clean metadata
sudo dnf makecache --refresh
dnf check

The DNF5 clean command removes repository metadata or marks it expired, while makecache --refresh downloads current metadata for enabled repositories. If this path fixes DNF and dnf check stays quiet, the RPM database did not need a rebuild.

Use dnf clean all only when you deliberately want to remove all temporary repository data, including cached packages. For most repository-metadata failures, dnf clean metadata is the narrower first step.

Check Space Before RPM Database Work

A full root filesystem or unwritable temporary directory can break package-manager operations and can also make a rebuild fail halfway through. Check the filesystem that stores the rpmdb and the filesystem that will hold the backup before continuing:

dbpath=$(rpm -E '%{_dbpath}')
df -h "$dbpath" /var/tmp
findmnt -T "$dbpath" -no TARGET,FSTYPE,AVAIL,USE%
findmnt -T /var/tmp -no TARGET,FSTYPE,AVAIL,USE%

If the output shows little usable space, free space first and rerun the read-only RPM checks. Duplicate mount rows are normal when the rpmdb and /var/tmp live on the same filesystem, including Fedora Workstation’s default Btrfs root layout.

Stop Package Managers Before RPM Repair

Close graphical software managers and any terminal running dnf or rpm before backing up or rebuilding the database. Fedora Workstation can have PackageKit, GNOME Software, KDE Discover, or dnf5daemon-server in the background, but the useful question is whether a process currently holds the RPM database lock:

rpm_lock="$(rpm -E '%{_dbpath}')/.rpm.lock"
if locks=$(sudo lslocks -o PID,COMMAND,PATH); then
    printf '%s\n' "$locks" | grep -F "$rpm_lock" || echo "No process currently holds the RPM database lock"
else
    echo "Could not read the system lock table; stop before repairing the RPM database"
    false
fi

If the lock check prints a process, wait for the package operation to finish. If the command cannot read the lock table, fix sudo or run the recovery from a root shell before continuing.

A running desktop software service is not always a database writer. Use the lock result to decide whether to wait, and avoid killing package-manager processes or removing lock files. Interrupting a real transaction can leave more state to recover.

Back Up the Fedora RPM Database

Back up the RPM database before running a rebuild. If your account cannot run privileged commands yet, add a user to sudoers on Fedora or switch to a root shell before continuing.

If rpm -qa still works, save a package-name list before the rebuild. This gives you a simple count and comparison point after recovery:

rpm -qa --qf '%{NAME}\n' | sort > "$HOME/rpm-packages-before-rebuild.txt"
wc -l "$HOME/rpm-packages-before-rebuild.txt"

Now create a compressed backup from the actual RPM database path reported by RPM:

dbpath=$(rpm -E '%{_dbpath}')
backup="/var/tmp/rpmdb-$(date +%F-%H%M%S).tar.gz"
sudo tar -C "$(dirname "$dbpath")" -czf "$backup" "$(basename "$dbpath")"
sudo tar -tzf "$backup" | sed -n '1,6p'
printf 'RPM database backup: %s\n' "$backup"

On a current Fedora SQLite rpmdb, the backup listing includes the database directory and SQLite files:

rpm/
rpm/.rpm.lock
rpm/rpmdb.sqlite
rpm/rpmdb.sqlite-shm
rpm/rpmdb.sqlite-wal

Keep this archive until RPM queries, DNF checks, and the package-count comparison all pass. Do not delete the backup just because the rebuild command exits successfully.

If the package-list command fails because the database will not open, continue with the compressed database backup anyway. The package list is a helpful comparison point, but the database archive is the required safety copy.

Rebuild the RPM Database on Fedora

Run the lock check again if any package manager has opened since the backup. When no process holds the RPM database lock, rebuild it:

sudo rpmdb --rebuilddb

The rpmdb manual describes --rebuilddb as a database rebuild from installed package headers. That makes it the right tool when the RPM database itself is damaged, but it is not a repair command for every DNF solver error, missing file, or changed configuration file.

The rebuild does not reinstall Fedora, download packages, replace modified configuration files, or repair damaged storage. It recreates the RPM database structures RPM uses to answer package queries, ownership checks, dependency checks, and verification requests.

Verify Fedora Package State After Rebuild

After the rebuild, run the same local checks again before installing, removing, or upgrading packages:

rpmdb --verifydb
rpm -qa >/dev/null
dnf check
sudo dnf makecache --refresh

A clean rpmdb --verifydb, rpm -qa, and dnf check run returns without error. A successful DNF5 metadata refresh should also complete without an error and commonly ends with lines similar to these:

Repositories loaded.
Metadata cache created.

If you captured a package list before rebuilding, capture the list again and compare the counts:

rpm -qa --qf '%{NAME}\n' | sort > "$HOME/rpm-packages-after-rebuild.txt"
wc -l "$HOME/rpm-packages-before-rebuild.txt" "$HOME/rpm-packages-after-rebuild.txt"
diff -u "$HOME/rpm-packages-before-rebuild.txt" "$HOME/rpm-packages-after-rebuild.txt"

No diff output means both package-name lists match. If the after list is much shorter, stop and investigate before running DNF transactions, because unreadable package headers may have been discarded during the rebuild.

When the two lists differ, read the package names before acting. A small expected difference can happen only if another package operation changed the system between the two captures, which is another reason to keep package managers closed during this repair.

Fix Common RPM Database Recovery Outcomes

Rebuilding the RPM database is only one recovery step. The next command depends on what remains broken after the database opens again.

DNF Still Reports Local Package Problems

Run a focused DNF package-database check to look for dependency problems, duplicate packages, or obsoleted packages:

dnf check --dependencies --duplicates --obsoleted

The DNF5 check command reports problems in the local packagedb. If the issue is now a package conflict or dependency problem rather than a database-open failure, use the DNF5 install examples for Fedora to review solver-safe options such as search, reinstall, and transaction previews.

Package Files Changed but RPM Database Checks Pass

RPM verification differences usually mean package-owned files, permissions, or configuration changed on disk. Verify the specific package, then reinstall it only if you want Fedora’s packaged copy restored:

rpm --verify package-name
sudo dnf reinstall package-name

Be careful with broad rpm --verify -a output. Modified configuration files under /etc can be legitimate local changes, so treat verification output as evidence to inspect, not as automatic proof that the RPM database needs another rebuild.

The Rebuild Fails or the Package List Shrinks

If rpmdb --rebuilddb fails, if rpmdb --verifydb still fails afterward, or if the rebuilt package list is unexpectedly short, stop using DNF for normal package operations. Check disk space and recent storage or filesystem errors before trying another rebuild:

df -h /
sudo journalctl -p err -b --no-pager | sed -n '1,80p'

Do not delete rpmdb.sqlite, rpmdb.sqlite-shm, or rpmdb.sqlite-wal to force a fresh start. If the SQLite database cannot be recovered from installed headers, use the backup archive, storage diagnostics, and Fedora support channels before making destructive changes to the live database directory.

Restoring the backup is a last-resort recovery action, not a cleanup step. If you need to restore it, do it from a root shell or rescue environment after confirming no package manager is running, then rerun rpmdb --verifydb, rpm -qa, and dnf check before attempting package changes.

Old BDB Recovery Advice Mentions __db Files

Older RPM recovery articles often mention removing __db.* files. That advice belongs to the Berkeley DB backend, not a current Fedora SQLite rpmdb. Check rpm -E '%{_db_backend}' first, and do not apply BDB-specific recovery steps to a SQLite database.

The Failure Started During a Fedora Release Upgrade

If the RPM database error appeared after an interrupted release upgrade, check whether a DNF offline transaction is still queued or whether an upgrade log explains the failure:

sudo dnf offline status
sudo dnf system-upgrade log --number=-1

If no offline transaction or stored upgrade log exists, DNF reports that state instead of inventing a recovery target. Use the DNF5 system-upgrade commands for Fedora when the problem belongs to the staged offline transaction. Use the broader Fedora release upgrade guide when you need the full upgrade workflow, backups, and post-upgrade checks.

On Fedora Workstation, dnf offline status can also report an offline transaction initiated by the desktop updater. Resolve or clear that queued transaction with the correct DNF offline workflow before treating the RPM database as the only problem.

If the queued offline transaction is intentional and the RPM database checks now pass, reboot into it with sudo dnf offline reboot. If the status is stale and you have decided to discard the queued transaction, remove the stored offline transaction with sudo dnf offline clean; do not clean it just to hide a database-open error that still needs recovery.

Conclusion

The Fedora RPM database is back in a recoverable state when read-only RPM checks, the current-path backup, rpmdb --verifydb, rpm -qa, package-list comparison, and dnf check all pass. Keep the backup until the system survives a normal DNF metadata refresh, then handle remaining conflicts with focused package troubleshooting instead of another database rebuild.