In this section we will discuss a few special problems during the boot process. The purpose here will be to gain access to the system so that you can fix it. This usually involves reducing the level of functionality of the system when it is booted to circumvent the problem in order to gain access. We will discuss some of the more common problems beginning with the most functional and finishing with the least functional unable to boot at all case. Before we discuss individual problems, however, we need to cover how to boot a single-user shell.

Booting to single-user mode

Although we discussed this briefly in the last section, we need to review the steps for booting to single-user mode. Single-user mode is needed for performing maintenance operations that may be needed if the system is not booting properly. Briefly, this type of maintenance is performed by:

• booting to single user mode by modifying the normal boot process
• when in single-user mode, performing whatever system configuration changes are needed 
• rebooting to the normal system state

To modify the boot process to boot to single-user state you must

• reboot and interrupt grub to get a list of bootable configurations. The default boot configuration should be highlighted. Enter p then a password to unlock modifications if grub is password-protected.
• use the 'e' command to edit the current configuration. This opens the configuration to show its three constituent lines.
• select the kernel line 
• use 'e' again to edit the kernel line. This places the cursor at the end of the kernel line so you can append it.
• append a space followed by the word single to the end of the kernel line and hit ENTER
• type the b command to boot the current configuration.
• Now the system will stop in single-user mode. (Note: the configuration change you made to the boot configuration was temporary. grub reloads its configuration when you reboot)

If you have configured your system to password-protect the single-user shell as suggested in the previous section, you will be asked to enter the root password to get to single-user mode.

Booting to single-user mode is required for many of the configuration changes that are required to solve the specific problems in this section.

Note: instead of the word single you can substitute a number 1-5 which indicates the runlevel to go to. Thus, 1 and single are the same.

Problem: the system boots, but the GUI won't start

This indicates that Xorg has not been configured correctly for your monitor and/or your graphics card. The most common reason for this problem is that you have very new hardware and a new installation of linux. Assuming your linux version has a driver available that can talk to your graphics chipset, the issue boils down to getting (or creating) a configuration file for Xorg with the information it needs.

Traditionally, the Xorg configuration file was named xorg.conf and was usually found in /etc/X11. (There are about 15 places it 'could' be: see xorg.conf(5), but this is the most common one.) However, recent releases did not include this file, and let Xorg figure out the configuration when it started. This makes sense, as the first step in a 'fix' of a misconfiguration is to force Xorg to regenerate it, and if it can generate the correct configuration parameters, why does it need a configuration file?

In any case, the first step is to see if there is an xorg.conf file. If there is, you may just try to regenerate it, replace the file, and try it. If this doesn't work, about the only thing you can do is to search the Internet.

First, get access to a shell. The easiest way to do this is to use CNTL-ALT-FN to change to a virtual console (remember, FN is functionkey-N, where N is 2-5). Then login and become root. Next, disable the window manager using initctl stop prefdm. Then you can work to resolve the problem using the text console. When you have a new xorg.conf file to install, you simply run startx to start the X server. 

• Begin by saving a copy of the current xorg.conf file. Even though it is not working, it may have some useful partial configuration in it.

• Now, see if Xorg can generate the configuration file. (It may have tried to do this on its own, but we will do it by hand explicitly here). As root, use the command

# Xorg -configure

• X will [try to] create a new xorg.conf and place it in your (root's) home directory. To test it, just copy it to /etc/X11/xorg.conf and use startx to start Xorg. If you run startx in the foreground, you can easily kill X by simply switching back to your virtual console and typing ^C. (Unfortunately, of late, this 'regeneration' step may fail for unknown reasons. Perhaps the Xorg folks have so much faith in their autoconfiguration that the 'generate an xorg.conf file' code has gotten out-of-date.)
  

• If this correctly configures X you are very lucky. Otherwise you are stuck with a research problem. Fortunately, lots of people use X and someone may very well have encountered this problem and been knowledgeable enough to post an appropriate xorg.conf file. My suggestion is to do a search on xorg.conf specifying your graphics chipset and display model number. If you don't know the graphics chipset, you may look in the output of the dmesg command. grep it for the words graphic or chipset or video. Otherwise you will have to consult your motherboard manufacturer. Detailed information about the failure of Xorg to start and about what pieces of the configuration succeeded can be found in Xorg's log file /var/log/Xorg.0.log.
  

Once you find an xorg.conf file that seems to work, drop it into /etc/X11 and restart prefdm using initctl.

Note: The xorg.conf file contains parameters for clocking and driving your video display and graphics chipset. You should not tweek these parameters yourself unless you know what you are doing, as incorrect clocking of your devices can damage them.

Note: the next section contains commands that will be easier to understand after we cover the Filesystems topic. You may want to review this section later.

Problem: I can boot the system, but I've forgotten the root password!

This is the a common problem. It requires starting the system in single-user mode, then running the passwd program after you get a single-user shell. This changes the root password.

IF you have added the sulogin program as a safeguard to the single-user shell you have a bigger problem. The simplest (but not the safest) solution is to force your single-user shell to run instead of init when the system boots. The safer solution is to use a rescue disk to change  /etc/sysconfig/init to not use the sushell program first, then reboot the system. See the instructions for the use of a rescue disk in the procedure about the forgotten grub password.

To force your single-user shell to run, follow this procedure:

• edit the kernel line of your grub configuration and add the argument init=/sbin/sushell to the end of the line. Then boot.

• when your sushell program runs you will be root. You will find, however, that / has been mounted read-only. You must first mount / read-write. In the output of /proc/mounts, find the device file for the / filesystem. It will look something like /dev/sda2 or /dev/hda4. The line should indicate the device is read-only (ro).

• remount your root filesystem read-write. We will assume your device is /dev/sdaX:

mount -o remount,rw  /dev/sdaX

• Your root filesystem should now be writable. You may just be able to run the passwd program to reset the root password. If this has a problem, edit /etc/sysconfig/init to change the SINGLE variable to /sbin/sushell instead of /sbin/sulogin. When you reboot you will have to get to single-user mode to change the root password.

• You may not be able to reboot cleanly. Before you try it, type sync a few times and wait a few seconds.

• Try to execute the reboot command. If it doesn't work, type sync again, then
  mount -o remount,ro  /dev/sdaX, then hit the reset button. (This is why this is not the safest procedure!)

Alternate procedure to circumventing sulogin if the root password is forgotten:

This requires the use of a rescue disk. Note: modifying the filesystem from a rescue disk may cause SELinux to relabel your entire filesystem the next time you boot. This is a time-consuming operation. Be prepared.

• Reboot the system with the rescue disk in the CD. (The rescue disk is the first installation disk, a special installation boot disk or the installation DVD). When the prompt comes up select the rescue operation.

• It doesn't matter whether you activate the network on the system you are booting, but you need to instruct the rescue system to locate your current linux system and mount it in an alternate location so that you can access it. The rescue kernel will then search for your installed version and mount its partitions under an alternate directory for you such as /mnt/sysimage.

• Next, look at the output of mount to ensure that the root filesystem under /mnt/sysimage is mounted read-write. If not, you will have to remount it. This may require unmounting all of the partitions and remounting just your linux root partition (the one that is mounted under /mnt/sysimage).

• Once your root partition is mounted read-write, either

• change directory to the etc directory beneath the alternate location (such as /mnt/sysimage/etc) and edit the sysconfig/init file. Change the SINGLE variable to the single-user shell (instead of the sulogin program).

• save the file and type sync. (This is added, perhaps old-fashioned, safety.) Wait a few seconds.

• execute the command chroot /mnt/sysimage. You are now running with the installed system as your real system. You can just execute the passwd program from here to change the root password.

• type exit to exit the chroot-ed shell.

• Exit the single-user shell, remove the rescue disk, and boot to single-user mode.

Problem: I need to be able to boot to single-user mode, and I've forgotten grub's password.

This problem is similar to the previous one. You must use the rescue disk to locate your grub.conf file. Then comment out the password line, remove the rescue disk, and reboot. Now follow the instructions about booting to single-user mode. (Of course if you are using the sulogin program you should fix this at the same time!)

Problem: The system won't boot at all. It's just dead!

This may be due to a hardware failure. In that case, I hope you have backed up your data. In any case, the boot loader in the master boot record (MBR) has been destroyed. Unfortunately, since the main partition table is in the same sector as the boot loader, the viability of your system is in serious question. (If you have lost your main parition table, you are pretty well sunk unless you have saved a copy of the disk parameters somewhere.)

The only solution here is to try to re-install grub into your MBR. Begin by using the rescue disk to mount your data under the alternate location (/mnt/sysimage) as indicated previously. If this is successful, it means that your partition table is intact(!) and your chances of success are high. 

Next, invoke grub and ask grub to locate your configuration file. In the example below, we assume you are using a separate /boot parition. If you do not have a separate /boot partition, search for /boot/grub/grub.conf instead:

grub> find /grub/grub.conf

grub will report the partition(s) that contain a grub.conf file. (There will only be one if you have a single distro installed. Otherwise you will have to select one.) The output will describe the device and partition in grub's format like (hd0,4). (This is the fifth partition on the first IDE-type disk.)

set grub's root to the device specification that contains the configuration file using the command 

grub> root (hd0,4)

(in the case of grub.conf being on (hd0,4).) Now you are ready to install grub. Use the command setup, giving it the device of your boot disk. Given the device spec for grub.conf above, this would be (hd0):

grub> setup (hd0)

grub will noisily install itself in your MBR using the data from your root device. Now you are ready to reboot. Exit the single-user shell, remove the rescue disk, and reboot.