FAQ
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 at 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 480, ...}) = 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�3757, ...}) = 0
stat64("/var/cache/yum/base/primary.xml.gz", {st_mode=S_IFREG|0644,
st_size�3757, ...}) = 0
stat64("/var/cache/yum/base/primary.xml.gz", {st_mode=S_IFREG|0644,
st_size�3757, ...}) = 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.

Search Discussions

  • Always Learning at Sep 14, 2011 at 6:09 pm

    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

    ?
  • Sebastiano Pilla at Sep 14, 2011 at 6:26 pm

    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 at picard ~]# yum clean all
    Loaded plugins: downloadonly, fastestmirror, priorities
    Cleaning up Everything
    Cleaning up list of fastest mirrors
    [root at 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
  • Always Learning at Sep 14, 2011 at 6:31 pm

    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 at picard ~]# yum clean all
    Loaded plugins: downloadonly, fastestmirror, priorities
    Cleaning up Everything
    Cleaning up list of fastest mirrors
    [root at 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!


    --
    With best regards,

    Paul.
    England,
    EU.
  • Sebastiano Pilla at Sep 14, 2011 at 6:35 pm

    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 at 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 at 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&repo=os
    #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&repo=updates
    #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&repo=extras
    #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&repo=centosplus
    #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&repo=contrib
    #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 at 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.
  • Always Learning at Sep 14, 2011 at 6:48 pm

    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.



    --
    With best regards,

    Paul.
    England,
    EU.
  • Sebastiano Pilla at Sep 15, 2011 at 2:19 am

    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 at 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
  • Keith Roberts at Sep 14, 2011 at 6:49 pm

    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]
    -----------------------------------------------------------------
  • Sebastiano Pilla at Sep 15, 2011 at 2:20 am

    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.
  • Always Learning at Sep 14, 2011 at 7:01 pm

    On Thu, 2011-09-15 at 00:35 +0200, Sebastiano Pilla wrote:

    [root at 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.



    --
    With best regards,

    Paul.
    England,
    EU.
  • Sebastiano at Sep 15, 2011 at 8:01 am

    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 at 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 at picard yum.repos.d]# yum clean all
    Loaded plugins: downloadonly, fastestmirror, priorities
    Cleaning up Everything
    Cleaning up list of fastest mirrors
    [root at 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
  • Craig White at Sep 14, 2011 at 6:18 pm

    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 at 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 480, ...}) = 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�3757, ...}) = 0
    stat64("/var/cache/yum/base/primary.xml.gz", {st_mode=S_IFREG|0644,
    st_size�3757, ...}) = 0
    stat64("/var/cache/yum/base/primary.xml.gz", {st_mode=S_IFREG|0644,
    st_size�3757, ...}) = 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
  • Sebastiano Pilla at Sep 15, 2011 at 2:22 am

    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 at 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 at 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 at 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 at picard yum.repos.d]# yum clean dbcache
    Loaded plugins: downloadonly, fastestmirror, priorities
    0 sqlite files removed
    [root at 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
  • Kahlil Hodgson at Sep 15, 2011 at 2:31 am

    On 15/09/11 16:22, Sebastiano Pilla wrote:
    [root at picard yum.repos.d]# yum clean dbcache
    Loaded plugins: downloadonly, fastestmirror, priorities
    0 sqlite files removed
    [root at 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
  • Fajar Priyanto at Sep 15, 2011 at 2:44 am

    On Thu, Sep 15, 2011 at 2:31 PM, Kahlil Hodgson 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 at picard yum.repos.d]# yum update
    Maybe using Startrek name as server name is not a good idea.
  • Sebastiano at Sep 15, 2011 at 8:10 am

    On Thu, 15 Sep 2011 14:44:59 +0800, Fajar Priyanto wrote:
    On Thu, Sep 15, 2011 at 2:31 PM, Kahlil Hodgson
    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.
  • Sebastiano at Sep 15, 2011 at 9:18 am

    On Thu, 15 Sep 2011 14:10:50 +0200, sebastiano at 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
    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 at 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.
  • Always Learning at Sep 15, 2011 at 9:30 am

    On Thu, 2011-09-15 at 15:18 +0200, sebastiano at datafaber.net wrote:


    Update: yum chose to use another mirror and it failed in the exact
    same way.
    Time for a file check on your disk.



    --
    With best regards,

    Paul.
    England,
    EU.
  • Sebastiano at Sep 15, 2011 at 9:59 am

    On Thu, 15 Sep 2011 14:30:01 +0100, Always Learning wrote:
    On Thu, 2011-09-15 at 15:18 +0200, sebastiano at 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.
  • William Hooper at Sep 16, 2011 at 9:51 am
    On Thu, Sep 15, 2011 at 9:18 AM, 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)?

    --
    William Hooper
  • Sebastiano at Sep 16, 2011 at 11:26 am
    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
  • Alain Péan at Sep 16, 2011 at 12:33 pm

    Le 16/09/2011 17:26, sebastiano at 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

    --
    ==========================================================
    Alain P?an - LPP/CNRS
    Administrateur Syst?me/R?seau
    Laboratoire de Physique des Plasmas - UMR 7648
    Observatoire de Saint-Maur
    4, av de Neptune, Bat. A
    94100 Saint-Maur des Foss?s
    Tel : 01-45-11-42-39 - Fax : 01-48-89-44-33
    ==========================================================
  • Denniston, Todd A CIV NAVSURFWARCENDIV Crane at Sep 16, 2011 at 2:16 pm

    -----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.
  • Craig White at Sep 15, 2011 at 8:57 am

    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 at 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 at 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 at 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 at picard yum.repos.d]# yum clean dbcache
    Loaded plugins: downloadonly, fastestmirror, priorities
    0 sqlite files removed
    [root at 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


    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.
  • Sebastiano at Sep 15, 2011 at 10:18 am

    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 at 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.
  • Fajar Priyanto at Sep 15, 2011 at 10:21 am
    Stupid question.
    Can we uninstall yum? And install again using manual rpm.


    ?? iPhone?? ??
  • Craig White at Sep 15, 2011 at 11:42 am

    On Sep 15, 2011, at 7:18 AM, sebastiano at 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 at 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
  • Sebastiano at Sep 15, 2011 at 12:16 pm

    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 at picard ~]# rpm -Va --nofiles --nodigest
    [root at picard ~]#

    In the meantime I have found an interesting data point:

    [root at picard ~]# yum clean all
    Loaded plugins: fastestmirror
    Cleaning up Everything
    Cleaning up list of fastest mirrors
    [root at 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 at 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.
  • Nicolas Thierry-Mieg at Sep 15, 2011 at 12:33 pm

    sebastiano at 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?
  • Sebastiano at Sep 15, 2011 at 12:37 pm

    On Thu, 15 Sep 2011 18:33:39 +0200, Nicolas Thierry-Mieg wrote:
    sebastiano at 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 at 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.
  • Alain Péan at Sep 15, 2011 at 12:46 pm

    Le 15/09/2011 18:37, sebastiano at datafaber.net a ?crit :
    On Thu, 15 Sep 2011 18:33:39 +0200, Nicolas Thierry-Mieg wrote:
    sebastiano at 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 at 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 - LPP/CNRS
    Administrateur Syst?me/R?seau
    Laboratoire de Physique des Plasmas - UMR 7648
    Observatoire de Saint-Maur
    4, av de Neptune, Bat. A
    94100 Saint-Maur des Foss?s
    Tel : 01-45-11-42-39 - Fax : 01-48-89-44-33
    ==========================================================
  • Sebastiano Pilla at Sep 15, 2011 at 5:49 pm

    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 at picard ~]# yum clean all
    Loaded plugins: downloadonly, fastestmirror, priorities
    Cleaning up Everything
    [root at picard ~]# ll /var/cache/yum/base

    total 4.0K
    drwxr-xr-x 2 root root 4.0K Sep 14 21:56 packages/
    [root at 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 at 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 at picard ~]# rm -f /var/cache/yum/base/primary.xml.gz.sqlite
    [root at 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 at 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 at 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
  • Brian Miller at Sep 15, 2011 at 6:01 pm

    On Thu, 2011-09-15 at 18:37 +0200, sebastiano at 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.
  • Sebastiano Pilla at Sep 15, 2011 at 6:11 pm

    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 at picard ~]# yum clean all
    Loaded plugins: downloadonly, fastestmirror, priorities
    Cleaning up Everything
    [root at picard ~]# yum --noplugins check-update
    base | 1.1 kB 00:00
    base/primary | 961 kB 00:00
    Segmentation fault
  • Alain Péan at Sep 15, 2011 at 12:36 pm

    Le 15/09/2011 18:16, sebastiano at datafaber.net a ?crit :
    [root at 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

    --
    ==========================================================
    Alain P?an - LPP/CNRS
    Administrateur Syst?me/R?seau
    Laboratoire de Physique des Plasmas - UMR 7648
    Observatoire de Saint-Maur
    4, av de Neptune, Bat. A
    94100 Saint-Maur des Foss?s
    Tel : 01-45-11-42-39 - Fax : 01-48-89-44-33
    ==========================================================
  • Sebastiano at Sep 15, 2011 at 12:44 pm

    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 at 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)
  • Alain Péan at Sep 15, 2011 at 12:54 pm

    Le 15/09/2011 18:44, sebastiano at 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

    --
    ==========================================================
    Alain P?an - LPP/CNRS
    Administrateur Syst?me/R?seau
    Laboratoire de Physique des Plasmas - UMR 7648
    Observatoire de Saint-Maur
    4, av de Neptune, Bat. A
    94100 Saint-Maur des Foss?s
    Tel : 01-45-11-42-39 - Fax : 01-48-89-44-33
    ==========================================================
  • Craig White at Sep 15, 2011 at 12:44 pm

    On Sep 15, 2011, at 9:16 AM, sebastiano at 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 at picard ~]# rpm -Va --nofiles --nodigest
    [root at picard ~]#

    In the meantime I have found an interesting data point:

    [root at picard ~]# yum clean all
    Loaded plugins: fastestmirror
    Cleaning up Everything
    Cleaning up list of fastest mirrors
    [root at 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 at 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
  • Sebastiano Pilla at Sep 15, 2011 at 5:45 pm

    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 at picard ~]# yum clean all

    Loaded plugins: downloadonly, fastestmirror, priorities
    Cleaning up Everything
    [root at picard ~]# ll /var/cache/yum/base

    total 4.0K
    drwxr-xr-x 2 root root 4.0K Sep 14 21:56 packages/
    [root at 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 at 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 at picard ~]# rm -f /var/cache/yum/base/primary.xml.gz.sqlite
    [root at 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 at 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 at 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
  • Craig White at Sep 15, 2011 at 6:06 pm

    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
  • Always Learning at Sep 15, 2011 at 6:07 pm

    On Thu, 2011-09-15 at 15:06 -0700, Craig White wrote:


    post the output of...
    It was the same as mine in Centos 5.6, now 5.7

    Paul.
  • Sebastiano Pilla at Sep 15, 2011 at 6:08 pm

    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 at 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&repo=os
    #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&repo=updates
    #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&repo=extras
    #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&repo=centosplus
    #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&repo=contrib
    #baseurl=http://mirror.centos.org/centos/$releasever/contrib/$basearch/
    gpgcheck=1
    enabled=0
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-5
  • Josh Miller at Sep 15, 2011 at 6:11 pm

    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
    Open Source Solutions Architect
    http://itsecureadmin.com/
  • Sebastiano Pilla at Sep 15, 2011 at 6:22 pm

    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.
  • Craig White at Sep 15, 2011 at 6:31 pm

    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
  • Kahlil Hodgson at Sep 15, 2011 at 7:05 pm

    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
  • Mark Roth at Sep 16, 2011 at 9:15 am

    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
  • Sebastiano at Sep 16, 2011 at 9:25 am

    On Fri, 16 Sep 2011 09:15:23 -0400, m.roth at 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 at 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 at picard ~]# yum clean all
    Loaded plugins: downloadonly, fastestmirror, priorities
    Cleaning up Everything
    Cleaning up list of fastest mirrors
    [root at picard ~]# yum --noplugins reinstall yum
    Setting up Reinstall Process
    base | 1.1 kB 00:00
    base/primary | 961 kB 00:01
    Segmentation fault
  • Mark Roth at Sep 16, 2011 at 9:38 am

    sebastiano at datafaber.net wrote:
    On Fri, 16 Sep 2011 09:15:23 -0400, m.roth at 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
  • Mark Roth at Sep 16, 2011 at 9:39 am

    sebastiano at datafaber.net wrote:
    On Fri, 16 Sep 2011 09:15:23 -0400, m.roth at 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

Related Discussions

People

Translate

site design / logo © 2023 Grokbase