> -----Original Message----- > From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On > Behalf Of sebastiano at datafaber.net > Sent: Friday, September 16, 2011 11:27 > To: centos at 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.