I have a weird problem that I need some help with. Whenever I try to install a program through Yast I get the following error.
Subprocess failed. Error: RPM failed: error: %post(wireshark-1.0.4-2.7.1.i586) scriptlet failed, signal 6.
In this example I was trying to install wireshark. But it does not matter what program it is. The interesting think is even though it pops up an error it still installs the package. It happens in both Yast and using zypper.
The problem is if I were to say want to install a whole bunch of packages like lets say the KDE4 repository. I hope you can see my problem. I would love to give more details if I knew where to look. Any help would be appreciated.
This is from the zypper command to update
Abort, retry, ignore? [A/r/i]: i
Retrieving package libdvdcss-1.2.10-6.1.i686 (10/80), 19.0 K (34.0 K unpacked)
Retrieving: libdvdcss-1.2.10-6.1.i686.rpm [done]
Installing: libdvdcss-1.2.10-6.1 [error]
Installation of libdvdcss-1.2.10-6.1 failed:
(with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: %post(libdvdcss-1.2.10-6.1.i686) scriptlet failed, signal 6
Abort, retry, ignore? [A/r/i]: i
Retrieving package libmodplug0-0.8.6-1.1.i686 (11/80), 156.0 K (336.0 K unpacked)
Retrieving: libmodplug0-0.8.6-1.1.i686.rpm [done (51.0 K/s)]
Installing: libmodplug0-0.8.6-1.1 [error]
Installation of libmodplug0-0.8.6-1.1 failed:
(with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: %post(libmodplug0-0.8.6-1.1.i686) scriptlet failed, signal 6
Abort, retry, ignore? [A/r/i]: i
Retrieving package libvlccore0-0.9.9a-1.2.i586 (12/80), 336.0 K (832.0 K unpacked)
Retrieving: libvlccore0-0.9.9a-1.2.i586.rpm [done (67.2 K/s)]
Installing: libvlccore0-0.9.9a-1.2 [error]
Installation of libvlccore0-0.9.9a-1.2 failed:
(with --nodeps --force) Error: Subprocess failed. Error: RPM failed: error: %post(libvlccore0-0.9.9a-1.2.i586) scriptlet failed, signal 6
I just noticed my post title was wrong the international dead keys did that it should read “Can’t install packages…”
su -
cp -ar /var/lib/rpm /root
rpm --rebuilddb
and try again.
Thanks you for you response. I rebuilt the db as explained below but it does not appear to fix the problem. Any other ideas or things to try. If there is information in a log file that I can give let me know. I have looked into the zypper log but could not find anything to interesting but maybe I don’t know what to look for.
Thanks again and any other ideas are welcome.
As root, run “/sbin/ldconfig”. It should fail, but we need to know why is failing… copy any output it gives.
The first time I ran it, it just returned “Aborted.” I turned on the -v option and this is what I got.
The only place I could paste the output though was on pastebin.com here pastebin - collaborative debugging tool.
The thing is every time you install a package that contains a library the last step is running “/sbin/ldconfig”. Since it fails you receive the error message in YaST.
Feel free to open a bug report at https://bugzilla.novell.com/. But they probably will ask you for a backtrace.
Run “gdb /sbin/ldconfig”. Then inside gdb execute “run”, and when it fails execute “bt”… the output from bt is the important part. If you prefer you can copy it also here.
JonsNotebook:/home/jonw # gdb /sbin/ldconfig
GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux".
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>...
(no debugging symbols found)
(gdb) run
Starting program: /sbin/ldconfig
(no debugging symbols found)
Program received signal SIGABRT, Aborted.
0xffffe430 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe430 in __kernel_vsyscall ()
#1 0x08079ed8 in ?? ()
#2 0x080546be in ?? ()
#3 0x0804b189 in ?? ()
#4 0x0804b4a6 in ?? ()
#5 0x0804a54e in ?? ()
#6 0x0804aa07 in ?? ()
#7 0x0804dd57 in ?? ()
#8 0x080481a1 in ?? ()
(gdb)
Is there supposed to be more than this? Did I do something wrong? Or does this help anyone out in understanding my problem?
I forgot, you have to install glibc-debuginfo and glibc-debugsource to obtain something of use.
These packages are available in the debug repo:
Index of /debug/update/11.1
Got these installed, but output did not change. I might be trashing my root directory and reinstalling today. I would really like to find the cause of this so that if someone else has the same problem they don’t have to reinstall the system. I installed glibc-debuginfo and source as well as gdb-debuginfo and source.
So open that bug report in Novell bugzilla.
Probably there is a bad library that ldconfig has problems parsing. But the thing is that if ldconfig finds a problem it should output a message saying “error processing file XXXX”… not a SIGABORT. So in any case it is a valid bug.
If you want to just “fix” it… if you remember when this problem started you can guess which library is the problematic one and uninstall it. But to understand and fix the real problem a real developer would be needed.
…you can also try with “strace -e trace=file /sbin/ldconfig” to see which file was ldconfig trying to process before the SIGABORT.
Well,RedDwarf you solved it. Running strace showed me two problems and the exact libraries it was dealing with. I fixed them by forcing them to update and after that it worked perfectly.
Thanks everyone for your support on this.
Hi. Just just had about the same problem as in the opening post. The difference is, that in my case packages did not install after “RPM failed: error: bla scriptlet failed, signal foo.” Thanks to your help I found a way out!
gdb said:
(gdb) bt
#0 load_aux_cache (aux_cache_name=0x80c8bff "/var/cache/ldconfig/aux-cache") at cache.c:692
#1 0x0804a9f3 in main (argc=1, argv=0xbffff434) at ldconfig.c:1330
So I decided to delete “/var/cache/ldconfig/aux-cache” and “/etc/ld.so.cache” and rebuilt the rpm database. Now it seems to work.