Section 1.9. I Can t Get to the GUI | Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It

1.9. I Can't Get to the GUI

Sometimes the GUI just won't start. You've configured your /etc/inittab to boot Linux in a runlevel associated with the GUI. You may see a command-line login prompt for a very few seconds. You may get to a GUI Login Manager and enter the correct username and password, and the GUI Login Manager just reappears.

There are several possible causes of this failure:

The key packages associated with the GUI desktop environment aren't installed.
The configuration files aren't set to automatically start the GUI.
The X font server is not running.
Key directories are either full or missing.

In this annoyance, I limit coverage to the most popular desktop environments, KDE and GNOME.

1.9.1. Packages Associated with the GUI

If you can't start the GUI, you might have forgotten to install the associated packages. You could navigate to the package-management tool of your choice, but for Red Hat and Fedora's system-config-packages or pirut, that requires the GUI. If all you're familiar with on Debian is the Synaptic package manager, that requires the GUI. SUSE's YaST won't work if the /tmp directory is completely deleted. I'll describe what you can do in each of these cases.

1.9.1.1. Fedora Core

Fedora Core Linux comes with an excellent command-line update system, known as the Yellowdog Updater, Modified, or yum for short. I'm assuming that the repositories specified in your /etc/yum.repos.d directory are up-to-date, as described in "Find the Right Update Repository" in Chapter 8.

There are two approaches that you can take with yum. One approach is to focus on a key package and make sure it's installed or up-to-date. Either of the following commands upgrades the noted package if it's already installed:

 yum install gnome-desktop yum install kdebase

Alternatively, you can focus on the package group. For example, if you want to install the KDE Desktop Environment on your system, the following command installs the default and mandatory packages from the associated package group, as defined in the comps.xml file in the /usr/share/comps/i386/ directory (if your architecture is different, substitute accordingly for i386):

 yum groupinstall KDE

If you want to see a list of package groups, run the following command; you may want to pipe it to a pager such as more or less:

 yum grouplist

1.9.1.2. Red Hat Enterprise Linux

If you're running Red Hat Enterprise Linux and need to install a GUI, you don't have the option of yum for updates from the Red Hat Network. You'll need to install the appropriate packages via the Red Hat Network. As the up2date utility also installs any dependent packages, the following commands will install the packages required for the GNOME and KDE Desktop Environments:

 up2date -u gnome* up2date -u kde*

1.9.1.3. Debian Linux

If you need to install the GNOME or KDE desktop environments on Debian Linux, first make sure your apt databases are up-to-date with the following command. You may need to run it more than once if you get an error message, as the packages in some repositories may depend on others:

 apt-get update

While there are no appropriately configured package groups for Debian Linux, you can take advantage of dependencies. Install critical packages with commands such as:

 apt-get install gnome-desktop-environment apt-get install kdebase

If you need to list packages associated with a desktop environment, you can use a command such as the following to get a full list:

 apt-cache search kde

The associated list is long; you may want to pipe the output to a pager such as less or more. For more information on the apt commands, see "Avoid Dependency Hell with apt" in Chapter 8.

1.9.1.4. SUSE Linux

Generally, SUSE's YaST works even in command-line consoles. However, it won't start if the /tmp directory is missing. No special files are required. Just add the directory, and you can take advantage of YaST to install the GNOME or KDE desktop environment.

1.9.2. Making Configuration Files Point to the GUI

When you configure a desktop for ordinary users, you'll generally want to let them log directly in to the GUI. The "I Need a Custom Login Menu" annoyance, earlier in this chapter, illustrates how you can create a custom GUI login menu. You'll also need to make sure the boot system, as defined in /etc/inittab, starts you in a runlevel appropriate for the GUI.

Assuming you've installed the appropriate GUI login manager, open the /etc/inittab file in a text editor. Inspect the line with the id directive. If you're running Debian Linux, make sure this directive reads as follows:

 id:2:initdefault

If you're running SUSE, Fedora Core, or Red Hat Enterprise Linux, make sure the id directive reads as follows:

 id:5:initdefault

1.9.3. The X Font Server Is Not Running

The X Font Server is important to the GUI only on Red Hat/Fedora distributions. If it isn't running, the X Window System won't start. If your system is configured to start in GUI runlevel 5, the screen will just flash for a while. If you try navigating to another console with the Alt-Ctrl-F2 keys, you'll see the console login prompt for a second or two.

After a couple of minutes, you'll see a blue screen with the following message:

 I cannot start the X server (your graphical interface). It is likely that it is not set up correctly. Would you like to view the X server output to diagnose the problem?

If you see the message, you're offered the opportunity to review the logfiles, and then a chance to start the Red Hat display tool. If the X Font Server is not running, the display tool won't start. If you refuse to restart X, Red Hat/Fedora disables the GUI and returns you to the command-line console.

If you can't get back to the command-line console, you'll have to reboot the computer and make sure to restart in a different runlevel. Generally, you can do so at the bootloader with the following steps:

Restart the computer. If necessary, use the power button.
At the bootloader, use the up or down arrow keys to stop the timer.
If a password is required, press p and enter your GRUB bootloader password when prompted.
Press a to display the kernel command line. At the end of the line, enter the runlevel of your choice. For Red Hat/Fedora, this should be runlevel 3, which corresponds to full multiuser mode without the GUI.

Now you can start diagnosing problems with the X Font Server:

Make sure it's configured to run in runlevel 5 with the following commands:
```
 chkconfig xfs on chkconfig --list xfs 
```
Make sure the X Font Server runs with the following command:
```
 /etc/init.d/xfs restart 
```
As the GUI depends on the X Font Server, this command won't work from the GUI.
If there are other problems with the X Font Server, do an Internet search based on the error messages.

1.9.4. Key Directories Are Full or Missing

As described in the next annoyance, the GUI depends on files stored in the /tmp directory. You'll see that the cron jobs that clear temporary files on a regular basis take care to exclude directories and files required to start the GUI.

If for some reason someone deletes the /tmp directory, users won't be able to start the GNOME or KDE desktops. The quickest solution is to re-create the directory with appropriate permissions:

 mkdir /tmp chmod 1777 /tmp init 5

As you've seen throughout this chapter, key configuration files are stored in each user's home directory. If the partition with /home is full, the GUI won't be able to update those files, and it can't start. In that case, you may see an error message such as:

 Fatal server error: could not open default font 'fixed'

It's true that Linux could not start the X window because it couldn't open the default font. However, the problem is not related to the X Font Server just described; it's just a symptom of the lack of space on the aforementioned directories. The df command can tell you whether one or more critical partitions are full. What you do to make more space is up to you.