fc4 yum update problems on two installations

[Jim Cornette]

sport wrote:

>Yum does look like it is working now, but I have multiple versions of
>some items installed, such as kdebase 2.5.x, and 2.4.x.  There should
>only be one version installed. 
>
Usually, he newer package is installed. The database enry for the older 
package does not get removed , though it was overwritten by the new version.
run
rpm -e --justdb olderpackage
to remove the rpm entry only from the database. Then you could run
rpm -q --verify newestpackage
to verify the new package is intact.

yum stores transaction information in /var/log/yum.log

To get a sorted list of current database enries, I use
rpm -qa |sort >myrpms.txt
to get a sorted list of rpms installed. The kernels and gpg-keys should 
be the only duplicates on an i386 computer.
There are some scripts which use unique to only show the duplicate rpms 
and saving a bit of time sorting through the rpm listings. I lost the 
script that someone else passed on and Icould not find it on a recent 
search through he archives. It would simplify the task somewhat.

> I checked on my not broken machine.
>Using yum remove kernel xxx worked to get the latest kernel installed,
>but there could be a hundred or more packages partly installed or
>installed with multiple versions due to the yum crash.  Does anyone know
>how to force yum to update everything, and know where yum keeps track of
>its history?
>  
>
If you do find a package where it does not verify correctly, removing 
only the db entry as stated above. (you might need --nodeps) will allow 
you to overwrite the nonverified package but not remove files  actually 
in the rpm until you run:
yum install newerpackage
again. This should stomp all over the files again and give you the new 
package with all of its dsired content.

>-cm
>
>On Tue, 2005-12-20 at 16:24 -0600, akonstam at trinity.edu wrote:
>  
>
>>On Tue, Dec 20, 2005 at 02:07:31PM +0000, sport wrote:
>>    
>>
>>>I have three machines all 32 bit running fc4.  These machines have been
>>>up and running without problems for five months or so.  I ran yum update
>>>on a one machine last sunday dec. 18th, and yum eventually failed with a
>>>segmentation fault.  I rebooted the machine, and kde won't come up.
>>>With the root login I was able to run gnome, and successive yum clean
>>>all, yum updates failed.  On a second machine I tried yum update on
>>>monday the 19th, and yum failed in a similar fashion, and repeated
>>>attempts caused rpmdb 4096 Input/output errors.  On a third machine I
>>>ran yum update on the 14th with success, and am afraid to attempt it
>>>again.  It appears as though yum was updated in each of these.  
>>>
>>>The yum.log is blank on machine #2.  I have run yum remove kernel
>>>2.6.4-1.1653_fc4 on this machine, and yum makes it through, but
>>>complains about rpmdb errors.  Running yum update
>>>kernel-2.6.4-1.1653_fc4 completes, and says that the kernel w as
>>>installed, but also complains of the rpmdb errors.  It does add the
>>>kernel, but the machine fails to boot on that kernel.
>>>      
>>>
This might be related to SELinux and file policies not being correct. 
try running
setenforce 0
before running the yum transaction. This will put you in warn, but don't 
prevent me from completing tasks not approved by policies or system 
labeling.
If you find that setenforce 0 allowed you to update your desired rpm. 
Try to relabel your system by running the below command as root to allow 
your system to fall into a relabeing of your system on next boot.
Alternatively, you could add autorelabel as an option to the kernel 
parameters  on your next boot. (covered on the test list, I didn't know 
of option before discussion on test list)

>>>Does anyone know of changes made last week to some packages, possibly
>>>yum or rpm that could be causing this?  The problem occurring on two
>>>separate systems and only when yum update was run in the last few days
>>>makes me think there is some new issue with the update mechanism.
>>>      
>>>
I'm on test, I do think that it could have been relaed to SELinux when 
it was updated to track with rawhide.
SELinux is protective, which I like. It also is sensitive to having all 
elements related to the system to be ironed out to get the wrinkles out. 
I believe it is progressing now to work as intended.

>>>I would appreciate any comments.
>>>
>>>Thanks,
>>>Chris 
>>>      
>>>
Jim


-- 
Don't shoot until you're sure you both aren't on the same side.