-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of sebastiano@datafaber.net Sent: Friday, September 16, 2011 11:27 To: centos@centos.org Subject: Re: [CentOS] Yum segmentation fault updating from 5.6 to 5.7
I've finally managed to update one of my boxes to 5.7. I did it in a very roundabout way, which however confirms that at least in my boxes there's something wrong in the way yum creates the sqlite databases.
I've basically followed the guide at http://wiki.centos.org/HowTos/CreateLocalMirror to create my own mirror
Which uses rsync instead of http.
of the 5.7 'os' and 'updates' directories, created the yum repository with 'createrepo -d' to pre-create the sqlite database and made this mirror accessible to the other boxes via HTTP.
I then created a /etc/yum.repos.d/Local.repo file which specifies my private mirror for the [base] and [updates] repositories, commented out everything in the /etc/yum.repos.d/CentOS-Base.repo and ran
yum clean all yum update
Everything updated flawlessly and the box restarted normally with the newer kernel.
Now, this doesn't solve the original yum problem, but at least confirms that the creation of a corrupted sqlite database was indeed the real issue.
Many thanks to all the people on the list who have suggestions and advice, particularly to Alain Péan who pointed me in the right direction.
For, what to me is, an interesting data point, I would suggest doing the following now that you have a local known good copy: On a machine that was still faulting:
for i in /var/cache/yum/base/ \ /PATHTOLOCALREPO/5.7/os/<arch>/repodata/ \ /var/cache/yum/updates/ \ /PATHTOLOCALREPO/5.7/updates/<arch>/repodata/ do ls -l $i md5sum $i/* done #you may want to unroll the for, into four terminals, for your own sanity. #you'll have two sqlite files in each /var/cache dirs you can ignore
My bet... some isp between you and the internet is transparent proxying*** to reduce their downloading bandwidth, and they keep cache too long, the error will clear just as soon as their cache clears or you force it by wgeting the broken file with the --no-cache flag. [got the tee-shirt]
But now that you have a local mirror, the updates should go faster in the future. :)
*** I know you keep indicating no proxy is _known_ to you in the path to the mirrors, but it is pretty much the only thing that makes any sense.