How to safely verify rpm database

We have a package installation application where we need to verify the integrity of the RPM database first so that we don’t crash or bail out in the middle of installing a bunch of RPMs. I’m having trouble finding a way to safely (i.e. without crashing or modifying the database making it worse) and reliably do this. A page on the rpm.org wiki says to use rpmdb_verify, but this does not exist on our OpenSuSE 12.1 distribution. Doing some tests, rpm -qa --dump seems oblivious to some corruptions, but on the other hand, so do -i and -e (I haven’t found a corruption yet that --dump misses that -i or -e catch, but I’d like to do a more thorough verify anyway – I am afraid that a cursory read-only operation like --dump will miss a read/write error). Am I stuck with rpm -qa --dump or is there a tool I haven’t discovered yet that will do this? What happened to rpmdb_verify and rpmdb_stat?

Thanks,
Eric

You’re wanting to verify the DB’s integrity? I assume this is because of
something special your software does, since you should not be trying to do
with with any old random application installation. If you want to do this
type of thing without modify the DB you could always copy it somewhere
else (a temporary directory) and then do whatever from that location,
though again this is all a bit abnormal for a regular package
installation. Is your package focused on data integrity or recovery? IF
so, installing via RPM seems like a bad idea. You could always create
your own RPM DB somewhere (one command) and then install into that so that
your software is installed but the main RPM database is not touched.

Without a business case for all of this it’s hard to come up with good
suggestions (above is probably not good… in fact, it may even be bad,
though functional based on wild speculation about your business case).
Provide more details for better answers, please.

Good luck.

I’m wanting to verify the DB’s integrity so that we fail gracefully at the beginning of an install instead of catastrophically in the middle with cryptic and frightening error messages if the RPM database is corrupt. We’ve already seen this in the field. The package is just installing normal system RPMs, they don’t pertain to data integrity or recovery per se. The business case is that the user gets a nice informative error message before the installation starts, rather than getting part way through what should be an atomic install and it dies with a scary message, leaving the system in a potentially inconsistent state. Dying in the middle of an install is about the worst thing that can happen.

I guess the bottom line is we want an atomic installation – it should either work, or not work, and not get halfway through and die for preventable reasons.

Does that make things a bit clearer?

The ‘db_verify’ command may be useful for this. It’s a good idea to make a copy of the database first, then check the integrity of that copy, (just in case some other concurrent process writes to the DB while checking as db_verify does not perform any locking AFAIU).

Repair an RPM database safely

For help with Zypper and including rpm database repair, have a look at my bash script here: Zypper Command - Zypper Package Management Menu System - Version 2.00 - Blogs - openSUSE Forums

Thank You,