Although everything is done to ensure that your RPM databases are intact, your RPM database may become corrupt and unuseable. This happens mainly if the filesystem on which the rpm db
resides is suddenly inaccessible (full, read-only, reboot, or so on).
This recipe will show you the two ways in which you can attempt to restore your RPM database.
We'll start with the easiest option and the one with the highest success rate in these steps:
rpm db
, as follows:~]# cd; tar zcvf rpm-db.tar.gz /var/lib/rpm/*
~]# rm -f /var/lib/rpm/__db*
Packages
database via the following:~]# /usr/lib/rpm/rpmdb_verify /var/lib/rpm/Packages; echo $?
If the previous step prints 0
, proceed to Step 7.
Packages
file (don't delete it, we'll need it!), as follows:~]# mv /var/lib/rpm/Packages /var/lib/rpm/Packages.org
Packages db
from the original Packages db
by executing the following command:~]# cd /usr/lib/rpm/rpmdb_dump Packages.org | /usr/lib/rpm/rpmdb_load Packages
Packages
database. Run the following:~]# /usr/lib/rpm/rpmdb_verify /var/lib/rpm/Packages; echo $?
If the exit code is not 0
, you will need to restore the database from backup.
rpm
indexes, as follows:~]# rpm -vv --rebuilddb
rpm db
with yum for any other issues (this may take a long time):~]# yum check
rpm
database through the following command:~]# restorecon -R -v /var/lib/rpm
If, for some reason, you are unable to recover your RPM database, there is one final option left. Enterprises tend to have standardized builds, and many servers are installed with the same packages, so copy the healthy /var/lib/rpm
directory from another server with the exact same package set to the corrupted one, and perform the preceding recipe's steps to ensure that everything is okay.
Although you'll find additional tools that can save your skin (such as RPM cron), it's usually more practical to have a decent backup.