Re: how to fix a nackered system by fixing every installed rpm ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



David Timms wrote:
> Hi, I am recovering a system that has a corrupted system drive after a
> disk death in a raid 5 array. Unfortunately the disk rebuild on a new
> disk (larger size) didn't go well. Some files are fine, others have dir
> entries, but are full of crap.
> 
> Booting linux rescue, I have fsck.ext3 the lvm root vol and it fixed the
> structure errors for more than one hour. It still didn't boot.
> 
> It looks like all the dir entries are there, and the contents of some
> files {eg text files in /etc/ and /root/} are OK, other file just have
> junk chars {blocks in midnite commander}.
> 
> When I tried to chroot /mnt/sysimage, It complained {I forget what} and
> didn't chroot.
> 
> I have another similar machine with same OS and updates, so {backed up
> the corrupt rpmdb and} copied the rpmdb from the other machine. I copied
> all the rpms from the install dvd into some available space {separate
> logical volume}.
> 
> I tried to --rebuild the rpmdb, but no success {probs with DB3}. rpm -V
> shows thousands of md5 bad files. I am able to eg:
> # rpm -Uvh --root=/mnt/sysimage rpm --force
> So I have over-installed various bits that are missing, and managed to
> get db4, rpm, and yum to be able to run.
> 
> I yum install gtk2 and it says nothing to do, but rpm -V gtk2 shows a
> heap of problems.
> 
> Is there a way to get yum to reinstall what rpm says is installed, but
> in fact is not actually there ?
> {doing it with rpm alone seems like a long way around ?}.
> 
> Any other ideas ??
> 
> Ta, DaveT.
> 
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.

You may want to look at using kickstart to make the install easier -
you can generate the kickstart file on the machine you coppied the
RPM database from.

On another note, I am not sure what you were trying to do with the
--rebuild option, but I suspect that it does not do what you think
it does. It will not fix the RPM database or the installed files.
The --rebuilddb will sometimes repair a corrupted RPM database, but
also does not fix the installed files.

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, 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.

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


[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux