Chapter 9. Troubleshooting Installation on AMD64 and Intel 64 Systems

This chapter discusses some common installation problems and their solutions.
For debugging purposes, Anaconda logs installation actions into files in the /tmp directory. These files are listed in the following table.

Table 9.1. Log Files Generated During the Installation

Log file Contents
/tmp/anaconda.log general Anaconda messages
/tmp/program.log all external programs run during the installation
/tmp/storage.log extensive storage module information
/tmp/packaging.log yum and rpm package installation messages
/tmp/syslog hardware-related system messages
If the installation fails, the messages from these files are consolidated into /tmp/anaconda-tb-identifier, where identifier is a random string.
After successful installation, by default, these files will be copied to the installed system under the directory /var/log/anaconda/. However, if installation is unsuccessful, or if the inst.nosave=all or inst.nosave=logs options are used when booting the installation system, these logs will only exist in the installation program's RAM disk. This means they are not saved permanently and will be lost once the system is powered down. To store them permanently, copy those files to another system on the network by using scp on the system running the installation program, or copy them to a mounted storage device (such as an USB flash drive). Details on how to transfer the log files over the network are below. Note that if you use an USB flash drive or other removable media, you should make sure to back up any data on it before starting the procedure.

Procedure 9.1. Transferring Log Files Onto a USB Drive

  1. On the system you are installing, press Ctrl+Alt+F2 to access a shell prompt. You will be logged into a root account and you will have access to the installation program's temporary file system.
  2. Connect a USB flash drive to the system and execute the dmesg command. A log detailing all recent events will be displayed. At the bottom of this log, you will see a set of messages caused by the USB flash drive you just connected. It will look like a set of lines similar to the following:
    [ 170.171135] sd 5:0:0:0: [sdb] Attached SCSI removable disk
    Note the name of the connected device - in the above example, it is sdb.
  3. Go to the /mnt directory and once there, create new directory which will serve as the mount target for the USB drive. The name of the directory does not matter; this example uses the name usb.
    # mkdir usb
  4. Mount the USB flash drive onto the newly created directory. Note that in most cases, you do not want to mount the whole drive, but a partition on it. Therefore, do not use the name sdb - use the name of the partition you want to write the log files to. In this example, the name sdb1 is used.
    # mount /dev/sdb1 /mnt/usb
    You can now verify that you mounted the correct device and partition by accessing it and listing its contents - the list should match what you expect to be on the drive.
    # cd /mnt/usb
    # ls
  5. Copy the log files to the mounted device.
    # cp /tmp/*log /mnt/usb
  6. Unmount the USB flash drive. If you get an error message saying that the target is busy, change your working directory to outside the mount (for example, /).
    # umount /mnt/usb
The log files from the installation are now saved on the USB flash drive.

Procedure 9.2. Transferring Log Files Over the Network

  1. On the system you are installing, press Ctrl+Alt+F2 to access a shell prompt. You will be logged into a root account and you will have access to the installation program's temporary file system.
  2. Switch to the /tmp directory where the log files are located:
    # cd /tmp
  3. Copy the log files onto another system on the network using the scp command:
    # scp *log user@address:path
    Replace user with a valid user name on the target system, address with the target system's address or host name, and path with the path to the directory you want to save the log files into. For example, if you want to log in as john to a system with an IP address of 192.168.0.122 and place the log files into the /home/john/logs/ directory on that system, the command will have the following form:
    # scp *log john@192.168.0.122:/home/john/logs/
    When connecting to the target system for the first time, the SSH client asks you to confirm that the fingerprint of the remote system is correct and that you want to continue:
    The authenticity of host '192.168.0.122 (192.168.0.122)' can't be established.
    ECDSA key fingerprint is a4:60:76:eb:b2:d0:aa:23:af:3d:59:5c:de:bb:c4:42.
    Are you sure you want to continue connecting (yes/no)?
    Type yes and press Enter to continue. Then, provide a valid password when prompted. The files will start transferring to the specified directory on the target system.
The log files from the installation are now permanently saved on the target system and available for review.

9.1. Trouble Beginning the Installation

9.1.1. System Does Not Boot When UEFI Secure Boot Is Enabled

Beta releases of Red Hat Enterprise Linux 7 have their kernels signed with a special public key which is not recognized by standard UEFI Secure Boot implementations. This prevents the system from booting when the Secure Boot technology is enabled.
To fix this issue, you must disable UEFI Secure Boot, install the system, and then import the Beta public key using the Machine Owner Key facility. See Section 5.9, “Using a Beta Release with UEFI Secure Boot” for instructions.

9.1.2. Problems with Booting into the Graphical Installation

Systems with some video cards have trouble booting into the graphical installation program. If the installation program does not run using its default settings, it attempts to run in a lower resolution mode. If that still fails, the installation program attempts to run in text mode.
There are several possible solutions to display issues, most of which involve specifying custom boot options. For more information, see Section 22.1, “Configuring the Installation System at the Boot Menu”.
Use the basic graphics mode
You can attempt to perform the installation using the basic graphics driver. To do this, either select Troubleshooting > Install Red Hat Enterprise Linux in basic graphics mode in the boot menu, or edit the installation program's boot options and append inst.xdriver=vesa at the end of the command line.
Specify the display resolution manually
If the installation program fails to detect your screen resolution, you can override the automatic detection and specify it manually. To do this, append the inst.resolution=x option at the boot menu, where x is your display's resolution (for example, 1024x768).
Use an alternate video driver
You can also attempt to specify a custom video driver, overriding the installation program's automatic detection. To specify a driver, use the inst.xdriver=x option, where x is the device driver you want to use (for example, nouveau).

Note

If specifying a custom video driver solves your problem, you should report it as a bug at https://bugzilla.redhat.com under the anaconda component. Anaconda should be able to detect your hardware automatically and use the appropriate driver without your intervention.
Perform the installation using VNC
If the above options fail, you can use a separate system to access the graphical installation over the network, using the Virtual Network Computing (VNC) protocol. For details on installing using VNC, see Chapter 24, Using VNC.

9.1.3. Serial Console Not Detected

In some cases, attempting to install in text mode using a serial console will result in no output on the console. This happens on systems which have a graphics card, but no monitor connected. If Anaconda detects a graphics card, it will attempt to use it for a display, even if no display is connected.
If you want to perform a text-based installation on a serial console, use the inst.text and console= boot options. See Chapter 22, Boot Options for more details.