Cannot login to SLES 11 SP2 GUI

SUSE Product Topics SLES Configure-Administer
21

Hi Jens,

strange and interesting things going on here :confused:

First of all I added the code to the next section of code in the Xsession file. There was one line more per “command” in my file as compared to the one you sent (not that I think it makes a difference) so this is how mine looks like now (at least the part being analyzed now):

…echo “$0 about to hand on to window manager” >> /tmp/Xsession.trace.out

if test “$forced” = “yes” ; then
test -x $syssess && exec_login “$syssess”
echo “$0: exec_login "$syssess" "$@"” >> /tmp/Xsession.trace.out
exec_login “/bin/bash $syssess”
fi

User login X session

If the user doesn’t have their own xsession, then run

system xsession or xinitrc script if they exist

if test -f $session ; then
test -x $session && exec_login “$session”
echo “$0: exec_login "$session" "$@"” >> /tmp/Xsession.trace.out
exec_login “/bin/bash $session”
elif test -f $xinitrc ; then
test -x $xinitrc && exec_login “$xinitrc”
echo “$0: exec_login "$xinitrc" "$@"” >> /tmp/Xsession.trace.out
exec_login “/bin/bash $xinitrc”
elif test -f $syssess; then
test -x $syssess && exec_login “$syssess”
echo “$0: exec_login "$syssess" "$@"” >> /tmp/Xsession.trace.out
exec_login “/bin/bash $syssess”
elif test -f $sysinit ; then
test -x $sysinit && exec_login “$sysinit”
echo “$0: exec_login "$sysinit" "$@"” >> /tmp/Xsession.trace.out
exec_login “/bin/bash $sysinit”
elif test -n “$WINDOWMANAGER” ; then
unset STARTUP WINDOW_MANAGER
echo “$0: exec_login "$WINDOWMANAGER" "$@"” >> /tmp/Xsession.trace.out
exec_login “$WINDOWMANAGER”
fi

echo “$0 no proper window manager detected” >> /tmp/Xsession.trace.out

The output of the Xsession trace file ends at the same place as before:

srappse03:/tmp # tail -F /tmp/Xsession.trace.out
/etc/X11/xdm/Xsession started
/etc/X11/xdm/Xsession about to hand on to window manager
/etc/X11/xdm/Xsession started
/etc/X11/xdm/Xsession about to hand on to window manager
/etc/X11/xdm/Xsession started
/etc/X11/xdm/Xsession about to hand on to window manager

So that would mean the program ends there and doesn’t hand over to the window manager properely?!?

I ran the rpm -V command for xdm and got this output:

rpm -V xdm
package xdm is not installed

This is really wierd because the command rcxdm status tells me that it’s running? And there are several folders and traces of it on the system. The same command for gdm gave this output:

rpm -V gdm
.M…U… /var/log/gdm
.M… /var/run/gdm

This really confusing and like looking for a needle in a haystack. WIll read check out the link you sent with the thread describing the permissions issue.

Regards
Patrick

22

Hi Patrick,

[QUOTE=Chomba;18014]Hi Jens,

strange and interesting things going on here :confused:

First of all I added the code to the next section of code in the Xsession file. There was one line more per “command” in my file as compared to the one you sent (not that I think it makes a difference) so this is how mine looks like now (at least the part being analyzed now):

…echo “$0 about to hand on to window manager” >> /tmp/Xsession.trace.out

if test “$forced” = “yes” ; then
test -x $syssess && exec_login “$syssess”
echo “$0: exec_login "$syssess" "$@"” >> /tmp/Xsession.trace.out
exec_login “/bin/bash $syssess”
fi
[…]
The output of the Xsession trace file ends at the same place as before:

srappse03:/tmp # tail -F /tmp/Xsession.trace.out
/etc/X11/xdm/Xsession started
/etc/X11/xdm/Xsession about to hand on to window manager
/etc/X11/xdm/Xsession started
/etc/X11/xdm/Xsession about to hand on to window manager
/etc/X11/xdm/Xsession started
/etc/X11/xdm/Xsession about to hand on to window manager

So that would mean the program ends there and doesn’t hand over to the window manager properely?!?[/QUOTE]

you file does look different from mine, which now causes a bit of confusion… the programming scheme is a bit different, thus your trace statements don’t catch:

if test "$forced" = "yes" ; then test -x $syssess && exec_login "$syssess" echo "$0: exec_login \"$syssess\" \"$@\"" >> /tmp/Xsession.trace.out exec_login "/bin/bash $syssess" fi

needs to be changed into

if test "$forced" = "yes" ; then if test -x $syssess ; then echo "$0: exec_login \"$syssess\" (forced version)" >> /tmp/Xsession.trace.out exec_login "$syssess" fi fi

and all other original statements alike. This is because the “&&” statement means “execute the following command if the previous one ran without an error” - the same as “if … then …” without “else”, and for only a single command. (There are tricks to make it multi-command, but I believe that fully written if…then constructs are more readable). And please only echo the command as invoked by the original code, in your script that’s without any parameter…

From your description, it sounds likely that the variable “forced” was set, it selected the according code path where, per your version, “exec_login $syssess” was invoked even before the new log statement was reached. So yes, it could be that extra statement… you should be able to verify after adopting the logging code.

[QUOTE=Chomba;18014]I ran the rpm -V command for xdm and got this output:

rpm -V xdm
package xdm is not installed

This is really wierd because the command rcxdm status tells me that it’s running? And there are several folders and traces of it on the system. The same command for gdm gave this output:

rpm -V gdm
.M…U… /var/log/gdm
.M… /var/run/gdm

This really confusing and like looking for a needle in a haystack.[/QUOTE]
Yes, sometimes it feels like indeed.

If you run “rpm -qf /etc/X11/xdm/Xsession”, it will tell you which RPM it belongs to.

In case my above (waek) assumption is correct and “forced” is set, you’d need to find out where that is set and why - maybe that’s already the answer to what’s going wrong.

Regards,
Jens

23

Good morning Jens,

the easy things first :slight_smile: here’s the output to show which RPM the Xession belongs to:

rpm -qf /etc/X11/xdm/Xsession
xorg-x11-7.4-9.47.1

My I ask what this tells me other than that this package the one is from which the current Xsession (Server) runs? Just trying to figure out how to place these infos into context and make them useful for this exercise and in the future.

Now to the trace part. I updated the script as you suggested (I am still a little unsure with the code so please counter-check to make sure I didn’t screw it up):

[QUOTE]echo “$0 about to hand on to window manager” >> /tmp/Xsession.trace.out

if test “$forced” = “yes” ; then
if test -x $syssess ; then
echo “$0: exec_login "$syssess" (forced version)” >> /tmp/Xsession.trace.out
exec_login “$syssess”
fi
fi

User login X session

If the user doesn’t have their own xsession, then run

system xsession or xinitrc script if they exist

if test -f $session ; then
if test -x $session ; then
echo “$0: exec_login "$session" (sessionP)” >> /tmp/Xsession.trace.out
exec_login “/bin/bash $session”
fi
elif test -f $xinitrc ; then
if test -x $xinitrc ; then
echo “$0: exec_login "$xinitrc" (xinitrcP)” >> /tmp/Xsession.trace.out
exec_login “/bin/bash $xinitrc”
fi
elif test -f $syssess; then
if test -x $syssess ; then
echo “$0: exec_login "$syssess" (syssessP)” >> /tmp/Xsession.trace.out
exec_login “/bin/bash $syssess”
fi
elif test -f $sysinit ; then
if test -x $sysinit ; then
echo “$0: exec_login "$sysinit" (sysinitP)” >> /tmp/Xsession.trace.out
exec_login “/bin/bash $sysinit”
fi
elif test -n “$WINDOWMANAGER” ; then
unset STARTUP WINDOW_MANAGER
echo “$0: exec_login "$WINDOWMANAGER" (windowMP)” >> /tmp/Xsession.trace.out
exec_login “$WINDOWMANAGER”
fi

echo “$0 no proper window manager detected” >> /tmp/Xsession.trace.out

[/QUOTE]

The output shows the following:

srappse03:~ # tail -F /tmp/Xsession.trace.out
/etc/X11/xdm/Xsession started
/etc/X11/xdm/Xsession about to hand on to window manager
/etc/X11/xdm/Xsession: exec_login “/etc/X11/xdm/sys.xsession” (forced version)

If I’m still on the ball with you on this, that would mean an X session is forced on the user BEFORE the login part can even be invoked? Further up in the file I saw one part which says:

if test “$forced” != “yes” ; then
. /etc/profile.d/profile.sh
fi

…so if the user doesen’t ask for a different environment then the profile.sh is loaded? So this leaves me with the question (as you rightly assumed) of if the forced version is being invoked, where is it set? I’ll keep digging while I wait for your analysis.

Best regards
PK

24

Hi everyone,

unfortunately despite all the help and suggestions I got, I couldn’t resolve this issue the way I would have wanted to and learn more about the way SUSE works. I couldn’t wait any longer so I reformated the disk reinstalled SUSE and everything works fine now. Now I have the task of reinstalling and reconfiguring all the software I had on the machine once again which I originally wanted to avoid.

Thanks anyway for the help especially from Jens.

Regards
PK

25

Hi PK,

[QUOTE=Chomba;18023]Good morning Jens,

the easy things first :slight_smile: here’s the output to show which RPM the Xession belongs to:

rpm -qf /etc/X11/xdm/Xsession
xorg-x11-7.4-9.47.1

My I ask what this tells me other than that this package the one is from which the current Xsession (Server) runs? Just trying to figure out how to place these infos into context and make them useful for this exercise and in the future.[/QUOTE]

sorry for the late reply.

On some systems (notably openSUSE), that file belongs to the xdm package. It seems that on SLES, it’s packaged with the X server’s base package. I’d assume all other xdm-related files to be part of the according package, thus my idea to verify the xdm RPM (to spot any other modified file causing potential problems) now focusses on xorg-x11 :wink:

[QUOTE=Chomba;18023][…]
The output shows the following:

srappse03:~ # tail -F /tmp/Xsession.trace.out
/etc/X11/xdm/Xsession started
/etc/X11/xdm/Xsession about to hand on to window manager
/etc/X11/xdm/Xsession: exec_login “/etc/X11/xdm/sys.xsession” (forced version)

If I’m still on the ball with you on this, that would mean an X session is forced on the user BEFORE the login part can even be invoked? Further up in the file I saw one part which says:

if test “$forced” != “yes” ; then
. /etc/profile.d/profile.sh
fi

…so if the user doesen’t ask for a different environment then the profile.sh is loaded? So this leaves me with the question (as you rightly assumed) of if the forced version is being invoked, where is it set? I’ll keep digging while I wait for your analysis.

Best regards
PK[/QUOTE]

“forced” just means that a specific window manager is forced, by parameter to Xsession. See line 162 (in my version of Xsession), where WINDOWMANAGER is set right after setting “forced” to true.
Execution thus continues in the script “/etc/X11/xdm/sys.xsession”, where you might want to continue debugging (you might as well change your debug statement in Xsession to echo "$0: exec_login \"$syssess\" (forced version, WINDOWMANAGER set to $WINDOWMANAGER)" >> /tmp/Xsession.trace.outto see if the manager to be invoked is reasonable at all…)

Although it seems impossible, as you had tested against a plain new user: Do you have your own “~/.xinitrc” for your test user? The terminal part of sys.xsession explicitly checks for that and invokes that. Else /etc/X11/xinit/xinitrc is called, which does finally call whatever is set in “$WINDOWMANAGER”. If that value is not pointing to a valid WM program - gone is your login session :wink: .

Regards,
Jens

26

Hi PK,

I couldn’t wait any longer so I reformated the disk reinstalled SUSE and everything works fine now.

just a single day on the road, and too late already :wink: Forget my other comment about further debugging this issue (except possibly for some further insight) and thanks for reporting back!

Regards,
Jens