Gray Screen with large X cursor

Copyright 2002 by James McQuillan
Released under the terms of the Gnu Free Documentation License

Last updated: Thursday, Sept. 12, 2002

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?
  2. 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 this 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.

  3. Is the display manager running?
  4. 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

  5. Is the workstation trying the wrong server?
  6. 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.

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

    3. 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.

  7. Is iptables or ipchains rules blocking access
  8. 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
  2. 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.

  3. Display manager is not running
  4. 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.

  5. Workstation trying to connect with the wrong server
  6. 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.

  7. Iptables or Ipchains blocking access
  8. 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