Menu Close

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

9.3. Problems After Installation

9.3.1. Are You Unable to Boot With Your RAID Card?

If you have performed an installation and cannot boot your system properly, you might need to reinstall and partition your system's storage differently.
Some BIOS types do not support booting from RAID cards. After you finish the installation and reboot the system for the first time, a text-based screen showing the boot loader prompt (for example, grub>) and a flashing cursor might be all that appears. If this is the case, you must repartition your system and move your /boot partition and the boot loader outside the RAID array. The /boot partition and the boot loader must be on the same drive.
Once these changes have been made, you should be able to finish your installation and boot the system properly. For more information about partitioning, see Section 8.14, “Installation Destination”.

9.3.2. Trouble With the Graphical Boot Sequence

After you finish the installation and reboot your system for the first time, it is possible that the system stops responding during the graphical boot sequence, requiring a reset. In this case, the boot loader is displayed successfully, but selecting any entry and attempting to boot the system results in a halt. This usually means a problem with the graphical boot sequence; to solve this issue, you must disable graphical boot. To do this, temporarily alter the setting at boot time before changing it permanently.

Procedure 9.4. Disabling Graphical Boot Temporarily

  1. Start your computer and wait until the boot loader menu appears. If you set your boot loader timeout period to 0, hold down the Esc key to access it.
  2. When the boot loader menu appears, use your cursor keys to highlight the entry you want to boot and press the e key to edit this entry's options.
  3. In the list of options, find the kernel line - that is, the line beginning with the keyword linux (or, in some cases, linux16 or linuxefi). On this line, locate the rhgb option and delete it. The option might not be immediately visible; use the cursor keys to scroll up and down.
  4. Press F10 or Ctrl+X to boot your system with the edited options.
If the system started successfully, you can log in normally. Then you will need to disable the graphical boot permanently - otherwise you will have to perform the previous procedure every time the system boots. To permanently change boot options, do the following.

Procedure 9.5. Disabling Graphical Boot Permanently

  1. Log in to the root account using the su - command: 
    $ su -
  2. Use the grubby tool to find the default GRUB2 kernel: 
    # grubby --default-kernel
/boot/vmlinuz-3.10.0-229.4.2.el7.x86_64
  3. Use the grubby tool to remove the rhgb boot option from the default kernel, identified in the last step, in your GRUB2 configuration. For example: 
    # grubby --remove-args="rhgb" --update-kernel /boot/vmlinuz-3.10.0-229.4.2.el7.x86_64
After you finish this procedure, you can reboot your computer. Red Hat Enterprise Linux will not use the graphical boot sequence any more. If you want to enable graphical boot in the future, follow the same procedure, replacing the --remove-args="rhgb" parameter with the --args="rhgb" paramter. This will restore the rhgb boot option to the default kernel in your GRUB2 configuration.
See the Red Hat Enterprise Linux 7 System Administrator's Guide for more information about working with the GRUB2 boot loader.

9.3.3. Booting into a Graphical Environment

If you have installed the X Window System but are not seeing a graphical desktop environment once you log into your system, you can start it manually using the startx command. Note, however, that this is just a one-time fix and does not change the log in process for future log ins.
To set up your system so that you can log in at a graphical login screen, you must change the default systemd target to graphical.target. When you are finished, reboot the computer. You will presented with a graphical login prompt after the system restarts.

Procedure 9.6. Setting Graphical Login as Default

  1. Open a shell prompt. If you are in your user account, become root by typing the su - command.
  2. Change the default target to graphical.target. To do this, execute the following command: 
    # systemctl set-default graphical.target
Graphical login is now enabled by default - you will be presented with a graphical login prompt after the next reboot. If you want to reverse this change and keep using the text-based login prompt, execute the following command as root: 
# systemctl set-default multi-user.target
For more information about targets in systemd, see the Red Hat Enterprise Linux 7 System Administrator's Guide.

9.3.4. No Graphical User Interface Present

If you are having trouble getting X (the X Window System) to start, it is possible that it has not been installed. Some of the preset base environments you can select during the installation, such as Minimal install or Web Server, do not include a graphical interface - it has to be installed manually.
If you want X, you can install the necessary packages afterwards. See the Knowledgebase article at https://access.redhat.com/site/solutions/5238 for information on installing a graphical desktop environment.

9.3.5. X Server Crashing After User Logs In

If you are having trouble with the X server crashing when a user logs in, one or more of your file systems can be full or nearly full. To verify that this is the problem you are experiencing, execute the following command: 
$ df -h
The output will help you diagnose which partition is full - in most cases, the problem will be on the /home partition. The following is a sample output of the df command: 
Filesystem                                  Size  Used Avail Use% Mounted on
/dev/mapper/vg_rhel-root                     20G  6.0G   13G  32% /
devtmpfs                                    1.8G     0  1.8G   0% /dev
tmpfs                                       1.8G  2.7M  1.8G   1% /dev/shm
tmpfs                                       1.8G 1012K  1.8G   1% /run
tmpfs                                       1.8G     0  1.8G   0% /sys/fs/cgroup
tmpfs                                       1.8G  2.6M  1.8G   1% /tmp
/dev/sda1                                   976M  150M  760M  17% /boot
/dev/dm-4                                    90G   90G     0 100% /home
In the above example, you can see that the /home partition is full, which causes the crash. You can make some room on the partition by removing unneeded files. After you free up some disk space, start X using the startx command.
For additional information about df and an explanation of the options available (such as the -h option used in this example), see the df(1) man page.

9.3.6. Is Your RAM Not Being Recognized?

In some cases the kernel does not recognize all of your memory (RAM), which causes the system to use less memory than is installed. You can find out how much RAM is being utilized using the free -m command. If the displayed total amount of memory does not match your expectations, it is likely that at least one of your memory modules is faulty. On BIOS-based systems, you can use the Memtest86+ utility to test your system's memory - see Section 23.2.1, “Loading the Memory (RAM) Testing Mode” for details.

Note

Some hardware configurations have a part of the system's RAM reserved and unavailable to the main system. Notably, laptop computers with integrated graphics cards will reserve some memory for the GPU. For example, a laptop with 4 GiB of RAM and an integrated Intel graphics card will show only roughly 3.7 GiB of available memory.
Additionally, the kdump crash kernel dumping mechanism, which is enabled by default on most Red Hat Enterprise Linux systems, reserves some memory for the secondary kernel used in case of the primary kernel crashing. This reserved memory will also not be displayed as available when using the free command. For details about kdump and its memory requirements, see the Red Hat Enterprise Linux 7 Kernel Crash Dump Guide.
If you made sure that your memory does not have any issues, you can try and set the amount of memory manually using the mem= kernel option.

Procedure 9.7. Configuring the Memory Manually

  1. Start your computer and wait until the boot loader menu appears. If you set your boot loader timeout period to 0, hold down the Esc key to access it.
  2. When the boot loader menu appears, use your cursor keys to highlight the entry you want to boot and press the e key to edit this entry's options.
  3. In the list of options, find the kernel line - that is, the line beginning with the keyword linux (or, in some cases, linux16). Append the following option to the end of this line: 
    mem=xxM
    Replace xx with the amount of RAM you have in MiB.
  4. Press F10 or Ctrl+X to boot your system with the edited options.
  5. Wait for the system to boot and log in. Then, open a command line and execute the free -m command again. If total amount of RAM displayed by the command matches your expectations, append the following to the line beginning with GRUB_CMDLINE_LINUX in the /etc/default/grub file to make the change permanent: 
    mem=xxM
    Replace xx with the amount of RAM you have in MiB.
  6. After you updated the file and saved it, refresh the boot loader configuration so that the change will take effect. Run the following command with root privileges: 
    # grub2-mkconfig --output=/boot/grub2/grub.cfg
In /etc/default/grub, the above example would look similar to the following: 
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release.*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.lvm.lv=rhel/root vconsole.font=latarcyrheb-sun16 rd.lvm.lv=rhel/swap $([ -x /usr/sbin/rhcrashkernel.param ] && /usr/sbin/rhcrashkernel-param || :) vconsole.keymap=us rhgb quiet mem=1024M"
GRUB_DISABLE_RECOVERY="true"
See the Red Hat Enterprise Linux 7 System Administrator's Guide for more information about working with the GRUB2 boot loader.

9.3.7. Is Your System Displaying Signal 11 Errors?

A signal 11 error, commonly known as a segmentation fault, means that a program accessed a memory location that was not assigned to it. A signal 11 error can occur due to a bug in one of the software programs that is installed, or faulty hardware.
If you receive a fatal signal 11 error during the installation, first make sure you are using the most recent installation images, and let Anaconda verify them to make sure they are not corrupted. Bad installation media (such as an improperly burned or scratched optical disk) are a common cause of signal 11 errors. Verifying the integrity of the installation media is recommended before every installation.
For information about obtaining the most recent installation media, see Chapter 2, Downloading Red Hat Enterprise Linux. To perform a media check before the installation starts, append the rd.live.check boot option at the boot menu. See Section 23.2.2, “Verifying Boot Media” for details.
If you performed a media check without any errors and you still have issues with segmentation faults, it usually means that your system encountered a hardware error. In this case, the problem is most likely in the system's memory (RAM). This can be a problem even if you previously used a different operating system on the same computer without any errors. On BIOS-based systems, you can use the Memtest86+ memory testing module included on the installation media to perform a thorough test of your system's memory. See Section 23.2.1, “Loading the Memory (RAM) Testing Mode” for details.
Other possible causes are beyond this document's scope. Consult your hardware manufacturer's documentation and also see the Red Hat Hardware Compatibility List, available online at https://hardware.redhat.com.