I'm trying to update my CentOS 5.6 boxes to 5.7, and on every single one of them yum is failing with a segmentation fault: the error happens when yum is checking the 'base' repository.
[root@picard yum]# yum update Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors * base: mirrors.ircam.fr * extras: mirrors.ircam.fr * updates: mirror.opendoc.net base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault
Running yum under strace produces lots of output, the last lines are:
access("/var/cache/yum/base/primary.xml.gz.sqlite-journal", F_OK) = -1 ENOENT (No such file or directory) fstat64(5, {st_mode=S_IFREG|0644, st_size=20480, ...}) = 0 _llseek(5, 0, [0], SEEK_SET) = 0 read(5, "SQLite format 3\0\4\0\1\1\0@ \0\0\0\21\0\0\0\0"..., 1024) = 1024 _llseek(5, 2048, [2048], SEEK_SET) = 0 read(5, "\r\0\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 fcntl64(5, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}, 0xbf86a1c4) = 0 futex(0x7ba0918, FUTEX_WAKE_PRIVATE, 2147483647) = 0 stat64("/var/cache/yum/base/primary.xml.gz", {st_mode=S_IFREG|0644, st_size=983757, ...}) = 0 stat64("/var/cache/yum/base/primary.xml.gz", {st_mode=S_IFREG|0644, st_size=983757, ...}) = 0 stat64("/var/cache/yum/base/primary.xml.gz", {st_mode=S_IFREG|0644, st_size=983757, ...}) = 0 open("/var/cache/yum/base/primary.xml.gz", O_RDONLY|O_LARGEFILE) = 6 _llseek(6, 0, [0], SEEK_CUR) = 0 read(6, "\37\213\10\10\0\0\0\0\2\377/home/buildcentos/CENT"..., 8192) = 8192 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
It seems that the primary.xml.gz file is somehow corrupted, but I've already tried a "yum clean all" and a "rm -rf /var/cache/yum/*" without success.
Apart from being at CentOS 5.6 and all having this problem, the boxes have very few in common:
- 2 physical machine running 5.6 32-bit, one in my office, the other in a datacenter - 1 physical machine running 5.6 64-bit in another datacenter - 2 KVM VPS running 5.6 32-bit in a third datacenter - 1 Xen VPS running 5.6 64-bit in a fourth datacenter
There was a thread on the forum some months ago which mentioned this same problem, but the original poster didn't find a solution (or if he did, he didn't share it with the forum). Any suggestion is appreciated, I cannot reinstall those boxes with 6.0 for at least 4/5 months.
On Wed, 2011-09-14 at 23:56 +0200, Sebastiano Pilla wrote:
I'm trying to update my CentOS 5.6 boxes to 5.7, and on every single one of them yum is failing with a segmentation fault: the error happens when yum is checking the 'base' repository.
Have you tried
yum clean all
followed by
yum update
?
Always Learning wrote:
On Wed, 2011-09-14 at 23:56 +0200, Sebastiano Pilla wrote:
I'm trying to update my CentOS 5.6 boxes to 5.7, and on every single one of them yum is failing with a segmentation fault: the error happens when yum is checking the 'base' repository.
Have you tried
yum clean all
followed by
yum update
?
Yes, I've tried it, with the exact same result:
[root@picard ~]# yum clean all Loaded plugins: downloadonly, fastestmirror, priorities Cleaning up Everything Cleaning up list of fastest mirrors [root@picard ~]# yum update Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors * base: mirror.opendoc.net * extras: mirror.opendoc.net * updates: mirror.opendoc.net base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault
On Thu, 2011-09-15 at 00:26 +0200, Sebastiano Pilla wrote:
Always Learning wrote:
Have you tried
yum clean all
followed by
yum update
?
Yes, I've tried it, with the exact same result:
[root@picard ~]# yum clean all Loaded plugins: downloadonly, fastestmirror, priorities Cleaning up Everything Cleaning up list of fastest mirrors [root@picard ~]# yum update Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors
- base: mirror.opendoc.net
- extras: mirror.opendoc.net
- updates: mirror.opendoc.net
base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault
Can you list, one line for each, the names of the repos in /etc/yum.repos.d
And list the entire file for your BASE repo in /etc/yum/repos.d - it is probably named something like
CentOS-Base.repo
Also can you do a
uname -a
and show us the result.
Curious!
Always Learning wrote:
On Thu, 2011-09-15 at 00:26 +0200, Sebastiano Pilla wrote:
Can you list, one line for each, the names of the repos in /etc/yum.repos.d
[root@picard ~]# ll /etc/yum.repos.d/ total 20K -rw-r--r-- 1 root root 1.9K Feb 8 2011 CentOS-Base.repo -rw-r--r-- 1 root root 631 Feb 8 2011 CentOS-Debuginfo.repo -rw-r--r-- 1 root root 626 Feb 8 2011 CentOS-Media.repo -rw-r--r-- 1 root root 4.6K Feb 8 2011 CentOS-Vault.repo
And list the entire file for your BASE repo in /etc/yum/repos.d - it is probably named something like
CentOS-Base.repo
(there may be some additional line wrapping inserted by my mail client)
[root@picard ~]# cat /etc/yum.repos.d/CentOS-Base.repo # CentOS-Base.repo # # The mirror system uses the connecting IP address of the client and the # update status of each mirror to pick mirrors that are updated to and # geographically close to the client. You should use this for CentOS updates # unless you are manually picking other mirrors. # # If the mirrorlist= does not work for you, as a fall back you can try the # remarked out baseurl= line instead. # #
[base] name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#released updates [updates] name=CentOS-$releasever - Updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#additional packages that may be useful [extras] name=CentOS-$releasever - Extras mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#additional packages that extend functionality of existing packages [centosplus] name=CentOS-$releasever - Plus mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/ gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#contrib - packages by Centos Users [contrib] name=CentOS-$releasever - Contrib mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/ gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
Also can you do a
uname -a
and show us the result.
[root@picard ~]# uname -a Linux picard.home.lan 2.6.18-238.19.1.el5 #1 SMP Fri Jul 15 07:32:29 EDT 2011 i686 i686 i386 GNU/Linux
Thank you very much for your help.
On Thu, 2011-09-15 at 00:35 +0200, Sebastiano Pilla wrote:
Thank you very much for your help.
Please do not forget I am a Learner, not an expert :-)
Please try one thing for me
yum install httpd
It does not matter whether or not you have this already installed. I am curious to know what type of response you get. You do not have to install this. It is the reaction from yum that interests me, so you can reject the installation - if it works.
Always Learning wrote:
Please try one thing for me
yum install httpd
It does not matter whether or not you have this already installed. I am curious to know what type of response you get. You do not have to install this. It is the reaction from yum that interests me, so you can reject the installation - if it works.
Same result:
[root@picard ~]# yum install httpd Loaded plugins: downloadonly, fastestmirror, priorities Loading mirror speeds from cached hostfile * base: mirror.opendoc.net * extras: mirror.opendoc.net * updates: mirror.opendoc.net base | 1.1 kB 00:00 Segmentation fault
On Thu, 15 Sep 2011, Sebastiano Pilla wrote:
-rw-r--r-- 1 root root 4.6K Feb 8 2011 CentOS-Vault.repo
Do you need CentOS-Vault, as it includes all the packages from Centos 5.x upwards IIRC?
Keith
----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
Keith Roberts wrote:
On Thu, 15 Sep 2011, Sebastiano Pilla wrote:
-rw-r--r-- 1 root root 4.6K Feb 8 2011 CentOS-Vault.repo
Do you need CentOS-Vault, as it includes all the packages from Centos 5.x upwards IIRC?
It's in there by default, since the first install on the box. All the repositories listed inside this file have enabled=0 however.
On Thu, 2011-09-15 at 00:35 +0200, Sebastiano Pilla wrote:
[root@picard ~]# ll /etc/yum.repos.d/ total 20K -rw-r--r-- 1 root root 1.9K Feb 8 2011 CentOS-Base.repo -rw-r--r-- 1 root root 631 Feb 8 2011 CentOS-Debuginfo.repo -rw-r--r-- 1 root root 626 Feb 8 2011 CentOS-Media.repo -rw-r--r-- 1 root root 4.6K Feb 8 2011 CentOS-Vault.repo
Please add an extra repo to the same directory
name: (your own choice) - something like this: centos-cr.repo
---------------contents---------------------
# CentOS-CR.repo # # The continuous release ( CR ) repository contains rpms from the # next point release of CentOS, which isnt itself released as yet. # # Look at http://wiki.centos.org/AdditionalResources/Repositories/CR # for more details about how this repository works and what users # should expect to see included / excluded
[cr] name=CentOS-$releasever - CR baseurl=http://mirror.centos.org/centos/$releasever/cr/$basearch/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
-------end------------------ (do not include this line)
and try again
yum clean all yum install httpd
and see what happens.
On Thu, 15 Sep 2011 00:01:23 +0100, Always Learning wrote:
On Thu, 2011-09-15 at 00:35 +0200, Sebastiano Pilla wrote:
[root@picard ~]# ll /etc/yum.repos.d/ total 20K -rw-r--r-- 1 root root 1.9K Feb 8 2011 CentOS-Base.repo -rw-r--r-- 1 root root 631 Feb 8 2011 CentOS-Debuginfo.repo -rw-r--r-- 1 root root 626 Feb 8 2011 CentOS-Media.repo -rw-r--r-- 1 root root 4.6K Feb 8 2011 CentOS-Vault.repo
Please add an extra repo to the same directory
name: (your own choice) - something like this: centos-cr.repo
---------------contents---------------------
# CentOS-CR.repo # # The continuous release ( CR ) repository contains rpms from the # next point release of CentOS, which isnt itself released as yet. # # Look at http://wiki.centos.org/AdditionalResources/Repositories/CR # for more details about how this repository works and what users # should expect to see included / excluded
[cr] name=CentOS-$releasever - CR baseurl=http://mirror.centos.org/centos/$releasever/cr/$basearch/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
-------end------------------ (do not include this line)
I get the same segmentation fault, I don't think that adding this new repository is going to change the fact that somehow the files for the base repository are corrupted:
[root@picard yum.repos.d]# yum clean all Loaded plugins: downloadonly, fastestmirror, priorities Cleaning up Everything Cleaning up list of fastest mirrors [root@picard yum.repos.d]# yum install httpd Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors * base: mirror.opendoc.net * extras: mirror.opendoc.net * updates: mirror.opendoc.net base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault
On Sep 14, 2011, at 2:56 PM, Sebastiano Pilla wrote:
I'm trying to update my CentOS 5.6 boxes to 5.7, and on every single one of them yum is failing with a segmentation fault: the error happens when yum is checking the 'base' repository.
[root@picard yum]# yum update Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors
- base: mirrors.ircam.fr
- extras: mirrors.ircam.fr
- updates: mirror.opendoc.net
base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault
Running yum under strace produces lots of output, the last lines are:
access("/var/cache/yum/base/primary.xml.gz.sqlite-journal", F_OK) = -1 ENOENT (No such file or directory) fstat64(5, {st_mode=S_IFREG|0644, st_size=20480, ...}) = 0 _llseek(5, 0, [0], SEEK_SET) = 0 read(5, "SQLite format 3\0\4\0\1\1\0@ \0\0\0\21\0\0\0\0"..., 1024) = 1024 _llseek(5, 2048, [2048], SEEK_SET) = 0 read(5, "\r\0\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024 fcntl64(5, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}, 0xbf86a1c4) = 0 futex(0x7ba0918, FUTEX_WAKE_PRIVATE, 2147483647) = 0 stat64("/var/cache/yum/base/primary.xml.gz", {st_mode=S_IFREG|0644, st_size=983757, ...}) = 0 stat64("/var/cache/yum/base/primary.xml.gz", {st_mode=S_IFREG|0644, st_size=983757, ...}) = 0 stat64("/var/cache/yum/base/primary.xml.gz", {st_mode=S_IFREG|0644, st_size=983757, ...}) = 0 open("/var/cache/yum/base/primary.xml.gz", O_RDONLY|O_LARGEFILE) = 6 _llseek(6, 0, [0], SEEK_CUR) = 0 read(6, "\37\213\10\10\0\0\0\0\2\377/home/buildcentos/CENT"..., 8192) = 8192 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++
It seems that the primary.xml.gz file is somehow corrupted, but I've already tried a "yum clean all" and a "rm -rf /var/cache/yum/*" without success.
Apart from being at CentOS 5.6 and all having this problem, the boxes have very few in common:
- 2 physical machine running 5.6 32-bit, one in my office, the other in
a datacenter
- 1 physical machine running 5.6 64-bit in another datacenter
- 2 KVM VPS running 5.6 32-bit in a third datacenter
- 1 Xen VPS running 5.6 64-bit in a fourth datacenter
There was a thread on the forum some months ago which mentioned this same problem, but the original poster didn't find a solution (or if he did, he didn't share it with the forum). Any suggestion is appreciated, I cannot reinstall those boxes with 6.0 for at least 4/5 months.
---- make sure that there isn't any yum/rpm processes running... ps aux|grep yum ps aux|grep rpm
Once you've determined they aren't running, try...
yum clean metadata yum clean dbcache
(those should be executed when you execute 'yum clean all' but maybe it ain't gettin' done)
and then yum update
Craig
Craig White wrote:
make sure that there isn't any yum/rpm processes running... ps aux|grep yum ps aux|grep rpm
Once you've determined they aren't running, try...
yum clean metadata yum clean dbcache
(those should be executed when you execute 'yum clean all' but maybe it ain't gettin' done)
and then yum update
Segmentation fault again:
[root@picard yum.repos.d]# ps aux | grep yum root 18050 0.0 0.0 4016 684 pts/1 S+ 08:21 0:00 grep yum [root@picard yum.repos.d]# ps aux | grep rpm
root 18052 0.0 0.0 4016 684 pts/1 S+ 08:21 0:00 grep rpm [root@picard yum.repos.d]# yum clean metadata Loaded plugins: downloadonly, fastestmirror, priorities 6 metadata files removed 1 sqlite files removed 0 metadata files removed [root@picard yum.repos.d]# yum clean dbcache Loaded plugins: downloadonly, fastestmirror, priorities 0 sqlite files removed [root@picard yum.repos.d]# yum update
Loaded plugins: downloadonly, fastestmirror, priorities Loading mirror speeds from cached hostfile * base: mirror.opendoc.net * extras: mirror.opendoc.net * updates: mirror.opendoc.net base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault
On 15/09/11 16:22, Sebastiano Pilla wrote:
[root@picard yum.repos.d]# yum clean dbcache Loaded plugins: downloadonly, fastestmirror, priorities 0 sqlite files removed [root@picard yum.repos.d]# yum update
Loaded plugins: downloadonly, fastestmirror, priorities Loading mirror speeds from cached hostfile
- base: mirror.opendoc.net
- extras: mirror.opendoc.net
- updates: mirror.opendoc.net
base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault
Perhaps your are downloading the same corrupted primary.xml.gz from mirror.opendoc.net. Maybe try another mirror? Perhaps download the file manually and compare?
Kal
On Thu, Sep 15, 2011 at 2:31 PM, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
Perhaps your are downloading the same corrupted primary.xml.gz from mirror.opendoc.net. Maybe try another mirror? Perhaps download the file manually and compare?
Yeah could be. And if your corporate network is behind a proxy, the proxy may cache that corrupted files.
[root@picard yum.repos.d]# yum update
Maybe using Startrek name as server name is not a good idea.
On Thu, 15 Sep 2011 14:44:59 +0800, Fajar Priyanto wrote:
On Thu, Sep 15, 2011 at 2:31 PM, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
Perhaps your are downloading the same corrupted primary.xml.gz from mirror.opendoc.net. Maybe try another mirror? Perhaps download the file manually and compare?
This is a good idea, however I don't know how can I force yum to use another mirror. Do you have any suggestion?
Yeah could be. And if your corporate network is behind a proxy, the proxy may cache that corrupted files.
I've set up the network in question and this box (as well as the other boxes in the other datacenters which exhibit the same problem) is not behind a proxy, so we can exlude the corruption of downloaded files.
On Thu, 15 Sep 2011 14:10:50 +0200, sebastiano@datafaber.net wrote:
On Thu, 15 Sep 2011 14:44:59 +0800, Fajar Priyanto wrote:
On Thu, Sep 15, 2011 at 2:31 PM, Kahlil Hodgson kahlil.hodgson@dealmax.com.au wrote:
Perhaps your are downloading the same corrupted primary.xml.gz from mirror.opendoc.net. Maybe try another mirror? Perhaps download the file manually and compare?
This is a good idea, however I don't know how can I force yum to use another mirror. Do you have any suggestion?
Update: yum chose to use another mirror and it failed in the exact same way.
[root@picard yum.repos.d]# yum repolist Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors * base: mirrors.ircam.fr * extras: mirrors.ircam.fr * updates: mirrors.ircam.fr base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault
So either several mirrors all have the same corrupted file, or my box is generating a corrupted file each time. I would tend towards the second hypothesis, since other people have successfully updated their 5.6 installations to 5.7.
On Thu, 15 Sep 2011 14:30:01 +0100, Always Learning wrote:
On Thu, 2011-09-15 at 15:18 +0200, sebastiano@datafaber.net wrote:
Update: yum chose to use another mirror and it failed in the exact same way.
I could do that, but it is again extremely unlikely that 6 disks on 6 different boxes fail in the exact same way when running the same yum command... I'll keep that as the last option before a complete wipe and reinstall.
On Thu, Sep 15, 2011 at 9:18 AM, sebastiano@datafaber.net wrote: [snip]
So either several mirrors all have the same corrupted file, or my box is generating a corrupted file each time. I would tend towards the second hypothesis, since other people have successfully updated their 5.6 installations to 5.7.
Have you added any non-CentOS versions of any of the packages that yum uses (python, sqlite, etc)?
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 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.
Have a nice weekend Sebastiano Pilla
Le 16/09/2011 17:26, sebastiano@datafaber.net a écrit :
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.
You are welcome, but I don't know how my suggestions lead you to the idea to setup a local repo
But I am glad it is working now for you.
Cheers, Alain
-----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.
On Thu, 2011-09-15 at 08:22 +0200, Sebastiano Pilla wrote:
Craig White wrote:
make sure that there isn't any yum/rpm processes running... ps aux|grep yum ps aux|grep rpm
Once you've determined they aren't running, try...
yum clean metadata yum clean dbcache
(those should be executed when you execute 'yum clean all' but maybe it ain't gettin' done)
and then yum update
Segmentation fault again:
[root@picard yum.repos.d]# ps aux | grep yum root 18050 0.0 0.0 4016 684 pts/1 S+ 08:21 0:00 grep yum [root@picard yum.repos.d]# ps aux | grep rpm
root 18052 0.0 0.0 4016 684 pts/1 S+ 08:21 0:00 grep rpm [root@picard yum.repos.d]# yum clean metadata Loaded plugins: downloadonly, fastestmirror, priorities 6 metadata files removed 1 sqlite files removed 0 metadata files removed [root@picard yum.repos.d]# yum clean dbcache Loaded plugins: downloadonly, fastestmirror, priorities 0 sqlite files removed [root@picard yum.repos.d]# yum update
Loaded plugins: downloadonly, fastestmirror, priorities Loading mirror speeds from cached hostfile
- base: mirror.opendoc.net
- extras: mirror.opendoc.net
- updates: mirror.opendoc.net
base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault
---- sounds like someone did some manual mucking in /etc/yum.repos.d
You probably want to start disabling some of the configured repo's in /etc/yum.repos.d... 'enabled = 0' - I'd probably start by making sure that all non-CentOS repo's were disabled though it does seem like you don't get very far through the repo list.
At the point where you stop getting the segfault, you will be able to identify which repo has a configuration issue.
Craig
On Thu, 15 Sep 2011 05:57:02 -0700, Craig White wrote:
sounds like someone did some manual mucking in /etc/yum.repos.d
You probably want to start disabling some of the configured repo's in /etc/yum.repos.d... 'enabled = 0' - I'd probably start by making sure that all non-CentOS repo's were disabled though it does seem like you don't get very far through the repo list.
At the point where you stop getting the segfault, you will be able to identify which repo has a configuration issue.
That was a very good idea, I have tried it:
- if I disable all repositories I get no errors but no updates (which is normal) - if I enable [base] only I get the segmentation fault - if I enable [updates] only I get the following output, which confirms that yum at least partially works: the missing package is in the [base] repository, which is the one that gives the error
[root@picard yum.repos.d]# yum update Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors * updates: mirror.opendoc.net updates | 1.9 kB 00:00 updates/primary_db | 134 kB 00:00 Excluding Packages in global exclude list Finished Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package curl.i386 0:7.15.5-9.el5_7.4 set to be updated ---> Package curl-devel.i386 0:7.15.5-9.el5_7.4 set to be updated ---> Package dbus.i386 0:1.1.2-16.el5_7 set to be updated ---> Package dbus-libs.i386 0:1.1.2-16.el5_7 set to be updated ---> Package device-mapper-multipath.i386 0:0.4.7-46.el5_7.1 set to be updated ---> Package dhclient.i386 12:3.0.5-29.el5_7.1 set to be updated ---> Package dhcp.i386 12:3.0.5-29.el5_7.1 set to be updated ---> Package kernel.i686 0:2.6.18-274.3.1.el5 set to be installed ---> Package kernel-devel.i686 0:2.6.18-274.3.1.el5 set to be installed ---> Package kernel-headers.i386 0:2.6.18-274.3.1.el5 set to be updated ---> Package kpartx.i386 0:0.4.7-46.el5_7.1 set to be updated ---> Package libXfont.i386 0:1.2.2-1.0.4.el5_7 set to be updated ---> Package libpng.i386 2:1.2.10-7.1.el5_7.5 set to be updated ---> Package libpng-devel.i386 2:1.2.10-7.1.el5_7.5 set to be updated ---> Package lvm2.i386 0:2.02.84-6.el5_7.1 set to be updated --> Processing Dependency: device-mapper >= 1.02.63-2 for package: lvm2 ---> Package nspr.i386 0:4.8.8-1.el5_7 set to be updated ---> Package nss.i386 0:3.12.10-4.el5.centos set to be updated ---> Package openssh.i386 0:4.3p2-72.el5_7.5 set to be updated ---> Package openssh-clients.i386 0:4.3p2-72.el5_7.5 set to be updated ---> Package openssh-server.i386 0:4.3p2-72.el5_7.5 set to be updated ---> Package rsync.i386 0:3.0.6-4.el5_7.1 set to be updated ---> Package tzdata.i386 0:2011h-2.el5 set to be updated --> Finished Dependency Resolution lvm2-2.02.84-6.el5_7.1.i386 from updates has depsolving problems --> Missing Dependency: device-mapper >= 1.02.63-2 is needed by package lvm2-2.02.84-6.el5_7.1.i386 (updates) --> Running transaction check ---> Package kernel.i686 0:2.6.18-194.32.1.el5 set to be erased ---> Package kernel-devel.i686 0:2.6.18-194.32.1.el5 set to be erased ---> Package lvm2.i386 0:2.02.84-6.el5_7.1 set to be updated --> Processing Dependency: device-mapper >= 1.02.63-2 for package: lvm2 --> Finished Dependency Resolution lvm2-2.02.84-6.el5_7.1.i386 from updates has depsolving problems --> Missing Dependency: device-mapper >= 1.02.63-2 is needed by package lvm2-2.02.84-6.el5_7.1.i386 (updates) Error: Missing Dependency: device-mapper >= 1.02.63-2 is needed by package lvm2-2.02.84-6.el5_7.1.i386 (updates) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest
I'm gonna try to download and install the missing package manually, then try the yum update again.
Stupid question. Can we uninstall yum? And install again using manual rpm.
나의 iPhone에서 보냄
On Sep 15, 2011, at 7:18 AM, sebastiano@datafaber.net wrote:
On Thu, 15 Sep 2011 05:57:02 -0700, Craig White wrote:
sounds like someone did some manual mucking in /etc/yum.repos.d
You probably want to start disabling some of the configured repo's in /etc/yum.repos.d... 'enabled = 0' - I'd probably start by making sure that all non-CentOS repo's were disabled though it does seem like you don't get very far through the repo list.
At the point where you stop getting the segfault, you will be able to identify which repo has a configuration issue.
That was a very good idea, I have tried it:
- if I disable all repositories I get no errors but no updates (which
is normal)
- if I enable [base] only I get the segmentation fault
- if I enable [updates] only I get the following output, which confirms
that yum at least partially works: the missing package is in the [base] repository, which is the one that gives the error
[root@picard yum.repos.d]# yum update Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors
- updates: mirror.opendoc.net
updates | 1.9 kB 00:00 updates/primary_db | 134 kB 00:00 Excluding Packages in global exclude list Finished Setting up Update Process Resolving Dependencies --> Running transaction check
<<<snip>>>
You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest
---- might be hard to run package-cleanup without having base enabled but I would certainly recommend that you run 'rpm -Va [--nofiles --nodigest]' to identify the broken dependencies - apparently something that the base repository really believes should be there no matter what.
Craig
On Thu, 15 Sep 2011 08:42:42 -0700, Craig White wrote:
might be hard to run package-cleanup without having base enabled but I would certainly recommend that you run 'rpm -Va [--nofiles --nodigest]' to identify the broken dependencies - apparently something that the base repository really believes should be there no matter what.
I get no output at all from this command, perhaps I have misunderstood the flags?
[root@picard ~]# rpm -Va --nofiles --nodigest [root@picard ~]#
In the meantime I have found an interesting data point:
[root@picard ~]# yum clean all Loaded plugins: fastestmirror Cleaning up Everything Cleaning up list of fastest mirrors [root@picard ~]# yum update Loaded plugins: fastestmirror Determining fastest mirrors * base: mirror.ash.fastserv.com * extras: mirror.net.cen.ct.gov * updates: mirror.7x24web.net base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault [root@picard ~]# ll /var/cache/yum/base total 1004K -rw-r--r-- 1 root root 0 Sep 15 19:12 cachecookie -rw-r--r-- 1 root root 1017 Sep 15 19:11 mirrorlist.txt drwxr-xr-x 2 root root 4.0K Jul 10 12:19 packages/ -rw-r--r-- 1 root root 961K Sep 5 13:52 primary.xml.gz -rw-r--r-- 1 root root 20K Sep 15 19:12 primary.xml.gz.sqlite -rw-r--r-- 1 root root 1.2K Sep 5 13:52 repomd.xml
The file /var/cache/yum/base/primary.xml.gz.sqlite is only 20KB, whereas in the "normal" case I'd expect it to be 6.5MB. Somehow, yum is failing to regenerate this file for the base repository, and is crashing with a segmentation fault when trying to read it. I don't know however how to make it generate a correct sqlite file.
On Thu, 15 Sep 2011 18:33:39 +0200, Nicolas Thierry-Mieg wrote:
sebastiano@datafaber.net wrote:
The file /var/cache/yum/base/primary.xml.gz.sqlite is only 20KB, whereas in the "normal" case I'd expect it to be 6.5MB. Somehow, yum is
you're not out of hard drive space on that partition, are you?
Not at all:
[root@picard ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 35G 3.1G 30G 10% / /dev/sdb1 1.8T 527G 1.2T 31% /data /dev/sda1 145M 34M 104M 25% /boot tmpfs 1005M 0 1005M 0% /dev/shm
And there's also plenty of available space on the other 5 boxes which exhibit the same issue.
Le 15/09/2011 18:37, sebastiano@datafaber.net a écrit :
On Thu, 15 Sep 2011 18:33:39 +0200, Nicolas Thierry-Mieg wrote:
sebastiano@datafaber.net wrote:
The file /var/cache/yum/base/primary.xml.gz.sqlite is only 20KB, whereas in the "normal" case I'd expect it to be 6.5MB. Somehow, yum is
you're not out of hard drive space on that partition, are you?
Not at all:
[root@picard ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda2 35G 3.1G 30G 10% / /dev/sdb1 1.8T 527G 1.2T 31% /data /dev/sda1 145M 34M 104M 25% /boot tmpfs 1005M 0 1005M 0% /dev/shm
And there's also plenty of available space on the other 5 boxes which exhibit the same issue.
What if you delete (or save elsewhere) the primary.xml.gz.sqlite file ? If it is corrupted, it would do no arm, and perhaps it is no more used or regenerated if it missing ?
Alain
Alain Péan wrote:
What if you delete (or save elsewhere) the primary.xml.gz.sqlite file ? If it is corrupted, it would do no arm, and perhaps it is no more used or regenerated if it missing ?
This doesn't work unfortunately, yum always creates the same corrupted file:
- here I use yum to delete the yum cache, then I confirm that the file does not exist anymore, but the subsequent update fails and the corrupted file is there again
[root@picard ~]# yum clean all Loaded plugins: downloadonly, fastestmirror, priorities Cleaning up Everything [root@picard ~]# ll /var/cache/yum/base
total 4.0K drwxr-xr-x 2 root root 4.0K Sep 14 21:56 packages/ [root@picard ~]# yum update Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors * base: mirrors.ircam.fr * updates: mirrors.ircam.fr base | 1.1 kB 00:00 base/primary | 961 kB 00:02 Segmentation fault [root@picard ~]# ll /var/cache/yum/base total 1000K -rw-r--r-- 1 root root 0 Sep 15 23:43 cachecookie -rw-r--r-- 1 root root 985 Sep 15 23:43 mirrorlist.txt drwxr-xr-x 2 root root 4.0K Sep 14 21:56 packages/ -rw-r--r-- 1 root root 961K Sep 5 13:52 primary.xml.gz -rw-r--r-- 1 root root 20K Sep 15 23:43 primary.xml.gz.sqlite -rw-r--r-- 1 root root 1.2K Sep 5 13:52 repomd.xml
- here I delete just the corrupted file, I confirm that it doesn't exist anymore, but the subsequent update fails and the file is there again
[root@picard ~]# rm -f /var/cache/yum/base/primary.xml.gz.sqlite [root@picard ~]# ll /var/cache/yum/base total 980K -rw-r--r-- 1 root root 0 Sep 15 23:43 cachecookie -rw-r--r-- 1 root root 985 Sep 15 23:43 mirrorlist.txt drwxr-xr-x 2 root root 4.0K Sep 14 21:56 packages/ -rw-r--r-- 1 root root 961K Sep 5 13:52 primary.xml.gz -rw-r--r-- 1 root root 1.2K Sep 5 13:52 repomd.xml [root@picard ~]# yum update Loaded plugins: downloadonly, fastestmirror, priorities Loading mirror speeds from cached hostfile * base: mirrors.ircam.fr * updates: mirrors.ircam.fr Segmentation fault [root@picard ~]# ll /var/cache/yum/base total 1000K -rw-r--r-- 1 root root 0 Sep 15 23:43 cachecookie -rw-r--r-- 1 root root 985 Sep 15 23:43 mirrorlist.txt drwxr-xr-x 2 root root 4.0K Sep 14 21:56 packages/ -rw-r--r-- 1 root root 961K Sep 5 13:52 primary.xml.gz -rw-r--r-- 1 root root 20K Sep 15 23:43 primary.xml.gz.sqlite -rw-r--r-- 1 root root 1.2K Sep 5 13:52 repomd.xml
On Thu, 2011-09-15 at 18:37 +0200, sebastiano@datafaber.net wrote:
And there's also plenty of available space on the other 5 boxes which exhibit the same issue.
Sorry if this has been suggested already - have you tried running with all plugins disabled?
'yum --noplugins check-update'
I have a very vague memory of encountering a problem similar to this years ago when my mirrors file was corrupted.
Brian Miller wrote:
Sorry if this has been suggested already - have you tried running with all plugins disabled?
'yum --noplugins check-update'
This wasn't suggested yet, but I did try it at some point. I've just tried again and the result is the same:
[root@picard ~]# yum clean all Loaded plugins: downloadonly, fastestmirror, priorities Cleaning up Everything [root@picard ~]# yum --noplugins check-update base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault
Le 15/09/2011 18:16, sebastiano@datafaber.net a écrit :
[root@picard ~]# ll /var/cache/yum/base total 1004K -rw-r--r-- 1 root root 0 Sep 15 19:12 cachecookie -rw-r--r-- 1 root root 1017 Sep 15 19:11 mirrorlist.txt drwxr-xr-x 2 root root 4.0K Jul 10 12:19 packages/ -rw-r--r-- 1 root root 961K Sep 5 13:52 primary.xml.gz -rw-r--r-- 1 root root 20K Sep 15 19:12 primary.xml.gz.sqlite -rw-r--r-- 1 root root 1.2K Sep 5 13:52 repomd.xml
The file /var/cache/yum/base/primary.xml.gz.sqlite is only 20KB, whereas in the "normal" case I'd expect it to be 6.5MB. Somehow, yum is failing to regenerate this file for the base repository, and is crashing with a segmentation fault when trying to read it. I don't know however how to make it generate a correct sqlite file.
It is interesting because I had previously this error :
# yum update .... http://mirror.centos.org/centos/5/cr/x86_64/repodata/filelists.sqlite.bz2: [Errno 14] HTTP Error 404: Not Found Trying other mirror. Error: failure: repodata/filelists.sqlite.bz2 from cr: [Errno 256] No more mirrors to try.
See : http://lists.centos.org/pipermail/centos/2011-September/117615.html
And here is the answer from Karanbir Singh :
"unfortunately, you hit an issue that I did not think anyone would see ( but was aware of... ). The issue originates from the fact that the new CR repo has no sqlite metadata store, its xml only. And your machine was trying to get the sqlite files - hitting a valid 404, since those files do not exist."
See the full answer on the thread. So I wonder if it is related... I had the CR repo configured, before trying to update. In my case, yum clean all worked, but I have indeed a bigger primary.xml.gz.sqlite : # ls -lh total 36M .... -rw-r--r-- 1 root root 1,3M sep 6 00:28 primary.xml.gz -rw-r--r-- 1 root root 8,9M sep 14 15:11 primary.xml.gz.sqlite -rw-r--r-- 1 root root 1,2K sep 6 00:28 repomd.xml ...
Alain
On Thu, 15 Sep 2011 18:36:10 +0200, Alain Péan wrote:
And here is the answer from Karanbir Singh :
"unfortunately, you hit an issue that I did not think anyone would see ( but was aware of... ). The issue originates from the fact that the new CR repo has no sqlite metadata store, its xml only. And your machine was trying to get the sqlite files - hitting a valid 404, since those files do not exist."
You may be onto something, I've seen that the 5.6 base repo has the sqlite metadata store while the 5.7 base repo hasn't it. But the 20K sqlite file that yum generates on my boxes looks to have at least something related to sqlite inside it rather than the response from a 404 error:
[root@picard base]# strings /var/cache/yum/base/primary.xml.gz.sqlite SQLite format 3 {tabledb_infodb_info CREATE TABLE db_info (dbversion INTEGER, checksum TEXT) tablepackagespackages CREATE TABLE packages ( pkgKey INTEGER PRIMARY KEY, pkgId TEXT, name TEXT, arch TEXT, version TEXT, epoch TEXT, release TEXT, summary TEXT, description TEXT, url TEXT, time_file INTEGER, time_build INTEGER, rpm_license TEXT, rpm_vendor TEXT, rpm_group TEXT, rpm_buildhost TEXT, rpm_sourcerpm TEXT, rpm_header_start INTEGER, rpm_header_end INTEGER, rpm_packager TEXT, size_package INTEGER, size_installed INTEGER, size_archive INTEGER, location_href TEXT, location_base TEXT, checksum_type TEXT)J cindexpackagenamepackages CREATE INDEX packagename ON packages (name)G aindexpackageIdpackages CREATE INDEX packageId ON packages (pkgId) tablefilesfiles CREATE TABLE files ( name TEXT, type TEXT, pkgKey INTEGER)@ Yindexfilenamesfiles CREATE INDEX filenames ON files (name) tablerequiresrequires CREATE TABLE requires ( name TEXT, flags TEXT, epoch TEXT, version TEXT, release TEXT, pkgKey INTEGER , pre BOOLEAN DEFAULT FALSE)L gindexpkgrequiresrequires CREATE INDEX pkgrequires on requires (pkgKey)L eindexrequiresnamerequires CREATE INDEX requiresname ON requires (name) gtableprovidesprovides CREATE TABLE provides ( name TEXT, flags TEXT, epoch TEXT, version TEXT, release TEXT, pkgKey INTEGER )L gindexpkgprovidesprovides CREATE INDEX pkgprovides on provides (pkgKey) triggerremovalspackagesCREATE TRIGGER removals AFTER DELETE ON packages BEGIN DELETE FROM files WHERE pkgKey = old.pkgKey; DELETE FROM requires WHERE pkgKey = old.pkgKey; DELETE FROM provides WHERE pkgKey = old.pkgKey; DELETE FROM conflicts WHERE pkgKey = old.pkgKey; DELETE FROM obsoletes WHERE pkgKey = old.pkgKey; ENDL eindexprovidesnameprovides CREATE INDEX providesname ON provides (name) itableconflictsconflicts CREATE TABLE conflicts ( name TEXT, flags TEXT, epoch TEXT, version TEXT, release TEXT, pkgKey INTEGER )P kindexpkgconflictsconflicts CREATE INDEX pkgconflicts on conflicts (pkgKey) itableobsoletesobsoletes CREATE TABLE obsoletes ( name TEXT, flags TEXT, epoch TEXT, version TEXT, release TEXT, pkgKey INTEGER )P kindexpkgobsoletesobsoletes CREATE INDEX pkgobsoletes on obsoletes (pkgKey)
Le 15/09/2011 18:44, sebastiano@datafaber.net a écrit :
You may be onto something, I've seen that the 5.6 base repo has the sqlite metadata store while the 5.7 base repo hasn't it. But the 20K sqlite file that yum generates on my boxes looks to have at least something related to sqlite inside it rather than the response from a 404 error:
My (wild) guess would be that this file is corrupted but no more downloaded or regenerated, because it's only now a xml file that is now used. But when it exists, it is nevertheless read and crashes...
Alain
On Sep 15, 2011, at 9:16 AM, sebastiano@datafaber.net wrote:
On Thu, 15 Sep 2011 08:42:42 -0700, Craig White wrote:
might be hard to run package-cleanup without having base enabled but I would certainly recommend that you run 'rpm -Va [--nofiles --nodigest]' to identify the broken dependencies - apparently something that the base repository really believes should be there no matter what.
I get no output at all from this command, perhaps I have misunderstood the flags?
---- no output means that you haven't changed any of the files I suppose. Seems odd but possible. ----
[root@picard ~]# rpm -Va --nofiles --nodigest [root@picard ~]#
In the meantime I have found an interesting data point:
[root@picard ~]# yum clean all Loaded plugins: fastestmirror Cleaning up Everything Cleaning up list of fastest mirrors [root@picard ~]# yum update Loaded plugins: fastestmirror Determining fastest mirrors
- base: mirror.ash.fastserv.com
- extras: mirror.net.cen.ct.gov
- updates: mirror.7x24web.net
base | 1.1 kB 00:00 base/primary | 961 kB 00:00 Segmentation fault [root@picard ~]# ll /var/cache/yum/base total 1004K -rw-r--r-- 1 root root 0 Sep 15 19:12 cachecookie -rw-r--r-- 1 root root 1017 Sep 15 19:11 mirrorlist.txt drwxr-xr-x 2 root root 4.0K Jul 10 12:19 packages/ -rw-r--r-- 1 root root 961K Sep 5 13:52 primary.xml.gz -rw-r--r-- 1 root root 20K Sep 15 19:12 primary.xml.gz.sqlite -rw-r--r-- 1 root root 1.2K Sep 5 13:52 repomd.xml
The file /var/cache/yum/base/primary.xml.gz.sqlite is only 20KB, whereas in the "normal" case I'd expect it to be 6.5MB. Somehow, yum is failing to regenerate this file for the base repository, and is crashing with a segmentation fault when trying to read it. I don't know however how to make it generate a correct sqlite file.
---- mv /var/cache/yum/base/primary.xml.gz/sqlite /tmp
and try again I suppose - yes, that file is supposed to be much larger - I suspect that it will create a new 'copy' of that file if it fails to find it.
Craig
Craig White wrote:
mv /var/cache/yum/base/primary.xml.gz/sqlite /tmp
and try again I suppose - yes, that file is supposed to be much larger - I suspect that it will create a new 'copy' of that file if it fails to find it.
Unfortunately yum recreates the same corrupted file, even if I move it out or delete it:
[root@picard ~]# yum clean all
Loaded plugins: downloadonly, fastestmirror, priorities Cleaning up Everything [root@picard ~]# ll /var/cache/yum/base
total 4.0K drwxr-xr-x 2 root root 4.0K Sep 14 21:56 packages/ [root@picard ~]# yum update
Loaded plugins: downloadonly, fastestmirror, priorities Determining fastest mirrors * base: mirrors.ircam.fr * updates: mirrors.ircam.fr base | 1.1 kB 00:00 base/primary | 961 kB 00:02 Segmentation fault [root@picard ~]# ll /var/cache/yum/base total 1000K -rw-r--r-- 1 root root 0 Sep 15 23:43 cachecookie -rw-r--r-- 1 root root 985 Sep 15 23:43 mirrorlist.txt drwxr-xr-x 2 root root 4.0K Sep 14 21:56 packages/ -rw-r--r-- 1 root root 961K Sep 5 13:52 primary.xml.gz -rw-r--r-- 1 root root 20K Sep 15 23:43 primary.xml.gz.sqlite -rw-r--r-- 1 root root 1.2K Sep 5 13:52 repomd.xml [root@picard ~]# rm -f /var/cache/yum/base/primary.xml.gz.sqlite [root@picard ~]# ll /var/cache/yum/base total 980K -rw-r--r-- 1 root root 0 Sep 15 23:43 cachecookie -rw-r--r-- 1 root root 985 Sep 15 23:43 mirrorlist.txt drwxr-xr-x 2 root root 4.0K Sep 14 21:56 packages/ -rw-r--r-- 1 root root 961K Sep 5 13:52 primary.xml.gz -rw-r--r-- 1 root root 1.2K Sep 5 13:52 repomd.xml [root@picard ~]# yum update Loaded plugins: downloadonly, fastestmirror, priorities Loading mirror speeds from cached hostfile * base: mirrors.ircam.fr * updates: mirrors.ircam.fr Segmentation fault [root@picard ~]# ll /var/cache/yum/base total 1000K -rw-r--r-- 1 root root 0 Sep 15 23:43 cachecookie -rw-r--r-- 1 root root 985 Sep 15 23:43 mirrorlist.txt drwxr-xr-x 2 root root 4.0K Sep 14 21:56 packages/ -rw-r--r-- 1 root root 961K Sep 5 13:52 primary.xml.gz -rw-r--r-- 1 root root 20K Sep 15 23:43 primary.xml.gz.sqlite -rw-r--r-- 1 root root 1.2K Sep 5 13:52 repomd.xml
On Sep 15, 2011, at 2:45 PM, Sebastiano Pilla wrote:
Craig White wrote:
mv /var/cache/yum/base/primary.xml.gz/sqlite /tmp
and try again I suppose - yes, that file is supposed to be much larger - I suspect that it will create a new 'copy' of that file if it fails to find it.
Unfortunately yum recreates the same corrupted file, even if I move it out or delete it:
---- post the output of...
cat /etc/yum.repos.d/CentOS-Base.repo
Craig
Craig White wrote:
On Sep 15, 2011, at 2:45 PM, Sebastiano Pilla wrote:
Craig White wrote:
mv /var/cache/yum/base/primary.xml.gz/sqlite /tmp
and try again I suppose - yes, that file is supposed to be much larger - I suspect that it will create a new 'copy' of that file if it fails to find it.
Unfortunately yum recreates the same corrupted file, even if I move it out or delete it:
post the output of...
cat /etc/yum.repos.d/CentOS-Base.repo
[root@picard ~]# cat /etc/yum.repos.d/CentOS-Base.repo # CentOS-Base.repo # # The mirror system uses the connecting IP address of the client and the # update status of each mirror to pick mirrors that are updated to and # geographically close to the client. You should use this for CentOS # updates unless you are manually picking other mirrors. # # If the mirrorlist= does not work for you, as a fall back you can try # the remarked out baseurl= line instead. # #
[base] name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#released updates [updates] name=CentOS-$releasever - Updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#additional packages that may be useful [extras] name=CentOS-$releasever - Extras mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/ gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#additional packages that extend functionality of existing packages [centosplus] name=CentOS-$releasever - Plus mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/centosplus/$basearch/ gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
#contrib - packages by Centos Users [contrib] name=CentOS-$releasever - Contrib mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&rep... #baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/ gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
On 09/15/2011 02:45 PM, Sebastiano Pilla wrote:
Craig White wrote:
mv /var/cache/yum/base/primary.xml.gz/sqlite /tmp
and try again I suppose - yes, that file is supposed to be much larger - I suspect that it will create a new 'copy' of that file if it fails to find it.
Unfortunately yum recreates the same corrupted file, even if I move it out or delete it:
Are you behind a proxy?
I've had issues where a proxy was caching the file and after the repo had updated it's version, the cached version was out of date and resulted in errors.
The fix was typically to issue a wget with the --no-cache directive to request an updated copy or restart the proxy.
wget --no-cache http://...
Josh Miller wrote:
On 09/15/2011 02:45 PM, Sebastiano Pilla wrote:
Craig White wrote:
mv /var/cache/yum/base/primary.xml.gz/sqlite /tmp
and try again I suppose - yes, that file is supposed to be much larger - I suspect that it will create a new 'copy' of that file if it fails to find it.
Unfortunately yum recreates the same corrupted file, even if I move it out or delete it:
Are you behind a proxy?
No, there are no proxies between this box and the Internet (and all the other boxes where the same problem appears aren't behind proxies either).
Based on what I'm seeing, I do not think that yum is downloading a corrupt sqlite database, rather than it is creating a corrupt database all by itself. I have however no definite confirmation of this and I would like to have one before filing a bug against yum.
On Sep 15, 2011, at 3:22 PM, Sebastiano Pilla wrote:
Josh Miller wrote:
On 09/15/2011 02:45 PM, Sebastiano Pilla wrote:
Craig White wrote:
mv /var/cache/yum/base/primary.xml.gz/sqlite /tmp
and try again I suppose - yes, that file is supposed to be much larger - I suspect that it will create a new 'copy' of that file if it fails to find it.
Unfortunately yum recreates the same corrupted file, even if I move it out or delete it:
Are you behind a proxy?
No, there are no proxies between this box and the Internet (and all the other boxes where the same problem appears aren't behind proxies either).
Based on what I'm seeing, I do not think that yum is downloading a corrupt sqlite database, rather than it is creating a corrupt database all by itself. I have however no definite confirmation of this and I would like to have one before filing a bug against yum.
---- I would agree with your assessment but perhaps you can remove/reinstall sqlite but the thing that I don't understand is you said there was no output from rpm -Va which should mean that the sqlite installed verified correctly so there's no reason to be optimistic that removing/reinstalling sqlite will have any positive impact.
Also note - you can file a bug against yum but I suspect that it will go nowhere because there are so many installations that haven't had this issue and yet you suggested that you have multiple systems exhibiting this same problem which suggests that there's something in the methodologies you employ.
Craig
On 16/09/11 08:22, Sebastiano Pilla wrote:
Based on what I'm seeing, I do not think that yum is downloading a corrupt sqlite database, rather than it is creating a corrupt database all by itself. I have however no definite confirmation of this and I would like to have one before filing a bug against yum.
Perhaps some python/sqlite/gzip library used by yum is broken/incompatible. Do you have anything under /usr/local that may be overriding the distro packages? Perhaps an NFS mount that is shared by all affected servers?
Kal
Kahlil Hodgson wrote:
On 16/09/11 08:22, Sebastiano Pilla wrote:
Based on what I'm seeing, I do not think that yum is downloading a corrupt sqlite database, rather than it is creating a corrupt database all by itself. I have however no definite confirmation of this and I would like to have one before filing a bug against yum.
Perhaps some python/sqlite/gzip library used by yum is broken/incompatible. Do you have anything under /usr/local that may be overriding the distro packages? Perhaps an NFS mount that is shared by all affected servers?
Has anyone in this thread - I may have missed some posts last night - suggested yum reinstall yum?
mark
On Fri, 16 Sep 2011 09:15:23 -0400, m.roth@5-cent.us wrote:
Has anyone in this thread - I may have missed some posts last night - suggested yum reinstall yum?
This wasn't suggested yet, so I've tried it and it fails in the same way (not unexpectedly, I would say):
[root@picard ~]# yum reinstall yum Loaded plugins: downloadonly, fastestmirror, priorities Setting up Reinstall Process Determining fastest mirrors * base: mirrors.ircam.fr * updates: mirrors.ircam.fr base | 1.1 kB 00:00 base/primary | 961 kB 00:02 Segmentation fault
Trying again without plugins:
[root@picard ~]# yum clean all Loaded plugins: downloadonly, fastestmirror, priorities Cleaning up Everything Cleaning up list of fastest mirrors [root@picard ~]# yum --noplugins reinstall yum Setting up Reinstall Process base | 1.1 kB 00:00 base/primary | 961 kB 00:01 Segmentation fault
sebastiano@datafaber.net wrote:
On Fri, 16 Sep 2011 09:15:23 -0400, m.roth@5-cent.us wrote:
Has anyone in this thread - I may have missed some posts last night - suggested yum reinstall yum?
This wasn't suggested yet, so I've tried it and it fails in the same way (not unexpectedly, I would say):
Next thought: d/l the rpm for yum, uninstall yum via rpm -e, and then install it via rpm -Ivh
mark
sebastiano@datafaber.net wrote:
On Fri, 16 Sep 2011 09:15:23 -0400, m.roth@5-cent.us wrote:
Has anyone in this thread - I may have missed some posts last night - suggested yum reinstall yum?
This wasn't suggested yet, so I've tried it and it fails in the same way (not unexpectedly, I would say):
Oh, *right*: before you reinstall, try rpm --rebuilddb.
Also, have you seen any errors in messages?
mark
-
Alain Péan -
Always Learning -
Brian Miller -
Craig White -
Craig White -
Denniston, Todd A CIV NAVSURFWARCENDIV Crane -
Fajar Priyanto -
Josh Miller -
Kahlil Hodgson -
Keith Roberts -
m.roth＠5-cent.us -
Nicolas Thierry-Mieg -
Sebastiano Pilla -
sebastiano＠datafaber.net
-
William Hooper