-   Slackware - Installation (
-   -   glibc-solibs-2.15-x86_64-7 seg fault: core dumped (

hpfeil 04-27-2013 11:29 AM

glibc-solibs-2.15-x86_64-7 seg fault: core dumped
Installing Slack14 x86_64 on a new drive using the extracted slackware64 sources from slackware64-14.0-install-dvd.iso, using `/mnt/slack64/sbin/installpkg --root /mnt/slack64 --md5sum $1`. Starting with the "a" set, everything went fine until:

Executing install script for glibc-solibs-2.15-x86_64-7.txz.
install/ line 55: 11689 Segmentation fault (core dumped) rm -f `basename $file .incoming`
install/ line 55: 11693 Segmentation fault (core dumped) cp -a $file `basename $file .incoming`
... for 68 lines until PID 12194, when I killed it.
Looking at, I don't think it's a smart idea to run ldconfig on the host system when doing an install on a new system. Since it's a sh script run from bash, doesn't code between the parentheses run as a sub-shell?

/sbin/ldconfig -l lib64/*.incoming 2> /dev/null
# Finally, rename them and clean up:
( cd lib64
## next line is 55, where something strange is going on
for file in *.incoming ; do
rm -f `basename $file .incoming`
cp -a $file `basename $file .incoming`
/sbin/ldconfig -l `basename $file .incoming`
rm -f $file
The ldconfig command links to the host putting the library into the host filesystem thus:
/lib64/ -> ../../lib64/
The host is running kernel 3.8.8, these libraries are linked to the slackware64/a kernel, 2.6.32.
`sudo /sbin/ldconfig -p | grep libBrokenLocal` (libc6,x86-64, OS ABI: Linux 2.6.32) => /lib64/ (libc6,x86-64, OS ABI: Linux 2.6.32) => /lib64/
Clearly that's not what I intended using the --root option to installpkg.

Sorry, I know the assumption is that the dummy behind the keyboard is supposed to use the install script from a Live DVD. This worked yesterday, using a host with slackware-current. I started over today because I had /boot on its own partition, which confused the startup program and is a configuration not sanctioned by the FSF. No problem for me, just thought someone might want to know.
One more thing: The install iso contains a/devs-2.3.1-noarch-25.txz, which was replaced with udev. No worries, /dev will get udev's devfs mounted on top of it.

willysr 04-28-2013 01:33 AM

It seems you mixed up between slackware-current and slackware-stable

GazL 04-28-2013 06:50 AM


Originally Posted by willysr (Post 4940313)
It seems you mixed up between slackware-current and slackware-stable

I think he's possibly using a host running current to install 14.0 packages to /mnt using installpkg's -root option.

I see what he's getting at. "/sbin/ldconfig -l lib64/*.incoming 2> /dev/null" in the will update the hosts config.

When -root is used it's probably best to either not run ldconfig at all in, or maybe use "ldconfig -r $PWD -l lib64/*.incoming 2> /dev/null" but I've not looked at this too deeply so there may be other considerations.

Obviously, $PWD would need to be captured before any sub-shell changed directory, so something like:

(  ROOT="$PWD"
    cd lib64
    for file in *.incoming ; do
      rm -f `basename $file .incoming`
      cp -a $file `basename $file .incoming`
      /sbin/ldconfig -r "$ROOT" -l `basename $file .incoming`
      rm -f $file

P.S. I kind of like having the old devices package still around - it's a good fall-back in case bad things ever happen to udev.

hpfeil 04-28-2013 10:06 AM

I'm so embarrassed. I was trying to avoid mentioning that the host system I had tried was Fedora18 with all current updates. Post mortem analysis: after I had started this string, I checked dmesg | tail. Each call to rm and cp had thrown a segfault. Fedora18, as I'm sure you have heard rumours to the effect, is an alpha/beta-test distribution for Redhat. It takes systemd a good 15-20 seconds to spawn a new tty. Each segfault was caused by a critical shortage of ttys that weren't being spawned fast enough to process all 23 files in *.incoming. No problem using a Slackware Current host.

I'm condemned to using a $200 used box because my four Opteron chips fried when the too-heavy fan/heat-pipes worked the mounting bracket loose after a couple of years with the motherboard mounted vertically. This old wheezer has a 300W power supply, so I have to connect only a couple of sata drives at a time, which is why the side panel is being used to cool the live drives sitting on it. Congenital indolence, from which I suffer occasionally, led me to use the Fedora drive as the host because I was using it to try to figure out why my USB2 scanner and camera were recognized, but the software couldn't find them. My main drive, Slackware-current, is starting to accumulate "Currently unreadable (pending) sector" errors from smartd, zero to three during the past week.

Everything was working as advertised in Slackware13.1, using manually-created /devs and hal. 13.7 to 14 to current somehow lost usb devices along the way. BTW, I had to do all the troubleshooting from a text console. I'm used to using gpm to copy/paste long strings with my mouse, but there's a disturbing comment in /lib/systemd/system/gpm.service:

# This could probably benefit from socket activation, but honestly I think it
# is time for gpm to go away, and hence I am not planning to spend the time
# to add socket activation here.

I only occasionally go over to the Dark Side because I couldn't use gnome utilities and games in XFCE4. With the Gnome-SlackBuild project abandoned in favor of replicating most of the gnome2 code from 13.1, I was in the process of trying to compile the mate-games when them pesky unreadable sectors started showing up, which means impending doom for the terabyte drive. But I digress.

Thanks for helping me, Willy and Gaz! Marking this solved-won't-fix.

All times are GMT -5. The time now is 05:03 AM.