Bug 405261 - can't use yum after latest yum update
can't use yum after latest yum update
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
i686 Linux
low Severity urgent
: ---
: ---
Assigned To: Jeremy Katz
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-11-29 19:17 EST by Konstantin Svist
Modified: 2014-01-21 18:00 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-01 20:37:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
List of last several packages that have been installed (3.96 KB, text/plain)
2007-11-29 19:17 EST, Konstantin Svist
no flags Details

  None (edit)
Description Konstantin Svist 2007-11-29 19:17:01 EST
Description of problem:
Trying to use yum now results in the following message:

There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

   /usr/lib/python2.5/lib-dynload/cPickle.so: undefined symbol:

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
2.5 (trunk, Nov 28 2007, 11:58:41)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)]

If you cannot solve this problem yourself, please go to
the yum faq at:

Last-installed packages should be listed in attachment (output of "rpm -qa --last")

How reproducible:
Every time

Steps to Reproduce:
1. Run any yum command, e.g. 'yum' or 'yum list'

Additional info:
Running python from command line and trying to import cPickle results in same error.

Custom version of Python 2.5 is installed into /usr/local/ - but using
executable extension option (which names the executable "python.foobar" instead
of "python").
Running custom version of python and importing cPickle works correctly (no error
is displayed).

P.S. not sure which package to file against, filing against yum for now.
Comment 1 Konstantin Svist 2007-11-29 19:17:01 EST
Created attachment 273441 [details]
List of last several packages that have been installed
Comment 2 Seth Vidal 2007-11-30 10:56:31 EST
right - your custom python version is polluting the library module paths for the
system python.

try this
python -c "import sys; print sys.path"

Comment 3 Konstantin Svist 2007-11-30 12:27:57 EST
[root@mireille ~]# python -c "import sys; print sys.path"
['', '/usr/lib/python25.zip', '/usr/lib/python2.5',
'/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk',
'/usr/lib/python2.5/lib-dynload', '/usr/lib/python2.5/site-packages',

By the way, that doesn't change even if I explicitly set

Someone suggested I reinstall python-libs, but that didn't help either :(
Comment 4 Konstantin Svist 2007-12-01 02:44:18 EST
Update: I've discovered how to make the problem go away.
Apparently, I needed to [re]move files /usr/local/lib/libpython2.5.so and
/usr/local/lib/libpython2.5.so.1.0 to make the stock python work.

I've checked that:
* $LD_LIBRARY_PATH was not set
* I was running /usr/bin/python
* "import sys; print sys.path" doesn't mention any /usr/local directories
* "import <some package that's only available in stock python>" works
* "import <some package that's only available in custom python>" doesn't work

So, it's really surprising that /usr/local/lib/libpython2.5.so would be used.

Is this a bug or a "feature"?
Comment 5 Konstantin Svist 2007-12-01 20:37:15 EST
update: found that /usr/local/lib exists in my /etc/ld.so.conf

Note You need to log in before you can comment on or make changes to this bug.