How to Rebuild a Corrupt RPM Database on RHEL and AlmaLinux

Updated: 18 October 2026 · Applies to: RPM 4.16.1.3 (AlmaLinux 9.8) and 4.19.1.1 (AlmaLinux 10.2) with the SQLite database, RPM 4.14.3 (AlmaLinux 8.10) with Berkeley DB; the same steps apply to Rocky Linux and RHEL

To rebuild the RPM database, back up its folder, then run rpmdb --rebuilddb as root (rpm --rebuilddb does the same) and compare rpm -qa | wc -l before and after. Check that count every time: in our tests, a rebuild of a damaged database kept only the packages it could still read and reported success anyway.

Where the RPM database is

• Version 9: /var/lib/rpm/rpmdb.sqlite, with rpmdb.sqlite-shm and rpmdb.sqlite-wal next to it.
• Version 10: /usr/lib/sysimage/rpm/rpmdb.sqlite; /var/lib/rpm is a link to that folder.
• Version 8 and older (CentOS 7): Berkeley DB files in /var/lib/rpm (Packages, Name, Basenames and others), plus __db.001 to __db.003 after rpm has run.

rpm -E %_dbpath prints the folder and rpm -E %_db_backend the type (sqlite on 9 and 10, bdb on 8).

Typical errors

• error: SELECT hnum, blob FROM 'Packages': 11: database disk image is malformed: the database file is damaged, for example after a full disk or a crash during an update. We saw this from rpm -qa and dnf check.
• error: can't create transaction lock on /usr/lib/sysimage/rpm/.rpm.lock (Resource temporarily unavailable): another rpm or dnf process is running. Wait for it; do not rebuild.
• error: cannot open Packages database in /var/lib/rpm and similar: see how to fix rpmdb open failed and cannot open Packages database errors.

If dnf fails but rpm -qa works normally, the RPM database is fine and the problem is dnf's own cache: run dnf clean all (see what yum clean all does).

Rebuild the RPM database

1. Make sure no package tool is running: pgrep -a 'rpm|dnf|yum|packagekit'. Stop PackageKit with systemctl stop packagekit if it is listed.
2. Check free space with df -h /var /usr. Free some space first if a file system is full.
3. Note the current package count:

   rpm -qa | wc -l

4. Back up the whole folder, so you can go back if the rebuild makes things worse:

   cp -a "$(rpm -E %_dbpath)" /root/rpmdb-backup-$(date +%F)

5. Check the database. No output means no problem was found:

   rpmdb --verifydb

   On our damaged lab copy it printed error: verify: *** in database main *** followed by lines such as Tree 2 page 404 cell 0: invalid page number 3398009620, and exited with code 2.
6. Version 8 and older only: remove the Berkeley DB environment files first. They are recreated automatically:

   rm -f /var/lib/rpm/__db.*

7. Rebuild:

   rpmdb --rebuilddb

   It prints nothing when it works.
8. Check the result:

   rpm -qa | wc -l
   rpmdb --verifydb
   dnf check

   The count should match step 3, and dnf check should report no problems.

If packages are missing after the rebuild

A rebuild cannot bring back records from a damaged file. In our AlmaLinux 10.2 lab, we overwrote part of the database in a throwaway test container: rpm -qa then listed 11 of 142 packages, rpmdb --rebuilddb printed the "malformed" error but exited with 0, and the new database passed --verifydb with only those 11 packages. AlmaLinux 9.8 behaved the same way (11 of 159). Trying the sqlite3 .recover command on the damaged file did not get more packages back either.

The installed files are still on disk; only the records are gone. The fix is to put back a database from before the damage, for example from your system backup:

D=$(rpm -E %_dbpath)
mv "$D" "$D.broken"
cp -a /path/to/good/rpm-folder "$D"
rpm -qa | wc -l

In our test this brought back every package, and dnf check was clean afterwards. Moving the damaged folder aside, instead of copying over it, keeps its old -wal and -shm files out of the restored database.

Without a backup, the missing packages must be registered again by reinstalling them, which needs care on a production server. If you prefer help, our engineers can do it through Hire an Expert.

Do not delete the database file

Never delete rpmdb.sqlite to "reset" it. In our test, rpm did not complain about a missing file: it created a new, empty database, and rpm -qa listed 0 packages.

Prevent it next time

• Do not stop dnf or rpm in the middle of a transaction, and keep free space on /var and /usr. An interrupted update is covered in how to recover an interrupted dnf or apt transaction.
• Keep a package list with your backups: rpm -qa | sort > /root/package-list.txt. It tells you exactly what to reinstall if the database is ever lost.

Official documentation: RPM documentation and rpmdb manual page.