On 11/22/06, Tony Nelson <tonynelson@xxxxxxxxxxxxxxxxx> wrote:
The RPM database should be verified more often than it is now. I've posted on this topic to the fedora-devel list.
Perhaps. Using --verifydb (or equivalently, running /usr/lib/rpm/rpmdb_verify, the preferred solution these days) does not do data checks, only structural checks on the database. (aside) rpm-4.0.2 used to do --verifydb on every close. I don't recall any problem that was meaningfully detected and solved by verifying more often. FWIW, the macros to verify a dabase on every close are likely still present and functional in current rpm. Note that running --verifydb can/will create locks, which is really the source of recent reported problems, and running --verifydb is likelier to create more, rather than fewer, problem reports imho. The data contained in Packages is signature/digest checked. A digest check is about the strongest data integrity check possible. The only other data in an rpmdb is join keys and index keys, and that data is regenerated whenever --rebuilddb is run.
With FC6 there has been a spate of RPM database corruption. It happened to me: though there may have been incipient corruption in my FC5, after --rebuilddb and upgrading successfully I found more corruption later. This brings up that the RPM database is just assumed to work, but isn't being checked until it falls over.
No there has not been a "spate of RPM database corruption". Yes there have been a number of reports of stale locks and cache (not database) incoherency. And there are a few other segfaults being reported against rpm. But feel free to describe rpm problems however you wish.
I propose that the RPM database should be verified on a regular basis. I have written a utility, rpm_verify_db, to automatically verify and repair the RPM database, via a daily cron job. Reports of errors are syslog'd, emailed to root, and shown by logwatch. It could be incorporated into the RPM package, or even Yum. It can be found at <http://georgeanelson.com/rpm-verifydb.htm>.
rpm used to do --verifydb, stopped because no problems were prevented or solved by verifying.
I propose that Anaconda should check the RPM database before starting an upgrade to an existing installation. Checking takes under a minute on my system, so it should not be objectionable. Anaconda should offer to repair a damaged RPM database (if the Package file is OK) before proceeding with the installation.
Anaconda used to do a --rebuilddb, stopped because no problems were being usefully solved.
I suggest that the --verifydb command should not be undocumented in RPM and its manpage. This seems to be on purpose, but I think it is a mistake.
The option is undocumented because using /usr/lib/rpm/rpmdb_verify (which is exactly the same operation) is the preferred means of database repair. rpmdb_verify is exactly the Sleepycat distributed utility linked against rpm rather than system libraries, and is quite well documented at sleepycat.com.
I would like some feedback about these proposals. If they are acceptable I will file RFE bugs on them. My knowlege of things RPM is superficial. It would be a good idea to have my proposed verification and repair methods criticised by authentic RPM developers.
None of the above should be considered criticism, just history. There are two needs if one wants to protect against rpmdb data loss. The most important is saving a copy of /var/lib/rpm/Packages routinely. All other information in an rpmdb can be regenerated from a reasonably recent copy of Packages. And in most cases a depsolver like yum/smart/apt/poldek will reinstall the packages that have changed since the last copy of Packages was saved. The other important need is to have a find-like utility to reconstruct an rpmdb using only md5 digests of installed files for those people who are not saving a copy of Packages ;-) 73 de Jeff _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
