Roger Leigh wrote:
"Thomas H. George" <lists@tomgeorge.info> writes:When I open a terminal from an X-Window it does not accept entries and after a minute displays a message, "There was an error creating a child process for this terminal." In some cases there was a message like failed to create child process x-terminal-emulator. There is in fact a soft link from x-terminal-emulator in /usr/bin to /etc/alternatives/x-terminal-emulator which is in turn a soft link to /usr/bin/gnome-terminal.wrapper. PATH includes bin and sbin in /, /usr and /usr/local.I installed this chrooted version of Etch as described in Debian Reference - Debian tips, sections 8.6.35.1-4. From the console (Ctl-Alt-F8) I can enter commands and edit files with no problems. From X-Window (CTL-ATL-F9) I can launch programs - example: Gimp2.2 - and access the internet - Gnome Web Browser 2.14.3 - but I can't do any system administration or open a working terminal window.Perhaps there is an ownership or permission issue that is the root of the terminal problem? If so, I haven't been able to pin it down.You need to have /dev/pts mounted inside the chroot in order to set up the pseudo-terminal master/slave pair needed by the terminal emulator to run a virtual terminal device.
I have recently been experimenting with a similar setup (running etch
but with a chrooted testing - lenny - installation on a separate
partition). I have the same problem as the OP even though I have mounted
(--bind) /dev from the 'real' installation. I don't understand why this
isn't good enough - shouldn't this bring in /dev/pts as well? Or is
there some reason why you have to mount that explicitly as well?
Also, I have written a short script to automatically prepare and begin a
chrooted session, which I have pasted below both in case anyone else
finds it useful, and for constructive criticism from anyone with more
skill than I have with this stuff who wants to comment. To use the
script, first edit the line 'JAIL_ROOT=/jail' to point to your chrooted
installation, then save it in /usr/local/bin on the non-chrooted system.
Then start a root terminal session as usual, and call the script. It
mounts /tmp/.X11-unix from the host system into the chrooted one,
allowing you to start X applications from the command line and have them
appear on your normal X display (probably best to do 'su username' from
the chrooted prompt first if you want to do this.)
andy
#!/bin/bash
#
# testing-shell - start a root shell chrooted to the testing release.
# must be run as root
JAIL_ROOT=/jail # modify this to point to your chrooted directory.
PROGRAM=$0
if [ `id -u` -ne 0 ] ; then
echo "Must be run as root"
exit
fi
if [ `ps ax | grep $PROGRAM | grep -v grep | wc -l` -gt 2 ] ; then
# n.b. -gt 2 above is because the process forks so you get 2 lines
in the output.
echo "${PROGRAM##*/} seems to be running already - not preparing the
chrooted system."
else
echo "Preparing the chrooted system..."
mount /dev $JAIL_ROOT/dev -o bind
mount proc -t proc $JAIL_ROOT/proc
mount /tmp/.X11-unix $JAIL_ROOT/tmp/.X11-unix -o bind
cp /tmp/.X0-lock $JAIL_ROOT/tmp
fi
cp /etc/hosts $JAIL_ROOT/etc/hosts
echo "--- entering chrooted system --->"
echo
chroot $JAIL_ROOT /bin/bash
if [ `ps ax | grep $PROGRAM | grep -v grep | wc -l` -gt 2 ] ; then
echo "${PROGRAM##*/} still running - not taking down chrooted system."
else
# last one out clean up...
echo "Taking down the chrooted system..."
umount $JAIL_ROOT/dev
umount $JAIL_ROOT/proc
umount $JAIL_ROOT/tmp/.X11-unix
rm $JAIL_ROOT/tmp/.X0-lock
fi
echo "<--- returned to root system ---"
echo