On 06/20/2012 11:46 AM, Andras Horvath wrote:
On Wed, 20 Jun 2012 17:18:21 +0200
Andras Horvath <[email protected]> wrote:

On Wed, 20 Jun 2012 10:23:40 -0400
Chris Schanzle <[email protected]> wrote:

On 06/20/2012 10:19 AM, Chris Schanzle wrote:
On 06/20/2012 10:09 AM, Andras Horvath wrote:
On Wed, 20 Jun 2012 10:04:03 -0400
Chris Schanzle<[email protected]>   wrote:

On 06/20/2012 09:55 AM, Andras Horvath wrote:
On Wed, 20 Jun 2012 09:49:04 -0400
Chris Schanzle<[email protected]>    wrote:

On 06/20/2012 07:30 AM, Andras Horvath wrote:
On Wed, 20 Jun 2012 15:26:16 +0400
Oleg Sadov<[email protected]>     wrote:

20/06/2012 08:35 +0200, Andras Horvath wrote:
On Tue, 19 Jun 2012 19:05:49 +0200
Andras Horvath<[email protected]>     wrote:

On Tue, 19 Jun 2012 09:59:26 -0700
Akemi Yagi<[email protected]>     wrote:

On Tue, Jun 19, 2012 at 9:55 AM, Andras
Horvath<[email protected]>   wrote:

How could I run a self check on all packages with rpm to
see if all the files are there and their hashes match
too?

Run 'rpm -V' against the packages.

If you get any output, then there is (are) some
mismatch(es). Man page has the explanation for the
output.

Akemi

I ran it against python and yum packages, but all are ok.

Andras

If I restore "/usr/lib64/python2.6" directory from my
backup, then yum works again just fine. I can run "yum
update" too. But when I run "yum reinstall python", then
after the package install everything goes wrong again.

Any idea what could cause this? This is a simple case
installing a package.

Required cElementTree module is actually located in
xml.etree (/usr/lib64/python2.6/xml/etree/cElementTree.py
from python rpm), standalone cElementTree is not included
in distro. Try to check access to the module at python
interactive session:

from xml.etree import cElementTree

Andras

$ python
Python 2.6.6 (r266:84292, Jun 18 2012, 09:57:52)
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
from xml.etree import cElementTree
Traceback (most recent call last):
       File "<stdin>", line 1, in<module>
       File "/usr/lib64/python2.6/xml/etree/cElementTree.py",
line 3, in<module>    from _elementtree import *
ImportError: /usr/lib64/python2.6/lib-dynload/pyexpat.so:
symbol XML_SetHashSalt, version EXPAT_2_0_1_RH not defined in
file libexpat.so.1 with link time reference



Andras

What does this output?

rpm -q expat

Do you have a yum update pending for it?

rpm -q --changelog expat | head
* Fri Apr 27 2012 Joe Orton<[email protected]>    - 2.0.1-11
- use symbol version for XML_SetHashSalt (CVE-2012-0876,
#816306)

Thanks for you help. The output of "rpm -q expat" is:

expat-2.0.1-11.el6_2.x86_64

I'm supposed to have all the updates installed to date.

Andras

Hmm.  Well, on a fully updated CentOS 6 system (sorry, I
switched back), I have:

rpm -q expat
expat-2.0.1-11.el6_2.x86_64
expat-2.0.1-11.el6_2.i686


python
Python 2.6.6 (r266:84292, Dec  7 2011, 20:48:22)
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
from xml.etree import cElementTree
^D


Could this be an issue with prelink?  Try unprelinking the
world.

# prelink -au
prelink: /usr/lib64/xulrunner-2/libxul.so: DT_JMPREL tag not
adjacent to DT_RELA relocations
prelink: /usr/lib64/sunbird-1.0b2pre/xpcshell: Could not find one
of the dependencies
prelink: /usr/lib64/sunbird-1.0b2pre/sunbird-bin: Could not find
one of the dependencies
prelink: /usr/lib64/xulrunner-2/libmozsqlite3.so: DT_JMPREL tag
not adjacent to DT_RELA relocations

Unfortunately problem still persists.

Andras


Running low on ideas...

Assuming your locate db is up to date (if not,
run /etc/cron.daily/mlocate.cron ), compare your results of:

locate libexpat.so

I have several others, but my LD_LIBRARY_PATH is empty:

locate libexpat.so
/lib/libexpat.so.1
/lib/libexpat.so.1.5.2
/lib64/libexpat.so.1
/lib64/libexpat.so.1.5.2
/local/opt/matlab-2012a/bin/glnxa64/libexpat.so.1
/local/opt/matlab-2012a/bin/glnxa64/libexpat.so.1.5.0
/usr/lib/vmware/lib/libexpat.so.0
/usr/lib/vmware/lib/libexpat.so.0/libexpat.so.0
/usr/lib/vmware/ovftool/libexpat.so.0
/usr/lib/vmware-installer/1.1/lib/lib/libexpat.so.0
/usr/lib/vmware-installer/1.1/lib/lib/libexpat.so.0/libexpat.so.0
/usr/lib64/libexpat.so
/usr/lib64/libexpat.so.0
/usr/lib64/libexpat.so.0.5.0


env | grep LD

One final check:

strace -e file python -c 'from xml.etree import cElementTree' 2>&1 |
grep libexpat.so open("/lib64/libexpat.so.1", O_RDONLY)  = 5

locate libexpat.so

/lib/libexpat.so.1
/lib/libexpat.so.1.5.2
/lib64/libexpat.so.1
/lib64/libexpat.so.1.5.2
/usr/lib64/libexpat.so

As I see I'm missing these compared to you:

/usr/lib64/libexpat.so.0
/usr/lib64/libexpat.so.0.5.0

I'll try to reinstall it then.

To the other:

$ strace -e file python -c 'from xml.etree import cElementTree' 2>&1
| grep libexpat.so open("/lib/libexpat.so.1", O_RDONLY)    = 5
ImportError: /usr/lib64/python2.6/lib-dynload/pyexpat.so: symbol
XML_SetHashSalt, version EXPAT_2_0_1_RH not defined in file
libexpat.so.1 with link time reference

This seems to be the cause of all this I guess. Any other idea on how
to resolve this specific one? :)

Thanks for you time!

When I restore my /usr/lib64/python2.6 directory, then all the above
commands work fine, no error messages regarding expat. I can even
reinstall expat, no problem.

But when I run "yum reinstall python", then everything goes wrong. I
don't understand why. What is sure, that python has its expat bindings
inside this directory, and they might change. So can there be some
version mismatch issue here?

But if libexpat.so doesn't change, then only pyexpat.py must have
something to do with addressing the lib wrongly.

Andras

This is confusing.  Stepping back a bit, you are obviously x86_64.
Your notfound /usr/lib64/libexpat.so.0 shouldn't be an issue since my python 
isn't loading that.  But anyway:
  rpm -qf /usr/lib64/libexpat.so.0
  compat-expat1-1.95.8-8.el6.x86_64

You wrote:
$ strace -e file python -c 'from xml.etree import cElementTree' 2>&1
| grep libexpat.so
 open("/lib/libexpat.so.1", O_RDONLY)    = 5

Why is python, which should be 64-bit python-2.6.6-29.el6_2.2.x86_64, trying to 
load the 32-bit library?

I'd poke around looking at 32/64 bit issues.  I'm no python expert...could you 
have something specific in your login directory, or PYTHONPATH/PYTHONHOME in 
your environment?
env | grep PYTHON

Do you have python.i686 installed?  I don't.

Reply via email to