Help: aborted 'yum upgrade' and corrupted rpm database resulted

[Robinson Tiemuqinke]

Hi,

 Just encounts an odd problem with yum 2.4 on Fedora
Core 4: obsoleted rpms are not cleanup by yum when the
latter is killed and runs again.

 I tried to update the system the newest patch level,
it works at the beginning but suddently yum hangs --
most packages were updated with a few left.

 I had to kill the yum process and restart again, this
time it runs to the end and upgrade all the left
packages.

But when I tried to see what's in my rpm database, I
found that there are duplicate entries for all
packages upgraded before hang -- Yum doesn't cleanup
the old version info from rpm database because it
hanged and then be killed.

Any one know how to deal with this problem
effectively? I hate to list tens of obsoleted rpms one
by one and feed them to "rpm -e --justdb" command. 

If I don't clean up the obsoleted rpms from rpm
database, then next upgrade will definitely falls into
trouble.

Please help.

Thanks.
 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Jeff Vian]

On Fri, 2006-04-28 at 16:07 -0700, Robinson Tiemuqinke wrote:
>  Hi,
>  
>   Just encounts an odd problem with yum 2.4 on Fedora
>  Core 4: obsoleted rpms are not cleanup by yum when the
>  latter is killed and runs again.
>  
>   I tried to update the system the newest patch level,
>  it works at the beginning but suddently yum hangs --
>  most packages were updated with a few left.
>  
>   I had to kill the yum process and restart again, this
>  time it runs to the end and upgrade all the left
>  packages.
>  
>  But when I tried to see what's in my rpm database, I
>  found that there are duplicate entries for all
>  packages upgraded before hang -- Yum doesn't cleanup
>  the old version info from rpm database because it
>  hanged and then be killed.
>  
>  Any one know how to deal with this problem
>  effectively? I hate to list tens of obsoleted rpms one
>  by one and feed them to "rpm -e --justdb" command. 
>   
I am not sure how to do a cleanup other than by hand.
The cause was killing the yum process before it had performed the
cleanup phase (as you already indicated)

You might try redoing the update one package at a time with a force to
see if that has any effect.  Otherwise you are stuck with manually doing
the clean up.
/var/log/yum.log will list those packages that were updated with
date/time so it should be easy to identify the ones of concern.

A simple bit of scripting would automate the processing of multiple
packages for cleanup.
You would need 2 things.  A list of the packages of concern complete
with the version that rpm can understand, and a simple script with a for
loop to walk through the list one package at a time and do the rpm -e on
it.


>  If I don't clean up the obsoleted rpms from rpm
>  database, then next upgrade will definitely falls into
>  trouble.
>  
>  Please help.
>  
>  Thanks.
>   
>  
>  
>  
>  
>  __________________________________________________
>  Do You Yahoo!?
>  Tired of spam?  Yahoo! Mail has the best spam protection around 
>  http://mail.yahoo.com 
>

[Sam Varshavchik]

Robinson Tiemuqinke writes:

>  But when I tried to see what's in my rpm database, I
>  found that there are duplicate entries for all
>  packages upgraded before hang -- Yum doesn't cleanup
>  the old version info from rpm database because it
>  hanged and then be killed.
>  
>  Any one know how to deal with this problem
>  effectively? I hate to list tens of obsoleted rpms one
>  by one and feed them to "rpm -e --justdb" command.  
Well, that's just what you'll have to do.

When I upgraded from FC3 to FC4, for some reason every invocation of 
/sbin/ldconfig from a %post and %postun segfaulted, when anaconda was doing 
its business.  The end result was a crapload of packages that had both the 
old and the new package versions in rpmdb.  This was 100% reproducible, with 
each machine that I upgraded from FC3 to FC4.  This was even more fun with 
the x86_64 FC, with multilib packages.

rpm can really blow goats, sometimes.

So, I just had to write a script to find every package with dupe versions 
installed, and remove the obsoleted version of the package.

That's life.

any existing script to fix the problem ?? -- Re: Help: aborted 'yum upgrade' and corrupted rpm database resulted

[Robinson Tiemuqinke]

Hi, Sam and Jeff,

 Thanks for your helpful guys's suggestions.

 Now since I'm being pushed to repair the crashed rpm
database, I just run the following steps to have
successfully fixed it in a quick and dirty way.

 1, cut the list of affected packages from
/var/log/yum.log file, and paste into a file
/var/tmp/hahaha.txt.

 2, rpm query the list in hahaha.txt and generate the
list of obsoleted version and save them into another
file with the following command: ( `head -1` because
ld obsolete version comes first)

for i in `cat /var/tmp/hahaha.txt `; do rpm -q ${i}|
head -1; done >/var/tmp/obsoletes

 3, feed the obsolete versions into "rpm -e --justdb":

 rpm -e --justdb `cat /var/tmp/obsoletes`

 After these three steps, rpm databases are clean
again.

 But, the above steps has some limitations especially
when there are multilib stuff kicked in. 

 Any one in this forum has an existing script to deal
with this problem? If so, I don't need to reinvent
wheel again.

Thanks.




--- Sam Varshavchik <mrsam(a)courier-mta.com&gt; wrote:

>  Robinson Tiemuqinke writes:
>  
>  > But when I tried to see what's in my rpm database,
>  I
>  > found that there are duplicate entries for all
>  > packages upgraded before hang -- Yum doesn't
>  cleanup
>  > the old version info from rpm database because it
>  > hanged and then be killed.
>  > 
>  > Any one know how to deal with this problem
>  > effectively? I hate to list tens of obsoleted rpms
>  one
>  > by one and feed them to "rpm -e --justdb" command.
>  
>  
>  Well, that's just what you'll have to do.
>  
>  When I upgraded from FC3 to FC4, for some reason
>  every invocation of 
>  /sbin/ldconfig from a %post and %postun segfaulted,
>  when anaconda was doing 
>  its business.  The end result was a crapload of
>  packages that had both the 
>  old and the new package versions in rpmdb.  This was
>  100% reproducible, with 
>  each machine that I upgraded from FC3 to FC4.  This
>  was even more fun with 
>  the x86_64 FC, with multilib packages.
>  
>  rpm can really blow goats, sometimes.
>  
>  So, I just had to write a script to find every
>  package with dupe versions 
>  installed, and remove the obsoleted version of the
>  package.
>   



>  That's life.
>  
>  > -- 
>  fedora-list mailing list
>  fedora-list(a)redhat.com
>  To unsubscribe: 
https://www.redhat.com/mailman/listinfo/fedora-list


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

any existing script to fix the problem ?? -- Re: Help: aborted 'yum upgrade' and corrupted rpm database resulted

[Sam Varshavchik]

Robinson Tiemuqinke writes:

>   3, feed the obsolete versions into "rpm -e --justdb":
>  
>   rpm -e --justdb `cat /var/tmp/obsoletes` 
I would not recommend the --justdb option.  It many cases, remnants of the 
old package are still there, and should really be removed.  With --justdb, 
the RPM database gets updated, but the old, obsolete files, may still be 
there and could cause some confusion in the future.

The procedure I used was:

1. Run rpm --rebuilddb, to make sure the RPM database is clean

2. rpm -q -a --queryformat '%{NAME}.%{ARCH}\n' | sort | uniq -c | sort -n

This gave me the list of all packages and how many versions of each are 
installed.  Some packages with >1 count, namely kernel and gpg-pubkey, are 
legitimate.

3. I took all the rest, ran rpm -q on them all, to get the actual versions 
that were installed, according to rpm.  And manually edited the output to 
contain only the obsolete versions, then fed the results to plain old 'rpm 
-e'.

[Paul Johnson]

If you run this all on one line, it will list all of your RPMS, find
the packages that have 2 or more listed entries, sort them from new to
old, and tell rpm to delete them.  Cut off the last bit, the xargs
part, if you just want to see a list of the redundant packages.

 Even if you don't need it right now, you should save it, because it
has come in handy for me a couple of times.

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 | tail -1 | cut -d" " -f1; done | grep -v gpg-pubkey | grep -v
kernel | xargs rpm -e

It seems to me that EVERY single time I've tried to run a DVD upgrade
of Fedora Core 4, the install bogs down and quits after installing
about three-fourths of the packages.  That's bad because it leaves a
full set of FC4 packages as well as the FC5 new ones.  This script
really helps to kill the duplicates.

On 4/28/06, Sam Varshavchik <mrsam(a)courier-mta.com&gt; wrote:
>  Robinson Tiemuqinke writes:
>
>  > But when I tried to see what's in my rpm database, I
>  > found that there are duplicate entries for all
>  > packages upgraded before hang -- Yum doesn't cleanup
>  > the old version info from rpm database because it
>  > hanged and then be killed.
>  >
>  > Any one know how to deal with this problem
>  > effectively? I hate to list tens of obsoleted rpms one
>  > by one and feed them to "rpm -e --justdb" command.
>
>  Well, that's just what you'll have to do.
>
>  When I upgraded from FC3 to FC4, for some reason every invocation of
>  /sbin/ldconfig from a %post and %postun segfaulted, when anaconda was doing
>  its business.  The end result was a crapload of packages that had both the
>  old and the new package versions in rpmdb.  This was 100% reproducible, with
>  each machine that I upgraded from FC3 to FC4.  This was even more fun with
>  the x86_64 FC, with multilib packages.
>
>  rpm can really blow goats, sometimes.
>
>  So, I just had to write a script to find every package with dupe versions
>  installed, and remove the obsoleted version of the package.
>
>  That's life.
>
>
>
>  --
>  fedora-list mailing list
>  fedora-list(a)redhat.com
>  To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>
>
>  

-- 
Paul E. Johnson
Professor, Political Science
1541 Lilac Lane, Room 504
University of Kansas