Red Hat Bugzilla – Bug 61373
It's difficult to reinstall a corrupted package.
Last modified: 2008-05-01 11:38:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.6 [en] (WinNT; I)
Description of problem:
For any of a number of reasons, a package instilation may need to be redone. In particular, some files in a package may have been deleted or corrupted. (The
notorious 'rm -rR /' is a good example of this.) Assuming the RPM database has survived and you have
access to a package distribution, it
should be fairly easy to verify which files are missing or corrupt and reinstall them. The current implementation makes locating the missing/corrupted file possible, but
is NOT easy to do the update. Either add a 'fixit' option to 'verify' mode, or add a seperate 'fixit' mode. Interactive confirmation and batch mode would be useful
On the other hand, if this already exists, I couldn't find anything on the subject in the documentation.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.rm -fR /
3.rpm -Va (or whatever...)
Now what do you do?
Actual Results: You're SOL and probably out on the street looking for a new job.
Expected Results: 4.mount /mnt/cdrom
5./mnt/cdrom/.../rpm -Va --fixit -interactive
This would be useful wien a machine has had a security compromise.
*** Bug 61372 has been marked as a duplicate of this bug. ***
There's a whole class of problems, like "rm -rf /"
and hard disk failures that rpm cannot "fix".
However, 'twould be nice if rpm provided more automated
assistance. Almost any problem (ignoring configuration)
can be "fix"ed by reinstalling packages, and this is a
prime candidate for automated repair. The rate limiting
step is setting up servers that can deliver all possible,
not just the release snapshot, packages.
BTW, you might take a look at /var/log/rpmpkgs, where you
will find the list of packages installed on the machine.
In rpm-4.0.4, there is also support for a "package id"
(i.e. md5 digest of header+payload) that can/will be used
as a retrieval key for packages to be reinstalled in case
of disaster recovery. What remains, again, is the server
infrastructure necessary to fully automate disaster recovery.
Please explain "DEFERRED". (I understand you're not in a position to fix this
immediatly, is this now on the work list, and with what urgency?)
If you are using RPM to manage your installations, there effectively is no other
tool for repairing a corrupted installation, so RPM _has_ to be the tool used to
"fix" the problem.
At least document/explain how to cleanly reinstall a corrupted package.
A 'quick-and-dirty' fix would be a script to read /var/log/rpmpkgs and issue
the appropriate RPM commands. Similarly, an RPM -qa would probably produce a
more current list that omits removed packages.
I use DEFERRED as "Look at later, food for thought".
Reinstalling packages fixes most any corruption
problem. Whethere there's enough left of your
system to do so after "rm -rf /" is not an rpm problem
Here's how to "fix" the accidental remove
1) Run "rpm -Va | grep missing".
2) Run "rpm -qf <path> | sort | uniq" to
get a list of package names. Add
if you want package file names.
3) Go download the packages. This is the part that
rpm cannot automate ATM.
4) Install the packages with --force to "fix"
If you don't have /var/lib/rpm, then the 1st step is
to create the database. This can be done by using
/var/log/rpmpkgs, performing 3), and then using
--justdb before performing the procedure above.
FWIW, rpm -qa assumes you haven't nuked
Yes, I've written quick-n-dirty scripts, what's
missing is a general and robust solution for
disaster recovery, and the rate limiting step
is finding exactly (not an rpmfind approximation)
to the necessary packages. That will take servers
willing to index and deliver the entire (or
large subsets anyways) universe of possible rpm
packages, and that's beyond rpm's scope.
OK. There are limits to a solution of this type. The idea was to recover from
some level of disaster LIKE a partial 'rm -fR /', a script-kiddy break-in or
a virus infection. Access to the requesite source of packages is a red herring.
(i.e. #3 is not an acceptable excuse for not working on the problem. If you
got the packages once, you can usually get them again.) A reasonable
simplifying assumption is the use of a recovery diskette and access to an
Issue: What impact does the '--force' have on the RPM database. Does it end up
with a record of two installations in the database? If it does, how do you
clean up afterwards?
Issue: If the problem is a breakin, the MD5 checksums and other information in
the database may be unreliable. Is there a mode that verifies the database
against the package contents. (Document the fact that you need a reliable
source for the packages and an uncorrupted set of RPM and library images, but
don't let that requirement hold up solving the problem.)
Issue: A document in /usr/share/doc/rpm-... or some other reasonable place
on disaster prevention, anticipation, mitigation and recovery would be a help.
Issue: What does DEFFERED mean in this context?
Sorry, stated the last issue baddly. try:
Will this information get to the people who can make the required changes and
how will I know that the problem is being worked on?
And BTW, my looking at the package index problem was what started me thingking
about this problem in the first place. The problem I was working on was
letting a developer find a reasonably large sample of packages containing
the project under question. All the mirror sites complicates the problem.
Your comments points up an alternate use for such an index.
Hmmm, needing packages for disaster recovery
is a "red herring"??? I beg to differ.
-Uvh --force reinstalls a given package, there
is only one instance afterwards.
If you are mistrustful of the database, then
go fetch a pile of red herrings from a trusted
source, and use rpm -Vp on a per-package basis.
Yup, the doco for non-existent functionality in rpm
sucks. In fact, all the doco for rpm sucks.
DEFERRED is a resolution state for bugzilla. It
means nothing more than that.
(Sorry, clobbered your comments)
Yes I am the person who will be implementing
whatever in rpm. When I'm not reading bugzilla
bugs that is ...
I have no idea what your last comment means.
I think I have enough information now that I can file these responses where I
can find them when I need them. If I get the time I might even write up a set
of formal notes on this topic.
'Red herring' is a rather jaundiced view of customer support talking. I spent
eleven years doing telephone support myself and saw the kind of schlock that
powerless support people were encouraged to tell customers. There was a hint
of that kind of response in some of what you said. When faced with a similar
situation, I would write up the problem to make sure the developers were aware
of the customers concerns. That did NOT make my local manager happy, but was
appreciated by the customers and by the developers and QA people. Many of the
other people didn't take the time unless pushed by the customer. Since you're
actually the one with the power to fix the problem, I don't have to push hard
to get the message to the right place.
The last comment was background information. You mentioned that RPM was not
the place to solve the package indexing problem. I was agreeing and letting
you know that someone was working on that exact problem, abet from a slightly
different point of view.