Visit Jeremy's Blog.
Go Back > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - Installation
User Name
Slackware - Installation This forum is for the discussion of installation issues with Slackware.


  Search this Thread
Old 04-27-2013, 11:29 AM   #1
Registered: Nov 2010
Location: Tucson, Arizona US
Distribution: Slackware Current, custom kernel, amd64, Beyond LinuxFromScratch
Posts: 130
Blog Entries: 1

Rep: Reputation: Disabled
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.
Old 04-28-2013, 01:33 AM   #2
Senior Member
Registered: Jul 2004
Location: Jogja, Indonesia
Distribution: Slackware-Current
Posts: 3,595

Rep: Reputation: 931Reputation: 931Reputation: 931Reputation: 931Reputation: 931Reputation: 931Reputation: 931Reputation: 931
It seems you mixed up between slackware-current and slackware-stable
Old 04-28-2013, 06:50 AM   #3
Senior Member
Registered: May 2008
Posts: 4,312
Blog Entries: 7

Rep: Reputation: 1760Reputation: 1760Reputation: 1760Reputation: 1760Reputation: 1760Reputation: 1760Reputation: 1760Reputation: 1760Reputation: 1760Reputation: 1760Reputation: 1760
Originally Posted by willysr View Post
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.

Last edited by GazL; 04-28-2013 at 07:56 AM.
Old 04-28-2013, 10:06 AM   #4
Registered: Nov 2010
Location: Tucson, Arizona US
Distribution: Slackware Current, custom kernel, amd64, Beyond LinuxFromScratch
Posts: 130
Blog Entries: 1

Original Poster
Rep: Reputation: Disabled
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.


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Segmentation fault (core dumped) Khaled ELmishad Programming 1 06-16-2012 11:13 AM
GLibC 2.5 emerge: seg. fault? tulcod Linux - General 4 02-08-2007 09:19 AM
Segmentation Fault (core dumped) newuser455 Linux - Software 3 08-28-2004 02:39 PM
Segmentation fault (core dumped) hasanaydin Linux - General 0 03-27-2002 07:47 AM
what is segmantation fault (core dumped) jolly Linux - General 5 10-01-2001 09:03 AM

All times are GMT -5. The time now is 02:37 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration