Bug 61373 - It's difficult to reinstall a corrupted package.
It's difficult to reinstall a corrupted package.
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
: FutureFeature
: 61372 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-18 13:46 EST by Max TenEyck Woodbury
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-19 13:51:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Max TenEyck Woodbury 2002-03-18 13:46:10 EST
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 
it 
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 
options. 
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):


How reproducible:
Always

Steps to Reproduce:
1.rm -fR /
2.^C (quickly!)
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

Additional info:

This would be useful wien a machine has had a security compromise.
Comment 1 Jeff Johnson 2002-03-18 15:41:28 EST
*** Bug 61372 has been marked as a duplicate of this bug. ***
Comment 2 Jeff Johnson 2002-03-19 10:39:51 EST
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.
Comment 3 Max TenEyck Woodbury 2002-03-19 13:51:06 EST
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.
Comment 4 Jeff Johnson 2002-03-19 14:32:19 EST
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
per se.

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 
  --queryformat '%{name}-%{version}-%{release}.%{arch}.rpm\n'
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"
corruption.

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
your database. 

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.
	
Comment 5 Max TenEyck Woodbury 2002-03-19 17:21:35 EST
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 
installation CD.

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?
Comment 6 Max TenEyck Woodbury 2002-03-19 17:33:52 EST
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.
Comment 7 Jeff Johnson 2002-03-19 17:36:31 EST
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.
Comment 8 Jeff Johnson 2002-03-19 17:39:20 EST
(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.
Comment 9 Max TenEyck Woodbury 2002-03-20 20:53:21 EST
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.

Thanks.

Note You need to log in before you can comment on or make changes to this bug.