The RPM database should be verified more often than it is now.
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.
I propose that there should be a nightly cron task to check the RPM database with --verifydb, which would also attempt automatic repair (if the Packages file is OK). I am developing and testing a shell script to do this. Currently it seems to work when run manually; we'll see what happens tonight. It logs its actions in syslog via logger. I expect that logwatch will inform root by email.
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.
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.
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 the proposed verification and repair methods criticised by authentic RPM developers, but I'm not sure where they hang out -- the Redhat Rpm-list appears to be for RPM users.
At 9:50 PM -0500 11/19/06, Sam Varshavchik wrote:
Tony Nelson writes:
I propose that there should be a nightly cron task to check the RPM
I proposed this several years ago, and got poo-poohed.
Well, did you offer to write it for them? :)
I now just have a cron.daily script that just makes a copy of /var/lib/rpm on a five day rotation.
I'm putting something of that sort into the script, saving the last 2 good ones. (Not like logrotate, which rotates the logs weekly whether they need it or not, so a month or so later all the data is lost.)
Tony Nelson writes:
At 9:50 PM -0500 11/19/06, Sam Varshavchik wrote:
Tony Nelson writes:
I propose that there should be a nightly cron task to check the RPM
I proposed this several years ago, and got poo-poohed.
Well, did you offer to write it for them? :)
No, but if they need my help to write a ten-line long shell script, I think the whole project is a lost cause.
At 9:50 PM -0500 11/19/06, Sam Varshavchik wrote:
Content-Type: multipart/signed; boundary="=_mimegpg-commodore.email-scan.com-5984-1163991009-0001"; micalg=pgp-sha1; protocol="application/pgp-signature"
Tony Nelson writes:
I propose that there should be a nightly cron task to check the RPM
I proposed this several years ago, and got poo-poohed.
OK, now I've been pooh-poohed as well.
I now just have a cron.daily script that just makes a copy of /var/lib/rpm on a five day rotation.
You might take a look at my rpm_verifydb package at http://georgeanelson.com/rpm-verifydb.htm, as it only saves the RPM database if it passes "rpm --verifydb".
At 9:42 PM -0500 11/19/06, Tony Nelson wrote:
The RPM database should be verified more often than it is now.
...
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.
I will be away for a few days, starting tomorrow, US Thanksgiving holiday. When I return I buzilla an RFE for it.
-
Sam Varshavchik -
Tony Nelson