Cannot login to SLES 11 SP2 GUI

SUSE Product Topics SLES Configure-Administer
1

Hello,

I’ve been trying to solve a problem I though was trivial, but after 2 days I’m nearing the point of desperation. I have SLES 11 SP2 running on an IBM Server x3200, enough power, RAM , disc space and compatibility is not a problem. Everything was running smoothly until a few days ago when I was trying to get a GUI remotely from my desktop using the “forwarding X11”. I changed a couple of entries in the ssh and sshd config files because I know this is a security issue (I’ve done this before and it worked but couldn’t remember what I did exactly).

I can access the Server per ssh remotely as well as locally on the command line, when I try to login through the GUI, the user and password is accepted, screen disappears and reappears! This happens over and over (user and pw are correct) and I just can’t get the gnome to load properely. I’ve searched countless forums using well known search engines with key words from the logs and have tried out a lot of stuff but nothing seems to work. One idea was a graphic card issue which I find strange because I didn’t change anything there. I tried running sax2 -r in runlevel 3 modus, readjusted the settings but that didn’t help.

This is what I found in /var/log/messages:
…
kernel: [10629.143358] pci 0000:07:00.0: Invalid ROM contents
kernel: [10629.143360] pci 0000:07:00.0: Invalid ROM contents
gdm-simple-greeter[29536]: GLib-GObject-CRITICAL: g_param_spec_flags: assertion G_TYPE_IS_FLAGS (flags_type)' failed gdm-simple-greeter[29536]: GLib-GObject-CRITICAL: g_object_class_install_property: assertion G_IS_PARAM_SPEC (pspec)’ failed

this also looks fishy but doesn’t tell me much…

gdm-session-worker[26956]: WARNING: gdm_session_settings_load: lang = (null)
checkproc: checkproc: can not get session id for process 26842!

These are the contents of ~/.xsession-errors (which keep coming up each time I try to login)

/etc/X11/xim: Checking whether an input method should be started.
/etc/X11/xim: use GDM_LANG=de_DE.UTF-8
sourcing /etc/sysconfig/language to get the value of INPUT_METHOD
INPUT_METHOD is not set or empty (no user selected input method).
Trying to start a default input method for the locale de_DE.UTF-8 …
There is no default input method for the current locale.
Dummy input method “none” (do not use any fancy input method by default)
No protocol specified
No protocol specified

** (gnome-session:29327): WARNING **: Anzeige kann nicht geöffnet werden: (TRANSLATION: Display cannot be opned)

Would really appreciate any help I could get here. As mentioned above, everything was working fine till I started fiddling with the X-server settings, I have changed all of them back to the old values as far as I can tell. I don’t really want to do a windows solution by re-installing everything, that would mean a lot of work getting everything back to where I had it. Help!

Regards

PK

2

Out of curiosity if you SSH into the system and try to run ‘xeyes’ does
that show up on your client machine properly? If so perhaps you just have
something in Gnome or gdm that is broken, and if that’s the case
reinstalling just that component should be pretty easy.

What are you trying to do within the GUI in the first place? Perhaps we
can help you with that temporarily.

Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

3

When I try xeyes I get the “Error: Can’t open display:” message, but this is a seperate issue. I thought of de- and reinstalling gnome, since there are so many packages are there any in particular I could leave out? I take it there’s no risk do this?

4

Hi PK,

my “crystal ball” tells me it isn’t a separate issue, but the issue.

For a starter, I understood the X11 output is to appear on your desktop machine, iow you have an X11 server running there.
You’re connecting to your SLES system and want to tunnel the X11 traffic from your clients (running on the SLES server) to your X server (running on your desktop).

What’s a bit funny is that you seem to have a graphical login (so the xdm manager on the SLES system is able to output stuff on your desktop machine’s X server), but as soon as you log in, this doesn’t work any more.

Are you establishing the initial X session (xdm to X server) via ssh or over some direct network connection?

When tunneling X11 through ssh, I have never been using it to start up a window manager, but only to run clients directly - one of the advantages of running Linux clients. What OS is your client using - does it already have a window manager running on the X11 display? Then it’d be like with “Highlanders” - there can only be one.

Seems I need a bit more details to be helpful.

Regards,
Jens

5

Hi Jens,

sorry I think I didn’t make myself clear enough. I have direct access to the server and can/could login via the GUI on a terminal connected directly to it. I wanted to be able to open the GUI from my desktop which is located in another office. WHile trying to do that something went wrong so that now I can’t login to the GUI directly on the server. With ctrl+alt+F1 I can change to command modeus and login, if I swith back ctrl+alt+F7 and try logging in via the GUI the screen just disappears and the login screen reappears again. I’ve set aside the tunneling issue for now as I’d like to have the server back in the state I had it before I started fiddling with the settings.

Regards and thanks
PK

6

Hi
If you create a test user, can you login to the GUI desktop when on
the machine?

Or from the login screen, change the session to icewm, does this work?

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLED 11 SP3 (x86_64) GNOME 2.28.0 Kernel 3.0.101-0.8-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

7

Hi PK,

[QUOTE=Chomba;17967]Hi Jens,

sorry I think I didn’t make myself clear enough. I have direct access to the server and can/could login via the GUI on a terminal connected directly to it. I wanted to be able to open the GUI from my desktop which is located in another office. WHile trying to do that something went wrong so that now I can’t login to the GUI directly on the server. With ctrl+alt+F1 I can change to command modeus and login, if I swith back ctrl+alt+F7 and try logging in via the GUI the screen just disappears and the login screen reappears again. I’ve set aside the tunneling issue for now as I’d like to have the server back in the state I had it before I started fiddling with the settings.

Regards and thanks
PK[/QUOTE]

I’m sorry that I got that completely wrong :[

Does this happen with only one user, or can no user at all log in at the local graphical server console? If it’s the former, and if it’s not the root user, check if there are any files in that user’s profile/home directory that are owned by a different user, i.e. root, or if any of the ~/.[xX]* files are not writable by your user. As you can see, I’m after a permissions problem, where window manager startup is aborted because some essential writes fail. Oh, another place to check is in /tmp, where there ought to be user-specific directories and/or files (/tmp/$(id -u) /tmp/$(id -un)) that could have been accidentially re-owned as well.

If it’s (only) the root user that cannot log in, permissions ought not be a problem.

The “hard-core approach” might be to substitute the home dir of the affected user with a clean, empty directory owned by that user and see if that fixes the login issue - if you only rename the original directory, you can switch back without losing data :wink:

If it’s every user that is affected, things seem a bit more difficult.

Regards,
Jens

8

Hi,

I already tried a different user, the same problem. icewm doesn’t work either.

9

No worries Jens! I coukd have been a little more specific.

I don’t think it’s a permission issue, the test user I created doesn’t wotrk either and the behaviour is the same. Did you have a look at the error messages I posted in my first message! The error “** (gnome-session:29327): WARNING **: can’t open display :0” from the file ~/.xsession-errors

…makes me wonder why now even the local display cannot be loaded… Really strange

10

Hi PK,

[QUOTE=Chomba;17975]No worries Jens! I coukd have been a little more specific.

I don’t think it’s a permission issue, the test user I created doesn’t wotrk either and the behaviour is the same. Did you have a look at the error messages I posted in my first message! The error “** (gnome-session:29327): WARNING **: can’t open display :0” from the file ~/.xsession-errors

…makes me wonder why now even the local display cannot be loaded… Really strange[/QUOTE]

I was busy hunting down the cause of the “INPUT_METHOD is not set or empty” message… but found nothing that would seem to be a likely cause.

Since it’s happening even with a freshly created test user, user profile issues shouldn’t be the cause.
“WARNING **: can’t open display :0” might have been caused by a dying X server - no server, no connection. Of course it might have been caused by some (Xauthority) permission problem, hard to distinguish from the logs.

I just noticed that we have no output from the X server log file (/var/log/Xorg.*.log - should be .0.log, but who knows…), it might list a reason for terminating the process.

The more bothersome way to debug this is to go through the kdm/xdm/gdm startup scripts and create manual log points (“echo Testpoint XX >> /tmp/mytest.log”) to see how far it came - that way, you might get a hint at what piece of code if failing.

Regards,
Jens

11

Hi Jens,

yes sorry I forgot to include that, the Xorg logs but to be honest there was nothing that looked suspicious to me. Could you maybe help me with the script for the manual log points and how to manually startup the scripts? Thanks!

Regards
PK

12

Hi
Sure it’s not just a hardware issue?

What gfx card?

hwinfo --gfxcard

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLED 11 SP3 (x86_64) GNOME 2.28.0 Kernel 3.0.101-0.8-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

13

Hi PK,

I’m on the road atm - sorry for the brief reply.

I’d start with /etc/X11/Xsession and insert echo statements (with output redirection). Then, simply log in via X while running a “tail” on the file you’re writing the messages to.

Tomorrow I’ll check back here.

Regards,
Jens

14

Chomba wrote:
[color=blue]

Everything was running smoothly until a few days ago when
I was trying to get a GUI remotely from my desktop using the
“forwarding X11”. I changed a couple of entries in the ssh and sshd
config files because I know this is a security issue (I’ve done this
before and it worked but couldn’t remember what I did exactly).[/color]

Have you tried to search for files changed on or after the date you
made the configuration changes?

You could try to revert the changes if you made a backup copy of the
file or if you documented the change you made in a specific file. If
you failed to do either, you could obtain the equivalent from from a
working system and compare it.

If you can put things back the way they were and that resolves your
issues, you can try again (one step at a time) and see where things
went wrong.

–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

15

Hi Malcom,

I can’t imagine why but here’s the info:

31: PCI 700.0: 0300 VGA compatible controller (VGA)
[Created at pci.323]
UDI: /org/freedesktop/Hal/devices/pci_102b_530
Unique ID: aK5u.dr3Y3T2YISA
Parent ID: vTuk.uPSDWcmPaZE
SysFS ID: /devices/pci0000:00/0000:00:1c.4/0000:06:00.0/0000:07:00.0
SysFS BusID: 0000:07:00.0
Hardware Class: graphics card
Model: “Matrox G200 VE”
Vendor: pci 0x102b “Matrox Graphics, Inc.”
Device: pci 0x0530 “G200 VE”
SubVendor: pci 0x1014 “IBM”
SubDevice: pci 0x0369
Memory Range: 0x90000000-0x90ffffff (ro,non-prefetchable)
Memory Range: 0x91800000-0x91803fff (rw,non-prefetchable)
Memory Range: 0x91000000-0x917fffff (rw,non-prefetchable)
I/O Ports: 0x3c0-0x3df (rw)
Module Alias: “pci:v0000102Bd00000530sv00001014sd00000369bc03sc00i00”
Driver Info #0:
XFree86 v4 Server Module: mga
Config Status: cfg=no, avail=yes, need=no, active=unknown
Attached to: #30 (PCI bridge)

Primary display adapter: #31

By the way I ran sax2 -r in runlevel 3 mode and that worked fine. Wouldn’t that eliminate the possibility of a graphic card issue?

Regards
PK

16

Hi Jens,

sorry you’ve lost me there mate. So I open the /etc/X11/xdm/Xsession file with vi and enter echo “statements” at strategic points within the code? I have two problems:

  • I have no idea how to write such a statement
  • I don’t know where to place them so that it makes sense

Sorry I know it pretty pathetic, but my scripting skills are somewhere near zero and I’m used to the linux systems working, I rarely have to dive in so deep :frowning:

Appreciate your help
PK

17

Hi Malcom,

no I can’t login to the GUI with any user, root or and other test user. Changing the session to icewm, fvwm or whatever has the same effect. Login, screen disappears (like its loading) and reappears again. I can login as often as I want the screen just keeps coming back.

Regards
PK

18

Hi PK,

now that I have a physical keyboard in front of me, this is all much easier :wink:

First thing to do is to make a backup copy of the file in question (/etc/X11/xdm/Xsession), i.e. via

cp -p /etc/X11/xdm/Xsession /etc/X11/xdm/Xsession.orig

Only after that you should start editing the file, in order to be able to revert any changes you made and which make break stuff.
The actual “poor man’s debugger” statement goes like

echo "Test point 1" >> /tmp/Xsession.trace.out

which will append a line with according content to the file “/tmp/Xsession.trace.out” - to monitor operations, you’ll run in a terminal session (ssh, local text console, anything not X11 :wink: )

tail -F /tmp/Xsession.trace.out

Now looking at the Xsession file, you can see that it does all the pre-“display manager” setup and finally switches control over to the selected manager. So two initial trace points seem useful:

  • at the beginning of the file, to verify you’re actually looking at the right file

  • right before control is handed to the window manager, to see if the script got there at all.

And as there’s a “catch all” exit statement that should never be reached, we’ll monitor that as well:

[CODE]*** Xsession 2012-06-18 15:36:04.000000000 +0200
— /tmp/Xsession 2013-12-11 11:16:25.682238190 +0100

*** 9,16 ****
— 9,18 ----

Author: Werner Fink werner@suse.de

  • echo “$0 started” >> /tmp/Xesssion.trace.out

  • What we do if we are signaled or do not leave this

    script with an appropriate exec call.

*** 225,232 ****
— 227,236 ----

system xsession or xinitrc script if they exist, but

use a forced X session type if the user asked for

an other session environment.

  • echo “$0 about to hand on to window manager” >> /tmp/Xesssion.trace.out
  • if test “$forced” = “yes” ; then
    exec_login “$syssess” “$@”
    elif test -f $session ; then
    exec_login “$session” “$@”

*** 240,247 ****
— 244,253 ----
unset STARTUP WINDOW_MANAGER
exec_login “$WINDOWMANAGER” “$@”
fi

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

  • Call failsafe

    exit 1[/CODE]

This might be the right time to actually get that deep, to learn some scripting and to get rather close to the inner working of things. You have not told about your professional background, but it seems you’re a systems administrator - thou shalt not fear the dragon! :smiley:

Regards,
Jens

19

Hi Jens,

you guessed it, I’m a sys admin and have neglected scripting because I hated it during my studies but I’ve always known there’s no way around it in our world :frowning: (terrified of the dragon! :o

Okay so I added the code you mentioned to the Xsession file and tried logging in again, this is the output of the Xsession.trace.out file:

srappse03:~ # tail -F /tmp/Xsession.trace.out
tail: cannot open /tmp/Xsession.trace.out' for reading: No such file or directory tail: /tmp/Xsession.trace.out’ has become accessible
/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

Looks like it’s working fine till there right? In the meantime I tried something else by trying to start the gdm by entering /usr/bin/gdm, I then get:

** (gdm:8350): WARNING **: Failed to acquire org.gnome.DisplayManager

** (gdm:8350): WARNING **: Could not acquire name; bailing out

I searched a bit using this error message but till now couldn’t find any useful tips as to what exactly is going wrong. By the way I compared the config files ssh_config, sshd_config, xdm_config with another maschine which is working (I mentioned in an earlier post that I had fiddled with these settings) and the parameters are exactly the same.

I take it the trace has to be extended? Pretty cool, never done that before, thanks again for the help!

Regards
PK

20

Hi PK,

[QUOTE=Chomba;18012]Hi Jens,

you guessed it, I’m a sys admin and have neglected scripting because I hated it during my studies but I’ve always known there’s no way around it in our world :frowning: (terrified of the dragon! :o[/QUOTE]
A little scripting can help a lot from time to time, especially when automating tasks that otherwise would require lots of typing… nothing to be afraid of and no urgent need to deep-dive into the complex parts :slight_smile:

[QUOTE=Chomba;18012]Okay so I added the code you mentioned to the Xsession file and tried logging in again, this is the output of the Xsession.trace.out file:

srappse03:~ # tail -F /tmp/Xsession.trace.out
tail: cannot open /tmp/Xsession.trace.out' for reading: No such file or directory tail: /tmp/Xsession.trace.out’ has become accessible
/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

Looks like it’s working fine till there right?
[…]
I take it the trace has to be extended? Pretty cool, never done that before, thanks again for the help![/QUOTE]
Yes indeed, this looks promising. You might want to further test which follow-up code is invoked after that last test point so you can spot where things break:

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

if test “$forced” = “yes” ; then
echo “$0: exec_login "$syssess" "$@"” >> /tmp/Xesssion.trace.out
exec_login “$syssess” “$@”
elif test -f $session ; then
echo “$0: exec_login "$session" "$@"” >> /tmp/Xesssion.trace.out
exec_login “$session” “$@”
elif test -f $xinitrc ; then
echo “$0: exec_login "$xinitrc" "$@"” >> /tmp/Xesssion.trace.out
exec_login “$xinitrc” “$@”
elif test -f $syssess; then
echo “$0: exec_login "$syssess" "$@"” >> /tmp/Xesssion.trace.out
exec_login “$syssess” “$@”
elif test -f $sysinit ; then
echo “$0: exec_login "$sysinit" "$@"” >> /tmp/Xesssion.trace.out
exec_login “$sysinit” “$@”
elif test -n “$WINDOWMANAGER” ; then
unset STARTUP WINDOW_MANAGER
echo “$0: exec_login "$WINDOWMANAGER" "$@"” >> /tmp/Xesssion.trace.out
exec_login “$WINDOWMANAGER” “$@”
fi[/CODE]

If it’s just starting the window manager, I’m puzzled that it’s a problem hitting all window managers you tested - from your previous description, I would has suspected something inside Xsession to break.

[QUOTE=Chomba;18012] In the meantime I tried something else by trying to start the gdm by entering /usr/bin/gdm, I then get:

** (gdm:8350): WARNING **: Failed to acquire org.gnome.DisplayManager

** (gdm:8350): WARNING **: Could not acquire name; bailing out

I searched a bit using this error message but till now couldn’t find any useful tips as to what exactly is going wrong.[/QUOTE]
The usual way to manually start X sessions (when no X is running - run “rcxdm stop” before trying this) is the command “startx”. I’ve seen this thread where a permissions problem is described in the last response https://bbs.archlinux.org/viewtopic.php?id=145557 but I have absolutely no gnome experience and no test installation here, so I cannot tell if you’ll have to apply that solution for SLES.

ssh stuff shouldn’t be the cause here, while XDM may well have to do with it. If you run “rpm -V xdm” you will receive a list of files that were modified since installing the xdm RPM - maybe there’s some hint for a file you missed to revert?

On a system running fine I get the following response, quoted so you have something to compare against:

[QUOTE]> rpm -V xdm
5S.T… c /etc/pam.d/xdm
5S.T… c /etc/pam.d/xdm-np
missing /var/lib/xdm/authdir/authfiles (Keine Berechtigung)[/QUOTE]

Regards,
Jens