duplicate packages after up2date failure

[Jim Cornette]

Damian Menscher wrote:

>  We were taking advantage of the weekend to update our RHEL4.1 machine
>  to RHEL4.2. It is worth mentioning that it is an x86_64 box. While
>  running up2date, it hung on one of the packages. There was a useradd
>  process sucking 99% of the CPU that couldn't be killed or traced.
>  (It ignored sigKILL and sigSTOP, was not a zombie or in iowait, and
>  [sl]trace just hung with no output (and required a kill -9) on it.
>  Killing its parent just got it adopted by init, with no change in
>  behavior. Bug report against shadow-utils has been filed [1] though
>  I believe that an unkillable process that uses CPU is an indication
>  of a problem in the kernel.
>
>  Anyway, at least a reboot fixed that. But the damage was much worse:
>  our RPM database appears to be mangled quite badly, and the standard
>  trick of rm /var/lib/rpm/__db.00[1-3] && rpm --rebuilddb doesn't
>  help. In particular, the RPM database now thinks that we have *both*
>  the old and new versions of several RPMs installed. For example:
>
>  # rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE} %{ARCH}\n" rpm
>  rpm-4.3.3-9_nonptl x86_64 rpm-4.3.3-11_nonptl x86_64
>
>  We have 164 packages which are duplicated in this fashion. Meanwhile
>  up2date wants to update them (since we have the old version) but
>  can't (because we have the new version). So... I'm looking for
>  advice on how to handle this.
>
>  My guess is that the cleanest thing to do is remove the newer of each
>  pair from the database and then run up2date, which should upgrade
>  everything (fixing any old files on disk). My proposed script for
>  doing this is:
>
>  for file in `rpm -qa --queryformat="%{NAME} %{ARCH}\n" | sort | uniq
>  -c | grep -v " 1 " | cut -c 9- | cut -d" " -f1`; do rpm -q --last
>  $file | head -1 | cut -d" " -f1; done | xargs rpm -e --justdb up2date
>  -p up2date
>
>  Does this look reasonable to everyone, or is there a better way to
>  handle this problem?
>
>  Many thanks in advance for any advice,

If up2date was prevented from completing its task, duplicate rpms will 
show in the database as you are seeing. Usually, the rpms are still in 
the /var/spool/up2date directory. Since the rpms should be still on the 
computer, running "rpm -Fvh *.rpm --replacefiles --replacepkgs" might 
clean up the database errors. Alternatively, you could come up with a 
script to remove just the db entry for the older  rpm versions. The 
option for removing just the database and not any files is --justdb.

 From my experience with problems encountered by power outages and times 
shutting down the computer before up2date finished its job, the old 
package entries was all that was actally left on the system. The newer 
rpm replaced all the files that the older rpms put on the system. 
Removing the older rpm has a likelyhood of removing the file that the 
newer rpm installed on your system.
BTW- This advice was originally passed on by a Red Hat employee on one 
of the many lists. My system seems to be intact after ionly removing the 
database entries from the older packages. Thanks goes to the original 
source of information.

Jim


>
>  Damian Menscher
>
>  [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170087



-- 
QOTD:
    If it's too loud, you're too old.