My former primary boot disk had some bad spots appear awhile back. Damage, per rpm --verify, seems to be predominately in loss of reference files in /usr/share/doc and such as that.
Being the type that wastes my own time before wasting that of others, I did a semi-careful perusal of the rpm man pages. Thought the --files or some such might offer a way ought. IIUC, nope! Seems that I can't select specific files. It looks like I could do a new install in a new root (chrooted) and then copy the files out, but I was already aware of an apparently easier way I had used years ago, rpm2cpio (easier because I can use the verify output list, slightly edited and reduced, to select the desired files.
Thought "Well, it probably can do what I want, I just missed it. Maybe tutorials, HOWTOs, etc. will give the answer". So, using the TOC of each of these, I probed in vain (in that vein, it was fruitless but not painless :-).
http://fedora.redhat.com/docs/drafts/rpm-guide-en/ http://www.rpm.org/max-rpm-snapshot/ http://www.redhat.com/magazine/001nov04/features/betterliving/ http://www.redhat.com/magazine/002dec04/features/betterliving-part2/
I've settled on rpm2cpio unless someone can point me in a better direction.
TIA
On 7/11/06, William L. Maltby BillsCentOS@triad.rr.com wrote:
My former primary boot disk had some bad spots appear awhile back. Damage, per rpm --verify, seems to be predominately in loss of reference files in /usr/share/doc and such as that.
Being the type that wastes my own time before wasting that of others, I did a semi-careful perusal of the rpm man pages. Thought the --files or some such might offer a way ought. IIUC, nope! Seems that I can't select specific files. It looks like I could do a new install in a new root (chrooted) and then copy the files out, but I was already aware of an apparently easier way I had used years ago, rpm2cpio (easier because I can use the verify output list, slightly edited and reduced, to select the desired files.
Thought "Well, it probably can do what I want, I just missed it. Maybe tutorials, HOWTOs, etc. will give the answer". So, using the TOC of each of these, I probed in vain (in that vein, it was fruitless but not painless :-).
Depending on the corruption you've got, rpm -Fvh might be what you want. Freshen may solve some of your dilemma.
On Tue, 2006-07-11 at 13:41 -0400, Jim Perrin wrote:
On 7/11/06, William L. Maltby BillsCentOS@triad.rr.com wrote:
My former primary boot disk had some bad spots appear awhile back. Damage, per rpm --verify, seems to be predominately in loss of reference files in /usr/share/doc and such as that.
<snip>
Depending on the corruption you've got, rpm -Fvh might be what you want. Freshen may solve some of your dilemma.
I'll give it a short-shot. It didn't occur to me that RPM *might* go check file(s), not just the DB, to see if a "frshen" was needed.
I will say I'm not hopeful, but I appreciate the time and suggestion regardless of outcome. I've just got the list of all available RPMs and just started selecting those I need. So I haven't lost a lot of time either way.
Thanks again!
On Tue, 2006-07-11 at 13:54 -0400, William L. Maltby wrote:
On Tue, 2006-07-11 at 13:41 -0400, Jim Perrin wrote:
On 7/11/06, William L. Maltby BillsCentOS@triad.rr.com wrote:
My former primary boot disk had some bad spots appear awhile back. Damage, per rpm --verify, seems to be predominately in loss of reference files in /usr/share/doc and such as that.
<snip>
Depending on the corruption you've got, rpm -Fvh might be what you want. Freshen may solve some of your dilemma.
I'll give it a short-shot. It didn't occur to me that RPM *might* go check file(s), not just the DB, to see if a "frshen" was needed.
I will say I'm not hopeful, but I appreciate the time and suggestion regardless of outcome. I've just got the list of all available RPMs and just started selecting those I need. So I haven't lost a lot of time either way.
Just an FYI (and a "just in case I overlooked something"), it *seems* to be "No Joy in Mudville". Ran it twice on redhat logos that is missing a directory and a file. Silence ensued and results didn't! :-O
So I did it again with a "--verbose" figuring that you folks who have lived with it awhile might spot something I borked. Then, did an rpm2cpio to confirm the two components were indeed carried in the rpm file. They are.
Here's the verbosdity in case there is some value in it. I expect not and thanks again.
====================================================================== # rpm -Fvh --verbose ${URL}redhat-logos-1.1.26-1.centos4.1.noarch.rpm Retrieving http://centosg.centos.org/centos-4/4.3/os/i386/CentOS/RPMS/redhat- logos-1.1.26-1.centos4.1.noarch.rpm D: ... as /var/tmp/rpm-xfer.vHkhDB D: ============== /var/tmp/rpm-xfer.vHkhDB D: Expected size: 7985002 = lead(96)+sigs(344)+pad(0)+data(7984562) D: Actual size: 7985002 D: opening db environment /var/lib/rpm/Packages joinenv D: opening db index /var/lib/rpm/Packages rdonly mode=0x0 D: locked db index /var/lib/rpm/Packages D: opening db index /var/lib/rpm/Pubkeys rdonly mode=0x0 D: read h# 1397 Header sanity check: OK D: ========== DSA pubkey id a53d0bab443e1821 D: /var/tmp/rpm-xfer.vHkhDB: V3 DSA signature: OK, key ID 443e1821 D: opening db index /var/lib/rpm/Name rdonly mode=0x0 D: read h# 2056 Header V3 DSA signature: OK, key ID 443e1821 D: found 0 source and 0 binary packages D: closed db index /var/lib/rpm/Pubkeys D: closed db index /var/lib/rpm/Name D: closed db index /var/lib/rpm/Packages D: closed db environment /var/lib/rpm/Packages ================================================================================
<snip>
On 7/11/06, William L. Maltby BillsCentOS@triad.rr.com wrote:
On Tue, 2006-07-11 at 13:54 -0400, William L. Maltby wrote:
On Tue, 2006-07-11 at 13:41 -0400, Jim Perrin wrote:
On 7/11/06, William L. Maltby BillsCentOS@triad.rr.com wrote:
My former primary boot disk had some bad spots appear awhile back. Damage, per rpm --verify, seems to be predominately in loss of reference files in /usr/share/doc and such as that.
<snip>
Depending on the corruption you've got, rpm -Fvh might be what you want. Freshen may solve some of your dilemma.
rpm also has a --replacefiles
On Tue, 2006-07-11 at 15:29 -0400, Jim Perrin wrote:
On 7/11/06, William L. Maltby BillsCentOS@triad.rr.com wrote:
On Tue, 2006-07-11 at 13:54 -0400, William L. Maltby wrote:
On Tue, 2006-07-11 at 13:41 -0400, Jim Perrin wrote:
On 7/11/06, William L. Maltby BillsCentOS@triad.rr.com wrote:
My former primary boot disk had some bad spots appear awhile back. Damage, per rpm --verify, seems to be predominately in loss of reference files in /usr/share/doc and such as that.
<snip>
Depending on the corruption you've got, rpm -Fvh might be what you want. Freshen may solve some of your dilemma.
rpm also has a --replacefiles
Gave it a shot, seems to be NG. Here's my actions and results.
# rpm --install --verbose --replacefiles \ redhat-logos-1.1.26-1.centos4.1.noarch.rpm Preparing packages for installation... package redhat-logos-1.1.26-1.centos4.1 is already installed # Did an ls and files not in /usr/share/doc/redhat* # rpm -Fvh --replacefiles redhat-logos-1.1.26-1.centos4.1.noarch.rpm # ls -l /usr/share/doc/redhat-logos* ls: /usr/share/doc/redhat-logos*: No such file or directory # rpm -Uvh --replacefiles redhat-logos-1.1.26-1.centos4.1.noarch.rpm Preparing... ########################################### [100%] package redhat-logos-1.1.26-1.centos4.1 is already installed
I'm doing a small script for the rpm2cpio, so keep those ideas coming! Only a few minutes to test the ideas and it might save me some effort (just selecting the rpm files and adding to the script iinput ATM).
On Tue, 2006-07-11 at 16:15 -0400, William L. Maltby wrote:
<snip>
Since Jim went out of his way helping to hunt for a good solution, I thought I would summarize here for folks that might have a similar need down the road. Experienced rpmers/bashers/perlers/pythoners/.... should probably skip this.
Thanks Jim Perrin!
Situation was that rpm --verify showed lots of missing files. Most due to a bad spot that developed on my former boot drive. After a little thought, I suspect some had been removed by me because they were internationalization files (*/locale/* and */i18n/*) and it is the sort of thing I would do... sometimes and forget to log! :-(
Anyway, none of the rpm params we tried seemed to "recover" missing files, whether we tried --install ("... package already installed ...") --update or --freshen (both just did nothing since I was up-to-date). The --replacefiles also did not help.
While this was going on, I was scripting (Q & D for sure) to utilize the rpm2cpio utility. We could easily expand the rudimentary Q&D crap I started here into a fairly automated assistant, if so desired. I suspect that it might be better done in something other than bash though.
I had a basic file which was an annotated list of missing files (and other errors) from my "rpm --verify ..." run. It looked similar to this.
missing d /usr/share/doc/redhat-logos-1.1.26/COPYING
############################################################# # Owned by Apache Runtime Development # missing /usr/share/doc/apr-devel-0.9.4 missing d /usr/share/doc/apr-devel-0.9.4/APRDesign.html
Ownership was determined manually by running an rpm query using selected files, thusly.
# rpm --query --file /var/spool/mqueue sendmail-8.13.1-3.RHEL4.5.i386 #
The results were (eventually) saved in a list of all the needed rpm files.
To help determine that I didn't miss any rpm packages, I would also run something similar to this.
# rpm --query sendmail --filesbypkg sendmail /etc/aliases.db sendmail /etc/mail sendmail /etc/mail/Makefile sendmail /etc/mail/access
So that I could visually make sure I knew where the next package missing file was in my original list of missing files.
Once I had the complete list of needed rpm files, a simple script did a wget of the files from a CentOS (and Extras) mirror. The rpms were converted to cpio files using the utility "rpm2cpio".
I wrote another slightly less simple script that operated over that list, running cpio extract, and prompted me for glob patterns to select files to be re-installed for each package. I could manually enter up to 25 match patterns (TG only glibc-common used them all) so that I could re-install a set of files almost no larger than needed. Since I did not provide the "u" flag to cpio, it would not replace files that had a later/equal time stamp, thereby freeing me from worry about locally modified configuration files. This allowed a more liberal glob pattern, in many cases, saving some typing.
A short note about the pattern matching: most of the converted cpio files had relative paths that began "./", while a *few* had just the relative path name (e.g. "usr/share", no leading "./"). This caused some delay as multiple extract runs had to be made after investigating failures. Fortunately, I was logging to files so even vary large extracts did not scroll off-screen and vanish into the ether.
I'd be glad to annotate and provide my shells if anyone wants them. Keep in mind they are Q&D status only and no shame or pride is associated with them.
A recent rpm --verify shows just the normal stuff now, so success was had (hmm... as long as it took, *I* was had ;-)
HTH someone down the road.
On Wed, 12 Jul 2006, William L. Maltby wrote:
On Tue, 2006-07-11 at 16:15 -0400, William L. Maltby wrote:
<snip>
Since Jim went out of his way helping to hunt for a good solution, I thought I would summarize here for folks that might have a similar need down the road. Experienced rpmers/bashers/perlers/pythoners/.... should probably skip this.
Thanks Jim Perrin!
Situation was that rpm --verify showed lots of missing files. Most due to a bad spot that developed on my former boot drive. After a little thought, I suspect some had been removed by me because they were internationalization files (*/locale/* and */i18n/*) and it is the sort of thing I would do... sometimes and forget to log! :-(
Anyway, none of the rpm params we tried seemed to "recover" missing files, whether we tried --install ("... package already installed ...") --update or --freshen (both just did nothing since I was up-to-date). The --replacefiles also did not help.
While this was going on, I was scripting (Q & D for sure) to utilize the rpm2cpio utility. We could easily expand the rudimentary Q&D crap I started here into a fairly automated assistant, if so desired. I suspect that it might be better done in something other than bash though.
I had a basic file which was an annotated list of missing files (and other errors) from my "rpm --verify ..." run. It looked similar to this.
missing d /usr/share/doc/redhat-logos-1.1.26/COPYING
############################################################# # Owned by Apache Runtime Development # missing /usr/share/doc/apr-devel-0.9.4 missing d /usr/share/doc/apr-devel-0.9.4/APRDesign.html
Ownership was determined manually by running an rpm query using selected files, thusly.
# rpm --query --file /var/spool/mqueue sendmail-8.13.1-3.RHEL4.5.i386 #
The results were (eventually) saved in a list of all the needed rpm files.
To help determine that I didn't miss any rpm packages, I would also run something similar to this.
# rpm --query sendmail --filesbypkg sendmail /etc/aliases.db sendmail /etc/mail sendmail /etc/mail/Makefile sendmail /etc/mail/access
So that I could visually make sure I knew where the next package missing file was in my original list of missing files.
Once I had the complete list of needed rpm files, a simple script did a wget of the files from a CentOS (and Extras) mirror. The rpms were converted to cpio files using the utility "rpm2cpio".
I wrote another slightly less simple script that operated over that list, running cpio extract, and prompted me for glob patterns to select files to be re-installed for each package. I could manually enter up to 25 match patterns (TG only glibc-common used them all) so that I could re-install a set of files almost no larger than needed. Since I did not provide the "u" flag to cpio, it would not replace files that had a later/equal time stamp, thereby freeing me from worry about locally modified configuration files. This allowed a more liberal glob pattern, in many cases, saving some typing.
A short note about the pattern matching: most of the converted cpio files had relative paths that began "./", while a *few* had just the relative path name (e.g. "usr/share", no leading "./"). This caused some delay as multiple extract runs had to be made after investigating failures. Fortunately, I was logging to files so even vary large extracts did not scroll off-screen and vanish into the ether.
I'd be glad to annotate and provide my shells if anyone wants them. Keep in mind they are Q&D status only and no shame or pride is associated with them.
A recent rpm --verify shows just the normal stuff now, so success was had (hmm... as long as it took, *I* was had ;-)
HTH someone down the road.
If you have a list of packages that were installed, you can provide that to apt-get with the --reinstall option.
apt-get install --reinstall <list of packages>
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Did you try rpm --replacepkgs --oldpackage?
Cheers,
MaZe.
On Thu, 2006-07-13 at 03:42 +0200, maze@cela.pl wrote:
Did you try rpm --replacepkgs --oldpackage?
No. Frankly, even though I read the man page again before starting the trek, I missed it entirely. However, even had I spotted it, it *might* have scared me off because ...
--oldpackage Allow an upgrade to replace a newer package with an older one.
This would have nailed me if I didn't get the right package. I did manage to pull one older version by mistake (by habitually pulling from base repository and not noticing that the package was a older one than what I had, from Extras repository). Fortunately, cpio "Did the Right Thing" (TM) and saved my butt because I had avoided the (u)nconditional flag. It forced me to investigate and correct without waiting for another "rpm --verify" to spot my error.
But in the future, I will give it a try.
Cheers,
MaZe.
<snip sig stuff>
Thanks.
On Thu, 2006-07-13 at 03:28 +0200, Dag Wieers wrote:
On Wed, 12 Jul 2006, William L. Maltby wrote:
On Tue, 2006-07-11 at 16:15 -0400, William L. Maltby wrote:
<snip>
Since Jim went out of his way helping to hunt for a good solution, I thought I would summarize here for folks that might have a similar need down the road. Experienced rpmers/bashers/perlers/pythoners/.... should probably skip this.
Thanks Jim Perrin!
Situation was that rpm --verify showed lots of missing files. <snip>
A recent rpm --verify shows just the normal stuff now, so success was had (hmm... as long as it took, *I* was had ;-)
HTH someone down the road.
If you have a list of packages that were installed, you can provide that to apt-get with the --reinstall option.
apt-get install --reinstall <list of packages>
Unfortunately for me, I have never installed that on my system. Don't even have the man page. And to keep peace on the list, I won't ask if you prefer it, if it's better, why doesn't CentOS... :-). I know how these things go and will just support the *reasonable* choices of the folks that choose things.
However, if I find myself in this situation in the future and have discarded my scripts by then (likely), your suggestion will still be in my mind.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
<snip the non-entertaining sig stuff>
Thanks Dag.
-
Dag Wieers -
Jim Perrin -
maze＠cela.pl -
William L. Maltby