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.
*** 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 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.
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?
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. Thanks.