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.