> There's plenty of room in each partition (ext3): that's cool, thanks for checking
> I've watch top and installpkg is never the topmost running application; in > fact, there are usually two processes running and both are sleeping (S+) > which I did not think was appropriate. > > If anyone can suggest other tests or information that will help diagnose > and resolve this situation I'll quickly provide the results. Strategy A is to observe more closely what the system is doing. Start the install, wait ten mins, and do 'vmstat 5 20' and 'iostat 5 20' and 'ps -efl' to see what's happening. Look for the tree of pids that starts with installpkg. This might reveal something like an i/o redirection that has gone wrong so that it's waiting forever for input (you might also want to try typing ctrl/d on the controlling terminal in case that's what's up). Strategy B is to think it through from the other end. Either installpkg itself has gone off on one, or it's the doinst.sh. Does the installpkg command print 'Executing install script for texlive-20130530-i486-2_SBo.tgz' before it seems to stop? If so, we're looking at a doinst.sh problem. The texlive doinst.sh has these three lines: chroot . /usr/bin/mktexlsr 1>/dev/null 2>/dev/null chroot . /usr/bin/updmap-sys --nohash --syncwithtrees 1>/dev/null 2>/dev/null chroot . /usr/bin/fmtutil-sys --all 1>/dev/null 2>/dev/null I'm not sure what these commands do, but it might be interesting to remove '1>/dev/null 2>/dev/null' from them to see what shows up when the package is installed. (Maybe you could shortcircuit the need to rebuild the whole package by using explodepkg, editing install/doinst.sh, and making a new package with makepkg). Anybody else have some tips? -D. _______________________________________________ SlackBuilds-users mailing list [email protected] http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - http://slackbuilds.org/faq/
