From Bugzilla Helper: User-Agent: Mozilla/4.7 (Macintosh; U; PPC) rpm core dumps if I try to -i (install), -U (update) or -F (freshen) on any rpm... -q (query) or -e (erase) works fine. Using strace, I was able to determine that seg fault was happening right after /etc/nsswitch.conf was read. Editing /etc/nsswitch.conf to remove my "ldap" directives solved problem. Reproducible: Always Steps to Reproduce: Fresh RH7 instal OpenLDAP rpm package removed OpenLDAP 2.07 installed from source nss_ldap rpm package removed nss_ldap-149 installed from source pam_ldap-105 installed from source Edit /etc/nsswitch.conf and add "ldap" to the "passwd:" line Run rpm and attempt to -U -F or -i some package. Actual Results: seg fault - core dump Expected Results: update, install or freshen of package A few lines of output from strace that led me to find the solution: # strace rpm -Uvh ed-0.2-19.i386.rpm read(13, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1787 read(13, "", 4096) = 0 close(13) = 0 munmap(0x4025d000, 4096) --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++
This is an rpm problem only because rpm is statically linked. The real problem has to do with glibc provided name services on top of ldap/pam modules. Off to ldap for analysis, jakub added to CC list for ideas, bounce it back to me if you think that rpm should do a getpwnam("root") call as early on its execution path as possible to insure that name services are functional.
Try Fedora Core 4.