FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 09-15-2011, 02:18 PM
 
Default Yum segmentation fault updating from 5.6 to 5.7

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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 02:21 PM
Fajar Priyanto
 
Default Yum segmentation fault updating from 5.6 to 5.7

Stupid question.
Can we uninstall yum? And install again using manual rpm.


나의 iPhone에서 보냄
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 03:42 PM
Craig White
 
Default Yum segmentation fault updating from 5.6 to 5.7

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

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 04:16 PM
 
Default Yum segmentation fault updating from 5.6 to 5.7

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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 04:33 PM
Nicolas Thierry-Mieg
 
Default Yum segmentation fault updating from 5.6 to 5.7

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?
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 04:36 PM
Alain Pan
 
Default Yum segmentation fault updating from 5.6 to 5.7

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

--
================================================== ========
Alain Pan - LPP/CNRS
Administrateur Systme/Rseau
Laboratoire de Physique des Plasmas - UMR 7648
Observatoire de Saint-Maur
4, av de Neptune, Bat. A
94100 Saint-Maur des Fosss
Tel : 01-45-11-42-39 - Fax : 01-48-89-44-33
================================================== ========

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 04:37 PM
 
Default Yum segmentation fault updating from 5.6 to 5.7

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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 04:44 PM
 
Default Yum segmentation fault updating from 5.6 to 5.7

On Thu, 15 Sep 2011 18:36:10 +0200, Alain Pan 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)


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 04:44 PM
Craig White
 
Default Yum segmentation fault updating from 5.6 to 5.7

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 09-15-2011, 04:46 PM
Alain Pan
 
Default Yum segmentation fault updating from 5.6 to 5.7

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 Pan - LPP/CNRS
Administrateur Systme/Rseau
Laboratoire de Physique des Plasmas - UMR 7648
Observatoire de Saint-Maur
4, av de Neptune, Bat. A
94100 Saint-Maur des Fosss
Tel : 01-45-11-42-39 - Fax : 01-48-89-44-33
================================================== ========

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 12:55 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org