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@xxxxxxxxxxx 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.
