> Dumb question, but have I lost anything that can't be replaced? It
> doesn't appear to be from your procedure. I truly don't know how this
> could have happen, and that scares me more than anything.
Hey Mario, that's a very relevant and understandable concern... not a
dumb question. The short answer is, you should not have lost anything
that can't be replaced from an RPM database perspective.
You can think of the information you deleted in /var/lib/rpm/__db.* as
a faster way to access the data which is also stored in
/var/lib/rpm/Packages. Your __db files became corrupt, so you removed
them and repopulated the information with a pristine copy of the
information in Packages. Normally a rebuilddb works to write the
Packages information to your existing rpm database, but because your
existing database was really trashed, rebuilddb would not proceed
until the problematic old database was gone.
It's hard to know what was going on on your system at the time of
corruption, but it's possible that the process was cancelled in such a
way that it did not recover properly or that you tickled a lurking bug
in RPM, kernel, filesystem, or possibly even one of the packages. RPM
was engineered to be recoverable from this kind of thing when it does
happen.
One thing that might have been lost are packages that were in the
process of being installed... they might have had their installation
scripts cut short or some other problem during installation. rpm -Va
will verify all installed packages, and unless you have been doing
naughty things with rpm (like forces), it should be fairly clean
except for modified configuration files or maybe some permission
changes for logs and that kind of thing. It is where you will discover
if something major is out of sync... like rpm thinking a package is
installed that really isn't.
~ Daniel
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 15:03:17 EDT