Gray Screen with large X cursor

Copyright ©2002 by James McQuillan

Released under the terms of the Gnu Free Documentation License

A frequently heard problem when setting up an LTSP workstation is getting a gray screen, with the large X cursor. This indicates that the Xserver running on the workstation was not able to connect with the display manager running on the LTSP server.

First, some background

A display manager is a program that runs on a server, and accepts connections from workstations. The workstation tries to connect to the display manager, to get a login dialog box. This is sort of the graphical equivalent of running getty on a serial port, where getty will detect a connection from a dumb terminal terminal and offer the Login prompt.

Examples of display managers include XDM, GDM and KDM. XDM is the old standard display manager that is included with the Xwindows distribution. GDM is the Gnome Display Manager, and KDM is the KDE Display Manager.

The GDM and KDM display managers offer great features, such as auto-login, session type menus, user icons and more.

There are several reasons why a the Xserver may not get a connection with the display manager.

1. The display manager isn't running.
2. The display manager isn't allowing connections from workstations.
3. The workstation is looking to the wrong server for a display manager.
4. iptables or ipchains rules are preventing the XDMCP query from getting from the workstation to the display manager running on the server.

In troubleshooting the Gray Screen problem, the trick is figuring which of the above conditions are causing the problem.

---

Determining the cause of problem

1. Is the display manager listening?

When I troubleshoot problems, I like to divide the problem in half, until I narrow the problem down so small that it is clear what is wrong. So, when troubleshooting a display manager problem, the simplest place to start is to see if the display manager is listening. Try running this (as root) on the server:

    netstat -anp | grep ":177 "

What does the above command mean ? Well, the netstat command can be used to monitor any network connections currently active on the server, and also show any ports that are currently being listened to, for incoming connection requests.

The '-a' option tells netstat to show information about ALL network sockets. The '-n' option tells netstat to NOT convert IP addresses and PORT numbers to names. This can speed up the operation, especially if you have DNS problems. The '-p' option tells netstat to display the Process ID (PID) and the name of the process that is currently listening on that port. If you get an error from netstat about the '-p' option, you can skip that option. Older versions of netstat don't have the ability to tell which program is listening on a port.

We then pipe the output of netstat through the grep utility. This is so we can show ONLY the lines that contain ":177 ". 177 is the registered UDP port number that a display manager is supposed to use. Notice the blank space after the 177. This will prevent it from showing other sockets that start with 177, such as '17739'. The above command should either produce no output at all, or a line, similar to this:

    udp     0   0  0.0.0.0:177       0.0.0.0:*          1407/kdm            

If you don't see any output from the netstat command, and you are sure that you typed the command correctly, then the display manager is either not running, or not configured to accept connections from remote workstations. Go to the next step, to see whether the display manager is running.

An added advantage to trying this test first is that if the display manager is running, and is listening on port 177, you can see all of that in one command, and you can see which display manager is running, because the '-p' option well show that.

2. Is the display manager running?

If the previous step shows that a display manager is listening on port 177, then you can skip this step.

One problem with trying to figure out if a display manager is actually running is the fact that there are 3 different display managers that could be running. The good news is that they all share the last 2 characters in their name 'dm'. The bad news is that other programs that may be running on your server can also contain the 'dm' characters. For example, 'sendmail'.

If you use an appropriate pattern to the grep command, you should be able to see just the processes you want. The following command should show you whether xdm, gdm or kdm are running:

    ps -e | grep " .dm"

Notice that it is a single space, followed by a dot (period) and the letters 'dm'.

You should see some output, similar to the following:

    30289 ?        00:00:00 kdm

That shows that kdm is running.

If you don't see any output from the above command, and you are sure that you typed the command correctly, then the display manager is NOT running. Go down to the next section

3. Is the workstation trying the wrong server?

If the display manager has been confirmed to be running, and listening on udp port 177, then the next place to look is to see if the workstation is actually trying to contact the correct server.

The default network address for the server is 192.168.0.254. It is common for a sysadmin to setup the LTSP server on a different IP address, sometimes in an entirely different class-c. An often overlooked source of trouble is the entries in the lts.conf file that control which server the workstation will attempt to contact.

The LTSP workstations can be configured to request a connection from any server on the network. This is controlled by a couple of entries in the /opt/ltsp/i386/etc/lts.conf file.

The following entries are looked for, in the following order:

1. The value of: XDM_SERVER This is not normally specified. It is really only necessary when the workstations are supposed to contact a server that is different from the LTSP server that the workstations booted from.

1. The value of: SERVER This setting is almost always present, and should contain the IP address of the LTSP server.

1. The default of: 192.168.0.254 If neither then SERVER nor the XDM_SERVER are present in the lts.conf file, then the default address of 192.168.0.254 will be used.

4. Is iptables or ipchains rules blocking access

It is possible that you've configured the display manager to run and accept remote connections, and you've configured the workstation to contact the correct server, and still, your workstation can't get a log in screen. The reason could be that you have some filtering on your network that is blocking the XDMCP packets from getting from the workstation to the server.

iptables and ipchains do basically the same thing. It is possible that one or the other is configured on your system, but definately not both.

Testing for iptables To test for iptables, you can issue the following command:

    iptables -L

If your system is not configured to use ipchains, then you will likely see some really scary looking errors, like the following:

    /lib/modules/2.4.18-2/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
    /lib/modules/2.4.18-2/kernel/net/ipv4/netfilter/ip_tables.o: insmod /lib/modules/2.4.18-2/kernel/net/ipv4/netfilter/ip_tables.o failed
    /lib/modules/2.4.18-2/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
    Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
    iptables v1.2.4: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
    Perhaps iptables or your kernel needs to be upgraded.

This is Ok! - If you see that error, don't worry, it simply means that your server is NOT running iptables, and therefore, iptables is not the cause of your display manager troubles.

If your system is configured to use iptables, then you need to look at the rules that are set. If you see output like this:

    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         

    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination         

    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination         

This is Ok! - Output showing 'policy ACCEPT' for all chains indicates that all packets are being allowed through the network, and in this case, iptables is not the reason for the problems with the display manager.

If you do show other rules, then possibly the rules are blocking udp port 177. See the next session on Fixing the problem, to see how to turn off iptables.

Testing for ipchains To test for ipchains, you can issue a similar command:

    ipchains -L

If your system is not configured to use ipchains, then you will likely get the following message:

    ipchains: Incompatible with this kernel

This is Ok! - If you do see that message, then it is NOT ipchains that is causing your display manager problem.

If your system is configured to use ipchains, then you need to look at the rules that are set. The above command will display currently active rules. If they are like the following:

    Chain input (policy ACCEPT):
    Chain forward (policy ACCEPT):
    Chain output (policy ACCEPT):

This is Ok! - It just shows that ipchains is allowing all packets, and again, ipchains is NOT the cause of your display manager problems.

If you do show other rules, then possibly the rules are blocking udp port 177. See the next session on Fixing the problem, to see how to turn off ipchains.

---

Fixing the problem

1. Display manager is not listening

If you have determined from the troubleshooting steps above, that the display manager is running, but not accepting requests from remote workstations (ie: not listening on port 177), then you need to figure out how to convice the display manager to accept remote connections.

Of course, it matters a great deal which display manager is configured to run. That should have been discovered in step 2 of the troubleshooting section above, using the ps -e | grep " .dm" command.

XDM

On Redhat (and Redhat derived) systems, the XDM configuration is all in the /etc/X11/xdm directory.

The following files need to be setup correctly:

• • xdm-config You should be able to find an entry that looks like this:

          DisplayManager.requestPort:  0

This is the line that controls whether XDM will listen on udp port 177. As it is configured by Redhat, it is set to '0', which tells xdm to NOT listen on any ports, and only allow connections from the Xserver running on the console (via UNIX Sockets).

To fix this, you can either comment out the entry, by placing a '#' or '!' in front of the line, or by changing the value from 0 to 177.

• • Xaccess In the Xaccess file, you will need a line that starts with an asterisk ('*'). The line should look like this:

          *      #any host can get a login window

Note that the asterisk MUST be the first character on the line. No leading spaces or tabs are allowed.

GDM

GDM uses a configuration file called gdm.conf. You'll need to figure out where that file is on your system. For Redhat systems, it is in /etc/X11/gdm/gdm.conf. I think other systems also put it there, but you may have to search for it using the locate command, or the find command.

Once you find the gdm.conf file, open it with your favorite editor, and look for the '[xdmcp]' section. It should look like this:

      [xdmcp]
      Enable=true

Make sure that the 'Enable' parameter is set to 'true'. Note that older versions of gdm used 0 and 1, rather than false and true.

KDM

KDM uses a configuration file called kdmrc. You will need to find that file on your system. It may be in /etc/kde/kdm/kdmrc, but again, like GDM above, you may need to use locate or find to find the file on your system.

Once you've found the file, open it with your favorite editor, and look for the '[Xdmcp]' section. It should look like this:

      [Xdmcp]
      Enable=true

make sure that the 'Enable' parameter is set to 'true'. Older versions of KDM actually used the xdm-config file from the XDM display manager, so if you don't find the '[Xdmcp]' section, you may need to edit the /etc/X11/xdm/xdm-config file as described above in the XDM section

KDM also needs to know which workstations on the network it will accept an Xdmcp query from. for this it looks at its Xaccess file: /etc/kde3/kdm/kdmrc

Remove the comment marker ('#') at the beginning of the line that says:

#*                            #any host can get a login window
so it looks like this:
 *                            #any host can get a login window

Then restart kdm.

2. Display manager is not running

The biggest problem with getting a display manager running is figuring out which display manager is supposed to be running. Each of the Linux distros seem to make the process very obscure, depending on which packages have been installed on the system.

Redhat

     The first thing to check on a Redhat system is to make sure that the system is in Runlevel 5. That is the runlevel that /etc/X11/prefdm will run in.

You can see what runlevel the system is currently in by running the runlevel command. It should return output something like this:

      N 5

It is the 2nd field that indicates the current runlevel. Make sure that it is 5. The default runlevel is set by the initdefault entry in the /etc/inittab file. During the installation of LTSP, the initdefault entry should have been set to '5'. If your initdefault entry is indeed set to '5', but your server is still in runlevel 3, then perhaps you haven't rebooted the server since installing LTSP. You could reboot the server, or you could just run the init command. For example, you could run this:

      /sbin/init 5

That will put the system into runlevel 5. Be prepared though! If your display manager is configured to start X windows on the console, then you may see X pop up on the screen when you least expect it.

Now, the gory details about how Redhat determines which display manager to run:

Redhat starts the display manager from the /etc/inittab file. That is, near the end of the inittab file, there is an entry for runlevel 5 that will run a shell script called /etc/X11/prefdm. The entry in /etc/inittab looks like this:

      x:5:respawn:/etc/X11/prefdm -nodaemon

The secret to knowing which display manager is going to run, is to know what the prefdm script does.

It starts by reading the /etc/sysconfig/desktop file. Within that file are lines that set the DESKTOP environment variable. If DESKTOP has a value of 'GNOME', then gdm will be the preferred display manager. If DESKTOP has a value of 'KDE', 'KDE1' or 'KDE2', then kdm will be the preferred display manager. If DESKTOP is set to AnotherLevel, then xdm will be the preferred display manager. If DESKTOP is not set, or is set to something else not mentioned above, then a search will be made, looking for gdm, kdm and finally xdm. Whichever is found first will be the preferred display manager.

So, once the preferred display manager is decided on, the script will check to see if the preferred display manager exists, and can be executed. If the preferred cannot be run, then it forgets about the preferred display manager and just tried gdm, kdm and finally xdm (in that order). The first display manager found will be the one.

The real downside of Redhats prefdm script is you can't simply force a specific display manager to run, regardless of the window manager or desktop environment that is desired.

Mandrake

     Mandrake is quite similar in regards to how the display manager starts up. It also runs the /etc/X11/prefdm script from the inittab file, in runlevel 5. So, most of what is documented above for Redhat applies to Mandrake as well. The difference seems to be in how Mandrake has fixed the issue with being able to force a specific display manager to run, by setting the DISPLAYMANAGER entry in the /etc/sysconfig/desktop file to be 'kdm', 'gdm' or 'xdm'. It actually works in Mandrake Linux.

Debian

Debian uses debconf to ask users about what configuration shall be used to the packege.

When a new display manager (like xdm, gdm or kdm) is installed, user is asked whether that manager should be used by default.

The inicialization script for the manager is then put onto the directory /etc/init.d and a link to it is added to /etc/rc5.d.

Restarting display manager is just running /etc/init.d/name_of_display restart

SuSE

SuSE^? uses /etc/sysconfig/displaymanager to configure which display manager to use as the default. This can be accessed via

• yast2
• Services
• /etc/sysconfig Editor

then navigating to

• Desktop
• Display Manager
• DISPLAYMANAGER

and entering in your choice.

It can also be edited with any text editor in the file /etc/sysconfig/displaymanager. The comments in that file should help you navigate it. There is also a variable in this file DISPLAYMANAGER_REMOTE_ACCESS that may need to be changed to yes depending on your version of SuSE^?.

The display manager (any) can be restarted with either the rcxdm restart or the /etc/init.d/xdm restart command.

Conectiva

     Need more info, any volunteers ?

Slackware

Slackware's graphical runlevel is 4 (not 5, as is the case in most distributions). The default runlevel is set to 3 by default, and can be changed to 4 by making the Default Runlevel entry in the /etc/inittab file read:

id:4:initdefault:

Init executes the /etc/rc.d/rc.4 script when entering runlevel 4:

! /bin/sh
#
# rc.4          This file is executed by init(8) when the system is being
#               initialized for run level 4 (XDM)
#
# Version:      @(#)/etc/rc.d/rc.4      2.00    02/17/93
#
# Author:       Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>
# At least 47% rewritten by:  Patrick J. Volkerding <volkerdi@slackware.com>
#

# Tell the viewers what's going to happen...
echo "Starting up X11 session manager..."
# Try to use GNOME's gdm session manager:
if [ -x /usr/bin/gdm ]; then
  exec /usr/bin/gdm -nodaemon
fi

# Not there?  OK, try to use KDE's kdm session manager:
if [ -x /opt/kde/bin/kdm ]; then
  exec /opt/kde/bin/kdm -nodaemon
fi

# If all you have is XDM, I guess it will have to do:
if [ -x /usr/X11R6/bin/xdm ]; then
  exec /usr/X11R6/bin/xdm -nodaemon
fi

# error
echo
echo "Hey, you don't have KDM, GDM, or XDM.  Can't use runlevel 4 without"
echo "one of those installed."
sleep 30

# All done.        

This looks for gdm, then kdm, then xdm, and executes the first one found. The order can be changed, and undesired desktop managers can be commented out (eg. if you have gdm installed, but you want to use kdm, either comment out the three rows belonging to gdm, or move them to a place after kdm)

Kdm config files and scripts (eg. kdmrc) are kept in the /opt/kde/share/config/kdm/ directory.

Gentoo

     Gentoo is quite easy to configure. To choose your display manager, look within the /etc/rc.conf file, locate the DISPLAYMANAGER entry, and set it to be 'kdm', 'gdm' or 'xdm'. By the same token, you can choose your desktop environment by looking for the XSESSION entry in the same file, and setting it to 'Gnome', 'kde-3.1.0' or 'Xsession'. Note that these settings can be overriden by a ~/.xinitrc file.

3. Workstation trying to connect with the wrong server

If the workstation is trying to connect with the wrong server, this is a simple matter of changing an entry in the /opt/ltsp/i386/etc/lts.conf file. Normally, you'd want to set the SERVER entry to point to the IP address of the LTSP server. But, if the display manager is running on a system other than the LTSP server, then you will want to setup a 'XDM_SERVER' entry to point to that server running the display manager.

4. Iptables or Ipchains blocking access

If firewall rules are blocking the ability of the workstation to make a connection with the server on udp port 177, then you need to either create a rule that will allow those packets through, or you need to disable iptables or ipchains entirely.

On a Redhat based system, you can turn off iptables by running the following command:

    service iptables stop

If you are using ipchains, the command is:

    service ipchains stop

The above commands will turn off iptables/ipchains temporarily, this should give you a chance to try the workstation again. On a Redhat based system, you can turn it off permanently using the ntsysv utility, or the chkconfig command.

For systems such as Debian, SuSE and the others, I need more information about how to disable iptables/ipchains.

Other things to check

1. Make sure the workstation is listed in the /etc/hosts file

2. Check that ws has enough ram.

X may freeze on random places when running out of memory (in my case, just when gdm login screen appeared). You may try to turn on nfs swap.

3. on some occasions, when there is no Internet link or the link is veryyyyy slowwww. workstations are unable to connect to dns server, which halts the login process. when the Internet link is back again, all's well (funny)

---

This Wiki page was copied from a document on the ltsp.org site.

-- SteveSwitzer - 08 Dec 2004