I've got a CentOS 6.1 x86_64 VM running atop CentOS 6.1 x86_64 KVM
host. The VM is in production, so any fix needs to be fairly
non-intrusive.
In the VM, yum consistently segfaults when reading non-base
repositories. The problem appears to be related to the faulty creation
of
/var/cache/yum/x86_64/<<reponame>>/primary.xml.gz.sqlite
The latest installment of this problem is related to the 6.1 cr
repository, but it's happened with other non-base repos in the past.
Steps to duplicate, fix, and re-duplicate the problem:
1. "yum clean all && yum update" will segfault. strace shows
that the SIGSEGV is received while doing work in the cr
repository.
2. Run "yum clean all && yum update" on a different CentOS machine
that uses the exact same yum repositories. The copy
/var/cache/yum/x86_64/6/cr/primary.xml.gz.sqlite from the
working machine to the broken one.
3. "yum update" on the broken machine works flawlessly!
4. "yum clean all && yum update" on the broken machine (which
removes and tries to rebuild the .sqlite file) will segfault
once again.
The primary.xml.gz.sqlite file that gets created on the broken VM is
quite a bit smaller than that on all my working machines.
On the broken machine, it looks like
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE db_info [...];
CREATE TABLE packages [...];
# several more CREATE TABLE commands
CREATE TRIGGER removals [...];
COMMIT;
On all my working machines, it looks like
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE db_info [...];
INSERT INTO "db_info" [...];
CREATE TABLE packages [...];
# several more CREATE TABLE commands
CREATE TRIGGER removals [...];
CREATE INDEX packagename [...];
# several more CREATE INDEX commands
COMMIT;
The working machine all do an INSERT into db_info and create several
indexes; the broken machine does not. Otherwise, the sql statements
are identical.
On the broken machine, I've done
yum reinstall sqlite
yum reinstall python
yum reinstall yum\*
But the outcome is the same.
The problem is limited to this VM. Other VMs on the same host have no
such difficulties.
Anyone have a clue?
--
Paul Heinlein <> heinlein at madboa.com <> http://www.madboa.com/