At 9:05 AM -0500 11/29/06, Jeff Johnson wrote: >On 11/28/06, Tony Nelson <tonynelson@xxxxxxxxxxxxxxxxx> wrote: >> True. It would be a good thing if RPM did such checks. >We disagree, at least on the frequency of checking and the amount of >automation. OK. >So create problem reports. The current problem reports have to do >with stale locks and __db cache corruption, not with Packages or --verifydb. RH BZ 215127. >> I hope rpm-verifydb will create more problem reports. Currently, problems >> in the RPM database can go unnoticed for a long time, until disaster >> strikes. >If a tree falls in the forest, who hears the noise? Only the end-user it falls on. >> I chose "rpm --verifydb" over some Berkely DB tool as I expect that rpm >> already does proper locking of its database during checks (modulo any >> kernel bugs). >> > >RPM with concurrent access uses exactly Berkely DB locks, there really >is no meaningful difference between --verifydb and rpmdb_verify. Nor did I claim that there was. "rpmdb_verify" is part of RPM, not part of Berkely DB. >The external executable is preferred to simplify rpm options (there are >far too many) and to provide better doco (of which there is far too little) >for verifying an rpmdb. There is no man page for rpmdb_verify in FC6. >>>>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". >> >> How do you know? 8-) After all, who's checking now? >> > >Ultimately, noone knows. > >Meanwhile, I have years of experience diagnosing and fixing rpmdb >problems. I am not seeing or hearing that headers were damaged in >databases (which is my definition of "corruption"). YMMV as always. I suggest that you supplement your years of experience with actual hard data, gathered by a daily cron task that checks the RPM database for corruption and reports that corruption to the user, and to someone at RH or Fedora -- "yum update" seems a reasonable reporting channel. (While there is much angst over counting Fedora installations, counting broken RPM databases is another matter. If you are correct, no reports will be sent.) >Then ask anaconda (or yum) to do run rpmdb_verify or --verifydb or >call the python method ts.verifyDB() as needed. That does seem like the course of action that is most likely to produce benefit. >When an rpmdb is verified is not solvable in rpmlib >(except by verifying on every close, been there, done that, dinna help). It is solvable in the RPM /package/, by installing a cron task much as my rpm_verifydb package does. >> Where is rpmdb_verify documented? "man rpmdb_verify" doesn't find >> anything. "apropos rpm" | grep 'verify'" doesn't find anything either. It >> doesn't seem to be in "man rpm". >Look for "db_verify" in the Berkely DB utilities doco, which is also included >in the db4 package last I checked. So "rpmdb_verify" is not documented anywhere? It should be documented in RPM's documentation, which could assert that it is the same as "db_verify" in the Beredely DB docs. >> RPM users would benefit from having that documented some place RPM (other >> than this list). "man rpm" is where they would expect to find it. >> > >"expect" is in the eye of the beholder. Exactly. RPM's users are RPM's customers. RPM should try to serve them well, and this includes putting the documentatin for RPM in RPM's own documentation. >> OK, though Packages is too large to save every day, and just keeping the >> last one would mean that the sysadmin would need to notice the problem >> before that last good copy of Packages was overwritten. (I have an RPM >> database instance that has corruption but functioned normally most of the >> time, though not during an Anacoda upgrade to FC6. See RH BZ 215127.) It >> would seem that it would be better to only save good copies of the Packages >> file, and to report to a responsible sysadmin that there is an issue (if >> only there were such a sysdamin for most systems). I don't know how to do >> that with "rpm --rebuilddb", but I do know how to do that with "rpm >> --verifydb". >> > >Too large is a different problem, try "man rdiff" if you want an easy >incremental >backup. I see rdiff is in extras. I see it uses rsync. Possibly I will add that capability to my rpm_verifydb package. >> /No one/ saves a copy of Packages, as such an implementation detail is >> RPM's responsibility, and it does not do it. Don't blame the users for >> omissions! > >We disagree. If you want to protect your data, you need to take precautions. It disapoints me that you think it is not RPM's responsibility to protect its database. >RPM cannot do reliable backups for all possible users under all cases. > >Meanwhile, there is nothing stopping you or anyone else from doing whatever >you wish to achieve reliability. I understand completely. -- ____________________________________________________________________ TonyN.:' The Great Writ <mailto:tonynelson@xxxxxxxxxxxxxxxxx> ' is no more. <http://www.georgeanelson.com/> _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
