As mentioned in Chapter 3, the RPM database is stored in /var/lib/rpm. The files in that directory are Berkeley DB files, as shown by the file command:
# file /var/lib/rpm/*
/var/lib/rpm/Basenames: Berkeley DB (Hash, version 7, native byte-order)
/var/lib/rpm/Conflictname: Berkeley DB (Hash, version 7, native byte-order)
/var/lib/rpm/__db.001: data
/var/lib/rpm/__db.002: X11 SNF font data, LSB first
/var/lib/rpm/__db.003: X11 SNF font data, LSB first
/var/lib/rpm/Dirnames: Berkeley DB (Btree, version 8, native byte-order)
/var/lib/rpm/Filemd5s: Berkeley DB (Btree, version 8, native byte-order)
/var/lib/rpm/Group: Berkeley DB (Hash, version 7, native byte-order)
/var/lib/rpm/Installtid: Berkeley DB (Btree, version 8, native byte-order)
/var/lib/rpm/Name: Berkeley DB (Hash, version 7, native byte-order)
/var/lib/rpm/Packages: Berkeley DB (Hash, version 7, native byte-order)
/var/lib/rpm/Providename: Berkeley DB (Hash, version 7, native byte-order)
/var/lib/rpm/Provideversion: Berkeley DB (Btree, version 8, native byte-order)
/var/lib/rpm/Requirename: Berkeley DB (Hash, version 7, native byte-order)
/var/lib/rpm/Requireversion: Berkeley DB (Btree, version 8, native byte-order)
/var/lib/rpm/Sha1header: Berkeley DB (Btree, version 8, native byte-order)
/var/lib/rpm/Sigmd5: Berkeley DB (Btree, version 8, native byte-order)
/var/lib/rpm/Triggername: Berkeley DB (Hash, version 7, native byte-order)
Each file is a separate database in Berkeley DB format, except for a few __db data files. (These are not really X11 font files, just plain data files. The file command is confused by the data in the files.)
The Berkeley DB Library
Available from SleepyCat Software at www.sleepycat.com/, the Berkeley DB library provides a simple database API. This is not a traditional relational database. Instead, data values are stored in what amounts to a persistent hash table of name/value pairs. This type of database is very quick to look up a named entry (such as a package name) but is not so quick for iterating over all the entries.
One of the nice things about this library is that it is available in an open-source format, and you can get programming API libraries for C, C++, Java, Python, Perl, and Tcl languages.
The RPM database is really a number of Berkeley DB databases, each designed for a different type of query.
If something goes wrong with your RPM database, you can first try to rebuild it. If that fails, you may need to initialize a new database, although that is generally not needed. First and foremost, however, you should back up this database.
As mentioned before, the RPM database resides in the /var/lib/rpm. You can back up the RPM database by using commands such as the following:
# cd /var/lib
# tar cvf rpmdb.tar ./rpm
# gzip rpmdb.tar
These commands create a tar archive from the contents of the rpm directory (where the RPM database is stored) and compress the file with the gzip command.
Note
Adding the z option to the tar command can create a compressed archive directly, without the need for the gzip command.
If the RPM database has been corrupted in some way, you can use the --rebuilddb option to tell the rpm command to rebuild your database.
For example:
rpm --rebuilddb
This command rebuilds the RPM database from the installed packages, the file named Packages in the /var/lib/rpm directory. Only the Packages file is required. All the other files can be recreated from the Packages file. If your database is OK, this command won't do much, other than shrink the size of your RPM database by removing unused entries. This command will take some time to execute, though.
Warning
Before running this command, back up your RPM database.
To check that the rpm --rebuilddb command has not damaged the RPM database, you can check with a file listing, query all packages, and then check the results of the rpm –rebuilddb command with another file listing when done.
Another useful technique that can help with a corrupted RPM database is to use the db_dump and db_load utilities that come with RPM (from the SleepyCat DB database library). Use db_dump to dump the Packages file. Then, use db_load to reload the Packages file. The act of dumping and restoring may fix a corrupted file. As always, back up your RPM database prior to performing these commands.
If all else fails, use the --initdb option to tell the rpm command to create a new empty RPM database. In almost all cases, you do not want to create a new RPM database, since this database will be empty. It will not have any knowledge about the packages you have already installed on your system. That could lead to a lot of problems, since you have the files installed, but the RPM system just doesn’t know about them.
The basic syntax follows.
rpm --initdb
Note
This command should not damage an existing database.
If the RPM system cannot be rebuilt, you may have to reinstall the operating system to recreate a clean system. In general, if things are this far gone, reinstalling may be your best answer instead of wiping the RPM database and creating an empty database.
You can also use the --dbpath option to tell the rpm command to create an RPM database in a different directory.
For example:
mkdir /tmp/rpm
rpm --initdb --dbpath /tmp/rpm
These commands create a temporary directory and an RPM database in the /tmp/rpm directory.
After running this command, you can examine the files created.
# ls -l /tmp/rpm
total 288
-rw-r--r-- 1 root root 8192 Oct 10 20:29 __db.001
-rw-r--r-- 1 root root 1310720 Oct 10 20:29 __db.002
-rw-r--r-- 1 root root 360448 Oct 10 20:29 __db.003
-rw-r--r-- 1 root root 12288 Oct 10 20:29 Packages
This shows an empty RPM database.