Active Member
Sep 22, 2008
Here's something i don't understand:

In a nutshell:

The basic issue is, if i start slim (the displaymanager) in two different, but very similar ways, that in the one way everything works fine when logging out of xfce, but in the other way the system hangs. I managed to track down the problem and solve (or work around) the problem, but I would love to understand what is causing this. So if anyone got a clue, please let me know.

Basic situation:

I'm booting from SD-card with a modified boot-up process. I disabled the splashscreen and modified my inittab. The modifications make the Pandora boot into a self-written bashscript on tty1, that displays a small menu. On tty2 there is the usual getty-login, so if i want to directly log in as root or user without starting X, I can use alt+left/right to get to tty2.

The menu on tty1 enables me to start certain sub-scripts by pressing a single key. For example i start usb-network/dropbear/rdate by pressing "1", enable wlan (start NetworkManager, wifi-adapter) by pressing "2" or start the display-manager "slim" by pressing "3".

Here is my modified inittab:

# /etc/inittab: init(8) configuration.

# $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

# The default runlevel.


# Boot-time system configuration/initialization script.

# This is run first except when booting in emergency (- B) mode.


# What to do in single-user mode.


# /etc/init.d executes the S and K scripts upon change

# of runlevel.


# Runlevel 0 is halt.

# Runlevel 1 is single-user.

# Runlevels 2-5 are multi-user.

# Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0

l1:1:wait:/etc/init.d/rc 1

l2:2:wait:/etc/init.d/rc 2

l3:3:wait:/etc/init.d/rc 3

l4:4:wait:/etc/init.d/rc 4

l5:5:wait:/etc/init.d/rc 5

l6:6:wait:/etc/init.d/rc 6

# Normally not reached, but fallthrough in case of emergency.


S:2345:respawn:/sbin/getty 115200 ttyS0

# /sbin/getty invocations for the runlevels.


# The "id" field MUST be the same as the last

# characters of the device (after "tty").


# Format:

# <id>:<runlevels>:<action>:<process>


1:2345:respawn:/sbin/getty -n -l /home/root/scripts/autologin-menu 38400 tty1

2:2345:respawn:/sbin/getty 38400 tty2

Regarding the slim-launch, the bash-menu does nothing else than print a menu, read a keystroke and run "/etc/init.d/slim-init start"

The two different ways:

If i start slim from my self-made menu on tty1, login in slim as user so xfce starts and log out again, then I get back to slim. So everything is just as it should be.

If i switch to tty2, log in as root, run "/etc/init.d/slim-init start", then slim shows up and I can log in as user. Xfce starts fine, but when i log out then the system hangs with an empty blue screen (like my background is).

The reason and solution for the hang:

I tracked this issue down to a flaw in the ".xinitrc". Here is the the related snippet:

if [ "$SESSION" == "" ]


exit 0;



SESSION=$(cat /tmp/gui.load)

STOP_SESSION=$(grep $SESSION /etc/pandora/conf/gui.conf | awk -F\; '{print $4}')

For testing purposed I echoed $SESSION when running slim from tty2. It's empty. I don't know why the check in the if-clause does not detect the empty SESSION-variable, but the system-hang results in a miss-configured grep-command-line (see last line of snippet), which makes grep wait for some input and thus the system hangs. I verified this by killing grep from ssh when the system hangs. Once i do that, slim-login shows up again. I can prevent the system-hang by modifying the grep-line (put quotation-marks around $SESSION).

My question:

Has anyone got an idea why the whole thing works if slim is run from tty1, but does not work if initiated from tty2? I don't manage to get behind this. Not even why the if-clause which checks for the empty $SESSION does not work. Despite thinking about it for some while and trying out various things, I have no idea where else i should start to look for the reason.
Last edited by a moderator: