From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010917
Description of problem:
rpm core dumps when trying to install of update a package. It started to
happen after doing the following command:
rpm -Uvh NVIDIA_kernel-1.0-1541.i386.rpm --force
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rpm -Uvh <package> --force
2. rpm -Uvh <other-package>
Actual Results: rpm core dumps everytime, when installing (-ivh) or
Expected Results: packages should be installed cleanly.
I tried doing an rpm --rebuilddb, but this hasn't worked. I also conducted
an experiment, where I created a new rpm database in an alternate location.
I then proceeded to install a package using the new database, instead of
the old, and it still core dumped. I also updated rpm to version 4.0.3,
using rpm2cpio, and cpio. I then did an rpm --rebuilddb again, but
installing packages stills core dumps.
Some other things that slipped my mind are that I can remove packages with rpm
-e. I can also install packages that don't seem to have an preinstall or
postinstall scripts, although I don't know whether this is true in all cases.
One example is the Mesa source package.
One other thing that I have learned on this problem. When using the up2date
application to apply updates from Red Hat Network, everything works fine! I
don't understand why up2date can sucessfully install rpm's, but it core dumps at
the command line. Below is some gdb output from one of the cores:
(gdb) core-file core
Core was generated by `rpm -Uvh mozilla-0.9.5-0.i386.rpm
Program terminated with signal 11, Segmentation fault.
#0 0x4062e50a in ?? ()
#0 0x4062e50a in ?? ()
#1 0x4062ef3f in ?? ()
#2 0x4060414c in ?? ()
#3 0x406347c3 in ?? ()
#4 0x4060462e in ?? ()
#5 0x40605491 in ?? ()
#6 0x406347c3 in ?? ()
#7 0x4060533c in ?? ()
#8 0x405e677f in ?? ()
#9 0x405e70e6 in ?? ()
#10 0x405e808c in ?? ()
#11 0x405e9aa7 in ?? ()
#12 0x4077bf17 in ?? ()
#13 0x4077c0e7 in ?? ()
#14 0x4077b2a2 in ?? ()
#15 0x4076eb81 in ?? ()
#16 0x4076ed13 in ?? ()
#17 0x40768a61 in ?? ()
#18 0x4076985e in ?? ()
#19 0x40769aba in ?? ()
#20 0x4076a451 in ?? ()
#21 0x0813fa3e in ?? ()
#22 0x0813f613 in ?? ()
#23 0x08061c46 in ?? ()
#24 0x08060d40 in ?? ()
#25 0x08061af3 in ?? ()
#26 0x08071454 in ?? ()
#27 0x08066732 in ?? ()
#28 0x08049878 in ?? ()
#29 0x081180c2 in ?? ()
Are you using LDAP passwords? If so start up nscd.
Yes, I am using LDAP passwords. I started nscd and tried to install some
postgresql rpms, and the install hung after the preparing... [100%].
One more thing. After doing a Ctrl-C, to stop the rpm installation that was
hung, I couldn't do anything else on my machine. I couldn't start another
terminal window, I couldn't start another GUI application, nothing. In fact, I
had to reboot to clear everything up. Of course, the difference after rebooting
is the nscd daemon is no longer running.
Good. Now try doing
If you're going to use LDAP, then you *must* run nscd or
statically linked binaries like rpm will core dump.
Everything still just hung, even after removing the __db* files from
/var/lib/rpm. Based on your comment about nscd, I looked at nsswitch.conf. In
it I had changed the passwd, shadow & group lines to have ldap first in the
sequence instead of last. I started, for some unknown reason, to not be able to
login as root with the ldap password. I switched this back to having ldap last,
restarted nscd, and tried to install the postgresql rpms, and they installed
without a hitch! Now we will see whether everything else continues to work.
OK, this problem seems to be related to LDAP pam modules, and
appears resolved. Please reopen if I'm wrong.