David Timms wrote:
> Mikkel L. Ellertson wrote:
>> David Timms wrote:
> ...
>> You are probably better off backing up your good config and data
>> files, wiping the drive, and doing a fresh install. Treat the system
>> the same way you would a cracked system. With file corruption as bad
>> as you indicate, you are better off assuming that all files are
>> damaged until you check them. Running rpm -Va is not going to catch
>> everything. It can only check the files in the RPM database. Any
>> custom configuration files will fail the test. User files, and
>> generated files like menu's and passwords are not checked.
> Yeah, it's more of a OK, if this happened on my main machine - would /
> could it be recovered in a reasonable time ?/? I do expect to have to do
> a full format/reinstall.
>
I would hope you would have backups of your main machine, so you
could restore from them. In any case, I would expect a re-install to
take less time then tracking down and fixing all the corrupted
files. Depending on the speed of your Internet connection, and the
number of corrupted RPMs, the download time for the updated packages
may be an issue. If it is, you may want to consider creating a local
repo with the update for the machines on your network. (Backed up on
a regular bases, and cleaned of old RPMs that have been replaced by
newer updates.)
>
>> If you are are going to try and fix it instead of doing a new
>> install, you may want to try running something like: (NOT tested!)
>>
>> for i in $(rpm -qa) ; do
>> echo Trying to fix $i.
>> rpm -i --quiet --oldpackage $i >> /tmp/fix.log
>> done
>>
>> If you run this in the directory with all the RPMs in it, it will
>> attempt to re-install all the installed RPMs. But it will generate
>> an error if there is a newer package installed then is in the
>> directory,
> So if I change it to -Uvh, then I think it wont try to install a second
> parallel version, but rather change the version to the one in the folder.
> Also, where the package is already installed according to the rpmdb
> {broken} wouldn't --force {--oldpackage --replacefiles} be better ?
>
Yes, it should be -U, and not -u. But you are probably not going to
want to use the vh, because it makes spotting problems harder. With
the --quiet option, you will only get errors, and possibly notices
of the creating of .rpmsave and .rpmnew files.
Yes, using the --force option is probably better in this case. I
avoid it normally, but this is probably a case that it is designed
to handle. Otherwise, the --replacepkgs would probably be a better
choice then --oldpackage.
>> or if the package is not in the directory. It will
>> probably generate some .rpmnew and/or .rpmsave files where you have
>> change the config files.
> I can get the machine to do the work for me. I'll find them with
> updatedb folowed by locate *.rpmnew and locate *.rpmsave
>
> Thanks for your tips, I'll give that a try {I'll limit it {eg: rpm -qa
> a\*} to test}.
>
Let us know how it works out.
I am trying to remember the name of the program that will help you
sort out differences in config files. It does the equivalent of
using locate to fine the files, diff to find the differences, and an
editor to migrate the changes. I remember seeing it posted on the
list, but I can not find the name in my notes.
Mikkel
--
Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
