Red Hat Bugzilla – Bug 84187
Segmentation fault when erasing old kernel
Last modified: 2007-04-18 12:51:06 EDT
Description of problem:
I get a segmentation fault when I try and remove an old kernel. I do not get a
Version-Release number of selected component (if applicable):
All the time.
Steps to Reproduce:
1.rpm -e kernel-2.4.18-18.7.x.
Old kernel should be removed.
A "rpm --rebuilddb" with rpm-4.1 should fix your problem.
Otherwise, please reopen this bug, and give me a pointer
(i.e. URL, attachments won't work) to a tarball of your
tar czvf /tmp/rpmdb-84187.tar.gz rpm
This is turning into a dependency nightmare. I have downloaded the following RPMs:
But I still have the following failed dependencies:
gnome-python2-bonobo is needed by gnome-python2-1.99.11-8
libart_lgpl_2.so.2 is needed by gnome-python2-1.99.11-8
libbonobo-2.so.0 is needed by gnome-python2-1.99.11-8
libbonobo-activation.so.4 is needed by gnome-python2-1.99.11-8
libbonoboui-2.so.0 is needed by gnome-python2-1.99.11-8
libgconf-2.so.4 is needed by gnome-python2-1.99.11-8
libgnome-2.so.0 is needed by gnome-python2-1.99.11-8
libgnomecanvas-2.so.0 is needed by gnome-python2-1.99.11-8
libgnomeui-2.so.0 is needed by gnome-python2-1.99.11-8
libgnomevfs-2.so.0 is needed by gnome-python2-1.99.11-8
liblinc.so.1 is needed by gnome-python2-1.99.11-8
libORBit-2.so.0 is needed by gnome-python2-1.99.11-8
libgnomecanvas >= 2.0.0 is needed by gnome-python2-canvas-1.99.11-8
pygtk2 >= 1.99.11 is needed by gnome-python2-canvas-1.99.11-8
libart_lgpl_2.so.2 is needed by gnome-python2-canvas-1.99.11-8
libgnomecanvas-2.so.0 is needed by gnome-python2-canvas-1.99.11-8
pygtk2 >= 1.99.12-6 is needed by rhn-applet-2.0.0-28
libgnomeui >= 2.0.3-1 is needed by rhn-applet-2.0.0-28
libgnome >= 2.0.2-5 is needed by rhn-applet-2.0.0-28
gnome-python2-gtkhtml2 is needed by rhn-applet-2.0.0-28
libart_lgpl_2.so.2 is needed by rhn-applet-2.0.0-28
libbonobo-2.so.0 is needed by rhn-applet-2.0.0-28
libbonobo-activation.so.4 is needed by rhn-applet-2.0.0-28
libbonoboui-2.so.0 is needed by rhn-applet-2.0.0-28
libgconf-2.so.4 is needed by rhn-applet-2.0.0-28
libgnome-2.so.0 is needed by rhn-applet-2.0.0-28
libgnomecanvas-2.so.0 is needed by rhn-applet-2.0.0-28
libgnomeui-2.so.0 is needed by rhn-applet-2.0.0-28
libgnomevfs-2.so.0 is needed by rhn-applet-2.0.0-28
liblinc.so.1 is needed by rhn-applet-2.0.0-28
libORBit-2.so.0 is needed by rhn-applet-2.0.0-28
librpm-4.0.4.so is needed by gnorpm-0.96-14
librpm-4.0.4.so is needed by ucd-snmp-4.2.5-7.73.0
librpmdb-4.0.4.so is needed by gnorpm-0.96-14
librpmdb-4.0.4.so is needed by ucd-snmp-4.2.5-7.73.0
librpmio-4.0.4.so is needed by gnorpm-0.96-14
librpmio-4.0.4.so is needed by ucd-snmp-4.2.5-7.73.0
I don't want to upgrade my whole system just to get rpm-4.1. I have rebuilt the
database with rpm-4.0.4 and I have put the tar file you requested at:
The md5sum is:
I don't know if that helps you or not.
There's nothing wrong with your database, so something
else is going on.
Are you using LDAP passwords? If so, then you need to
run nscd to avoid a segfault with statically linked
executables like /bin/rpm.
Can you upgrade/erase/install other packages?
Do other rpm commands "work"?
SOme other (i.e. not rpmdb) common factor needs to be identified.
I am not using LDAP passwords. I can install packages but I can't upgrade or
erase packages. I haven't done an exhaustive survey of all the rpm commands
but, of the commands I commonly use, only erase is broken.
If I can build RPM from source I should be able to determine exactly where the
segfault is happening. However, I want to avoid installing this test RPM over
the current rpm binary. Can you give me a source RPM that turns debugging on
and installs to another location? If you build a source RPM, does it keep the
build tree or does it remove it?
Another thing. I just upgraded the shadow-utils package using up2date. I don't
know how this works if rpm isn't working.
I still need some hint other than rpmdb to attempt
to reproduce this problem.
I don't have a src rpm with debugging symbols. There
are symbols aavailable by doing
after rebuilding. Otherwise, -vv output is often
enough to characterize a problem.
Created attachment 90774 [details]
I took a hint from bug 86047 and am attaching the strace file from:
strace -o /tmp/strace.out rpm -evv kernel-2.4.18-18.7.x
I will attach the output from rpm in a separate attachment.
Created attachment 90775 [details]
This was apparently fixed by the fix for bug 86047.