Red Hat Training

A Red Hat training course is available for RHEL 8

System Design Guide

Red Hat Enterprise Linux 8

Designing a RHEL 8 system

Red Hat Customer Content Services

Abstract

This content covers how to start using Red Hat Enterprise Linux 8. To learn about Red Hat Enterprise Linux technology capabilities and limits, see https://access.redhat.com/articles/rhel-limits.

Providing feedback on Red Hat documentation

We appreciate your input on our documentation. Please let us know how we could make it better. To do so:

  • For simple comments on specific passages, make sure you are viewing the documentation in the Multi-page HTML format. Highlight the part of text that you want to comment on. Then, click the Add Feedback pop-up that appears below the highlighted text, and follow the displayed instructions.
  • For submitting more complex feedback, create a Bugzilla ticket:

    1. Go to the Bugzilla website.
    2. As the Component, use Documentation.
    3. Fill in the Description field with your suggestion for improvement. Include a link to the relevant part(s) of documentation.
    4. Click Submit Bug.

Part I. Design of installation

Chapter 1. Introduction

Red Hat Enterprise Linux 8 delivers a stable, secure, consistent foundation across hybrid cloud deployments with the tools needed to deliver workloads faster with less effort. It can be deployed as a guest on supported hypervisors and Cloud provider environments as well as deployed on physical infrastructure, so your applications can take advantage of innovations in the leading hardware architecture platforms.

1.1. Supported architectures

Red Hat Enterprise Linux supports the following architectures:

  • AMD and Intel 64-bit architectures
  • The 64-bit ARM architecture
  • IBM Power Systems, Little Endian
  • IBM Z

1.2. Installation terminology

This section describes Red Hat Enterprise Linux installation terminology. Different terminology can be used for the same concepts, depending on its upstream or downstream origin.

Anaconda: The operating system installer used in Fedora, Red Hat Enterprise Linux, and their derivatives. Anaconda is a set of Python modules and scripts with additional files like Gtk widgets (written in C), systemd units, and dracut libraries. Together, they form a tool that allows users to set parameters of the resulting (target) system. In this document, the term installation program refers to the installation aspect of Anaconda.

Chapter 2. Installation methods

You can install Red Hat Enterprise Linux using one of the following methods:

Quick install
Install Red Hat Enterprise Linux on AMD64, Intel 64, and 64-bit ARM architectures using the graphical user interface. The quick installation assumes that you are familiar with Red Hat Enterprise Linux and your environment, and that you can accept the default settings provided by the installation program.
Graphical install
Install Red Hat Enterprise Linux using the graphical user interface and customize the graphical settings for your specific requirements.
Automated install
Install Red Hat Enterprise Linux using Kickstart. The automated installation allows you to perform unattended operating system installation tasks.

Additional resources

2.1. Performing a quick install on AMD64, Intel 64, and 64-bit ARM

Follow this procedure to perform a quick installation on AMD64, Intel 64, and 64-bit ARM architectures using the graphical user interface. To complete this procedure you must be familiar with Red Hat Enterprise Linux and your environment, and you must be able to accept the default settings provided by the installation program.

Prerequisites

  • You have downloaded the required ISO image file.
  • You have created bootable installation media.
  • You have booted the installation program and the boot menu is displayed.

Procedure

  1. From the boot menu, select Install Red Hat Enterprise Linux 8.0.
  2. Press the Enter key on your keyboard.
  3. From the Welcome to Red Hat Enterprise Linux 8.0 window, select your language and location.
  4. Click Continue to proceed to the Installation Summary window.

    Note

    The Installation Summary window is the central hub that you can use to configure the Red Hat Enterprise Linux graphical user interface. The default settings assigned by the installation program are displayed under each category.

  5. From the Installation Summary window, accept the default Localization and Software options.
  6. Select System > Installation Destination.

    1. From the Local Standard Disks pane, select the target disk.
    2. Click Done to accept the selection and the default setting of automatic partitioning, and return to the Installation Summary window.
  7. Select Network & Host Name.

    1. Toggle the Ethernet switch to ON to enable network configuration.

      1. Optional: Select a network device and click Configure to update the network interface configuration.
    2. Click Done to accept the changes and return to the Installation Summary window.
  8. Optional: Select Security Policy.

    1. Select the profile that you require, and click Select profile.
    2. Click Done to accept the changes and return to the Installation Summary window.
  9. Optional: Select System Purpose.

    1. Select the role, service level agreement, and usage.
    2. Click Done to accept the changes and return to the Installation Summary window.
  10. Click Begin Installation to start the installation.
  11. From the Configuration window, configure a root password and create a user account.
  12. When the installation process is complete, click Reboot to restart the system.
  13. From the Initial Setup window, accept the licensing agreement and register your system.

Chapter 3. Installation workflow

This installation workflow contains the high-level steps for installing Red Hat Enterprise Linux on AMD64, Intel 64, and 64-bit ARM architectures using the graphical user interface.

Procedure

  1. Prepare for your installation by checking your system and hardware requirements, downloading an installation image file, and creating bootable installation media.
  2. Boot the installation program and install Red Hat Enterprise Linux using the graphical user interface.
  3. Complete post-installation tasks such as initial setup and system registration.

Chapter 4. Preparing for your installation

If you are new to Red Hat Enterprise Linux, it is important to prepare for your installation by reviewing system requirements, downloading the required installation image, and creating installation media.

4.1. Recommended steps

Preparing for your installation consists of several steps.

Note
  • If you are new to Red Hat Enterprise Linux, complete steps 1 to 5.
  • If you are familiar with Red Hat Enterprise Linux, complete steps 3 to 5.

Procedure

  1. Check system requirements.
  2. Choose an installation boot method.
  3. Select and download the installation image.
  4. Create bootable installation media.
  5. Prepare the installation source*

*Only required for the Boot ISO (minimal install) image.

4.2. Check system requirements

If this is a first-time install of Red Hat Enterprise Linux it is recommended that you review the guidelines provided for system, hardware, security, memory, and RAID before installing.

Additional resources

For more information about securing Red Hat Enterprise Linux, see the Security hardening document.

4.3. Choose an installation boot method

There are several methods to boot the Red Hat Enterprise Linux installation program. The method you choose depends on your installation media.

Full installation DVD or USB flash drive
Create a full installation DVD or USB flash drive using the Binary DVD ISO image. The DVD or USB flash drive can be used as a boot device and as an installation source for installing software packages. Due to the size of the Binary DVD ISO image, a DVD or USB flash drive are the recommended media types.
Minimal installation DVD, CD, or USB flash drive
Create a minimal installation CD, DVD, or USB flash drive using the Boot ISO image, which contains only the minimum files necessary to boot the system and start the installation program. The Boot ISO image requires an installation source that contains the required software packages.
PXE Server
A preboot execution environment (PXE) server allows the installation program to boot over the network. After a system boot, you must complete the installation from a different installation source, such as a local hard drive or a network location.

Additional Resources

4.4. Select the required installation image

Two Red Hat Enterprise Linux 8 installation images are available from the Red Hat Customer Portal.

Binary DVD ISO image file

A full installation program that contains the BaseOS and AppStream repositories and allows you to complete the installation without additional repositories. Installing Red Hat Enterprise Linux from the Binary DVD ISO is the easiest and the recommended method of performing a standard RHEL installation.

Important
  • It is recommended that you use the Binary DVD ISO image file to install Red Hat Enterprise Linux 8.
  • You can use a Binary DVD for IBM Z to boot the installation program using a SCSI DVD drive, or as an installation source.
Boot ISO image file
The Boot ISO image is a minimal installation that requires access to the BaseOS and AppStream repositories to install software packages. The repositories are part of the Binary DVD ISO image that is available for download from https://access.redhat.com/home. Download and unpack the Binary DVD ISO image to access the repositories.

The following table contains information about the images that are available for the supported architectures.

Table 4.1. Boot and Installation Images

ArchitectureInstallation DVDBoot DVD

AMD64 and Intel 64

x86_64 Binary DVD ISO image file

x86_64 Boot ISO image file

ARM 64

AArch64 Binary DVD ISO image file

AArch64 Boot ISO image file

IBM POWER

ppc64le Binary DVD ISO image file

ppc64le Boot ISO image file

IBM Z

s390x Binary DVD ISO image file

s390x Boot ISO image file

4.5. Downloading the installation ISO image

This section contains instructions about downloading a Red Hat Enterprise Linux installation image from the Red Hat Customer Portal or by using the curl command.

4.5.1. Downloading an ISO image from the Customer Portal

Follow this procedure to download a Red Hat Enterprise Linux 8 ISO image from the Red Hat Customer Portal.

Note
  • Red Hat recommends using the Binary DVD ISO image to install Red Hat Enterprise Linux 8 as it contains all repositories and software packages, and does not require any additional configuration.
  • If you download the Boot ISO image file, you must configure an installation source to obtain the repositories and software packages.

Prerequisites

Procedure

  1. From the Product Downloads page, select the By Category tab.
  2. Click the Red Hat Enterprise Linux 8 link.

    The Download Red Hat Enterprise Linux web page opens.

  3. From the Product Variant drop-down menu, select the variant that you require, for example Red Hat Enterprise Linux for x86_64.

    Note

    If you are unsure of the variant for your requirements, see http://www.redhat.com/en/technologies/linux-platforms/enterprise-linux.

  4. The Version drop-down menu defaults to 8.0.
  5. The Architecture drop-down menu defaults to x86_64.

    The Product Software tab displays the images, which include:

    • Red Hat Enterprise Linux 8.0 Binary DVD image.
    • Red Hat Enterprise Linux 8.0 Boot ISO image.

    Additional images may be available, for example, preconfigured virtual machine images, but they are beyond the scope of this document.

  6. Click Download Now beside the ISO image that you require.

4.5.2. Downloading an ISO image using curl

Use the curl command to download installation images directly from a specific URL.

Prerequisites
  • Verify the curl package is installed:

    • If your distribution uses the yum package manager:

      # yum install curl
    • If your distribution uses the dnf package manager:

      # dnf install curl
    • If your distribution uses the apt package manager:

      # apt update
      # apt install curl
    • If your Linux distribution does not use yum, dnf, or apt, or if you do not use Linux, download the most appropriate software package from the curl web site.
  • You have navigated to the Product Downloads section of the Red Hat Customer Portal at https://access.redhat.com/downloads, and selected the variant, version, and architecture that you require. You have right-clicked on the required ISO image file, and selected Copy Link Location to copy the URL of the ISO image file to your clipboard.
Procedure
  1. On the command line, enter a suitable directory, and run the following command to download the file:

    $ curl --output directory-path/filename.iso 'copied_link_location'

    Replace directory-path with a path to the location where you want to save the file; replace filename.iso with the ISO image name as displayed in the Customer Portal; replace copied_link_location with the link that you have copied from the Customer Portal.

4.6. Creating installation media

This section contains information about using the ISO image file that you downloaded in Section 4.5, “Downloading the installation ISO image” to create bootable physical installation media, such as a USB, DVD, or CD.

Note

By default, the inst.stage2= boot option is used on the installation media and is set to a specific label, for example, inst.stage2=hd:LABEL=RHEL8\x86_64. If you modify the default label of the file system containing the runtime image, or if you use a customized procedure to boot the installation system, you must verify that the label is set to the correct value.

4.6.1. Creating a bootable DVD or CD

You can create a bootable installation DVD or CD using burning software and a CD/DVD burner. The exact steps to produce a DVD or CD from an ISO image file vary greatly, depending on the operating system and disc burning software installed. Consult your system’s burning software documentation for the exact steps to burn a CD or DVD from an ISO image file.

Warning

You can create a bootable DVD or CD using either the Binary DVD ISO image (full install), or the Boot ISO image (minimal install). However, the Binary DVD ISO image is larger than 4.7 GB, and as a result, it might not fit on a single-layer DVD. A dual-layer DVD or USB key is recommended when using the Binary DVD ISO image to create bootable installation media.

4.6.2. Creating a bootable USB device on Linux

Follow this procedure to create a bootable USB device on a Linux system.

Prerequisites
Procedure
Note

This procedure is destructive and data on the USB flash drive is destroyed without a warning.

  1. Connect the USB flash drive to the system.
  2. Open a terminal window and run the dmesg command:

    $ dmesg|tail

    The dmesg command returns a log that details all recent events. Messages resulting from the attached USB flash drive are displayed at the bottom of the log. Record the name of the connected device.

  3. Switch to user root:

    $ su -
  4. Enter your root password when prompted.
  5. Find the device node assigned to the drive. In this example, the drive name is sdd.

    # dmesg|tail
    [288954.686557] usb 2-1.8: New USB device strings: Mfr=0, Product=1, SerialNumber=2
    [288954.686559] usb 2-1.8: Product: USB Storage
    [288954.686562] usb 2-1.8: SerialNumber: 000000009225
    [288954.712590] usb-storage 2-1.8:1.0: USB Mass Storage device detected
    [288954.712687] scsi host6: usb-storage 2-1.8:1.0
    [288954.712809] usbcore: registered new interface driver usb-storage
    [288954.716682] usbcore: registered new interface driver uas
    [288955.717140] scsi 6:0:0:0: Direct-Access     Generic  STORAGE DEVICE   9228 PQ: 0 ANSI: 0
    [288955.717745] sd 6:0:0:0: Attached scsi generic sg4 type 0
    [288961.876382] sd 6:0:0:0: sdd Attached SCSI removable disk
  6. Run the dd command to write the ISO image directly to the USB device.

    # dd if=/image_directory/image.iso of=/dev/device

    Replace /image_directory/image.iso with the full path to the ISO image file that you downloaded, and replace device with the device name that you retrieved with the dmesg command. In this example, the full path to the ISO image is /home/testuser/Downloads/rhel-8-x86_64-boot.iso, and the device name is sdd:

    # dd if=/home/testuser/Downloads/rhel-8-x86_64-boot.iso of=/dev/sdd
    Note

    Ensure that you use the correct device name, and not the name of a partition on the device. Partition names are usually device names with a numerical suffix. For example, sdd is a device name, and sdd1 is the name of a partition on the device sdd.

  7. Wait for the dd command to finish writing the image to the device. The data transfer is complete when the # prompt appears. When the prompt is displayed, log out of the root account and unplug the USB drive. The USB drive is now ready to be used as a boot device.

4.6.3. Creating a bootable USB device on Windows

Follow the steps in this procedure to create a bootable USB device on a Windows system. The procedure varies depending on the tool. Red Hat recommends using Fedora Media Writer, available for download at https://github.com/FedoraQt/MediaWriter/releases.

Note

Fedora Media Writer is a community product and is not supported by Red Hat. You can report any issues with the tool at https://github.com/FedoraQt/MediaWriter/issues.

Prerequisites
Procedure
Note

This procedure is destructive and data on the USB flash drive is destroyed without a warning.

  1. Download and install Fedora Media Writer from https://github.com/FedoraQt/MediaWriter/releases.

    Note

    To install Fedora Media Writer on Red Hat Enterprise Linux, use the pre-built Flatpak package. You can obtain the package from the official Flatpak repository Flathub.org at https://flathub.org/apps/details/org.fedoraproject.MediaWriter.

  2. Connect the USB flash drive to the system.
  3. Open Fedora Media Writer.
  4. From the main window, click Custom Image and select the previously downloaded Red Hat Enterprise Linux ISO image.
  5. From Write Custom Image window, select the drive that you want to use.
  6. Click Write to disk. The boot media creation process starts. Do not unplug the drive until the operation completes. The operation may take several minutes, depending on the size of the ISO image, and the write speed of the USB drive.
  7. When the operation completes, unmount the USB drive. The USB drive is now ready to be used as a boot device.

4.6.4. Creating a bootable USB device on Mac OS X

Follow the steps in this procedure to create a bootable USB device on a Mac OS X system.

Prerequisites
Procedure
Note

This procedure is destructive and data on the USB flash drive is destroyed without a warning.

  1. Connect the USB flash drive to the system.
  2. Identify the device path with the diskutil list command. The device path has the format of /dev/disknumber, where number is the number of the disk. The disks are numbered starting at zero (0). Typically, Disk 0 is the OS X recovery disk, and Disk 1 is the main OS X installation. In the following example, the USB device is disk2:

    $ diskutil list
    /dev/disk0
    #:                       TYPE NAME                    SIZE       IDENTIFIER
    0:      GUID_partition_scheme                        *500.3 GB   disk0
    1:                        EFI EFI                     209.7 MB   disk0s1
    2:          Apple_CoreStorage                         400.0 GB   disk0s2
    3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3
    4:          Apple_CoreStorage                         98.8 GB    disk0s4
    5:                 Apple_Boot Recovery HD             650.0 MB   disk0s5
    /dev/disk1
    #:                       TYPE NAME                    SIZE       IDENTIFIER
    0:                  Apple_HFS YosemiteHD             *399.6 GB   disk1
    Logical Volume on disk0s1
    8A142795-8036-48DF-9FC5-84506DFBB7B2
    Unlocked Encrypted
    /dev/disk2
    #:                       TYPE NAME                    SIZE       IDENTIFIER
    0:     FDisk_partition_scheme                        *8.0 GB     disk2
    1:               Windows_NTFS SanDisk USB             8.0 GB     disk2s1
  3. To identify your USB flash drive, compare the NAME, TYPE and SIZE columns to your flash drive. For example, the NAME should be the title of the flash drive icon in the Finder tool. You can also compare these values to those in the information panel of the flash drive.
  4. Use the diskutil unmountDisk command to unmount the flash drive’s filesystem volumes:

    $ diskutil unmountDisk /dev/disknumber
    					Unmount of all volumes on disknumber was successful

    When the command completes, the icon for the flash drive disappears from your desktop. If the icon does not disappear, you may have selected the wrong disk. Attempting to unmount the system disk accidentally returns a failed to unmount error.

  5. Log in as root:

    $ su -
  6. Enter your root password when prompted.
  7. Use the dd command as a parameter of the sudo command to write the ISO image to the flash drive:

    # sudo dd if=/path/to/image.iso of=/dev/rdisknumber bs=1m>
    Note

    Mac OS X provides both a block (/dev/disk*) and character device (/dev/rdisk*) file for each storage device. Writing an image to the /dev/rdisknumber character device is faster than writing to the /dev/disknumber block device.

  8. To write the /Users/user_name/Downloads/rhel-8-x86_64-boot.iso file to the /dev/rdisk2 device, run the following command:

    # sudo dd if=/Users/user_name/Downloads/rhel-8-x86_64-boot.iso of=/dev/rdisk2
  9. Wait for the dd command to finish writing the image to the device. The data transfer is complete when the # prompt appears. When the prompt is displayed, log out of the root account and unplug the USB drive. The USB drive is now ready to be used as a boot device.

4.7. Preparing an installation source

The Boot ISO image file does not include any repositories or software packages; it contains only the installation program and the tools required to boot the system and start the installation. This section contains information about creating an installation source for the Boot ISO image using the Binary DVD ISO image that contains the required repositories and software packages.

Important

Creating an installation source is required only for the Boot ISO image. Red Hat recommends the Binary DVD ISO image as the preferred method to install Red Hat Enterprise Linux.

4.7.1. Types of installation source

You can use one of the following installation sources for minimal boot images:

  • DVD: Burn the Binary DVD ISO image to DVD and configure the installation program to install the software packages.
  • Hard drive or USB drive: Copy the Binary DVD ISO image to the drive and configure the installation program to install the software packages from the drive. If you use a USB drive, verify that it is connected to the system before the installation begins. The installation program cannot detect media after the installation begins.

    • Hard drive limitation: The Binary DVD ISO image on the hard drive must be on a partition with a file system that the installation program can mount. The supported file systems are xfs, ext2, ext3, ext4, and vfat (FAT32).
Warning

On Microsoft Windows systems, the default file system used when formatting hard drives is NTFS; the exFAT file system is also available. However, neither of these file systems can be mounted during the installation. If you are creating a hard drive or a USB drive as an installation source on Microsoft Windows, verify that you formatted the drive as FAT32, however, the FAT32 file system cannot store files larger than 4 GiB.

In Red Hat Enterprise Linux 8 you can enable installation from a repository on a local hard drive. To do so, you need to copy the content of DVD ISO image to a directory on a hard drive and then specify the directory as installation source instead of the ISO image. For example: inst.repo=hd:<device>:<path to the repository>

  • Network location: Copy the Binary DVD ISO image or the installation tree (extracted contents of the Binary DVD ISO image) to a network location and perform the installation over the network using the following protocols:

    • NFS: The Binary DVD ISO image is in a Network File System (NFS) share.
    • HTTPS or HTTP: The installation tree is on a network location that is accessible over HTTP or HTTPS.

4.7.2. Specify the installation source

You can specify the installation source using any of the following methods:

  • Graphical installation: Select the installation source in the Installation Source window of the graphical install.
  • Boot option: Configure a custom boot option to specify the installation source.
  • Kickstart file: Use the install command in a Kickstart file to specify the installation source. See the Performing an advanced RHEL installation document for more information.

4.7.3. Ports for network-based installation

The following table lists the ports that must be open on the server providing the files for each type of network-based installation.

Table 4.2. Ports for network-based installation

Protocol usedPorts to open

HTTP

80

HTTPS

443

NFS

2049, 111, 20048

TFTP

69

Additional resources

4.7.4. Creating an installation source on an NFS server

Follow the steps in this procedure to place the installation source on an NFS server. Use this installation method to install multiple systems from a single source, without having to connect to physical media. A network-based installation is convenient when used with a TFTP server, as it enables you to boot the installation from the network. This approach eliminates the need to create physical media and simultaneously deploys Red Hat Enterprise Linux on multiple systems.

Prerequisites
  • You have downloaded a Binary DVD image. See Downloading the installation ISO image from the Performing a standard RHEL installation document for more information.
  • You have created a bootable CD, DVD, or USB device from the image file. See Creating installation media from the Performing a standard RHEL installation document for more information.
  • You have verified that your firewall allows the server you are installing to access the remote installation source. See Ports for network-based installation from the Performing a standard RHEL installation document for more information.
Procedure
Note

The NFS installation method uses the Binary DVD ISO image in a Network File System server’s exported directory, which the system must be able to read. To perform an NFS-based installation, another system must act as the NFS host. The steps to configure an NFS server vary depending on the system architecture, operating system, package manager, and service manager. This procedure contains a basic outline of the process.

  1. Install the nfs-utils package by running the following command as root:

    # yum install nfs-utils
  2. Copy the Binary DVD ISO image to a directory on the NFS server.
  3. Open the /etc/exports file using a text editor and add a line with the following syntax:

    /exported_directory/ clients
  4. Replace /exported_directory/ with the full path to the directory with the ISO image. Replace clients with the host name or IP address of the target system, the subnetwork that all target systems can use to access the ISO image, or the asterisk sign (*) if you want to allow any system with network access to the NFS server to use the ISO image. See the exports(5) man page for detailed information about the format of this field.

    A basic configuration that makes the /rhel8-install/ directory available as read-only to all clients is:

    /rhel8-install *
  5. Save the /etc/exports file and exit the text editor.
  6. Start the nfs service:

    # systemctl start nfs-server.service

    If the service was running before you changed the /etc/exports file, run the following command for the running NFS server to reload its configuration:

    # systemctl reload nfs-server.service

    The ISO image is now accessible over NFS and ready to be used as an installation source.

Note

When configuring the installation source, use nfs: as the protocol, the server host name or IP address, the colon sign (:), and the directory holding the ISO image. For example, if the server host name is myserver.example.com and you have saved the ISO image in /rhel8-install/, specify nfs:myserver.example.com:/rhel8-install/ as the installation source.

4.7.5. Creating an installation source using HTTP or HTTPS

Follow the steps in this procedure to create an installation source for a network-based installation using an installation tree, which is a directory containing extracted contents of the Binary DVD ISO image and a valid .treeinfo file. The installation source is accessed over HTTP or HTTPS.

Prerequisites
  • You have downloaded a Binary DVD image. See Downloading the installation ISO image from the Performing a standard RHEL installation document for more information.
  • You have created a bootable CD, DVD, or USB device from the image file. See Creating installation media from the Performing a standard RHEL installation document for more information.
  • You have verified that your firewall allows the server you are installing to access the remote installation source. See Ports for network-based installation from the Performing a standard RHEL installation document for more information.
Procedure
  1. Install the httpd package by running the following command as root:

    # yum install httpd
    Warning

    If your Apache web server configuration enables SSL security, verify that you enable only the TLSv1 protocol, and disable SSLv2 and SSLv3. This is due to the POODLE SSL vulnerability (CVE-2014-3566). See https://access.redhat.com/solutions/1232413 for details.

    Important

    If you use an HTTPS server with a self-signed certificate, you must boot the installation program with the noverifyssl option.

  2. Copy the Binary DVD ISO image to the HTTP(S) server.
  3. Mount the Binary DVD ISO image, using the mount command, to a suitable directory:

    # mount -o loop,ro -t iso9660 /image_directory/image.iso /mount_point/
    • Replace /image_directory/image.iso with the path to the Binary DVD ISO image.
    • Replace /mount_point/ with the path to the directory where you want to locate the contents of the ISO image.
  4. Copy the files from the mounted image to the HTTP(S) server root. This command creates the /var/www/html/rhel8-install/ directory with the contents of the image.

    # cp -r /mnt/rhel8-install/ /var/www/html/
  5. Start the httpd service:

    # systemctl start httpd.service

    The installation tree is now accessible and ready to be used as the installation source.

    Note

    When configuring the installation source, use http:// or https:// as the protocol, the server host name or IP address, and the directory that contains the files from the ISO image, relative to the HTTP server root. For example, if you are using HTTP, the server host name is myserver.example.com, and you have copied the files from the image to /var/www/html/rhel8-install/, specify http://myserver.example.com/rhel8-install/ as the installation source.

Additional resources

Chapter 5. Booting the installation

Installing Red Hat Enterprise Linux from the Binary DVD ISO is the easiest and the recommended method of performing a standard RHEL installation. Other installation methods require additional setup and configuration. For example, when installing Red Hat Enterprise Linux on a large number of systems simultaneously, the best approach is to boot from a PXE server and install from a source in a shared network location.

After you have created a bootable USB, DVD, or CD you are ready to boot the Red Hat Enterprise Linux installation.

5.1. Booting the installation from a USB, CD, or DVD

Follow the steps in this procedure to boot the Red Hat Enterprise Linux installation using a USB, CD, or DVD. The following steps are generic. Consult your hardware manufacturer’s documentation for specific instructions.

Prerequisite

You have created bootable installation media (USB, CD or DVD). See Section 4.6, “Creating installation media” for more information.

Procedure

  1. Power off the system to which you are installing Red Hat Enterprise Linux.
  2. Disconnect any drives from the system.
  3. Power on the system.
  4. Insert the bootable installation media (USB, DVD, or CD).
  5. Power off the system but do not remove the boot media.
  6. Power on the system.

    Note

    You might need to press a specific key or combination of keys to boot from the media or configure the Basic Input/Output System (BIOS) of your system to boot from the media. For more information, see the documentation that came with your system.

  7. The Red Hat Enterprise Linux boot window opens and displays information about a variety of available boot options.
  8. Use the arrow keys on your keyboard to select the boot option that you require, and press Enter to select the boot option. The Welcome to Red Hat Enterprise Linux window opens and you can install Red Hat Enterprise Linux using the graphical user interface.

    Note

    The installation program automatically begins if no action is performed in the boot window within 60 seconds.

  9. Optional: For UEFI-based systems, press E to edit the available boot options. For BIOS-based systems, press the Tab key on your keyboard to edit the available boot options. The boot window enters edit mode and you can change the predefined command line to add or remove boot options.

    1. Press Enter to confirm your choice.

5.2. Booting the installation from a network using PXE

Follow the steps in this procedure to boot the Red Hat Enterprise Linux installation from a network using PXE.

Prerequisites

  • You have configured a TFTP server, and there is a network interface in your system that supports PXE. See Additional resources for more information.
  • You have configured your system to boot from the network interface. This option is in the BIOS, and can be labeled Network Boot or Boot Services.
  • You have verified that the BIOS is configured to boot from the specified network interface. Some BIOS systems specify the network interface as a possible boot device, but do not support the PXE standard. See your hardware’s documentation for more information. When you have properly enabled PXE booting, the system can boot the Red Hat Enterprise Linux installation program without any other media.

Procedure

Note

To boot the installation process from a network using PXE, you must use a physical network connection, for example, Ethernet. You cannot boot the installation process with a wireless connection.

  1. Verify that the network cable is attached. The link indicator light on the network socket should be lit, even if the computer is not switched on.
  2. Switch on the system.

    Depending on your hardware, some network setup and diagnostic information can be displayed before your system connects to a PXE server. When connected, a menu is displayed according to the PXE server configuration.

  3. Press the number key that corresponds to the option that you require.

    Note

    In some instances, boot options are not displayed. If this occurs, press the Enter key on your keyboard or wait until the boot window opens.

    The Red Hat Enterprise Linux boot window opens and displays information about a variety of available boot options.

  4. Use the arrow keys on your keyboard to select the boot option that you require, and press Enter to select the boot option. The Welcome to Red Hat Enterprise Linux window opens and you can install Red Hat Enterprise Linux using the graphical user interface.

    Note

    The installation program automatically begins if no action is performed in the boot window within 60 seconds.

  5. Optional: For UEFI-based systems, press E to edit the available boot options. For BIOS-based systems, press the Tab key on your keyboard to edit the available boot options. The boot window enters edit mode and you can change the predefined command line to add or remove boot options.

    1. Press Enter to confirm your choice.

Additional Resources

5.3. Boot options

This section contains information about some of the boot options that you can use to modify the default behavior of the installation program. For a full list of boot options, see the upstream boot option content. For Kickstart and advanced boot options, see the Performing an advanced RHEL installation document.

5.3.1. Types of boot options

There are two types of boot options; those with an equals "=" sign, and those without an equals "=" sign. Boot options are appended to the boot command line and multiple options must be separated by a single space. Boot options that are specific to the installation program always start with inst.

Options with an equals "=" sign
You must specify a value for boot options that use the = symbol. For example, the inst.vncpassword= option must contain a value, in this case, a password. The correct syntax for this example is inst.vncpassword=password.
Options without an equals "=" sign
This boot option does not accept any values or parameters. For example, the rd.live.check option forces the installation program to verify the installation media before starting the installation. If this boot option is present, the verification is performed; if the boot option is not present, the verification is skipped.

5.3.2. Editing boot options

This section contains information about the different ways that you can edit boot options from the boot menu. The boot menu opens after you boot the installation media.

Editing the boot: prompt

When using the boot: prompt, the first option must always specify the installation program image file that you want to load. In most cases, you can specify the image using the keyword. You can specify additional options according to your requirements.

Prerequisites

  • You have created bootable installation media (USB, CD or DVD).
  • You have booted the installation from the media, and the installation boot menu is open.

Procedure

  1. With the boot menu open, press the Esc key on your keyboard.
  2. The boot: prompt is now accessible.
  3. Press the Tab key on your keyboard to display the help commands.
  4. Press the Enter key on your keyboard to start the installation with your options. To return from the boot: prompt to the boot menu, restart the system and boot from the installation media again.
Note

The boot: prompt also accepts dracut kernel options. A list of options is available in the dracut.cmdline(7) man page.

Editing the > prompt

You can use the > prompt to edit predefined boot options. For example, select Test this media and install Red Hat Enterprise Linux 8.0.0 from the boot menu to display a full set of options.

Note

This procedure is for BIOS-based AMD64 and Intel 64 systems.

Prerequisites

  • You have created bootable installation media (USB, CD or DVD).
  • You have booted the installation from the media, and the installation boot menu is open.

Procedure

  1. From the boot menu, select an option and press the Tab key on your keyboard. The > prompt is accessible and displays the available options.
  2. Append the options that you require to the > prompt.
  3. Press the Enter key on your keyboard to start the installation.
  4. Press the Esc key on your keyboard to cancel editing and return to the boot menu.
Editing the GRUB2 menu

The GRUB2 menu is available on UEFI-based AMD64, Intel 64, and 64-bit ARM systems.

Prerequisites

  • You have created bootable installation media (USB, CD or DVD).
  • You have booted the installation from the media, and the installation boot menu is open.

Procedure

  1. From the boot menu window, select an option and press the e key on your keyboard.
  2. When you finish editing, press F10 or Ctrl+X on your keyboard to start the installation using the specified options.

5.3.3. Installation source boot options

This section contains information about the various installation source boot options.

inst.repo=

The inst.repo= boot option specifies the installation source, that is, the location of images and packages. For example: inst.repo=cdrom. The target of the inst.repo= option must be one of the following installation media:

  • an installable tree, which is a directory structure containing the installation program images, packages, and repository data as well as a valid .treeinfo file
  • a DVD (a physical disk present in the system DVD drive)
  • an ISO image of the full Red Hat Enterprise Linux installation DVD, placed on a hard drive or a network location accessible to the system.

    You can use the inst.repo= boot option to configure different installation methods using different formats. The following table contains details of the inst.repo= boot option syntax:

    Table 5.1. Installation source boot options

    Installation sourceBoot option format

    Any CD/DVD drive

    inst.repo=cdrom

    Specific CD/DVD drive

    inst.repo=cdrom:device

    Hard Drive

    inst.repo=hd:device:/path

    HMC

    inst.repo=hmc

    HTTP Server

    inst.repo=http://host/path

    HTTPS Server

    inst.repo=https://host/path

    NFS Server

    inst.repo=nfs:[options:]server:/path

    Note

    The NFS Server option uses NFS protocol version 3 by default. To use a different version, add +nfsvers=X to the option.

    You can set disk device names with the following formats:

  • Kernel device name, for example /dev/sda1 or sdb2
  • File system label, for example LABEL=Flash or LABEL=RHEL8
  • File system UUID, for example UUID=8176c7bf-04ff-403a-a832-9557f94e61db

    Non-alphanumeric characters must be represented as \xNN, where NN is the hexadecimal representation of the character. For example, \x20 is a white space (" ").

inst.stage2=

The inst.stage2= boot option specifies the location of the installation program runtime image. This option expects a path to a directory containing a valid .treeinfo file. The location of the runtime image is read from the .treeinfo file. If the .treeinfo file is not available, the installation program attempts to load the image from LiveOS/squashfs.img.

You can use the inst.stage2= boot option multiple times to specify multiple HTTP or HTTPS sources. For example:

inst.stage2=host1/install.img inst.stage2=host2/install.img
inst.stage2=host3/install.img
Note

By default, the inst.stage2= boot option is used on the installation media and is set to a specific label, for example, inst.stage2=hd:LABEL=RHEL-8-0-0-BaseOS-x86_64. If you modify the default label of the file system containing the runtime image, or if you use a customized procedure to boot the installation system, you must verify that the inst.stage2= boot option is set to the correct value.

inst.dd=
The inst.dd= boot option is used to perform a driver update during the installation. See the Performing an advanced RHEL installation document for information on how to update drivers during installation.
inst.repo=hmc
When booting from a Binary DVD, the installation program prompts you to enter additional kernel parameters. To set the DVD as an installation source, append inst.repo=hmc to the kernel parameters. The installation program then enables SE and HMC file access, fetches the images for stage2 from the DVD, and provides access to the packages on the DVD for software selection. This option eliminates the requirement of an external network setup and expands the installation options.
Additional resources

5.3.4. Network boot options

This section contains information about commonly used network boot options.

Note

Initial network initialization is handled by dracut. For a complete list, see the dracut.cmdline(7) man page.

ip=

Use the ip= boot option to configure one or more network interfaces. To configure multiple interfaces, you can use the ip option multiple times - once for each interface. If you configure multiple interfaces, you must specify a primary boot interface using the bootdev option. Alternatively, you can use the ip option once, and then use Kickstart to set up further interfaces. This option accepts several different formats. The following tables contain information about the most common options.

Note

In the following tables:

  • The ip parameter specifies the client IP address. You can specify IPv6 addresses in square brackets, for example, [2001:DB8::1].
  • The gateway parameter is the default gateway. IPv6 addresses are also accepted.
  • The netmask parameter is the netmask to be used. This can be either a full netmask (for example, 255.255.255.0) or a prefix (for example, 64).
  • The hostname parameter is the host name of the client system. This parameter is optional.

Table 5.2. Network interface configuration boot option formats

Configuration methodBoot option format

Automatic configuration of any interface

ip=method

Automatic configuration of a specific interface

ip=interface:method

Static configuration

ip=ip::gateway:netmask:hostname:interface:none

Automatic configuration of a specific interface with an override

ip=ip::gateway:netmask:hostname:interface:method:mtu

Note

The method automatic configuration of a specific interface with an override brings up the interface using the specified method of automatic configuration, such as dhcp, but overrides the automatically-obtained IP address, gateway, netmask, host name or other specified parameters. All parameters are optional, so specify only the parameters that you want to override.

The method parameter can be any of the following:

Table 5.3. Automatic interface configuration methods

Automatic configuration methodValue

DHCP

dhcp

IPv6 DHCP

dhcp6

IPv6 automatic configuration

auto6

iSCSI Boot Firmware Table (iBFT)

ibft

Note
  • If you use a boot option that requires network access, such as inst.ks=http://host:/path, without specifying the ip option, the installation program uses ip=dhcp.
  • To connect to an iSCSI target automatically, you must activate a network device for accessing the target. The recommended way to activate a network is to use the ip=ibft boot option.
nameserver=
The nameserver= option specifies the address of the name server. You can use this option multiple times.
rd.neednet=
Typically, ip= options are applied only if the network is required by the installation (based on any other boot options that are used). You can use rd.neednet=1 to explicitly force the application of ip= options.
bootdev=
The bootdev= option specifies the boot interface. This option is mandatory if you use more than one ip option.
ifname=

The ifname= options assigns an interface name to a network device with a given MAC address. You can use this option multiple times. The syntax is ifname=interface:MAC. For example:

ifname=eth0:01:23:45:67:89:ab
Note

The ifname= option is the only supported way to set custom network interface names during installation.

inst.dhcpclass=
The inst.dhcpclass= option specifies the DHCP vendor class identifier. The dhcpd service sees this value as vendor-class-identifier. The default value is anaconda-$(uname -srm).
inst.waitfornet=
Using the inst.waitfornet=SECONDS boot option causes the installation system to wait for network connectivity before installation. The value given in the SECONDS argument specifies the maximum amount of time to wait for network connectivity before timing out and continuing the installation process even if network connectivity is not present.
vlan=

Use the vlan= option to configure a Virtual LAN (VLAN) device on a specified interface with a given name. The syntax is vlan=name:interface. For example:

vlan=vlan5:em1

This configures a VLAN device named vlan5 on the em1 interface. The name can take the following forms:

Table 5.4. VLAN device naming conventions

Naming schemeExample

VLAN_PLUS_VID

vlan0005

VLAN_PLUS_VID_NO_PAD

vlan5

DEV_PLUS_VID

em1.0005

DEV_PLUS_VID_NO_PAD

em1.5

bond=

Use the bond= option to configure a bonding device with the following syntax: bond=name[:slaves][:options]. Replace name with the bonding device name, slaves with a comma-separated list of physical (ethernet) interfaces, and options with a comma-separated list of bonding options. For example:

bond=bond0:em1,em2:mode=active-backup,tx_queues=32,downdelay=5000

For a list of available options, execute the modinfo bonding command. Using this option without any parameters assumes bond=bond0:eth0,eth1:mode=balance-rr.

team=

Use the team= option to configure a team device with the following syntax: team=master:slaves. Replace master with the name of the master team device and slaves with a comma-separated list of physical (ethernet) devices to be used as slaves in the team device. For example:

team=team0:em1,em2
Additional resources

5.3.5. Console boot options

This section contains information about configuring boot options for your console, monitor display, and keyboard.

console=
Use the console= option to specify a device that you want to use as the primary console. For example, to use a console on the first serial port, use console=ttyS0. Use this option in conjunction with the inst.text option. You can use the console= option multiple times. If you do, the boot message is displayed on all specified consoles, but only the last one is used by the installation program. For example, if you specify console=ttyS0 console=ttyS1, the installation program uses ttyS1.
noshell
Use the noshell option to disable access to the root shell during installation. This is useful with Kickstart installations.
inst.lang=
Use the inst.lang= option to set the language that you want to use during the installation. locale -a or localectl list-locales returns a list of locales.
inst.geoloc=

Use the inst.geoloc= option to configure geolocation usage in the installation program. Geolocation is used to preset the language and time zone, and uses the following syntax: inst.geoloc=value. The value can be any of the following parameters:

Table 5.5. Values for the inst.geoloc boot option

ValueBoot option format

Disable geolocation

inst.geoloc=0

Use the Fedora GeoIP API

inst.geoloc=provider_fedora_geoip

Use the Hostip.info GeoIP API

inst.geoloc=provider_hostip

If you do not specify the inst.geoloc= option, the installation program uses provider_fedora_geoip.

inst.keymap=
Use the inst.keymap= option to specify the keyboard layout that you want to use for the installation.
inst.text
Use the inst.text option to force the installation program to run in text mode instead of graphical mode.
inst.cmdline
Use the inst.cmdline option to force the installation program to run in command-line mode. This mode does not allow any interaction, and you must specify all options in a Kickstart file or on the command line.
inst.graphical
Use the inst.graphical option to force the installation program to run in graphical mode. This mode is the default.
inst.resolution=
Use the inst.resolution= option to specify the screen resolution in graphical mode. The format is NxM, where N is the screen width and M is the screen height (in pixels). The lowest supported resolution is 800x600.
inst.xdriver=
Use the inst.xdriver= option to specify the name of the X driver that you want to use both during installation and on the installed system.
inst.usefbx
Use the inst.usefbx option to prompt the installation program to use the frame buffer X driver instead of a hardware-specific driver. This option is equivalent to inst.xdriver=fbdev.
modprobe.blacklist=

Use the modprobe.blacklist= option to blacklist or completely disable one or more drivers. Drivers (mods) that you disable using this option cannot load when the installation starts, and after the installation finishes, the installed system retains these settings. You can find a list of the blacklisted drivers in the /etc/modprobe.d/ directory. Use a comma-separated list to disable multiple drivers. For example:

modprobe.blacklist=ahci,firewire_ohci
inst.sshd=0
By default, the sshd option is automatically started only on the IBM Z architecture. On other architectures, sshd is not started unless you use the inst.sshd option. Use the inst.sshd=0 option to prevent sshd from starting automatically on IBM Z.
inst.sshd

Use the inst.sshd option to start the sshd service during installation, so that you can connect to the system during the installation using SSH, and monitor the installation progress. For more information about SSH, see the ssh(1) man page. By default, the sshd option is automatically started only on the IBM Z architecture. On other architectures, sshd is not started unless you use the inst.sshd option.

Note

During installation, the root account has no password by default. You can set a root password during installation with the sshpw Kickstart command.

inst.kdump_addon=
Use the inst.kdump_addon= option to enable or disable the Kdump configuration screen (add-on) in the installation program. This screen is enabled by default; use inst.kdump_addon=off to disable it. Disabling the add-on disables the Kdump screens in both the graphical and text-based interface as well as the %addon com_redhat_kdump Kickstart command.
Additional resources

5.3.6. Debug boot options

This section contains information about the options that you can use when debugging issues.

inst.rescue=
Use the inst.rescue= option to run the rescue environment. The option is useful for trying to diagnose and fix systems.
inst.updates=

Use the inst.updates= option to specify the location of the updates.img file that you want to apply during installation. There are a number of sources for the updates.

Updates from a network

The easiest way to use inst.updates= is to specify the network location of updates.img. This does not require any modification to the installation tree. To use this method, edit the kernel command line to include inst.updates, for example:

inst.updates=http://some.website.com/path/to/updates.img
Updates from a disk image

You can also save an updates.img on a floppy drive or a USB key. This can be done only with an ext2 filesystem type of updates.img. To save the contents of the image on your floppy drive, insert the floppy disc and run the following command:

dd if=updates.img of=/dev/fd0 bs=72k count=20

To use a USB key or flash media, replace /dev/fd0 with the device name of your USB key.

Updates from an installation tree

If you are using a CD, hard drive, or HTTP install, you can save the updates.img in the installation tree so that all installations can detect the .img. Save the file in the images/ directory. The file name must be updates.img.

For NFS installs, there are two options: You can either save the image in the images/ directory, or in the RHupdates/ directory in the installation tree.

inst.loglevel=
Use the inst.loglevel= option to specify the minimum level of messages logged on a terminal. This concerns only terminal logging; log files always contain messages of all levels. Possible values for this option from the lowest to highest level are: debug, info, warning, error and critical. The default value is info, which means that by default, the logging terminal displays messages ranging from info to critical.
inst.syslog=
When installation starts, the inst.syslog= option sends log messages to the syslog process on the specified host. The remote syslog process must be configured to accept incoming connections.
inst.virtiolog=
Use the inst.virtiolog= option to specify the virtio port (a character device at /dev/virtio-ports/name) that you want to use for forwarding logs. The default value is org.fedoraproject.anaconda.log.0; if this port is present, it is used.
inst.nokill
The inst.nokill option is a debugging option that prevents the installation program from rebooting when a fatal error occurs, or at the end of the installation process. Use the inst.nokill option to capture installation logs which would be lost upon reboot.
Additional resources

Chapter 6. Installing RHEL using the Graphical User Interface

This section contains information about installing Red Hat Enterprise Linux using the Graphical User Interface (GUI). The GUI is the preferred method of installing Red Hat Enterprise Linux when you boot the system from a CD, DVD, or USB flash drive, or from a network using PXE.

Note

There may be some variance between the online help and the content that is published on the Customer Portal. For the latest updates, see the installation content on the Customer Portal.

6.1. Graphical installation workflow

Complete the following steps to install Red Hat Enterprise Linux using the graphical user interface:

Steps

  1. Configure language and location settings. See Section 6.2, “Configuring language and location settings” for more information.
  2. Configure localization settings. See Section 6.4, “Configuring localization options” for more information.
  3. Select the installation source and software packages that you require. See Section 6.5, “Configuring software options” for more information.
  4. Configure installation destination, KDUMP, network, security policy, and system purpose. See Section 6.6, “Configuring system options” for more information.
  5. Configure storage. See Section 6.7, “Configuring storage devices” for more information.
  6. Start the installation and create a user account and password. See Section 6.9, “Starting the installation program” for more information.
  7. Complete the graphical installation. See Section 6.9.4, “Graphical installation complete” for more information.
Note

When installing from a network location, you must configure the network before you can select the software packages that you want to install.

6.2. Configuring language and location settings

The installation program uses the language that you select during installation, and on the installed system.

Prerequisites

  1. You created installation media.
  2. You specified an installation source if you are using the Boot ISO image file.
  3. You booted the installation.

Procedure

  1. From the left-hand pane of the Welcome to Red Hat Enterprise Linux window, select a language. Alternatively, type your preferred language into the Search field.

    Note

    A language is pre-selected by default. If network access is configured, that is, if you booted from a network server instead of local media, the pre-selected language is determined by the automatic location detection feature of the GeoIP module. If you used the inst.lang= option on the boot command line or in your PXE server configuration, then the language that you define with the boot option is selected.

  2. From the right-hand pane of the Welcome to Red Hat Enterprise Linux window, select a location specific to your region.
  3. Click Continue to proceed to the Section 6.3, “The Installation Summary window” window.

    Important

    If you are installing a pre-release version of Red Hat Enterprise Linux, a warning message is displayed about the pre-release status of the installation media. Click I want to proceed to continue with the installation, or I want to exit to quit the installation and reboot the system.

Additional resources

For information about how to change language and location settings during the installation program, see Section 6.4, “Configuring localization options”

6.3. The Installation Summary window

The Installation Summary window is the central location for the Red Hat Enterprise Linux 8 installation program.

Figure 6.1. Installation summary

The Installation Summary window, showing most of the options configured. The Installation Destination icon has a warning sign, which means it requires user attention before the installation can proceed.

The Installation Summary window contains three categories:

  • LOCALIZATION: You can configure Keyboard, Language Support, and Time and Date.
  • SOFTWARE: You can configure Installation Source and Software Selection.
  • SYSTEM: You can configure Installation Destination, KDUMP, Network and Host Name, Security Policy, and System Purpose.

A category can have a different status depending on where it is in the installation program.

Table 6.1. Category status

Category statusStatusDescription

Warning symbol type 1

Yellow triangle with an exclamation mark and red text

Requires attention before installation. For example, Installation Destination requires attention as you must confirm the default automatic partitioning variant.

Warning symbol type 2

Grayed out and with a warning symbol (yellow triangle with an exclamation mark)

The installation program is configuring a category and you must wait for it to finish before accessing the window.

Note

A warning message is displayed at the bottom of the Installation Summary window and the Begin Installation button is disabled until you configure all of the required categories.

6.4. Configuring localization options

This section contains information about configuring your keyboard, language support, and time and date settings.

Important

If you use a layout that cannot accept Latin characters, such as Russian, add the English (United States) layout and configure a keyboard combination to switch between the two layouts. If you select only a layout that does not have Latin characters, you might be unable to enter a valid root password and user credentials later in the installation process. This can prevent you from completing the installation.

6.4.1. Configuring keyboard, language, and time and date settings

Note

Keyboard, Language, and Time and Date Settings are configured by default as part of Section 6.2, “Configuring language and location settings”. To change any of the settings, complete the following steps, otherwise proceed to Section 6.5, “Configuring software options”.

Procedure: Configuring keyboard settings

  1. From the Installation Summary window, click Keyboard. The default layout depends on the option selected in Section 6.2, “Configuring language and location settings”.

    1. Click + to open the Add a Keyboard Layout window and change to a different layout.
    2. Select a layout by browsing the list or use the Search field.
    3. Select the required layout and click Add. The new layout appears under the default layout.
    4. Click Options to optionally configure a keyboard switch that you can use to cycle between available layouts. The Layout Switching Options window opens.
    5. To configure key combinations for switching, select one or more key combinations and click OK to confirm your selection.

      Note

      When you select a layout, click the Keyboard button to open a new dialog box that displays a visual representation of the selected layout.

    6. Click Done to apply the settings and return to Section 6.3, “The Installation Summary window”.

Procedure: Configuring language settings

  1. From the Installation Summary window, click Language Support. The Language Support window opens. The left pane lists the available language groups. If at least one language from a group is configured, a check mark is displayed and the supported language is highlighted.

    1. From the left pane, click a group to select additional languages, and from the right pane, select regional options. Repeat this process for languages that you require.
    2. Click Done to apply the changes and return to Section 6.3, “The Installation Summary window”.

Procedure: Configuring time and date settings

  1. From the Installation Summary window, click Time & Date. The Time & Date window opens.

    Note

    The Time & Date settings are configured by default based on the settings you selected in Section 6.2, “Configuring language and location settings”.

    The list of cities and regions come from the Time Zone Database (tzdata) public domain that is maintained by the Internet Assigned Numbers Authority (IANA). Red Hat can not add cities or regions to this database. You can find more information at the IANA official website.

    1. From the Region drop-down menu, select a region.

      Note

      Select Etc as your region to configure a time zone relative to Greenwich Mean Time (GMT) without setting your location to a specific region.

    2. From the City drop-down menu, select the city, or the city closest to your location in the same time zone.
    3. Toggle the Network Time switch to enable or disable network time synchronization using the Network Time Protocol (NTP).

      Note

      Enabling the Network Time switch keeps your system time correct as long as the system can access the internet. By default, one NTP pool is configured; you can add a new option, or disable or remove the default options by clicking the gear wheel button next to the Network Time switch.

    4. Click Done to apply the changes and return to Section 6.3, “The Installation Summary window”.
    Note

    If you disable network time synchronization, the controls at the bottom of the window become active, allowing you to set the time and date manually.

6.5. Configuring software options

This section contains information about configuring your installation source and software selection settings, and activating a repository.

6.5.1. Configuring installation source

Follow the steps in this procedure to configure the Binary DVD ISO image as the installation source, which is the recommended method of installing Red Hat Enterprise Linux.

Prerequisites

  • You have downloaded the full installation image.
  • You have created a bootable physical media.
  • The Installation Summary window is open.
Note

When the Installation Summary window first opens, the installation program attempts to configure an installation source based on the type of media that was used to boot the system. The full Red Hat Enterprise Linux Server DVD configures the source as local media.

Procedure

  1. From the Installation Summary window, click Installation Source. The Installation Source window opens.

    1. Review the Auto-detected installation section to verify the details. This option is selected by default if you started the installation program from media containing an installation source, for example, a DVD.
    2. Click Verify to check the media integrity.
    3. Review the Additional repositories section and note that the Appstream checkbox is selected by default.

      Important
      • No additional configuration is necessary as the BaseOS and Appstream repositories are installed as part of the full installation image.
      • Do not disable the Appstream repository check box if you want a full Red Hat Enterprise Linux 8 installation.
  2. Select the On the network option to download and install packages from a network location instead of local media.

    Note
    1. Select the On the network drop-down menu to specify the protocol for downloading packages. This setting depends on the server that you want to use.

      Warning

      The Appstream repository check box is disabled if you select On the network and then decide to revert to Auto-detected installation. You must select the Appstream check box to enable the Appstream repository.

    2. Type the server address (without the protocol) into the address field. If you choose NFS, a second input field opens where you can specify custom NFS mount options. This field accepts options listed in the nfs(5) man page.

      Important

      When selecting an NFS installation source, you must specify the address with a colon (:) character separating the host name from the path. For example:

      server.example.com:/path/to/directory
      Note

      The following steps are optional and are only required if you use a proxy for network access.

    3. Click Proxy setup…​ to configure a proxy for an HTTP or HTTPS source.
    4. Select the Enable HTTP proxy check box and type the URL into the Proxy Host field.
    5. Select the Use Authentication check box if the proxy server requires authentication.
    6. Type in your user name and password.
    7. Click OK to finish the configuration and exit the Proxy Setup…​ dialog box.

      Note

      If your HTTP or HTTPS URL refers to a repository mirror menu, select the required option from the URL type drop-down list. All environments and add-ons are available for selection when you finish configuring the sources.

  3. Click + to add a repository.
  4. Click - to delete a repository.
  5. Click the arrow icon to revert the current entries to the setting when you opened the Installation Source window.
  6. To activate or deactivate a repository, click the check box in the Enabled column for each entry in the list.

    Note

    You can name and configure your additional repository in the same way as the primary repository on the network.

  7. Click Done to apply the settings and return to the Installation Summary window.

6.5.2. Configuring software selection

Use the Software Selection window to select the software packages that you require. The packages are organized by Base Environments and Add-Ons.

  • Base Environments are predefined packages. You can select only one base environment, and availability is dependent on the installation ISO image used as the installation source.
  • Add-Ons are additional packages for the base environment. You can select multiple add-ons.

Use the predefined environments and add-ons to customize your system, but in a standard installation, you cannot select individual packages to install. To view the packages contained in a specific environment or add-on, see the repository/repodata/*-comps-repository.architecture.xml file on your installation source media (DVD, CD, USB). The XML file contains details of the packages installed as part of a base environment or add-on. Available environments are marked by the <environment> tag, and add-ons are marked by the <group> tag.

If you are unsure about which packages to install, Red Hat recommends that you select the Minimal Install base environment. Minimal install installs a basic version of Red Hat Enterprise Linux with only a minimal amount of additional software. After the system finishes installing and you log in for the first time, you can use the Yum package manager to install additional software. For more information about Yum package manager, see the Configuring basic system settings document.

Note
  • The yum group list command lists all package groups from yum repositories. See the Configuring basic system settings document for more information.
  • If you need to control which packages are installed, you can use a Kickstart file and define the packages in the %packages section. See the Performing an advanced RHEL installation document for information about installing Red Hat Enterprise Linux using Kickstart.

Prerequisites

  • You have configured the installation source.
  • The installation program downloaded package metadata.
  • The Installation Summary window is open.

Procedure

  1. From the Installation Summary window, click Software Selection. The Software Selection window opens.
  2. From the Base Environment pane, select a base environment. You can select only one base environment.

    Note

    The Server with GUI base environment is the default base environment and it launches the Initial Setup application after the installation completes and you restart the system.

  3. From the Add-Ons for Selected Environment pane, select one or more add-ons.
  4. Click Done to apply the settings and return to Section 6.3, “The Installation Summary window”.

6.6. Configuring system options

This section contains information about configuring Installation Destination, KDUMP, Network and Host Name, Security Policy, and System Purpose.

6.6.1. Configuring installation destination

Use the Installation Destination window to configure the storage options, for example, the disks that you want to use as the installation target for your Red Hat Enterprise Linux installation. You must select at least one disk.

Warning

Back up your data if you plan to use a disk that already contains data. For example, if you want to shrink an existing Microsoft Windows partition and install Red Hat Enterprise Linux as a second system, or if you are upgrading a previous release of Red Hat Enterprise Linux. Manipulating partitions always carries a risk. For example, if the process is interrupted or fails for any reason data on the disk can be lost.

Important
  • Some BIOS types do not support booting from a RAID card. In these instances, the /boot partition must be created on a partition outside of the RAID array, such as on a separate hard drive. It is necessary to use an internal hard drive for partition creation with problematic RAID cards. A /boot partition is also necessary for software RAID setups. If you choose to partition your system automatically, you should manually edit your /boot partition.
  • To configure the Red Hat Enterprise Linux boot loader to chain load from a different boot loader, you must specify the boot drive manually by clicking the Full disk summary and bootloader link from the Installation Destination window.
  • When you install Red Hat Enterprise Linux on a system with both multipath and non-multipath storage devices, the automatic partitioning layout in the installation program creates volume groups that contain a mix of multipath and non-multipath devices. This defeats the purpose of multipath storage. It is recommended that you select either multipath or non-multipath devices on the Installation Destination window. Alternatively, proceed to manual partitioning.

Prerequisite

The Installation Summary window is open.

Procedure

  1. From the Installation Summary window, click Installation Destination. The Installation Destination window opens.

    1. From the Local Standard Disks section, select the storage device that you require; a white check mark indicates your selection. Disks without a white check mark are not used during the installation process; they are ignored if you choose automatic partitioning, and they are not available in manual partitioning.

      Note

      All locally available storage devices (SATA, IDE and SCSI hard drives, USB flash and external disks) are displayed under Local Standard Disks. Any storage devices connected after the installation program has started are not detected. If you use a removable drive to install Red Hat Enterprise Linux, your system is unusable if you remove the device.

    2. Optional: Click the Refresh link in the lower right-hand side of the window if you want to configure additional local storage devices to connect new hard drives. The Rescan Disks dialog box opens.

      Note

      All storage changes that you make during the installation are lost when you click Rescan Disks.

      1. Click Rescan Disks and wait until the scanning process completes.
      2. Click OK to return to the Installation Destination window. All detected disks including any new ones are displayed under the Local Standard Disks section.
  2. Optional: To add a specialized storage device, click Add a disk…​.

    The Storage Device Selection window opens and lists all storage devices that the installation program has access to. For information about how to add a specialized disk, see Section 6.7.3, “Using advanced storage options”.

  3. Optional: Under Storage Configuration, select the Automatic radio button.

    Important

    Automatic partitioning is the recommended method of partitioning your storage. You can also configure custom partitioning, for more details see Section 6.8, “Configuring manual partitioning”

  4. Optional: To reclaim space from an existing partitioning layout, select the I would like to make additional space available check box. For example, if a disk you want to use already contains a different operating system and you want to make this system’s partitions smaller to allow more room for Red Hat Enterprise Linux.
  5. Optional: Select Encrypt my data to encrypt all partitions except the ones needed to boot the system (such as /boot) using Linux Unified Key Setup (LUKS). Encrypting your hard drive is recommended.

    1. If you selected Encrypt my data the Disk Encryption Passphrase dialog box opens.

      1. Type your passphrase in the Passphrase and Confirm fields.
      2. Click Save Passphrase to complete disk encryption.

        Warning

        If you lose the LUKS passphrase, any encrypted partitions and their data is completely inaccessible. There is no way to recover a lost passphrase. However, if you perform a Kickstart installation, you can save encryption passphrases and create backup encryption passphrases during the installation. See the Performing an advanced RHEL installation document for information.

  6. Optional: Click the Full disk summary and bootloader link in the lower left-hand side of the window to select which storage device contains the boot loader. For more information, see Section 6.6.1.1, “Configuring boot loader”.

    Note

    In most cases it is sufficient to leave the boot loader in the default location. Some configurations, for example, systems that require chain loading from another boot loader require the boot drive to be specified manually.

  7. Click Done.

    1. If you selected automatic partitioning and I would like to make additional space available, or if there is not enough free space on your selected hard drives to install Red Hat Enterprise Linux, the Reclaim Disk Space dialog box opens when you click Done, and lists all configured disk devices and all partitions on those devices. The dialog box displays information about how much space the system needs for a minimal installation and how much space you have reclaimed.

      Warning

      If you delete a partition, all data on that partition is lost. If you want to preserve your data, use the Shrink option, not the Delete option.

    2. Review the displayed list of available storage devices. The Reclaimable Space column shows how much space can be reclaimed from each entry.
    3. To reclaim space, select a disk or partition, and click either the Delete button to delete that partition, or all partitions on a selected disk, or click Shrink to use free space on a partition while preserving the existing data.

      Note

      Alternatively, you can click Delete all, this deletes all existing partitions on all disks and makes this space available to Red Hat Enterprise Linux. Existing data on all disks is lost.

    4. Click Reclaim space to apply the changes and return to Section 6.3, “The Installation Summary window”.
Important

No disk changes are made until you click Begin Installation on the Installation Summary window. The Reclaim Space dialog only marks partitions for resizing or deletion; no action is performed.

6.6.1.1. Configuring boot loader

Red Hat Enterprise Linux uses GRand Unified Bootloader version 2 (GRUB2) as the boot loader for AMD64 and Intel 64, IBM Power Systems, and ARM. For IBM Z, the zipl boot loader is used.

The boot loader is the first program that runs when the system starts and is responsible for loading and transferring control to an operating system. GRUB2 can boot any compatible operating system (including Microsoft Windows) and can also use chain loading to transfer control to other boot loaders for unsupported operating systems.

Warning

Installing GRUB2 may overwrite your existing boot loader.

If an operating system is already installed, the Red Hat Enterprise Linux installation program attempts to automatically detect and configure the boot loader to start the other operating system. If the boot loader is not detected, you can manually configure any additional operating systems after you finish the installation.

If you are installing a Red Hat Enterprise Linux system with more than one disk, you might want to manually specify the disk where you want to install the boot loader.

Procedure

  1. From the Installation Destination window, click the Full disk summary and bootloader link. The Selected Disks dialog box opens.

    The boot loader is installed on the device of your choice, or on a UEFI system; the EFI system partition is created on the target device during guided partitioning.

  2. To change the boot device, select a device from the list and click Set as Boot Device. You can set only one device as the boot device.
  3. To disable a new boot loader installation, select the device currently marked for boot and click Do not install boot loader. This ensures GRUB2 is not installed on any device.
Warning

If you choose not to install a boot loader, you cannot boot the system directly and you must use another boot method, such as a standalone commercial boot loader application. Use this option only if you have another way to boot your system.

The boot loader may also require a special partition to be created, depending on if your system uses BIOS or UEFI firmware, or if the boot drive has a GUID Partition Table (GPT) or a Master Boot Record (MBR, also known as msdos) label. If you use automatic partitioning, the installation program creates the partition.

6.6.2. Configuring Kdump

Kdump is a kernel crash-dumping mechanism. In the event of a system crash, Kdump captures the contents of the system memory at the moment of failure. This captured memory can be analyzed to find the cause of the crash. If Kdump is enabled, it must have a small portion of the system’s memory (RAM) reserved to itself. This reserved memory is not accessible to the main kernel.

Procedure

  1. From the Installation Summary window, click Kdump. The Kdump window opens.
  2. Select the Enable kdump check box.
  3. Select either the Automatic or Manual memory reservation setting.

    1. If you select Manual, enter the amount of memory (in megabytes) that you want to reserve in the Memory to be reserved field using the + and - buttons. The Usable System Memory readout below the reservation input field shows how much memory is accessible to your main system after reserving the amount of RAM that you select.
  4. Click Done to apply the settings and return to Section 6.3, “The Installation Summary window”.
Note

The amount of memory that you reserve is determined by your system architecture (AMD64 and Intel 64 have different requirements than IBM Power) as well as the total amount of system memory. In most cases, automatic reservation is satisfactory.

Important

Additional settings, such as the location where kernel crash dumps will be saved, can only be configured after the installation using either the system-config-kdump graphical interface, or manually in the /etc/kdump.conf configuration file.

6.6.3. Configuring network and host name options

Use the Network and Host name window to configure network interfaces. Options that you select here are available both during the installation for tasks such as downloading packages from a remote location, and on the installed system.

6.6.3.1. Configuring network and host name

Follow the steps in this procedure to configure your network and host name.

Procedure

  1. From the Installation Summary window, click Network and Host Name.
  2. From the list in the left-hand pane, select an interface. The details are displayed in the right-hand pane.
  3. Toggle the ON/OFF switch to enable or disable the selected interface.

    Note

    Locally accessible interfaces are automatically detected by the installation program and cannot be manually added or deleted.

  4. Click + to add a virtual network interface, which can be either: Team, Bond, Bridge, or VLAN.
  5. Click - to remove a virtual interface.
  6. Click Configure to change settings such as IP addresses, DNS servers, or routing configuration for an existing interface (both virtual and physical).
  7. Type a host name for your system in the Host Name field.

    Note
    • There are several types of network device naming standards used to identify network devices with persistent names, for example, em1 and wl3sp0. For information about these standards, see the Configuring and managing networking document.
    • The host name can be either a fully-qualified domain name (FQDN) in the format hostname.domainname, or a short host name with no domain name. Many networks have a Dynamic Host Configuration Protocol (DHCP) service that automatically supplies connected systems with a domain name. To allow the DHCP service to assign the domain name to this machine, specify only the short host name. The value localhost.localdomain means that no specific static host name for the target system is configured, and the actual host name of the installed system is configured during the processing of the network configuration, for example, by NetworkManager using DHCP or DNS.
  8. Click Apply to apply the host name to the environment.

6.6.3.2. Adding a virtual network interface

Follow the steps in this procedure to add a virtual network interface.

Procedure

  1. From the Network & Host name window, click the + button to add a virtual network interface. The Add a device dialog opens.
  2. Select one of the four available types of virtual interfaces:

    • Bond: NIC (Network Interface Controller) Bonding, a method to bind multiple physical network interfaces together into a single bonded channel.
    • Bridge: Represents NIC Bridging, a method to connect multiple separate networks into one aggregate network.
    • Team: NIC Teaming, a new implementation to aggregate links, designed to provide a small kernel driver to implement the fast handling of packet flows, and various applications to do everything else in user space.
    • Vlan (Virtual LAN): A method to create multiple distinct broadcast domains which are mutually isolated.
  3. Select the interface type and click Add. An editing interface dialog box opens, allowing you to edit any available settings for your chosen interface type. For more information see Section 6.6.3.3, “Editing network interface configuration”.
  4. Click Save to confirm the virtual interface settings and return to the Network & Host name window.
Note

If you need to change the settings of a virtual interface, select the interface and click Configure.

6.6.3.3. Editing network interface configuration

This section contains information about the most important settings for a typical wired connection used during installation. Configuration of other types of networks is broadly similar, although the specific configuration parameters might be different.

Note

On IBM Z, you cannot add a new connection as the network subchannels need to be grouped and set online beforehand, and this is currently done only in the booting phase.

Procedure

  1. To configure a network connection manually, select the interface from the Network and Host name window and click Configure.

    An editing dialog specific to the selected interface opens.

Note

The options present depend on the connection type - the available options are slightly different depending on whether the connection type is a physical interface (wired or wireless network interface controller) or a virtual interface (Bond, Bridge, Team, or Vlan) that was previously configured in Section 6.6.3.2, “Adding a virtual network interface”.

6.6.3.4. Enabling or Disabling the Interface Connection

Follow the steps in this procedure to enable or disable an interface connection.

Procedure

  1. Click the General tab.
  2. Select the Automatically connect to this network when it is available check box to enable connection by default.

    Note
    • When enabled on a wired connection, the system typically connects during startup (unless you unplug the network cable). On a wireless connection, the interface attempts to connect to any known wireless networks in range.
    • You can enable or disable all users on the system from connecting to this network using the All users may connect to this network option. If you disable this option, only root will be able to connect to this network.
    • It is not possible to only allow a specific user other than root to use this interface, as no other users are created at this point during the installation. If you need a connection for a different user, you must configure it after the installation.
  3. Click Save to apply the changes and return to the Network and Host name window.

6.6.3.5. Setting up Static IPv4 or IPv6 Settings

By default, both IPv4 and IPv6 are set to automatic configuration depending on current network settings. This means that addresses such as the local IP address, DNS address, and other settings will be detected automatically when the interface connects to a network. In many cases, this is sufficient, but you can also provide static configuration in the IPv4 Settings and IPv6 Settings tabs. Complete the following steps to configure IPv4 or IPv6 settings:

Procedure

  1. To set static network configuration, navigate to one of the IPv Settings tabs and from the Method drop-down menu, select a method other than Automatic, for example, Manual. The Addresses pane is enabled.

    Note

    In the IPv6 Settings tab, you can also set the method to Ignore to disable IPv6 on this interface.

  2. Click Add and enter your address settings.
  3. Type the IP addresses in the Additional DNS servers field; it accepts one or more IP addresses of DNS servers, for example, 10.0.0.1,10.0.0.8.
  4. Select the Require IPvX addressing for this connection to complete check box.

    Note

    Select this option in the IPv4 Settings or IPv6 Settings tabs to allow this connection only if IPv4 or IPv6 was successful. If this option remains disabled for both IPv4 and IPv6, the interface is able to connect if configuration succeeds on either IP protocol.

  5. Click Save to apply the changes and return to the Network & Host name window.

6.6.3.6. Configuring Routes

Complete the following steps to configure routes.

Procedure

  1. In the IPv4 Settings and IPv6 Settings tabs, click Routes to configure routing settings for a specific IP protocol on an interface. An editing routes dialog specific to the interface opens.
  2. Click Add to add a route.
  3. Select the Ignore automatically obtained routes check box to configure at least one static route and to disable all routes not specifically configured.
  4. Select the Use this connection only for resources on its network check box to prevent the connection from becoming the default route.

    Note

    This option can be selected even if you did not configure any static routes. This route is used only to access certain resources, such as intranet pages that require a local or VPN connection. Another (default) route is used for publicly available resources. Unlike the additional routes configured, this setting is transferred to the installed system. This option is useful only when you configure more than one interface.

  5. Click OK to save your settings and return to the editing routes dialog that is specific to the interface.
  6. Click Save to apply the settings and return to the Network and Host Name window.

6.6.3.7. Additional resources

6.6.4. Configuring security policy

This section contains information about the Red Hat Enterprise Linux 8 security policy add-on and how to configure it for use on your system.

6.6.4.1. About security policy

The Red Hat Enterprise Linux security policy adheres to restrictions and recommendations (compliance policies) defined by the Security Content Automation Protocol (SCAP) standard. The packages are automatically installed. However, by default, no policies are enforced and therefore no checks are performed during or after installation unless specifically configured.

Applying a security policy is not a mandatory feature of the installation program. If you apply a security policy to the system, it is installed using restrictions and recommendations defined in the profile that you selected. The openscap-scanner package is added to your package selection, providing a preinstalled tool for compliance and vulnerability scanning. After the installation finishes, the system is automatically scanned to verify compliance. The results of this scan are saved to the /root/openscap_data directory on the installed system. You can also load additional profiles from an HTTP or HTTPS server.

6.6.4.2. Configuring a security policy

Complete the following steps to configure a security policy.

Prerequisite

The Installation Summary window is open.

Procedure

  1. From the Installation Summary window, click Security Policy. The Security Policy window opens.
  2. To enable security policies on the system, toggle the Apply security policy switch to ON.
  3. Select one of the profiles listed in the top pane.
  4. Click Select profile.

    Profile changes that you must apply before installation appear in the bottom pane.

    Note

    The default profiles do not require changes before installation. However, loading a custom profile can require pre-installation tasks.

  5. Click Change content to use a custom profile. A separate window opens allowing you to enter a URL for valid security content.

    1. Click Fetch to retrieve the URL.
    2. Click Use SCAP Security Guide to return to the Security Policy window.

      Note

      You can load custom profiles from an HTTP or HTTPS server. Use the full address of the content including the protocol, such as http://. A network connection must be active before you can load a custom profile. The installation program detects the content type automatically.

  6. Click Done to apply the settings and return to the Installation Summary window.

6.6.5. Configuring system purpose

System administrators use System Purpose to record the intended use of a Red Hat Enterprise Linux 8 system by the organization. When you set system purpose, the entitlement server receives information that helps to auto-attach a subscription that satisfies the intended use of the system. This section contains information about configuring System Purpose using either the graphical user interface, or the syspurpose command-line tool.

6.6.5.1. Overview

You can enter System Purpose data in the following ways:

  • During image creation.
  • During installation using the graphical user interface.
  • Using Kickstart automation scripts.
  • Using the syspurpose command-line tool.

You can configure the following components:

  • Role:

    • Red Hat Enterprise Linux Server
    • Red Hat Enterprise Linux Workstation
    • Red Hat Enterprise Linux Compute Node
  • Service Level Agreement:

    • Premium
    • Standard
    • Self-Support
  • Usage:

    • Production
    • Disaster Recovery
    • Development/Test

Benefits include:

  • In-depth system-level information for system administrators and business operations.
  • Reduced overhead when determining why a system was procured and its intended purpose.
  • Improved customer experience of Subscription Manager auto-attach as well as automated discovery and reconciliation of system usage.
Additional resources

6.6.5.2. Configuring system purpose using the graphical user interface

Follow the steps in this procedure to configure System Purpose using the graphical user interface.

Note

While it is strongly recommended that you configure System Purpose, it is an optional feature of the Red Hat Enterprise Linux installation program. If you want to enable System Purpose after the installation completes, you can do so using the syspurpose command-line tool.

Prerequisites

  • The Installation Summary window is open.

Procedure

  1. From the Installation Summary window, click System Purpose. The System Purpose window opens.
  2. Select the system role that you require from the Role pane.
  3. Select the service level agreement that you require from the Red Hat Service Level Agreement pane.
  4. Select the usage type that you require from the Usage pane.
  5. Click Done to apply the settings and return to the Installation Summary window.

The System Purpose data is now available for Subscription Manager to auto-attach to the system.

6.6.5.3. Configuring System Purpose using the syspurpose command-line tool

Follow the steps in this procedure to configure System Purpose after installation using the syspurpose command-line tool.

Prerequisites

  • You have installed and registered your Red Hat Enterprise Linux 8 system.
  • You are logged in as a root user.

Procedure

Follow the steps in this procedure to set and unset System Purpose options using the syspurpose command-line tool.

  1. From a terminal window, run the following command to set the intended role of the system:

    # syspurpose set-role "VALUE"

    Replace VALUE with the role that you want to assign:

    • Red Hat Enterprise Linux Server
    • Red Hat Enterprise Linux Workstation
    • Red Hat Enterprise Linux Compute Node

    For example:

    # syspurpose set-role "Red Hat Enterprise Linux Server"

    Run the following command to unset the role:

    # syspurpose unset-role
  2. Run the following command to set the intended sla of the system:

    # syspurpose set-sla "VALUE"

    Replace VALUE with the sla that you want to assign:

    • Premium
    • Standard
    • Self-Support

    For example:

    # syspurpose set-sla "Standard"

    Run the following command to unset the sla:

    # syspurpose unset-sla
  3. Run the following command to set the intended usage of the system:

    # syspurpose set-usage "VALUE"

    Replace VALUE with the usage that you want to assign:

    • Production
    • Disaster Recovery
    • Development/Test

      For example:

      # syspurpose set-usage "Production"

      Run the following command to unset the usage:

      # syspurpose unset-usage
  4. Run the following command to show the current system purpose properties:

    # syspurpose show

    Run the following command to access the syspurpose man page:

    # man syspurpose
Note

Using the syspurpose command-line tool to set the role, sla, and usage influences the subscriptions that are auto-attached to the system. If your system is registered and has subscriptions that do not satisfy the required system purpose, you can run the subscription-manager remove --all command to remove attached subscriptions. You can then use the syspurpose command-line tool to set the system purpose that you require, and run subscription-manager attach --auto to entitle the system with the updated system purpose attributes.

6.7. Configuring storage devices

You can install Red Hat Enterprise Linux on a large variety of storage devices. You can configure basic, locally accessible, storage devices in the Installation Destination window. Basic storage devices directly connected to the local system, such as hard disk drives and solid-state drives, are displayed in the Local Standard Disks section of the window. On IBM Z, this section contains activated Direct Access Storage Devices (DASDs).

Warning

A known issue prevents DASDs configured as HyperPAV aliases from being automatically attached to the system after the installation is complete. These storage devices are available during the installation, but are not immediately accessible after you finish installing and reboot. To attach HyperPAV alias devices, add them manually to the /etc/dasd.conf configuration file of the system.

6.7.1. Storage device selection

The storage device selection window lists all storage devices that the installation program can access. Depending on your system and available hardware, some tabs might not be displayed. The devices are grouped under the following tabs:

Multipath Devices

Storage devices accessible through more than one path, such as through multiple SCSI controllers or Fiber Channel ports on the same system.

Important

The installation program only detects multipath storage devices with serial numbers that are 16 or 32 characters long.

Other SAN Devices
Devices available on a Storage Area Network (SAN).
Firmware RAID
Storage devices attached to a firmware RAID controller.
NVDIMM Devices
Under specific circumstances, Red Hat Enterprise Linux 8 can boot and run from (NVDIMM) devices in sector mode on the Intel 64 and AMD64 architectures.
System z Devices
Storage devices, or Logical Units (LUNs), attached through the zSeries Linux FCP (Fiber Channel Protocol) driver.

6.7.2. Filtering storage devices

In the storage device selection window you can filter storage devices either by their World Wide Identifier (WWID) or by the port, target, or logical unit number (LUN).

Prerequisite

The Installation Summary window is open.

Procedure

  1. From the Installation Summary window, click Installation Destination. The Installation Destination window opens, listing all available drives.
  2. Under the Specialized & Network Disks section, click Add a disk…​. The storage devices selection window opens.
  3. Click the Search by tab to search by port, target, LUN, or WWID.

    Searching by WWID or LUN requires additional values in the corresponding input text fields.

  4. Select the option that you require from the Search drop-down menu.
  5. Click Find to start the search. Each device is presented on a separate row with a corresponding check box.
  6. Select the check box to enable the device that you require during the installation process.

    Later in the installation process you can choose to install Red Hat Enterprise Linux on any of the selected devices, and you can choose to mount any of the other selected devices as part of the installed system automatically.

    Note
    • Selected devices are not automatically erased by the installation process and selecting a device does not put the data stored on the device at risk.
    • You can add devices to the system after installation by modifying the /etc/fstab file.
  7. Click Done to return to the Installation Destination window.
Important

Any storage devices that you do not select are hidden from the installation program entirely. To chain load the boot loader from a different boot loader, select all the devices present.

6.7.3. Using advanced storage options

To use an advanced storage device, you can configure an iSCSI (SCSI over TCP/IP) target or FCoE (Fibre Channel over Ethernet) SAN (Storage Area Network).

To use iSCSI storage devices for the installation, the installation program must be able to discover them as iSCSI targets and be able to create an iSCSI session to access them. Each of these steps might require a user name and password for Challenge Handshake Authentication Protocol (CHAP) authentication. Additionally, you can configure an iSCSI target to authenticate the iSCSI initiator on the system to which the target is attached (reverse CHAP), both for discovery and for the session. Used together, CHAP and reverse CHAP are called mutual CHAP or two-way CHAP. Mutual CHAP provides the greatest level of security for iSCSI connections, particularly if the user name and password are different for CHAP authentication and reverse CHAP authentication.

Note

Repeat the iSCSI discovery and iSCSI login steps to add all required iSCSI storage. You cannot change the name of the iSCSI initiator after you attempt discovery for the first time. To change the iSCSI initiator name, you must restart the installation.

6.7.3.1. Discovering and starting an iSCSI session

Complete the following steps to discover and start an iSCSI session.

Prerequisites

  • The Installation Summary window is open.

Procedure

  1. From the Installation Summary window, click Installation Destination. The Installation Destination window opens, listing all available drives.
  2. Under the Specialized & Network Disks section, click Add a disk…​ The storage devices selection window opens.
  3. Click Add iSCSI target…​ The Add iSCSI Storage Target window opens.
  4. Enter the IP address of the iSCSI target in the Target IP Address field.
  5. Type a name in the iSCSI Initiator Name field for the iSCSI initiator in iSCSI qualified name (IQN) format. A valid IQN entry contains the following information:

    • The string iqn. (note the period).
    • A date code that specifies the year and month in which your organization’s Internet domain or subdomain name was registered, represented as four digits for the year, a dash, and two digits for the month, followed by a period. For example, represent September 2010 as 2010-09.
    • Your organization’s Internet domain or subdomain name, presented in reverse order with the top-level domain first. For example, represent the subdomain storage.example.com as com.example.storage.
    • A colon followed by a string that uniquely identifies this particular iSCSI initiator within your domain or subdomain. For example, :diskarrays-sn-a8675309.

      A complete IQN is as follows: iqn.2010-09.storage.example.com:diskarrays-sn-a8675309. The installation program prepopulates the iSCSI Initiator Name field with a name in this format to help you with the structure. For more information about IQNs, see 3.2.6. iSCSI Names in RFC 3720 - Internet Small Computer Systems Interface (iSCSI) available from tools.ietf.org and 1. iSCSI Names and Addresses in RFC 3721 - Internet Small Computer Systems Interface (iSCSI) Naming and Discovery available from tools.ietf.org.

  6. Select the Discovery Authentication Type drop-down menu to specify the type of authentication to use for iSCSI discovery. The following options are available:

    • No credentials
    • CHAP pair
    • CHAP pair and a reverse pair
    1. If you selected CHAP pair as the authentication type, enter the user name and password for the iSCSI target in the CHAP Username and CHAP Password fields.
    2. If you selected CHAP pair and a reverse pair as the authentication type, enter the user name and password for the iSCSI target in the CHAP Username and CHAP Password field, and the user name and password for the iSCSI initiator in the Reverse CHAP Username and Reverse CHAP Password fields.
  7. Optionally, select the Bind targets to network interfaces check box.
  8. Click Start Discovery.

    The installation program attempts to discover an iSCSI target based on the information provided. If discovery succeeds, the Add iSCSI Storage Target window displays a list of all iSCSI nodes discovered on the target.

  9. Select the check boxes for the node that you want to use for installation.

    Note

    The Node login authentication type menu contains the same options as the Discovery Authentication Type menu. However, if you need credentials for discovery authentication, use the same credentials to log in to a discovered node.

  10. Click the additional Use the credentials from discovery drop-down menu. When you provide the proper credentials, the Log In button becomes available.
  11. Click Log In to initiate an iSCSI session.

6.7.3.2. Configuring FCoE parameters

Complete the following steps to configure FCoE parameters.

Prerequisite

The Installation Summary window is open.

Procedure

  1. From the Installation Summary window, click Installation Destination. The Installation Destination window opens, listing all available drives.
  2. Under the Specialized & Network Disks section, click Add a disk…​. The storage devices selection window opens.
  3. Click dd FCoE SAN…​ A dialog box opens for you to configure network interfaces for discovering FCoE storage devices.
  4. Select a network interface that is connected to an FCoE switch in the NIC drop-down menu.
  5. Click Add FCoE disk(s) to scan the network for SAN devices.
  6. Select the required check boxes:

    • Use DCB:Data Center Bridging (DCB) is a set of enhancements to the Ethernet protocols designed to increase the efficiency of Ethernet connections in storage networks and clusters. Select the check box to enable or disable the installation program’s awareness of DCB. Enable this option only for network interfaces that require a host-based DCBX client. For configurations on interfaces that use a hardware DCBX client, disable the check box.
    • Use auto vlan:Auto VLAN is enabled by default and indicates whether VLAN discovery should be performed. If this check box is enabled, then the FIP (FCoE Initiation Protocol) VLAN discovery protocol runs on the Ethernet interface when the link configuration has been validated. If they are not already configured, network interfaces for any discovered FCoE VLANs are automatically created and FCoE instances are created on the VLAN interfaces.
  7. Discovered FCoE devices are displayed under the Other SAN Devices tab in the Installation Destination window.

6.7.3.3. Configuring DASD storage devices

Complete the following steps to configure DASD storage devices.

Prerequisite

The Installation Summary window is open.

Procedure

  1. From the Installation Summary window, click Installation Destination. The Installation Destination window opens, listing all available drives.
  2. Under the Specialized & Network Disks section, click Add a disk…​. The storage devices selection window opens.
  3. Click Add DASD. The Add DASD Storage Target dialog box opens and prompts you to specify a device number, such as 0.0.0204, and attach additional DASDs that were not detected when the installation started.
  4. Type the device number of the DASD that you want to attach in the Device number field.
  5. Click Start Discovery.
Note
  • If a DASD with the specified device number is found and if it is not already attached, the dialog box closes and the newly-discovered drives appear in the list of drives. You can then select the check boxes for the required devices and click Done. The new DASDs are available for selection (marked as DASD device 0.0.xxxx) in the Local Standard Disks section of the Installation Destination window.
  • If you entered an invalid device number, or if the DASD with the specified device number is already attached to the system, an error message appears in the dialog box, explaining the error and prompting you to try again with a different device number.

6.7.3.4. Configuring FCP devices

FCP devices enable IBM Z to use SCSI devices rather than, or in addition to, Direct Access Storage Device (DASD) devices. FCP devices provide a switched fabric topology that enables IBM Z systems to use SCSI LUNs as disk devices in addition to traditional DASD devices.

Prerequisites

  • The Installation Summary window is open.
  • For an FCP-only installation, remove the DASD= option from the CMS configuration file or the rd.dasd= option from the parameter file to indicate that no DASD is present.

Procedure

  1. From the Installation Summary window, click Installation Destination. The Installation Destination window opens, listing all available drives.
  2. Under the Specialized & Network Disks section, click Add a disk…​. The storage devices selection window opens.
  3. Click Add ZFCP LUN. The Add zFCP Storage Target dialog box opens allowing you to add a FCP (Fibre Channel Protocol) storage device.

    IBM Z requires that you enter any FCP device manually so that the installation program can activate FCP LUNs. You can enter FCP devices either in the graphical installation, or as a unique parameter entry in the parameter or CMS configuration file. The values that you enter must be unique to each site that you configure.

  4. Type the 4 digit hexadecimal device number in the Device number field.
  5. Type the 16 digit hexadecimal World Wide Port Number (WWPN) in the WWPN field.
  6. Type the 16 digit hexadecimal FCP LUN identifier in the LUN field.
  7. Click Start Discovery to connect to the FCP device.

The newly-added devices are displayed in the System z Devices tab of the Installation Destination window.

Note
  • Interactive creation of an FCP device is only possible in graphical mode. It is not possible to configure an FCP device interactively in text mode installation.
  • Use only lower-case letters in hex values. If you enter an incorrect value and click Start Discovery, the installation program displays a warning. You can edit the configuration information and retry the discovery attempt.
  • For more information about these values, consult the hardware documentation and check with your system administrator.

6.7.4. Installing to an NVDIMM device

Non-Volatile Dual In-line Memory Module (NVDIMM) devices combine the performance of RAM with disk-like data persistence when no power is supplied. Under specific circumstances, Red Hat Enterprise Linux 8 can boot and run from NVDIMM devices.

6.7.4.1. Criteria for using an NVDIMM device as an installation target

You can install Red Hat Enterprise Linux 8 to Non-Volatile Dual In-line Memory Module (NVDIMM) devices in sector mode on the Intel 64 and AMD64 architectures, supported by the nd_pmem driver.

Conditions for using an NVDIMM device as storage

To use an NVDIMM device as storage, the following conditions must be satisfied:

  • The architecture of the system is Intel 64 or AMD64.
  • The NVDIMM device is configured to sector mode. The installation program can reconfigure NVDIMM devices to this mode.
  • The NVDIMM device must be supported by the nd_pmem driver.

Conditions for booting from an NVDIMM Device

Booting from an NVDIMM device is possible under the following conditions:

  • All conditions for using the NVDIMM device as storage are satisfied.
  • The system uses UEFI.
  • The NVDIMM device must be supported by firmware available on the system, or by an UEFI driver. The UEFI driver may be loaded from an option ROM of the device itself.
  • The NVDIMM device must be made available under a namespace.

Utilize the high performance of NVDIMM devices during booting, place the /boot and /boot/efi directories on the device. The Execute-in-place (XIP) feature of NVDIMM devices is not supported during booting and the kernel is loaded into conventional memory.

6.7.4.2. Configuring an NVDIMM device using the graphical installation mode

A Non-Volatile Dual In-line Memory Module (NVDIMM) device must be properly configured for use by Red Hat Enterprise Linux 8 using the graphical installation.

Warning

Reconfiguration of a NVDIMM device process destroys any data stored on the device.

Prerequisites

  • A NVDIMM device is present on the system and satisfies all the other conditions for usage as an installation target.
  • The installation has booted and the Installation Summary window is open.

Procedure

  1. From the Installation Summary window, click Installation Destination. The Installation Destination window opens, listing all available drives.
  2. Under the Specialized & Network Disks section, click Add a disk…​. The storage devices selection window opens.
  3. Click the NVDIMM Devices tab.
  4. To reconfigure a device, select it from the list.

    If a device is not listed, it is not in sector mode.

  5. Click Reconfigure NVDIMM…​. A reconfiguration dialog opens.
  6. Enter the sector size that you require and click Start Reconfiguration.

    The supported sector sizes are 512 and 4096 bytes.

  7. When reconfiguration completes click OK.
  8. Select the device check box.
  9. Click Done to return to the Installation Destination window.

    The NVDIMM device that you reconfigured is displayed in the Specialized & Network Disks section.

  10. Click Done to return to the Installation Summary window.

The NVDIMM device is now available for you to select as an installation target. Additionally, if the device meets the requirements for booting, you can set the device as a boot device.

6.8. Configuring manual partitioning

You can use manual partitioning to configure your disk partitions and mount points and define the file system that Red Hat Enterprise Linux is installed on.

Note

Before installation, you should consider whether you want to use partitioned or unpartitioned disk devices. For more information, see the Knowledgebase article at https://access.redhat.com/solutions/163853.

An installation of Red Hat Enterprise Linux requires a minimum of one partition but Red Hat recommends using at least the following partitions or volumes: PReP, /, /home, /boot, and swap. You can also create additional partitions and volumes as you require.

Note

An installation of Red Hat Enterprise Linux on IBM Power Systems servers requires a PReP boot partition.

Warning

To prevent data loss it is recommended that you back up your data before proceeding. If you are upgrading or creating a dual-boot system, you should back up any data you want to keep on your storage devices.

6.8.1. Starting manual partitioning

Prerequisites

  • The Installation Summary screen is currently displayed.
  • All disks are available to the installation program.

Procedure

  1. Select disks for installation:

    1. Click Installation Destination to open the Installation Destination window.
    2. Select the disks that you require for installation by clicking the corresponding icon. A selected disk has a check-mark displayed on it.
    3. Under Storage Configuration, select the Custom radio-button.
    4. Optional: To enable storage encryption with LUKS, select the Encrypt my data check box.
    5. Click Done.
  2. If you selected to encrypt the storage, a dialog box for entering a disk encryption passphrase opens. Type in the LUKS passphrase:

    1. Enter the passphrase in the two text fields. To switch keyboard layout, use the keyboard icon.

      Warning

      In the dialog box for entering the passphrase, you cannot change the keyboard layout. Select the English keyboard layout to enter the passphrase in the installation program.

    2. Click Save Passphrase. The Manual Partitioning window opens.
  3. Deleted Mount points are listed in the left-hand pane. The mount points are organized by detected operating system installations. As a result, some file systems may be displayed multiple times if a partition is shared among several installations.

    1. Select the mount points in the left pane; the options that can be customized are displayed in the right pane.

      Note
      • If your system contains existing file systems, ensure that enough space is available for the installation. To remove any partitions, select them in the list and click the - button.

        The dialog has a check box that you can use to remove all other partitions used by the system to which the deleted partition belongs.

      • If there are no existing partitions and you want to create the recommended set of partitions as a starting point, select your preferred partitioning scheme from the left pane (default for Red Hat Enterprise Linux is LVM) and click the Click here to create them automatically link.

        A /boot partition, a / (root) volume, and a swap volume proportionate to the size of the available storage are created and listed in the left pane. These are the recommended file systems for a typical installation, but you can add additional file systems and mount points.

    2. Click Done to confirm any changes and return to the Installation Summary window.

6.8.2. Adding a mount point file system

Complete the following steps to add multiple mount point file systems.

Prerequisites

  • Plan for your partitions:

    • To avoid problems with space allocation, first create small partitions with known fixed sizes, such as /boot, and then create the remaining partitions, letting the installation program allocate the remaining capacity to them.
    • If you want to install the system on multiple disks, or if your disks differ in size and a particular partition must be created on the first disk detected by BIOS, then create these partitions first.

Procedure

  1. Click + to create a new mount point file system. The Add a New Mount Point dialog opens.
  2. Select one of the preset paths from the Mount Point drop-down menu or type your own; for example, select / for the root partition or /boot for the boot partition.
  3. Enter the size of the file system in to the Desired Capacity field; for example, 2GiB.

    Warning

    If you do not specify a value in the Desired Capacity field, or if you specify a size bigger than available space, then all remaining free space is used.

  4. Click Add mount point to create the partition and return to the Manual Partitioning window.

6.8.3. Configuring a mount point file system

This procedure describes how to set the partitioning scheme for each mount point that was created manually. The available options are Standard Partition, LVM, and LVM Thin Provisioning.

Note
  • BTRFS support has been deprecated in Red Hat Enterprise Linux 8.
  • The /boot partition is always located on a standard partition, regardless of the value selected.

Procedure

  1. To change the devices that a single non-LVM mount point should be located on, select the required mount point from the left-hand pane.
  2. Under the Device(s) heading, click Modify…​. The Configure Mount Point dialog opens.
  3. Select one or more devices and click Select to confirm your selection and return to the Manual Partitioning window.
  4. Click Update Settings to apply the changes.

    Note

    Click the Rescan button (circular arrow button) to refresh all local disks and partitions; this is only required after performing advanced partition configuration outside the installation program. Clicking the Rescan Disks button resets all configuration changes made in the installation program.

  5. In the lower left-hand side of the Manual Partitioning window, click the storage device selected link to open the Selected Disks dialog and review disk information.

6.8.4. Customizing a partition or volume

You can customize a partition or volume if you want to set specific settings.

Important

If /usr or /var is partitioned separately from the rest of the root volume, the boot process becomes much more complex as these directories contain critical components. In some situations, such as when these directories are placed on an iSCSI drive or an FCoE location, the system is unable to boot, or hangs with a Device is busy error when powering off or rebooting.

This limitation only applies to /usr or /var, not to directories below them. For example, a separate partition for /var/www works successfully.

Procedure

  1. From the left pane, select the mount point.

    Figure 6.2. Customizing Partitions

    Customizing partitions.
  2. From the right-hand pane, you can customize the following options:

    1. Enter the file system mount point into the Mount Point field. For example, if a file system is the root file system, enter /; enter /boot for the /boot file system, and so on. For a swap file system, do not set the mount point as setting the file system type to swap is sufficient.
    2. Enter the size of the file system in the Desired Capacity field. You can use common size units such as KiB or GiB. The default is MiB if you do not set any other unit.
    3. Select the device type that you require from the drop-down Device Type menu: Standard Partition, LVM, or LVM Thin Provisioning.

      Note

      RAID is available only if two or more disks are selected for partitioning. If you choose RAID, you can also set the RAID Level. Similarly, if you select LVM, you can specify the Volume Group.

    4. Select the Encrypt check box to encrypt the partition or volume. You must set a password later in the installation program. The LUKS Version drop-down menu is displayed.
    5. Select the LUKS version that you require from the drop-down menu.
    6. Select the appropriate file system type for this partition or volume from the File system drop-down menu.
    7. Select the Reformat check box to format an existing partition, or deselect the Reformat check box to retain your data. The newly-created partitions and volumes must be reformatted, and the check box cannot be deselected.
    8. Type a label for the partition in the Label field. Use labels to easily recognize and address individual partitions.
    9. Type a name in the Name field.

      Note

      Note that standard partitions are named automatically when they are created and you cannot edit the names of standard partitions. For example, you cannot edit the /boot name sda1.

  3. Click Update Settings to apply your changes and if required, select another partition to customize. Changes are not applied until you click Begin Installation from the Installation Summary window.

    Note

    Click Reset All to discard your partition changes.

  4. Click Done when you have created and customized all file systems and mount points. If you choose to encrypt a file system, you are prompted to create a passphrase.

    A Summary of Changes dialog box opens, displaying a summary of all storage actions for the installation program.

  5. Click Accept Changes to apply the changes and return to the Installation Summary window.

6.8.5. Creating software RAID

Follow the steps in this procedure to create a Redundant Arrays of Independent Disks (RAID) device. RAID devices are constructed from multiple storage devices that are arranged to provide increased performance and, in some configurations, greater fault tolerance.

A RAID device is created in one step and disks are added or removed as necessary. You can configure one RAID partition for each physical disk in your system, so the number of disks available to the installation program determines the levels of RAID device available. For example, if your system has two hard drives, you cannot create a RAID10 device, as it requires 4 separate partitions.

Note

On IBM Z, the storage subsystem uses RAID transparently. There is no need to configure a software RAID manually.

Prerequisites

  • You have selected two or more disks for installation before RAID configuration options are visible. At least two disks are required to create a RAID device.
  • You have created a mount point. By configuring a mount point, you configure the RAID device.
  • You have selected the Custom radio button on the Installation Destination window.

Procedure

  1. From the left pane of the Manual Partitioning window, select the required partition.
  2. Under the Device(s) section, click Modify. The Configure Mount Point dialog box opens.
  3. Select the disks that you want to include in the RAID device and click Select.
  4. Click the Device Type drop-down menu and select RAID.
  5. Click the File System drop-down menu and select your preferred file system type.
  6. Click the RAID Level drop-down menu and select your preferred level of RAID.
  7. Click Update Settings to save your changes.
  8. Click Done to apply the settings and return to the Installation Summary window.

A message is displayed at the bottom of the window if the specified RAID level requires more disks.

6.8.6. Creating an LVM logical volume

Logical Volume Management (LVM) presents a simple logical view of underlying physical storage space, such as hard drives or LUNs. Partitions on physical storage are represented as physical volumes that you can group together into volume groups. You can divide each volume group into multiple logical volumes, each of which is analogous to a standard disk partition. Therefore, LVM logical volumes function as partitions that can span multiple physical disks.

Note

LVM configuration is available only in the graphical installation program.

Important

During text-mode installation, LVM configuration is not available. To create an LVM configuration, press Ctrl+Alt+F2 to use a different virtual console, and run the lvm command. To return to the text-mode installation, press Ctrl+Alt+F1.

Procedure

  1. From the left-hand pane of the Manual Partitioning window, select the mount point.
  2. Click the Device Type drop-down menu and select LVM. The Volume Group drop-down menu is displayed with the newly-created volume group name.

    Note

    You cannot specify the size of the volume group’s physical extents in the configuration dialog. The size is always set to the default value of 4 MiB. If you want to create a volume group with different physical extents, you must create it manually by switching to an interactive shell and using the vgcreate command, or use a Kickstart file with the volgroup --pesize=size command. See the Performing an advanced RHEL installation document for more information about Kickstart.

Additional resources

6.8.7. Configuring an LVM logical volume

Follow the steps in this procedure to configure a newly-created LVM logical volume.

Warning

Placing the /boot partition on an LVM volume is not supported.

Procedure

  1. From the left-hand pane of the Manual Partitioning window, select the mount point.
  2. Click the Device Type drop-down menu and select LVM. The Volume Group drop-down menu is displayed with the newly-created volume group name.
  3. Click Modify to configure the newly-created volume group.

    The Configure Volume Group dialog box opens.

    Note

    You cannot specify the size of the volume group’s physical extents in the configuration dialog. The size is always set to the default value of 4 MiB. If you want to create a volume group with different physical extents, you must create it manually by switching to an interactive shell and using the vgcreate command, or use a Kickstart file with the volgroup --pesize=size command. See the Performing an advanced RHEL installation document for more information about Kickstart.

  4. From the RAID Level drop-down menu, select the RAID level that you require.

    The available RAID levels are the same as with actual RAID devices.

  5. Select the Encrypt check box to mark the volume group for encryption.
  6. From the Size policy drop-down menu, select the size policy for the volume group.

    The available policy options are:

    • Automatic: The size of the volume group is set automatically so that it is large enough to contain the configured logical volumes. This is optimal if you do not need free space within the volume group.
    • As large as possible: The volume group is created with maximum size, regardless of the size of the configured logical volumes it contains. This is optimal if you plan to keep most of your data on LVM and later need to increase the size of some existing logical volumes, or if you need to create additional logical volumes within this group.
    • Fixed: You can set an exact size of the volume group. Any configured logical volumes must then fit within this fixed size. This is useful if you know exactly how large you need the volume group to be.
  7. Click Save to apply the settings and return to the Manual Partitioning window.
  8. Click Update Settings to save your changes
  9. Click Done to return to the Installation Summary window.

6.9. Starting the installation program

Before you start the installation program, you must configure your root password and user settings.

6.9.1. Beginning installation

When the installation process has started, it is not possible to return to the Installation Summary window and change any settings. To change settings, you must wait for the installation process to finish, reboot your system, log in, and change your settings on the installed system.

Prerequisites

Procedure

  1. From the Installation Summary window, click Begin Installation. The Configuration window opens and the installation process starts.

    Two user setting options, Root Password (mandatory) and User Creation (optional) are available.

Important

Before you finish the installation and reboot, either remove the media (CD, DVD, or a USB drive) used to start the installation, or verify that your system tries to boot from the hard drive before attempting removable media. Otherwise, your system starts the installation program again, instead of the installed system.

6.9.2. Configuring a root password

You must configure a root password to finish the installation process and to log in to the administrator (also known as superuser or root) account that is used for system administration tasks. These tasks include installing and updating software packages and changing system-wide configuration such as network and firewall settings, storage options, and adding or modifying users, groups and file permissions.

Important
  • Use one or both of the following ways to gain root privileges to the installed system:

    • Use a root account
    • Create a user account with administrative privileges (member of the wheel group). The root account is always created during the installation. Switch to the administrator account only when you need to perform a task that requires administrator access.
Warning

The root account has complete control over the system. If unauthorized personnel gain access to the account, they can access or delete users' personal files.

Procedure

  1. From the Configuration window, click Root Password. The Root Password window opens.
  2. Type your password in the Root Password field.

    The requirements and recommendations for creating a strong root password are:

    • Must be at least eight characters long
    • May contain numbers, letters (upper and lower case) and symbols
    • Is case-sensitive
  3. Type the same password in the Confirm field.
  4. Click Done to confirm your root password and return to Section 6.9.1, “Beginning installation”.

    Note

    If you proceeded with a weak password, you must click Done twice.

6.9.3. Creating a user account

It is recommended that you create a user account to finish the installation. If you do not create a user account, you must log in to the system as root directly, which is not recommended.

Procedure

  1. From the Configuration window, click User Creation. The Create User window opens.
  2. Type the user account name in to the Full name field, for example: John Smith.
  3. Type the username in to the User name field, for example: jsmith.

    Note

    The User name is used to log in from a command line; if you install a graphical environment, then your graphical login manager uses the Full name.

  4. Select the Make this user administrator check box if the user requires administrative rights (the installation program adds the user to the wheel group ).

    Important

    An administrator user can use the sudo command to perform tasks that are only available to root using the user password, instead of the root password. This may be more convenient, but it can also cause a security risk.

  5. Select the Require a password to use this account check box.

    Warning

    If you give administrator privileges to a user, verify that the account is password protected. Never give a user administrator privileges without assigning a password to the account.

  6. Type a password into the Password field.
  7. Type the same password into the Confirm password field.
  8. Save Changes to apply the changes and return to the Configuration window.
  9. When the installation process is complete, click Reboot to reboot and log in to your Red Hat Enterprise Linux 8 system.

6.9.3.1. Editing advanced user settings

Follow the steps in this procedure to edit the default settings for the user account in the Advanced User Configuration dialog box.

Procedure

  1. Edit the details in the Home directory field, if required. The field is populated by default with /home/username .
  2. In the User and Groups IDs section you can:

    1. Select the Specify a user ID manually check box and use the + or - to enter the required value.

      Note

      The default value is 1000. User IDs (UIDs) 0-999 are reserved by the system so they cannot be assigned to a user.

    2. Select the Specify a group ID manually check box and use the + or - to enter the required value.

      Note

      The default group name is the same as the user name, and the default Group ID (GID) is 1000. GIDs 0-999 are reserved by the system so they can not be assigned to a user group.

  3. Specify additional groups as a comma-separated list in the Group Membership field. Groups that do not already exist are created; you can specify custom GIDs for additional groups in parentheses. If you do not specify a custom GID for a new group, the new group receives a GID automatically.

    Note

    The user account created always has one default group membership (the user’s default group with an ID set in the Specify a group ID manually field).

  4. Click Save Changes to apply the updates and return to the Configuration window.

6.9.4. Graphical installation complete

Remove any installation media if it is not ejected automatically upon reboot.

Red Hat Enterprise Linux 8 starts after your system’s normal power-up sequence is complete. If your system was installed on a workstation with the X Window System, applications to configure your system are launched. These applications guide you through initial configuration and you can set your system time and date, register your system with Red Hat, and more. If the X Window System is not installed, a login: prompt is displayed.

To learn how to complete initial setup, register, and secure your system, see the Completing post-installation tasks section of the Performing a standard RHEL installation document.

Chapter 7. Completing post-installation tasks

This section describes how to complete the following post-installation tasks:

  • Completing initial setup
  • Registering your system
  • Securing your system

7.1. Completing initial setup

This section contains information about how to complete initial setup on a Red Hat Enterprise Linux 8 system.

Important

If you selected the Server with GUI base environment during installation, the Initial Setup window opens the first time you reboot your system after the installation process is complete.

The information displayed in the Initial Setup window might vary depending on what was configured during installation. At a minimum, the Licensing and Subscription Manager options are displayed.

Prerequisite

Procedure

  1. From the Initial Setup window, select Licensing Information.

    The License Agreement window opens and displays the licensing terms for Red Hat Enterprise Linux.

  2. Review the license agreement and select the I accept the license agreement checkbox.

    Note

    You must accept the license agreement. Exiting Initial Setup without completing this step causes a system restart. When the restart process is complete, you are prompted to accept the license agreement again.

  3. Click Done to apply the settings and return to the Initial Setup window.

    Note

    If you did not configure network settings, you cannot register your system immediately. In this case, click Finish Configuration. Red Hat Enterprise Linux 8 starts and you can login, activate access to the network, and register your system. See Section 7.3, “Registering your system using the Subscription Manager User Interface” for more information. If you configured network settings, as described in Section 6.6.3, “Configuring network and host name options”, you can register your system immediately, as shown in the following steps:

  4. From the Initial Setup window, select Subscription Manager.
  5. The Subscription Manager graphical interface opens and displays the option you are going to register, which is: subscription.rhsm.redhat.com.
  6. Click Next.
  7. Enter your Login and Password details and click Register.
  8. Confirm the Subscription details and click Attach. You must receive the following confirmation message: Registration with Red Hat Subscription Management is Done!
  9. Click Done. The Initial Setup window opens.
  10. Click Finish Configuration. The login window opens.
  11. Configure your system. See the Configuring basic system settings document for more information.

Additional resources

There are four methods to register your system:

7.2. Registering your system using the command line

This section contains information about how to register your Red Hat Enterprise Linux 8 system using the command line.

Note

When auto-attaching a system, the subscription service checks if the system is physical or virtual, as well as how many sockets are on the system. A physical system usually consumes two entitlements, a virtual system usually consumes one. One entitlement is consumed per two sockets on a system.

Prerequisites

  • You have an active, non-evaluation Red Hat Enterprise Linux subscription.
  • Your Red Hat subscription status is verified.
  • You have not previously received a Red Hat Enterprise Linux 8 subscription.
  • You have activated your subscription before attempting to download entitlements from the Customer Portal. You need an entitlement for each instance that you plan to use. Red Hat Customer Service is available if you need help activating your subscription.
  • You have successfully installed Red Hat Enterprise Linux 8  and logged into the system.

Procedure

  1. Open a terminal window and run the following command to register a subscription:

    # subscription-manager register
  2. Enter your Customer Portal credentials:

    # Registering to: subscription.rhsm.redhat.com:443/subscription
    # Username: USERNAME
    # Password: PASSWORD
  3. When the subscription is successfully registered, you should see an output similar to the following example:

    # The system has been registered with ID: 123456abcdef
    # The registered system name is: localhost.localdomain
  4. Set the role for the intended use of the system:

    Note

    Available roles depend on the subscriptions that have been purchased by the organization and the architecture of the RHEL 8 system. You can set one of the following roles: Red Hat Enterprise Linux Server, Red Hat Enterprise Linux Workstation, or Red Hat Enterprise Linux Compute Node.

    # subscription-manager role --set="Red Hat Enterprise Linux Server"
  5. Attach the system to an entitlement that matches the host system architecture:

    # subscription-manager attach
  6. When the subscription is successfully attached, you should see an output similar to the following example:

    Installed Product Current Status:
    Product Name: Red Hat Enterprise Linux for x86_64
    Status: Subscribed
Note

You can also register Red Hat Enterprise Linux 8 by logging in to the system as a root user and using the Subscription Manager graphical user interface.

7.3. Registering your system using the Subscription Manager User Interface

This section contains information about how to register your Red Hat Enterprise Linux 8 system using the Subscription Manager User Interface to receive updates and access package repositories.

Prerequisites

  • You have completed the graphical installation as per the recommended workflow described on Section 6.1, “Graphical installation workflow”.
  • You have an active, non-evaluation Red Hat Enterprise Linux subscription.
  • Your Red Hat subscription status is verified.

Procedure

  1. Log in to your system.
  2. From the top left-hand side of the window, click Activities.
  3. From the menu options, click the Show Applications icon.
  4. Click the Red Hat Subscription Manager icon, or enter Red Hat Subscription Manager in the search.
  5. Enter your administrator password in the Authentication Required dialog box.

    Note

    Authentication is required to perform privileged tasks on the system.

  6. The Subscriptions window opens, displaying the current status of Subscriptions, System Purpose, and installed products. Unregistered products display a red X.
  7. Click the Register button.
  8. The Register System dialog box opens. Enter your Customer Portal credentials and click the Register button.

The Register button in the Subscriptions window changes to Unregister and installed products display a green X. You can troubleshoot an unsuccessful registration using the subscription-manager status command.

Additional resources

7.4. Registration Assistant

Registration Assistant is designed to help you choose the most suitable registration option for your Red Hat Enterprise Linux environment. See https://access.redhat.com/labs/registrationassistant/ for more information.

7.5. Securing your system

Complete the following security-related steps immediately after you install Red Hat Enterprise Linux.

Prerequisites

  • You have completed the graphical installation.

Procedure

  1. To update your system, run the following command as root:

    # yum update
  2. Even though the firewall service, firewalld, is automatically enabled with the installation of Red Hat Enterprise Linux, there are scenarios where it might be explicitly disabled, for example in a Kickstart configuration. In that scenario, it is recommended that you re-enable the firewall.

    To start firewalld, run the following commands as root:

    # systemctl start firewalld
    # systemctl enable firewalld
  3. To enhance security, disable services that you do not need. For example, if your system has no printers installed, disable the cups service using the following command:

    # systemctl mask cups

    To review active services, run the following command:

    $ systemctl list-units | grep service

Appendix A. System requirements reference

This section provides information and guidelines for hardware, installation target, system, memory, and RAID when installing Red Hat Enterprise Linux.

A.1. Hardware compatibility

Red Hat works closely with hardware vendors on supported hardware.

A.2. Supported installation targets

An installation target is a storage device that stores Red Hat Enterprise Linux and boots the system. Red Hat Enterprise Linux supports the following installation targets for AMD64, Intel 64, and 64-bit ARM systems:

  • Storage connected by a standard internal interface, such as SCSI, SATA, or SAS
  • BIOS/firmware RAID devices
  • NVDIMM devices in sector mode on the Intel64 and AMD64 architectures, supported by the nd_pmem driver.
  • Fibre Channel Host Bus Adapters and multipath devices. Some can require vendor-provided drivers.
  • Xen block devices on Intel processors in Xen virtual machines.
  • VirtIO block devices on Intel processors in KVM virtual machines.

Red Hat does not support installation to USB drives or SD memory cards. For information about support for third-party virtualization technologies, see the Red Hat Hardware Compatibility List.

A.3. System specifications

The Red Hat Enterprise Linux installation program automatically detects and installs your system’s hardware, so you should not have to supply any specific system information. However, for certain Red Hat Enterprise Linux installation scenarios, it is recommended that you record system specifications for future reference. These scenarios include:

Installing RHEL with a customized partition layout

Record: The model numbers, sizes, types, and interfaces of the hard drives attached to the system. For example, Seagate ST3320613AS 320 GB on SATA0, Western Digital WD7500AAKS 750 GB on SATA1.

Installing RHEL as an additional operating system on an existing system

Record: Partitions used on the system. This information can include file system types, device node names, file system labels, and sizes, and allows you to identify specific partitions during the partitioning process. If one of the operating systems is a Unix operating system, Red Hat Enterprise Linux may report the device names differently. Additional information can be found by executing the equivalent of the mount command and the blkid command, and in the /etc/fstab file.

If multiple operating systems are installed, the Red Hat Enterprise Linux installation program attempts to automatically detect them, and to configure boot loader to boot them. You can manually configure additional operating systems if they are not detected automatically. See Configuring boot loader in Section 6.5, “Configuring software options” for more information.

Installing RHEL from an image on a local hard drive

Record: The hard drive and directory that holds the image.

Installing RHEL from a network location

If the network has to be configured manually, that is, DHCP is not used.

Record:

  • IP address
  • Netmask
  • Gateway IP address
  • Server IP addresses, if required

Contact your network administrator if you need assistance with networking requirements.

Installing RHEL on an iSCSI target

Record: The location of the iSCSI target. Depending on your network, you may need a CHAP user name and password, and a reverse CHAP user name and password.

Installing RHEL if the system is part of a domain

Verify that the domain name is supplied by the DHCP server. If it is not, enter the domain name during installation.

A.4. Disk and memory requirements

If several operating systems are installed, it is important that you verify that the allocated disk space is separate from the disk space required by Red Hat Enterprise Linux.

Note
  • For AMD64, Intel 64, and 64-bit ARM, at least two partitions (/ and swap) must be dedicated to Red Hat Enterprise Linux.
  • For IBM Power Systems servers, at least three partitions (/, swap, and a PReP boot partition) must be dedicated to Red Hat Enterprise Linux.

You must have a minimum of 10 GiB of available disk space.

To install Red Hat Enterprise Linux, you must have a minimum of 10 GiB of space in either unpartitioned disk space or in partitions that can be deleted. See Appendix B, Partitioning reference for more information.

Table A.1. Minimum RAM requirements

Installation typeRecommended minimum RAM

Local media installation (USB, DVD)

768 MiB

NFS network installation

768 MiB

HTTP or HTTPS network installation

1.5 GiB

Note

It is possible to complete the installation with less memory than the recommended minimum requirements. The exact requirements depend on your environment and installation path. It is recommended that you test various configurations to determine the minimum required RAM for your environment. Installing Red Hat Enterprise Linux using a Kickstart file has the same recommended minimum RAM requirements as a standard installation. However, additional RAM may be required if your Kickstart file includes commands that require additional memory, or write data to the RAM disk. See the Performing an advanced RHEL installation document for more information.

A.5. RAID requirements

It is important to understand how storage technologies are configured and how support for them may have changed between major versions of Red Hat Enterprise Linux.

Hardware RAID

Any RAID functions provided by the mainboard of your computer, or attached controller cards, need to be configured before you begin the installation process. Each active RAID array appears as one drive within Red Hat Enterprise Linux.

Software RAID

On systems with more than one hard drive, you can use the Red Hat Enterprise Linux installation program to operate several of the drives as a Linux software RAID array. With a software RAID array, RAID functions are controlled by the operating system rather than the dedicated hardware.

Note

When a pre-existing RAID array’s member devices are all unpartitioned disks/drives, the installation program treats the array as a disk and there is no method to remove the array.

USB Disks

You can connect and configure external USB storage after installation. Most devices are recognized by the kernel, but some devices may not be recognized. If it is not a requirement to configure these disks during installation, disconnect them to avoid potential problems.

NVDIMM devices

To use a Non-Volatile Dual In-line Memory Module (NVDIMM) device as storage, the following conditions must be satisfied:

  • Version of Red Hat Enterprise Linux is 7.6 or later.
  • The architecture of the system is Intel 64 or AMD64.
  • The device is configured to sector mode. Anaconda can reconfigure NVDIMM devices to this mode.
  • The device must be supported by the nd_pmem driver.

Booting from an NVDIMM device is possible under the following additional conditions:

  • The system uses UEFI.
  • The device must be supported by firmware available on the system, or by a UEFI driver. The UEFI driver may be loaded from an option ROM of the device itself.
  • The device must be made available under a namespace.

To take advantage of the high performance of NVDIMM devices during booting, place the /boot and /boot/efi directories on the device.

Note

The Execute-in-place (XIP) feature of NVDIMM devices is not supported during booting and the kernel is loaded into conventional memory.

Considerations for Intel BIOS RAID Sets

Red Hat Enterprise Linux uses mdraid for installing on Intel BIOS RAID sets. These sets are automatically detected during the boot process and their device node paths can change across several booting processes. For this reason, local modifications to the /etc/fstab, /etc/crypttab or other configuration files that refer to the devices by their device node paths may not work in Red Hat Enterprise Linux. It is recommended that you replace device node paths (such as /dev/sda) with file system labels or device UUIDs. You can find the file system labels and device UUIDs using the blkid command.

Appendix B. Partitioning reference

B.1. Supported device types

Standard partition
A standard partition can contain a file system or swap space. Standard partitions are most commonly used for /boot and the BIOS Boot and EFI System partitions. LVM logical volumes are recommended for most other uses.
LVM
Choosing LVM (or Logical Volume Management) as the device type creates an LVM logical volume. If no LVM volume group currently exists, one is automatically created to contain the new volume; if an LVM volume group already exists, the volume is assigned. LVM can improve performance when using physical disks, and it allows for advanced setups such as using multiple physical disks for one mount point, and setting up software RAID for increased performance, reliability, or both.
LVM Thin Provisioning
Using thin provisioning, you can manage a storage pool of free space, known as a thin pool, which can be allocated to an arbitrary number of devices when needed by applications. You can dynamically expand the pool when needed for cost-effective allocation of storage space.

B.2. Supported file systems

This section describes the file systems available in Red Hat Enterprise Linux.

xfs
XFS is a highly scalable, high-performance file system that supports file systems up to 16 exabytes (approximately 16 million terabytes), files up to 8 exabytes (approximately 8 million terabytes), and directory structures containing tens of millions of entries. XFS also supports metadata journaling, which facilitates quicker crash recovery. The maximum supported size of a single XFS file system is 500 TB. XFS is the default and recommended file system on Red Hat Enterprise Linux.
ext4
The ext4 file system is based on the ext3 file system and features a number of improvements. These include support for larger file systems and larger files, faster and more efficient allocation of disk space, no limit on the number of subdirectories within a directory, faster file system checking, and more robust journaling. The maximum supported size of a single ext4 file system is 50 TB.
ext3
The ext3 file system is based on the ext2 file system and has one main advantage - journaling. Using a journaling file system reduces the time spent recovering a file system after it terminates unexpectedly, as there is no need to check the file system for metadata consistency by running the fsck utility every time.
ext2
An ext2 file system supports standard Unix file types, including regular files, directories, or symbolic links. It provides the ability to assign long file names, up to 255 characters.
swap
Swap partitions are used to support virtual memory. In other words, data is written to a swap partition when there is not enough RAM to store the data your system is processing.
vfat
The VFAT file system is a Linux file system that is compatible with Microsoft Windows long file names on the FAT file system.
BIOS Boot
A very small partition required for booting from a device with a GUID partition table (GPT) on BIOS systems and UEFI systems in BIOS compatibility mode.
EFI System Partition
A small partition required for booting a device with a GUID partition table (GPT) on a UEFI system.
PReP
This small boot partition is located on the first partition of the hard drive. The PReP boot partition contains the GRUB2 boot loader, which allows other IBM Power Systems servers to boot Red Hat Enterprise Linux.

B.3. Supported RAID types

RAID stands for Redundant Array of Independent Disks, a technology which allows you to combine multiple physical disks into logical units. Some setups are designed to enhance performance at the cost of reliability, while others will improve reliability at the cost of requiring more disks for the same amount of available space.

This section describes supported software RAID types which you can use with LVM and LVM Thin Provisioning to set up storage on the installed system.

None
No RAID array will be set up.
RAID0
Performance: Distributes data across multiple disks. RAID 0 offers increased performance over standard partitions and can be used to pool the storage of multiple disks into one large virtual device. Note that RAID 0 offers no redundancy and that the failure of one device in the array destroys data in the entire array. RAID 0 requires at least two disks.
RAID1
Redundancy: Mirrors all data from one partition onto one or more other disks. Additional devices in the array provide increasing levels of redundancy. RAID 1 requires at least two disks.
RAID4
Error checking: Distributes data across multiple disks and uses one disk in the array to store parity information which safeguards the array in case any disk in the array fails. As all parity information is stored on one disk, access to this disk creates a "bottleneck" in the array’s performance. RAID 4 requires at least three disks.
RAID5
Distributed error checking: Distributes data and parity information across multiple disks. RAID 5 offers the performance advantages of distributing data across multiple disks, but does not share the performance bottleneck of RAID 4 as the parity information is also distributed through the array. RAID 5 requires at least three disks.
RAID6
Redundant error checking: RAID 6 is similar to RAID 5, but instead of storing only one set of parity data, it stores two sets. RAID 6 requires at least four disks.
RAID10
Performance and redundancy: RAID 10 is nested or hybrid RAID. It is constructed by distributing data over mirrored sets of disks. For example, a RAID 10 array constructed from four RAID partitions consists of two mirrored pairs of striped partitions. RAID 10 requires at least four disks.

B.5. Advice on partitions

There is no best way to partition every system; the optimal setup depends on how you plan to use the system being installed. However, the following tips may help you find the optimal layout for your needs:

  • Create partitions that have specific requirements first, for example, if a particular partition must be on a specific disk.
  • Consider encrypting any partitions and volumes which might contain sensitive data. Encryption prevents unauthorized people from accessing the data on the partitions, even if they have access to the physical storage device. In most cases, you should at least encrypt the /home partition, which contains user data.
  • In some cases, creating separate mount points for directories other than /, /boot and /home may be useful; for example, on a server running a MySQL database, having a separate mount point for /var/lib/mysql will allow you to preserve the database during a reinstallation without having to restore it from backup afterwards. However, having unnecessary separate mount points will make storage administration more difficult.
  • Some special restrictions apply to certain directories with regards on which partitioning layouts can they be placed. Notably, the /boot directory must always be on a physical partition (not on an LVM volume).
  • If you are new to Linux, consider reviewing the Linux Filesystem Hierarchy Standard at http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html for information about various system directories and their contents.
  • Each kernel installed on your system requires approximately 20 MB on the /boot partition. The default partition size of 1 GB for /boot should suffice for most common uses; increase the size of this partition if you plan to keep many kernels installed at the same time.
  • The /var directory holds content for a number of applications, including the Apache web server, and is used by the DNF package manager to temporarily store downloaded package updates. Make sure that the partition or volume containing /var has at least 3 GB.
  • The contents of the /var directory usually change very often. This may cause problems with older solid state drives (SSDs), as they can handle a lower number of read/write cycles before becoming unusable. If your system root is on an SSD, consider creating a separate mount point for /var on a classic (platter) HDD.
  • The /usr directory holds the majority of software on a typical Red Hat Enterprise Linux installation. The partition or volume containing this directory should therefore be at least 5 GB for minimal installations, and at least 10 GB for installations with a graphical environment.
  • If /usr or /var is partitioned separately from the rest of the root volume, the boot process becomes much more complex because these directories contain boot-critical components. In some situations, such as when these directories are placed on an iSCSI drive or an FCoE location, the system may either be unable to boot, or it may hang with a Device is busy error when powering off or rebooting.

    This limitation only applies to /usr or /var, not to directories below them. For example, a separate partition for /var/www will work without issues.

  • Consider leaving a portion of the space in an LVM volume group unallocated. This unallocated space gives you flexibility if your space requirements change but you do not wish to remove data from other volumes. You can also select the LVM Thin Provisioning device type for the partition to have the unused space handled automatically by the volume.
  • The size of an XFS file system can not be reduced - if you need to make a partition or volume with this file system smaller, you must back up your data, destroy the file system, and create a new, smaller one in its place. Therefore, if you expect needing to manipulate your partitioning layout later, you should use the ext4 file system instead.
  • Use Logical Volume Management (LVM) if you anticipate expanding your storage by adding more hard drives or expanding virtual machine hard drives after the installation. With LVM, you can create physical volumes on the new drives, and then assign them to any volume group and logical volume as you see fit - for example, you can easily expand your system’s /home (or any other directory residing on a logical volume).
  • Creating a BIOS Boot partition or an EFI System Partition may be necessary, depending on your system’s firmware, boot drive size, and boot drive disk label. See Section B.4, “Recommended partitioning scheme” for information about these partitions. Note that graphical installation will not let you create a BIOS Boot or EFI System Partition if your system does not require one - in that case, they will be hidden from the menu.
  • If you need to make any changes to your storage configuration after the installation, Red Hat Enterprise Linux repositories offer several different tools which can help you do this. If you prefer a command line tool, try system-storage-manager.

Appendix C. Troubleshooting

The following sections cover various troubleshooting information which may be helpful when diagnosing installation issues.

C.1. Consoles and logging during installation

The Red Hat Enterprise Linux installer uses the tmux terminal multiplexer to display and control several windows you can use in addition to the main interface. Each of these windows serves a different purpose - they display several different logs, which can be used to troubleshoot any issues during the installation, and one of the windows provides an interactive shell prompt with root privileges, unless this prompt was specifically disabled using a boot option or a Kickstart command.

Note

In general, there is no reason to leave the default graphical installation environment unless you need to diagnose an installation problem.

The terminal multiplexer is running in virtual console 1. To switch from the actual installation environment to tmux, press Ctrl+Alt+F1. To go back to the main installation interface which runs in virtual console 6, press Ctrl+Alt+F6.

Note

If you choose text mode installation, you will start in virtual console 1 (tmux), and switching to console 6 will open a shell prompt instead of a graphical interface.

The console running tmux has 5 available windows; their contents are described in the table below, along with keyboard shortcuts used to access them. Note that the keyboard shortcuts are two-part: first press Ctrl+b, then release both keys, and press the number key for the window you want to use.

You can also use Ctrl+b n and Ctrl+b p to switch to the next or previous tmux window, respectively.

Table C.1. Available tmux windows

ShortcutContents

Ctrl+b 1

Main installation program window. Contains text-based prompts (during text mode installation or if you use VNC direct mode), and also some debugging information.

Ctrl+b 2

Interactive shell prompt with root privileges.

Ctrl+b 3

Installation log; displays messages stored in /tmp/anaconda.log.

Ctrl+b 4

Storage log; displays messages related storage devices from kernel and system services, stored in /tmp/storage.log.

Ctrl+b 5

Program log; displays messages from other system utilities, stored in /tmp/program.log.

C.2. Saving screenshots

You can press Shift+Print Screen at any time during the graphical installation to capture the current screen. These screenshots are saved to /tmp/anaconda-screenshots.

C.3. Resuming an interrupted download attempt

You can resume an interrupted download using the curl command.

Prerequisite

You have navigated to the Product Downloads section of the Red Hat Customer Portal at https://access.redhat.com/downloads, and selected the required variant, version, and architecture. You have right-clicked on the required ISO file, and selected Copy Link Location to copy the URL of the ISO image file to your clipboard.

Procedure

  1. Download the ISO image from the new link. Add the --continue-at - option to automatically resume the download:

    $ curl --output directory-path/filename.iso 'new_copied_link_location' --continue-at -
  2. Use a checksum utility such as sha256sum to verify the integrity of the image file after the download finishes:

    $ sha256sum rhel-8.0-x86_64-dvd.iso
    			`85a...46c rhel-8.0-x86_64-dvd.iso`

    Compare the output with reference checksums provided on the Red Hat Enterprise Linux Product Download web page.

Example C.1. Resuming an interrupted download attempt

The following is an example of a curl command for a partially downloaded ISO image:

$ curl --output _rhel-8.0-x86_64-dvd.iso 'https://access.cdn.redhat.com//content/origin/files/sha256/85/85a...46c/rhel-8.0-x86_64-dvd.iso?_auth=141...963' --continue-at -

Chapter 8. Composing a customized RHEL system image

Chapter 9. Image Builder description

9.1. Introduction to Image Builder

You can use Image Builder to create customized system images of Red Hat Enterprise Linux, including system images prepared for deployment on cloud platforms. Image Builder automatically handles details of setup for each output type and is thus easier to use and faster to work with than manual methods of image creation. You can access Image Builder functionality through a command line interface in the composer-cli tool, or a graphical user interface in the RHEL 8 web console.

Image Builder runs as a system service lorax-composer. You can interact with this service through two interfaces:

  • CLI tool composer-cli for running commands in the terminal. Prefer this method.
  • GUI plugin for the RHEL 8 web console.

9.2. Image Builder terminology

Blueprint

Blueprints define customized system images by listing packages and customizations that will be part of the system. Blueprints can be edited and they are versioned. When a system image is created from a blueprint, the image is associated with the blueprint in the Image Builder interface of the RHEL 8 web console.

Blueprints are presented to the user as plain text in the Tom’s Obvious, Minimal Language (TOML) format.

Compose
Composes are individual builds of a system image, based on a particular version of a particular blueprint. Compose as a term refers to the system image, the logs from its creation, inputs, metadata, and the process itself.
Customization
Customizations are specifications for the system, which are not packages. This includes users, groups, and SSH keys.

9.3. Image Builder output formats

Image Builder can create images in multiple output formats shown in the following table.

Table 9.1. Image Builder output formats

DescriptionCLI namefile extension

QEMU QCOW2 Image

qcow2

.qcow2

Ext4 File System Image

ext4-filesystem

.img

Raw Partitioned Disk Image

partitioned-disk

.img

Live Bootable ISO

live-iso

.iso

TAR Archive

tar

.tar

Amazon Machine Image Disk

ami

.ami

VMware Virtual Machine Disk

vmdk

.vmdk

Openstack

openstack

.qcow2

9.4. Image Builder system requirements

The lorax tool underlying Image Builder performs a number of potentially insecure and unsafe actions while creating the system images. For this reason, use a virtual machine to run Image Builder.

The environment where Image Builder runs must meet requirements listed in the following table.

Table 9.2. Image Builder system requirements

ParameterMinimal Required Value

System type

A dedicated virtual machine

Processor

2 cores

Memory

4 GiB

Disk space

20 GiB

Access privileges

Administrator level (root)

Network

Connectivity to Internet

Chapter 10. Installing Image Builder

Image Builder is a tool for creating custom system images. Before using Image Builder, you must install Image Builder in a virtual machine.

10.1. Image Builder system requirements

The lorax tool underlying Image Builder performs a number of potentially insecure and unsafe actions while creating the system images. For this reason, use a virtual machine to run Image Builder.

The environment where Image Builder runs must meet requirements listed in the following table.

Table 10.1. Image Builder system requirements

ParameterMinimal Required Value

System type

A dedicated virtual machine

Processor

2 cores

Memory

4 GiB

Disk space

20 GiB

Access privileges

Administrator level (root)

Network

Connectivity to Internet

10.2. Installing Image Builder in a virtual machine

To install Image Builder on a dedicated virtual machine, follow these steps:

Prerequisites

  • Connect to the virtual machine.
  • The virtual machine for Image Builder must be installed, subscribed, and running.

Procedure

  1. Install the Image Builder and other necessary packages on the virtual machine:

    • lorax-composer
    • composer-cli
    • cockpit-composer
    • bash-completion

      # yum install lorax-composer composer-cli cockpit-composer bash-completion

      The web console is installed as a dependency of the cockpit-composer package.

  2. Enable Image Builder to start after each reboot:

    # systemctl enable lorax-composer.socket
    # systemctl enable cockpit.socket

    The lorax-composer and cockpit services start automatically on first access.

  3. Configure the system firewall to allow access to the web console:

    # firewall-cmd --add-service=cockpit && firewall-cmd --add-service=cockpit --permanent
  4. Load the shell configuration script so that the autocomplete feature for the composer-cli command starts working immediately without reboot:

    $ source  /etc/bash_completion.d/composer-cli

Chapter 11. Creating system images with Image Builder command line interface

Image Builder is a tool for creating custom system images. To control Image Builder and create your custom system images, use the command line interface which is currently the preferred method to use Image Builder.

11.1. Image Builder command line interface

Image Builder command line interface is currently the preferred method to use Image Builder. It offers more functionality than the Web console interface. To use this interface, run the composer-cli command with suitable options and subcommands.

The workflow for the command line interface can be summarized as follows:

  1. Export (save) the blueprint definition to a plain text file
  2. Edit this file in a text editor
  3. Import (push) the blueprint text file back into Image Builder
  4. Run a compose to build an image from the blueprint
  5. Export the image file to download it

Apart from the basic subcommands to achieve this procedure, the composer-cli command offers many subcommands to examine the state of configured blueprints and composes.

To run the composer-cli command, user must be in the weldr or root groups.

11.2. Creating an Image Builder blueprint with command line interface

This procedure describes how to create a new Image Builder blueprint using the command line interface.

Procedure

  1. Create a plain text file with the following contents:

    name = "BLUEPRINT-NAME"
    description = "LONG FORM DESCRIPTION TEXT"
    version = "0.0.1"
    modules = []
    groups = []

    Replace BLUEPRINT-NAME and LONG FORM DESCRIPTION TEXT with a name and description for your blueprint.

    Replace 0.0.1 with a version number according to the Semantic Versioning scheme.

  2. For every package that you want to be included in the blueprint, add the following lines to the file:

    [[packages]]
    name = "package-name"
    version = "package-version"

    Replace package-name with name of the package, such as httpd, gdb-doc, or coreutils.

    Replace package-version with a version to use. This field supports dnf version specifications:

    • For a specific version, use the exact version number such as 8.30.
    • For latest available version, use the asterisk *.
    • For a latest minor version, use format such as 8..
  3. Blueprints can be customized in a number of ways. For this example, Simultaneous Multi Threading (SMT) can be disabled by performing the steps below. For additional customizations available, please see the Image Customizations section.

    [customizations.kernel]
    append = "nosmt=force"
  4. Save the file as BLUEPRINT-NAME.toml and close the text editor.
  5. Push (import) the blueprint:

    # composer-cli blueprints push BLUEPRINT-NAME.toml

    Replace BLUEPRINT-NAME with the value you used in previous steps.

  6. To verify that the blueprint has been pushed and exists, list the existing blueprints:

    # composer-cli blueprints list
  7. Check whether the components and versions listed in the blueprint and their dependencies are valid:

    # composer-cli blueprints depsolve BLUEPRINT-NAME

11.3. Editing an Image Builder blueprint with command line interface

This procedure describes how to edit an existing Image Builder blueprint in the command line interface.

Procedure

  1. Save (export) the blueprint to a local text file:

    # composer-cli blueprints save BLUEPRINT-NAME
  2. Edit the BLUEPRINT-NAME.toml file with a text editor of your choice and make your changes.
  3. Before finishing with the edits, make sure the file is a valid blueprint:

    1. Remove this line, if present:

      packages = []
    2. Increase the version number. Remember that Image Builder blueprint versions must use the Semantic Versioning scheme. Note also that if you do not change the version, the patch component of version is increased automatically.
    3. Check if the contents are valid TOML specifications. See the TOML documentation for more information.

      Note

      TOML documentation is a community product and is not supported by Red Hat. You can report any issues with the tool at https://github.com/toml-lang/toml/issues

  4. Save the file and close the editor.
  5. Push (import) the blueprint back into Image Builder:

    # composer-cli blueprints push BLUEPRINT-NAME.toml

    Note that you must supply the file name including the .toml extension, while in other commands you use only the name of the blueprint.

  6. To verify that the contents uploaded to Image Builder match your edits, list the contents of blueprint:

    # composer-cli blueprints show BLUEPRINT-NAME
  7. Check whether the components and versions listed in the blueprint and their dependencies are valid:

    # composer-cli blueprints depsolve BLUEPRINT-NAME

11.4. Creating a system image with Image Builder in the command line interface

This procedure shows how to build a custom image using the Image Builder command line interface.

Prerequisites

  • You have a blueprint prepared for the image.

Procedure

  1. Start the compose:

    # composer-cli compose start BLUEPRINT-NAME IMAGE-TYPE

    Replace BLUEPRINT-NAME with name of the blueprint, and IMAGE-TYPE with the type of image. For possible values, see output of the composer-cli compose types command.

    The compose process starts in the background and the UUID of the compose is shown.

  2. Wait until the compose is finished. Please, notice that this may take several minutes.

    To check the status of the compose:

    # composer-cli compose status

    A finished compose shows a status value FINISHED. Identify the compose in the list by its UUID.

  3. Once the compose is finished, download the resulting image file:

    # composer-cli compose image UUID

    Replace UUID with the UUID value shown in the previous steps.

    Alternatively, you can access the image file directly under the path /var/lib/lorax/composer/results/UUID/.

    You can also download the logs using the composer-cli compose logs UUID command, or the metadata using the composer-cli compose metadata UUID command.

11.5. Basic Image Builder command line commands

The Image Builder command line interface offers the following subcommands.

Blueprint manipulation

List all available blueprints
# composer-cli blueprints list
Show a blueprint contents in the TOML format
# composer-cli blueprints show BLUEPRINT-NAME
Save (export) blueprint contents in the TOML format into a file
# composer-cli blueprints save BLUEPRINT-NAME
Remove a blueprint
# composer-cli blueprints delete BLUEPRINT-NAME
Push (import) a blueprint file in the TOML format into Image Builder
# composer-cli blueprints push BLUEPRINT-NAME

Composing images from blueprints

Start a compose
# composer-cli compose start BLUEPRINT COMPOSE-TYPE

Replace BLUEPRINT with name of the blueprint to build and COMPOSE-TYPE with the output image type.

List all composes
# composer-cli compose list
List all composes and their status
# composer-cli compose status
Cancel a running compose
# composer-cli compose cancel COMPOSE-UUID
Delete a finished compose
# composer-cli compose delete COMPOSE-UUID
Show detailed information about a compose
# composer-cli compose info COMPOSE-UUID
Download image file of a compose
# composer-cli compose image COMPOSE-UUID

Related information

  • The composer-cli(1) manual page provides a full list of the available subcommands and options:

    $ man composer-cli
  • The composer-cli command provides help on the subcommands and options:

    # composer-cli help

11.6. Image Builder blueprint format

Image Builder blueprints are presented to user as plain text in the Tom’s Obvious, Minimal Language (TOML) format.

The elements of a typical blueprint file include:

The blueprint metadata
name = "BLUEPRINT-NAME"
description = "LONG FORM DESCRIPTION TEXT"
version = "VERSION"
modules = []
groups = []

Replace BLUEPRINT-NAME and LONG FORM DESCRIPTION TEXT with a name and description for your blueprint.

Replace VERSION with a version number according to the Semantic Versioning scheme.

This part is present only once for the whole blueprint file.

The entry modules describe the package names and matching version glob to be installed into the image.

The entry group describe a group of packages to be installed into the image.

Packages to include in the image
[[packages]]
name = "package-name"
version = "package-version"

Replace package-name with name of the package, such as httpd, gdb-doc, or coreutils.

Replace package-version with a version to use. This field supports dnf version specifications:

  • For a specific version, use the exact version number such as 8.30.
  • For latest available version, use the asterisk *.
  • For a latest minor version, use format such as 8..

Repeat this block for every package to include.

11.7. Supported Image Customizations

A number of image customizations are supported at this time within blueprints. In order to make use of these options, they must be initially configured in the blueprint and imported (pushed) to Image Builder.

Note

These customizations are not currently supported within the accompanying cockpit-composer GUI.

Set the image hostname
[[customizations]]]
hostname = "baseimage"
User specifications for the resulting system image
[[customizations.user]]
name = "USER-NAME"
description = "USER-DESCRIPTION"
password = "PASSWORD-HASH"
key = "ssh-rsa (...) key-name"
home = "/home/USER-NAME/"
shell = "/usr/bin/bash"
groups = ["users", "wheel"]
uid = NUMBER
gid = NUMBER
Important

To generate the hash using the command below, install python on your system. The following steps will help you install the platform-python that contains the packages python3 and python3.6.

# yum install platform-python

Replace PASSWORD-HASH with the actual password hash. To generate the hash, use eg. this command:

$ python3 -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'

Replace ssh-rsa (…​) key-name with the actual public key.

Replace the other placeholders with suitable values.

Leave out any of the lines as needed, only the user name is required.

Repeat this block for every user to include.

Group specifications for the resulting system image
[[customizations.group]]
name = "GROUP-NAME"
gid = NUMBER

Repeat this block for every group to include.

Set an existing users ssh key
[[customizations.sshkey]]
user = "root"
KEY = "PUBLIC SSH KEY"
Note

This option is only applicable for existing users. To create a user and set an ssh key, use the User specifications for the resulting system image customization.

Append a kernel boot parameter option to the defaults
[[customizations.kernel]]
append = "KERNEL OPTION"

Chapter 12. Creating system images with Image Builder web console interface

Image Builder is a tool for creating custom system images. To control Image Builder and create your custom system images, you can use the web console interface. Note that the command line interface is the currently preferred alternative, because it offers more features.

12.1. Accessing Image Builder GUI in the RHEL 8 web console

The cockpit-composer plugin for the RHEL 8 web console enables users to manage Image Builder blueprints and composes with a graphical interface. Note that the preferred method for controlling Image Builder is at the moment using the command line interface.

Prerequisites

  • You must have root access to the system.

Procedure

  1. Open https://localhost:9090/ in a web browser on the system where Image Builder is installed.

    For more information how to remotely access Image Builder, see managing systems using the RHEL 8 web console.

  2. Log into the web console with credentials for an user account with sufficient privileges on the system.
  3. To display the Image Builder controls, click the Image Builder icon, which is in the upper-left corner of the window.

    The Image Builder view opens, listing existing blueprints.

12.2. Creating an Image Builder blueprint in the web console interface

To describe the customized system image, create a blueprint first.

Prerequisites

  • You have opened the Image Builder interface of the RHEL 8 web console in a browser.

Procedure

  1. Click Create Blueprint in the top right corner.

    A pop-up appears with fields for the blueprint name and description.

  2. Fill in the name of the blueprint, its description, then click Create.

    The screen changes to blueprint editing mode.

  3. Add components that you want to include in the system image:

    1. On the left, enter all or part of the component name in the Available Components field and press Enter.

      The search is added to the list of filters under the text entry field, and the list of components below is reduced to these that match the search.

      If the list of components is too long, add further search terms in the same way.

    2. The list of components is paged. To move to other result pages, use the arrows and entry field above the component list.
    3. Click on name of the component you intend to use to display its details. The right pane fills with details of the components, such as its version and dependencies.
    4. Select the version you want to use in the Component Options box, with the Version Release dropdown.
    5. Click Add in the top left.
    6. If you added a component by mistake, remove it by clicking the …​ button at the far right of its entry in the right pane, and select Remove in the menu.
    Note

    If you do not intend to select version for some components, you can skip the component details screen and version selection by clicking the + buttons on the right side of the component list.

  4. To save the blueprint, click Commit in the top right A dialog with a summary of the changes pops up. Click Commit.

    A small pop-up on the right informs you of the saving progress and then the result.

  5. To exit the editing screen, click Back to Blueprints in the top left.

    The Image Builder view opens, listing existing blueprints.

12.3. Editing an Image Builder blueprint in the web console interface

To change the specifications for a custom system image, edit the corresponding blueprint.

Prerequisites

  • You have opened the Image Builder interface of the RHEL 8 web console in a browser.
  • A blueprint exists.

Procedure

  1. Locate the blueprint that you want to edit by entering its name or a part of it into the search box at top left, and press Enter.

    The search is added to the list of filters under the text entry field, and the list of blueprints below is reduced to these that match the search.

    If the list of blueprints is too long, add further search terms in the same way.

  2. On the right side of the blueprint, press the Edit Blueprint button that belongs to the blueprint.

    The view changes to the blueprint editing screen.

  3. Remove unwanted components by clicking their button at the far right of its entry in the right pane, and select Remove in the menu.
  4. Change version of existing components:

    1. On the Blueprint Components search field, enter component name or a part of it into the field under the heading Blueprint Components and press Enter.

      The search is added to the list of filters under the text entry field, and the list of components below is reduced to these that match the search.

      If the list of components is too long, add further search terms in the same way.

    2. Click the button at the far right of the component entry, and select View in the menu.

      A component details screen opens in the right pane.

    3. Select the desired version in the Version Release drop-down menu and click Apply Change in top right.

      The change is saved and the right pane returns to listing the blueprint components.

  5. Add new components:

    1. On the left, enter component name or a part of it into the field under the heading Available Components and press Enter.

      The search is added to the list of filters under the text entry field, and the list of components below is reduced to these that match the search.

      If the list of components is too long, add further search terms in the same way.

    2. The list of components is paged. To move to other result pages, use the arrows and entry field above the component list.
    3. Click on name of the component you intend to use to display its details. The right pane fills with details of the components, such as its version and dependencies.
    4. Select the version you want to use in the Component Options box, with the Version Release drop-down menu.
    5. Click Add in the top right.
    6. If you added a component by mistake, remove it by clicking the button at the far right of its entry in the right pane, and select Remove in the menu.
Note

If you do not intend to select version for some components, you can skip the component details screen and version selection by clicking the + buttons on the right side of the component list.

  1. Commit a new version of the blueprint with your changes:

    1. Click the Commit button in top right.

      A pop-up window with a summary of your changes appears.

    2. Review your changes and confirm them by clicking Commit.

      A small pop-up on the right informs you of the saving progress and then result. A new version of the blueprint is created.

    3. In the top left, click Back to Blueprints to exit the editing screen.

      The Image Builder view opens, listing existing blueprints.

12.4. Adding users and groups to an Image Builder blueprint in the web console interface

Adding customizations such as users and groups to blueprints in the web console interface is currently not possible. To work around this limitation, use the Terminal tab in web console to use the command line interface (CLI) workflow.

Prerequisites

  • A blueprint must exist.
  • A CLI text editor such as vim, nano, or emacs must be installed. To install them:

    # yum install editor-name

Procedure

  1. Find out the name of the blueprint: Open the Image Builder (Image builder) tab on the left in the RHEL 8 web console to see the name of the blueprint.
  2. Navigate to the CLI in web console: Open the system administation tab on the left, then select the last item Terminal from the list on the left.
  3. Enter the super-user (root) mode:

    $ sudo bash

    Provide your credentials when asked. Note that the terminal does not reuse your credentials you entered when logging into the web console.

    A new shell with root privileges starts in your home directory.

  4. Export the blueprint to a file:

    # composer-cli blueprints save BLUEPRINT-NAME
  5. Edit the file BLUEPRINT-NAME.toml with a CLI text editor of your choice and add the users and groups.

    Important

    RHEL 8 web console does not have any built-in feature to edit text files on the system, so the use of a CLI text editor is required for this step.

    1. For every user to be added, add this block to the file:

      [[customizations.user]]
      name = "USER-NAME"
      description = "USER-DESCRIPTION"
      password = "PASSWORD-HASH"
      key = "ssh-rsa (...) key-name"
      home = "/home/USER-NAME/"
      shell = "/usr/bin/bash"
      groups = ["users", "wheel"]
      uid = NUMBER
      gid = NUMBER

      Replace PASSWORD-HASH with the actual password hash. To generate the hash, use eg. this command:

      $ python3 -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'

      Replace ssh-rsa (…​) key-name with the actual public key.

      Replace the other placeholders with suitable values.

      Leave out any of the lines as needed, only the user name is required.

    2. For every user group to be added, add this block to the file:

      [[customizations.group]]
      name = "GROUP-NAME"
      gid = NUMBER
    3. Increase the version number.
    4. Save the file and close the editor.
  6. Import the blueprint back into Image Builder:

    # composer-cli blueprints push BLUEPRINT-NAME.toml

    Note that you must supply the file name including the .toml extension, while in other commands you use only the name of the blueprint.

  7. To verify that the contents uploaded to Image Builder match your edits, list the contents of blueprint:

    # composer-cli blueprints show BLUEPRINT-NAME

    Check if the version matches what you put in the file and if your customizations are present.

    Important

    The Image Builder plugin for RHEL 8 web console does not show any information that could be used to verify that the changes have been applied, unless you edited also the packages included in the blueprint.

  8. Exit the privileged shell:

    # exit
  9. Open the Image Builder (Image builder) tab on the left and refresh the page, in all browsers and all tabs where it was opened.

    This prevents state cached in the loaded page from accidentally reverting your changes.

12.5. Creating a system image with Image Builder in the web console interface

The following steps below describe creating a system image.

Prerequisites

  • You have opened the Image Builder interface of the RHEL 8 web console in a browser.
  • A blueprint exists.

Procedure

  1. Locate the blueprint that you want to build an image by entering its name or a part of it into the search box at top left, and press Enter.

    The search is added to the list of filters under the text entry field, and the list of blueprints below is reduced to these that match the search.

    If the list of blueprints is too long, add further search terms in the same way.

  2. On the right side of the blueprint, press the Create Image button that belongs to the blueprint.

    A pop-up window appears.

  3. Select the image type and architecture and press Create.

    A small pop-up in the top right informs you that the image creation has been added to the queue.

  4. Click the name of the blueprint.

    A screen with details of the blueprint opens.

  5. Click the Images tab to switch to it. The image that is being created is listed with the status In Progress.

    Note

    Image creation takes a longer time, measured in minutes. There is no indication of progress while the image is created.

    To abort image creation, press its Stop button on the right.

  6. Once the image is successfully created, the Stop button is replaced by a Download button. Click this button to download the image to your system.

Chapter 13. Deploying cloud images with Image Builder

Image Builder can create custom system images ready for use in clouds of various providers. To use your customized RHEL system image in a cloud, create the system image with Image Builder using the respective output type, configure your system for uploading the image, and upload the image to your cloud account.

13.1. Preparing for uploading AWS AMI images

This describes steps to configure a system for uploading AWS AMI images.

Prerequisites

Procedure

  1. Install Python 3 and the pip tool:

    # yum install python3
    # yum install python3-pip
  2. Install the AWS command line tools with pip:

    # pip3 install awscli
  3. Configure the AWS command line client according to your AWS access details:

    $ aws configure
    AWS Access Key ID [None]:
    AWS Secret Access Key [None]:
    Default region name [None]:
    Default output format [None]:
  4. Configure the AWS command line client to use your bucket:

    $ BUCKET=bucketname
    $ aws s3 mb s3://$BUCKET

    Replace bucketname with the actual bucket name.

  5. Create a vmimport S3 Role in IAM and grant it permissions to access S3, if you have not already done so in the past:

    $ printf '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "vmie.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals":{ "sts:Externalid": "vmimport" } } } ] }' > trust-policy.json
    $ printf '{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucket" ], "Resource":[ "arn:aws:s3:::%s", "arn:aws:s3:::%s/*" ] }, { "Effect":"Allow", "Action":[ "ec2:ModifySnapshotAttribute", "ec2:CopySnapshot", "ec2:RegisterImage", "ec2:Describe*" ], "Resource":"*" } ] }' $BUCKET $BUCKET > role-policy.json
    $ aws iam create-role --role-name vmimport --assume-role-policy-document file://trust-policy.json
    $ aws iam put-role-policy --role-name vmimport --policy-name vmimport --policy-document file://role-policy.json

13.2. Uploading an AMI image to AWS

This section describes how to upload an AMI image to AWS.

Prerequisites

  • Your system must be set up for uploading AWS images.
  • You must have an AWS image created by Image Builder. Use the ami output type in CLI or Amazon Machine Image Disk (.ami) in GUI when creating the image.

Procedure

  1. Push the image to S3:

    $ AMI=8db1b463-91ee-4fd9-8065-938924398428-disk.ami
    $ aws s3 cp $AMI s3://$BUCKET
    Completed 24.2 MiB/4.4 GiB (2.5 MiB/s) with 1 file(s) remaining
    ...
  2. After the upload to S3 ends, import the image as a snapshot into EC2:

    $ printf '{ "Description": "my-image", "Format": "raw", "UserBucket": { "S3Bucket": "%s", "S3Key": "%s" } }' $BUCKET $AMI > containers.json
    $ aws ec2 import-snapshot --disk-container file://containers.json

    Replace my-image with the name of the image.

    To track progress of the import, run:

    $ aws ec2 describe-import-snapshot-tasks --filters Name=task-state,Values=active
  3. Create an image from the uploaded snapshot by selecting the snapshot in the EC2 console, right clicking on it and selecting Create Image:

    composer aws ec2 select snapshot

  4. Select the Virtualization type of Hardware-assisted virtualization in the image you create:

    composer aws ec2 create image

  5. Now you can run an instance using whatever mechanism you like (CLI or AWS Console) from the snapshot. Use your private key via SSH to access the resulting EC2 instance. Log in as ec2-user.

13.3. Uploading VMDK images to vSphere

Image Builder can generate images suitable for uploading to a VMware ESXi or vSphere system. This describes steps to upload an VMDK image to VMware vSphere.

Note

Because VMWare deployments typically does not have cloud-init configured to inject user credentials to virtual machines, we must perform that task ourselves on the blueprint.

Prerequisites

  • You must have an VMDK image created by Image Builder. Use the vmdk output type in CLI or VMware Virtual Machine Disk (.vmdk) in GUI when creating the image.

Procedure

  1. Upload the image into vSphere via HTTP. Click on Upload Files in the vCenter:

    composer vmware upload image

  2. When you create a VM, on the Device Configuration, delete the default New Hard Disk and use the drop-down to select an Existing Hard Disk disk image:

    composer vmware existing disk

  3. Make sure you use an IDE device as the Virtual Device Node for the disk you create. The default value SCSI results in an unbootable virtual machine.

    composer vmware existing ide

13.4. Uploading QCOW2 image to OpenStack

Image Builder can generate images suitable for uploading to OpenStack cloud deployments, and starting instances there. This describes steps to upload an QCOW2 image to OpenStack.

Prerequisites

  • You must have an OpenStack-specific image created by Image Builder. Use the openstack output type in CLI or OpenStack Image (.qcow2) in GUI when creating the image.

    Warning

    Image Builder also offers a generic QCOW2 image type output format as qcow2 or QEMU QCOW2 Image (.qcow2). Do not mistake it with the OpenStack image type which is also in the QCOW2 format, but contains further changes specific to OpenStack.

Procedure

  1. Upload the image to OpenStack and start an instance from it. Use the Images interface to do this:

    composer openstack upload image

  2. Start an instance with that image:

    composer openstack start instance

  3. You can run the instance using any mechanism (CLI or OpenStack web UI) from the snapshot. Use your private key via SSH to access the resulting instance. Log in as cloud-user.

Chapter 14. Performing an automated installation using Kickstart

Chapter 15. Kickstart installation basics

Learn what Kickstart is and how to automate installations of Red Hat Enterprise Linux with it.

15.1. What are Kickstart installations

Kickstart installations offer a means to automate the installation process, either partially or fully. Kickstart files contain answers to all questions normally asked by the installation program, such as what time zone you want the system to use, how the drives should be partitioned, or which packages should be installed. Providing a prepared Kickstart file therefore allows you to perform the installation automatically, without need for any manual intervention from the user. This is especially useful when deploying Red Hat Enterprise Linux on a large number of systems at once.

In addition to allowing you to automate the installation, Kickstart files also provide more options regarding software selection. When installing Red Hat Enterprise Linux manually using the graphical installation interface, your software selection is limited to pre-defined environments and add-ons. A Kickstart file allows you to install or remove individual packages as well.

Kickstart files can be kept on a single server system and read by individual computers during the installation. This installation method can support the use of a single Kickstart file to install Red Hat Enterprise Linux on multiple machines, making it ideal for network and system administrators.

All Kickstart scripts and the log files of their execution are stored in the /tmp directory to assist with debugging installation issues.

Note

In previous versions of Red Hat Enterprise Linux, Kickstart could be used for upgrading the system as well. Starting with Red Hat Enterprise Linux 7, this functionality has been removed and system upgrades are instead handled by specialized tools. For details on upgrading to Red Hat Enterprise Linux 8, see the documents Upgrading to RHEL 8 and Considerations in adopting RHEL 8.

15.2. Automated installation workflow

Kickstart installations can be performed using a local DVD, a local hard drive, NFS, FTP, HTTP, or HTTPS.

To use Kickstart:

  1. Create a Kickstart file. Instead of writing it entirely by hand, you can copy a Kickstart file saved after a manual installation, or use an online generator tool to create the file, and edit it afterwards.
  2. Make the Kickstart file available on removable media, a hard drive or a network location using an HTTP(S), FTP, or NFS server.
  3. Create the boot media, which will be used to begin the installation.
  4. Make the installation source available, similarly to the Kickstart file.
  5. Start the Kickstart installation. Use the inst.ks= boot option either in the boot menu or in the boot loader configuration file to load the Kickstart file and use it during the installation.
  6. Let the installation finish. This will happen automatically if the Kickstart file contains all mandatory commands and sections. If one or more of these mandatory parts are missing, or if an error occurs, the installation will require manual intervention to finish.

Chapter 16. Creating Kickstart files

Learn how to create a Kickstart file easier and faster than writing the file manually from scratch. The methods are:

  • Copy a Kickstart file created as a result of a manual installation
  • Use the online Kickstart configuration tool

You can manually edit and customize the file later, changing only the complicated parts.

16.1. Creating a Kickstart file by performing a manual installation

The recommended approach to creating Kickstart files is to perform a manual installation on one system first. After the installation completes, all choices made during the installation are saved into a file named anaconda-ks.cfg, located in the /root/ directory on the installed system. You can then use this file to reproduce the installation in exactly the same way as before. Alternatively, copy this file, make any changes you need, and use the resulting configuration file for further installations.

Procedure

  1. Install RHEL using the graphical interface on a system.

    During the installation, create a user with administrator privileges.

  2. Finish the installation and reboot into the installed system.
  3. Log into the system with the administrator account.
  4. Copy the file /root/anaconda-ks.cfg to a location of your choice.

    • To display the file contents in terminal:

      # cat /root/anaconda-ks.cfg

      You can copy the output and save to another file of your choice.

    • To copy the file to another location, use the file manager. Remember to change permissions on the copy, so that the file can be read by non-root users.
    Important

    The file contains information about users and passwords.

16.2. Creating a Kickstart file with the Kickstart configuration tool

Users with a Red Hat Customer Portal account can use the Kickstart Configuration Tool in the Customer Portal Labs to generate Kickstart files online. This tool will walk you through the basic configuration and enables you to download the resulting Kickstart file. However, the tool currently does not support any advanced partitioning.

Procedure

  1. Open the Kickstart generator lab information page at https://access.redhat.com/labsinfo/kickstartconfig
  2. Click the Go to Application button to the left of heading and wait for the next page to load.
  3. Select Red Hat Enterprise Linux 8 in the drop-down menu and wait for the page to update.
  4. Complete the form details that describe the system to be installed.

    You can use the links on the left side of the form to quickly navigate between the sections of the form.

  5. To download the generated Kickstart file, click the red Download button at the top of the page.

    Your web browser will save the file.

Chapter 17. Making Kickstart files available to the installation program

Learn about the options you have for placing the Kickstart file so that the installation program on the target system can read this file.

17.1. Ports for network-based installation

The following table lists the ports that must be open on the server providing the files for each type of network-based installation.

Table 17.1. Ports for network-based installation

Protocol usedPorts to open

HTTP

80

HTTPS

443

NFS

2049, 111, 20048

TFTP

69

Additional resources

17.2. Making a Kickstart file available on an NFS server

This procedure describes how to place the Kickstart script file on an NFS server. This method enables you to install multiple systems from a single source, without having to use physical media. A network-based installation is convenient when used with a TFTP server, as it enables you to boot the installation from the network. This approach eliminates the need to create physical media and simultaneously deploys Red Hat Enterprise Linux on multiple systems.

Prerequisites

  • You must have administrator level access to a server system reachable on the local network from the system to be installed.
  • Your server firewall must allow the system you are installing to access the server.

Procedure

Note

To perform an NFS-based installation, another system must act as the NFS host. This procedure is a basic outline of the process. The steps to set up an NFS server vary depending on the system’s architecture, operating system, package manager, and service manager.

  1. Install the nfs-utils package by running the following command as root:

    # yum install nfs-utils
  2. Copy the Kickstart file to a directory on the NFS server.
  3. Open the /etc/exports file using a text editor and add a line with the following syntax:

    /exported_directory/ clients
  4. Replace /exported_directory/ with the full path to the directory holding the Kickstart file. Instead of clients, use the host name or IP address of the computer that is to be installed from this NFS server, the subnetwork from which all computers are to have access the ISO image, or the asterisk sign (*) if you want to allow any computer with network access to the NFS server to use the ISO image. See the exports(5) man page for detailed information about the format of this field.

    A basic configuration that makes the /rhel8-install/ directory available as read-only to all clients is:

    /rhel8-install *
  5. Save the /etc/exports file and exit the text editor.
  6. Start the nfs service:

    # systemctl start nfs-server.service

    If the service was running before you changed the /etc/exports file, enter the following command, in order for the running NFS server to reload its configuration:

    # systemctl reload nfs-server.service

    The Kickstart file is now accessible over NFS and ready to be used for installation.

Note

When specifying the Kickstart source, use nfs: as the protocol, the server’s host name or IP address, the colon sign (:), and the path inside directory holding the file. For example, if the server’s host name is myserver.example.com and you have saved the file in /rhel8-install/my-ks.cfg, specify inst.ks=nfs:myserver.example.com:/rhel8-install/my-ks.cfg as the installation source boot option.

17.3. Making a Kickstart file available on an HTTP or HTTPS server

Place the Kickstart file on an HTTP or HTTPS server for a network-based installation.

Prerequisites

  • You must have administrator level access to a server system reachable on the local network from the system to be installed.
  • Your server firewall must allow the system you are installing to access the server.

Procedure

  1. Install the httpd package by running the following command as root:

    # yum install httpd
    Warning

    If your Apache web server configuration enables SSL security, verify that you only enable the TLSv1 protocol, and disable SSLv2 and SSLv3. This is due to the POODLE SSL vulnerability (CVE-2014-3566). See https://access.redhat.com/solutions/1232413 for details.

    Important

    If you use an HTTPS server with a self-signed certificate, you must boot the installation program with the inst.noverifyssl option.

  2. Copy the Kickstart file to the HTTP(S) server into a subdirectory of the /var/www/html/ directory.
  3. Start the httpd service:

    # systemctl start httpd.service

    The Kickstart file is now accessible and ready to be used for installation.

    Note

    When specifying the location of the Kickstart file, use http:// or https:// as the protocol, the server’s host name or IP address, and the path of the Kickstart file, relative to the HTTP server root. For example, if you are using HTTP, the server’s host name is myserver.example.com, and you have copied the Kickstart file as /var/www/html/rhel8-install/my-ks.cfg, specify http://myserver.example.com/rhel8-install/my-ks.cfg as the file location.

Additional resources

17.4. Making a Kickstart file available on a local volume

A Kickstart file can be present directly on a volume on the system to be installed. This lets you bypass the need for another system.

Prerequisites

  • You must have a drive that can be moved to the system to be installed, such as a USB stick.
  • The drive must contain a partition that can be read by the installation program. The supported types are ext2, ext3, ext4, xfs, and fat.
  • The drive must be already connected to the system and its volumes mounted.

Procedure

  1. Find where the volumes from the drive are mounted, and what their UUIDs are:

    # lsblk -l -p -o name,rm,ro,hotplug,size,type,mountpoint,uuid
  2. Navigate to a suitable file system mounted from the drive.
  3. Copy the Kickstart file into any place in this file system.
  4. The string to use later with the inst.ks= option is in the form hd:UUID=UUID:path/to/kickstart-file.cfg. Note that the path is relative to the file system root, not to the / root of file system hierarchy.
  5. Unmount the drive volumes:

    # umount /dev/xyz ...

    Add all the volumes to the command, separated by spaces.

17.5. Making a Kickstart file available on a local volume for automatic loading

A specially named Kickstart file can be present in the root of a specially named volume on the system to be installed. This lets you bypass the need for another system, and makes the installation program load the file automatically.

Prerequisites

  • You must have a drive that can be moved to the system to be installed, such as a USB stick.
  • The drive must contain a partition that can be read by the installation program. The supported types are ext2, ext3, ext4, xfs, and fat.
  • The drive must be already connected to the system and its volumes mounted.

Procedure

  1. Find where the volumes from the drive are mounted:

    # lsblk -l -p
  2. Navigate to a suitable file system mounted from the drive.
  3. Copy the Kickstart file into root of this file system.
  4. Rename the volume as OEMDRV:

    • For ext2, ext3, and ext4 file systems:

      # e2label /dev/xyz OEMDRV
    • For the XFS file system:

      # xfs_admin -L OEMDRV /dev/xyz

    Replace /dev/xyz with the path to the volume’s block device.

  5. Unmount the drive volumes:

    # umount /dev/xyz ...

    Add all the volumes to the command, separated by spaces.

Chapter 18. Creating installation sources for Kickstart installations

This section describes how to create an installation source for the Boot ISO image using the Binary DVD ISO image that contains the required repositories and software packages.

18.1. Types of installation source

You can use one of the following installation sources for minimal boot images:

  • DVD: Burn the Binary DVD ISO image to DVD and configure the installation program to install the software packages.
  • Hard drive or USB drive: Copy the Binary DVD ISO image to the drive and configure the installation program to install the software packages from the drive. If you use a USB drive, verify that it is connected to the system before the installation begins. The installation program cannot detect media after the installation begins.

    • Hard drive limitation: The Binary DVD ISO image on the hard drive must be on a partition with a file system that the installation program can mount. The supported file systems are xfs, ext2, ext3, ext4, and vfat (FAT32).
Warning

On Microsoft Windows systems, the default file system used when formatting hard drives is NTFS; the exFAT file system is also available. However, neither of these file systems can be mounted during the installation. If you are creating a hard drive or a USB drive as an installation source on Microsoft Windows, verify that you formatted the drive as FAT32, however, the FAT32 file system cannot store files larger than 4 GiB.

In Red Hat Enterprise Linux 8 you can enable installation from a repository on a local hard drive. To do so, you need to copy the content of DVD ISO image to a directory on a hard drive and then specify the directory as installation source instead of the ISO image. For example: inst.repo=hd:<device>:<path to the repository>

  • Network location: Copy the Binary DVD ISO image or the installation tree (extracted contents of the Binary DVD ISO image) to a network location and perform the installation over the network using the following protocols:

    • NFS: The Binary DVD ISO image is in a Network File System (NFS) share.
    • HTTPS or HTTP: The installation tree is on a network location that is accessible over HTTP or HTTPS.

18.2. Ports for network-based installation

The following table lists the ports that must be open on the server providing the files for each type of network-based installation.

Table 18.1. Ports for network-based installation

Protocol usedPorts to open

HTTP

80

HTTPS

443

NFS

2049, 111, 20048

TFTP

69

Additional resources

18.3. Creating an installation source on an NFS server

Follow the steps in this procedure to place the installation source on an NFS server. Use this installation method to install multiple systems from a single source, without having to connect to physical media. A network-based installation is convenient when used with a TFTP server, as it enables you to boot the installation from the network. This approach eliminates the need to create physical media and simultaneously deploys Red Hat Enterprise Linux on multiple systems.

Prerequisites

  • You have downloaded a Binary DVD image. See Downloading the installation ISO image from the Performing a standard RHEL installation document for more information.
  • You have created a bootable CD, DVD, or USB device from the image file. See Creating installation media from the Performing a standard RHEL installation document for more information.
  • You have verified that your firewall allows the server you are installing to access the remote installation source. See Ports for network-based installation from the Performing a standard RHEL installation document for more information.

Procedure

Note

The NFS installation method uses the Binary DVD ISO image in a Network File System server’s exported directory, which the system must be able to read. To perform an NFS-based installation, another system must act as the NFS host. The steps to configure an NFS server vary depending on the system architecture, operating system, package manager, and service manager. This procedure contains a basic outline of the process.

  1. Install the nfs-utils package by running the following command as root:

    # yum install nfs-utils
  2. Copy the Binary DVD ISO image to a directory on the NFS server.
  3. Open the /etc/exports file using a text editor and add a line with the following syntax:

    /exported_directory/ clients
  4. Replace /exported_directory/ with the full path to the directory with the ISO image. Replace clients with the host name or IP address of the target system, the subnetwork that all target systems can use to access the ISO image, or the asterisk sign (*) if you want to allow any system with network access to the NFS server to use the ISO image. See the exports(5) man page for detailed information about the format of this field.

    A basic configuration that makes the /rhel8-install/ directory available as read-only to all clients is:

    /rhel8-install *
  5. Save the /etc/exports file and exit the text editor.
  6. Start the nfs service:

    # systemctl start nfs-server.service

    If the service was running before you changed the /etc/exports file, run the following command for the running NFS server to reload its configuration:

    # systemctl reload nfs-server.service

    The ISO image is now accessible over NFS and ready to be used as an installation source.

Note

When configuring the installation source, use nfs: as the protocol, the server host name or IP address, the colon sign (:), and the directory holding the ISO image. For example, if the server host name is myserver.example.com and you have saved the ISO image in /rhel8-install/, specify nfs:myserver.example.com:/rhel8-install/ as the installation source.

18.4. Creating an installation source using HTTP or HTTPS

Follow the steps in this procedure to create an installation source for a network-based installation using an installation tree, which is a directory containing extracted contents of the Binary DVD ISO image and a valid .treeinfo file. The installation source is accessed over HTTP or HTTPS.

Prerequisites

  • You have downloaded a Binary DVD image. See Downloading the installation ISO image from the Performing a standard RHEL installation document for more information.
  • You have created a bootable CD, DVD, or USB device from the image file. See Creating installation media from the Performing a standard RHEL installation document for more information.
  • You have verified that your firewall allows the server you are installing to access the remote installation source. See Ports for network-based installation from the Performing a standard RHEL installation document for more information.

Procedure

  1. Install the httpd package by running the following command as root:

    # yum install httpd
    Warning

    If your Apache web server configuration enables SSL security, verify that you enable only the TLSv1 protocol, and disable SSLv2 and SSLv3. This is due to the POODLE SSL vulnerability (CVE-2014-3566). See https://access.redhat.com/solutions/1232413 for details.

    Important

    If you use an HTTPS server with a self-signed certificate, you must boot the installation program with the noverifyssl option.

  2. Copy the Binary DVD ISO image to the HTTP(S) server.
  3. Mount the Binary DVD ISO image, using the mount command, to a suitable directory:

    # mount -o loop,ro -t iso9660 /image_directory/image.iso /mount_point/
    • Replace /image_directory/image.iso with the path to the Binary DVD ISO image.
    • Replace /mount_point/ with the path to the directory where you want to locate the contents of the ISO image.
  4. Copy the files from the mounted image to the HTTP(S) server root. This command creates the /var/www/html/rhel8-install/ directory with the contents of the image.

    # cp -r /mnt/rhel8-install/ /var/www/html/
  5. Start the httpd service:

    # systemctl start httpd.service

    The installation tree is now accessible and ready to be used as the installation source.

    Note

    When configuring the installation source, use http:// or https:// as the protocol, the server host name or IP address, and the directory that contains the files from the ISO image, relative to the HTTP server root. For example, if you are using HTTP, the server host name is myserver.example.com, and you have copied the files from the image to /var/www/html/rhel8-install/, specify http://myserver.example.com/rhel8-install/ as the installation source.

Additional resources

Chapter 19. Starting Kickstart installations

You can start Kickstart installations in multiple ways:

  • Manually by entering the installation program boot menu and specifying the options including Kickstart file there.
  • Automatically by editing the boot options in PXE boot.
  • Automatically by providing the file on a volume with specific name.

Learn how to perform each of these methods in the following sections.

19.1. Starting a Kickstart installation manually

This section explains how to start a Kickstart installation manually, which means some user interaction is required (adding boot options at the boot: prompt). Use the boot option inst.ks=location when booting the installation system, replacing location with the location of your Kickstart file. The exact way to specify the boot option depends on your system’s architecture.

Prerequisites

  • You have a Kickstart file ready in a location accessible from the system to be installated

Procedure

  1. Boot the system using a local media (a CD, DVD, or a USB flash drive).
  2. At the boot prompt, specify the required boot options.

    1. If the Kickstart file or a required repository is in a network location, you may need to configure the network using the ip= option. The installer tries to configure all network devices using the DHCP protocol by default without this option.
    2. Add the inst.ks= boot option and the location of the Kickstart file.
    3. In order to access a software source from which necessary packages will be installed, you may need to add the inst.repo= option. If you do not specify this option, you must specify the installation source in the Kickstart file.
  3. Start the installation by confirming your added boot options.

    The installation begins now, using the options specified in the Kickstart file. If the Kickstart file is valid and contains all required commands, the installation is completely automated from this point forward.

19.2. Starting a Kickstart installation automatically using PXE

AMD64, Intel 64, and 64-bit ARM systems and IBM Power Systems servers have the ability to boot using a PXE server. When you configure the PXE server, you can add the boot option into the boot loader configuration file, which in turn lets you start the installation automatically. Using this approach, it is possible to automate the installation completely, including the boot process.

This procedure is intended as a general reference; detailed steps differ based on your system’s architecture, and not all options are available on all architectures (for example, you cannot use PXE boot on IBM Z).

Prerequisites

  • You must have a Kickstart file ready in a location accessible from the system to be installated.
  • You must have a PXE server which can be used to boot the system and begin the installation.

Procedure

  1. Open the boot loader configuration file on your PXE server, and add the inst.ks= boot option to the appropriate line. The name of the file and its syntax depends on your system’s architecture and hardware:

    • On AMD64 and Intel 64 systems with BIOS, the file name can be either default or based on your system’s IP address. In this case, add the inst.ks= option to the append line in the installation entry. A sample append line in the configuration file looks similar to the following:

      append initrd=initrd.img inst.ks=http://10.32.5.1/mnt/archive/RHEL-8/8.x/x86_64/kickstarts/ks.cfg
    • On systems using the GRUB2 boot loader (AMD64, Intel 64, and 64-bit ARM systems with UEFI firmware and IBM Power Systems servers), the file name will be grub.cfg. In this file, append the inst.ks= option to the kernel line in the installation entry. A sample kernel line in the configuration file will look similar to the following:

      kernel vmlinuz inst.ks=http://10.32.5.1/mnt/archive/RHEL-8/8.x/x86_64/kickstarts/ks.cfg
  2. Boot the installation from the network server.

    The installation begins now, using the installation options specified in the Kickstart file. If the Kickstart file is valid and contains all required commands, the installation is completely automated.

19.3. Starting a Kickstart installation automatically using a local volume

You can start a Kickstart installation by putting a Kickstart file with a specific name on a specifically labelled storage volume.

Prerequisites

  • You must have a volume prepared with label OEMDRV and the Kickstart file present in its root as ks.cfg.
  • A drive containing this volume must be available on the system as the installation program boots.

Procedure

  1. Boot the system using a local media (a CD, DVD, or a USB flash drive).
  2. At the boot prompt, specify the required boot options.

    1. If a required repository is in a network location, you may need to configure the network using the ip= option. The installer tries to configure all network devices using the DHCP protocol by default without this option.
    2. In order to access a software source from which necessary packages will be installed, you may need to add the inst.repo= option. If you do not specify this option, you must specify the installation source in the Kickstart file.
  3. Start the installation by confirming your added boot options.

    The installation begins now, and the Kickstart file is automatically detected and used to start an automated Kickstart installation.

Chapter 20. Consoles and logging during installation

The Red Hat Enterprise Linux installer uses the tmux terminal multiplexer to display and control several windows you can use in addition to the main interface. Each of these windows serves a different purpose - they display several different logs, which can be used to troubleshoot any issues during the installation, and one of the windows provides an interactive shell prompt with root privileges, unless this prompt was specifically disabled using a boot option or a Kickstart command.

Note

In general, there is no reason to leave the default graphical installation environment unless you need to diagnose an installation problem.

The terminal multiplexer is running in virtual console 1. To switch from the actual installation environment to tmux, press Ctrl+Alt+F1. To go back to the main installation interface which runs in virtual console 6, press Ctrl+Alt+F6.

Note

If you choose text mode installation, you will start in virtual console 1 (tmux), and switching to console 6 will open a shell prompt instead of a graphical interface.

The console running tmux has 5 available windows; their contents are described in the table below, along with keyboard shortcuts used to access them. Note that the keyboard shortcuts are two-part: first press Ctrl+b, then release both keys, and press the number key for the window you want to use.

You can also use Ctrl+b n and Ctrl+b p to switch to the next or previous tmux window, respectively.

Table 20.1. Available tmux windows

ShortcutContents

Ctrl+b 1

Main installation program window. Contains text-based prompts (during text mode installation or if you use VNC direct mode), and also some debugging information.

Ctrl+b 2

Interactive shell prompt with root privileges.

Ctrl+b 3

Installation log; displays messages stored in /tmp/anaconda.log.

Ctrl+b 4

Storage log; displays messages related storage devices from kernel and system services, stored in /tmp/storage.log.

Ctrl+b 5

Program log; displays messages from other system utilities, stored in /tmp/program.log.

Chapter 21. Maintaining Kickstart files

You can run automated checks on Kickstart files. Typically, you will want to verify that a new or problematic Kickstart file is valid.

21.1. Installing Kickstart maintenance tools

To use the Kickstart maintenance tools, you must install the package that contains them.

Procedure

  • Install the pykickstart package:

    # yum install pykickstart

21.2. Verifying a Kickstart file

Use the ksvalidator command line utility to verify that your Kickstart file is valid. This is useful when you make extensive changes to a Kickstart file.

Procedure

  • Run ksvalidator on your Kickstart file:

    $ ksvalidator /path/to/kickstart.ks

    Replace /path/to/kickstart.ks with the path to the Kickstart file you want to verify.

Important

The validation tool cannot guarantee the installation will be successful. It ensures only that the syntax is correct and that the file does not include deprecated options. It does not attempt to validate the %pre, %post and %packages sections of the Kickstart file.

Additional resources

  • The ksvalidator(1) manual page.

Chapter 22. Advanced configuration options

Chapter 23. Configuring System Purpose

System administrators use System Purpose to record the intended use of a Red Hat Enterprise Linux 8 system by the organization. When you set a system’s purpose, the entitlement server receives information that helps auto-attach a subscription that satisfies the intended use of the system. This section describes how to configure System Purpose using Kickstart.

23.1. Overview

You can enter System Purpose data in the following ways:

  • During image creation.
  • During installation using the graphical user interface.
  • Using Kickstart automation scripts.
  • Using the syspurpose command-line tool.

You can configure the following components:

  • Role:

    • Red Hat Enterprise Linux Server
    • Red Hat Enterprise Linux Workstation
    • Red Hat Enterprise Linux Compute Node
  • Service Level Agreement:

    • Premium
    • Standard
    • Self-Support
  • Usage:

    • Production
    • Disaster Recovery
    • Development/Test

Benefits include:

  • In-depth system-level information for system administrators and business operations.
  • Reduced overhead when determining why a system was procured and its intended purpose.
  • Improved customer experience of Subscription Manager auto-attach as well as automated discovery and reconciliation of system usage.

Additional resources

23.2. Configuring System Purpose in a Kickstart file

Follow the steps in this procedure to use the syspurpose command to configure System Purpose in a Kickstart configuration file.

Note

While it is strongly recommended that you configure System Purpose, it is an optional feature of the Red Hat Enterprise Linux installation program. If you want to enable System Purpose after the installation completes, you can do so using the syspurpose command-line tool.

The following actions are available:

role

Set the intended role of the system. This action uses the following format:

syspurpose --role=

The role assigned can be:

  • Red Hat Enterprise Linux Server
  • Red Hat Enterprise Linux Workstation
  • Red Hat Enterprise Linux Compute Node
sla

Set the intended sla of the system. This action uses the following format:

syspurpose --sla=

The sla assigned can be:

  • Premium
  • Standard
  • Self-Support
usage

Set the intended usage of the system. This action uses the following format:

syspurpose --usage=

The usage assigned can be:

  • Production
  • Disaster Recovery
  • Development/Test

Chapter 24. Updating drivers during installation

This section describes how to complete a driver update during the Red Hat Enterprise Linux installation process.

Note

This is an optional step of the installation process. Red Hat recommends that you do not perform a driver update unless it is necessary.

24.1. Prerequisite

You have been notified by Red Hat, your hardware vendor, or a trusted third-party vendor that a driver update is required during Red Hat Enterprise Linux installation.

24.2. Overview

Red Hat Enterprise Linux supports drivers for many hardware devices but some newly-released drivers may not be supported. A driver update should only be performed if an unsupported driver prevents the installation from completing. Updating drivers during installation is typically only required to support a particular configuration. For example, installing drivers for a storage adapter card that provides access to your system’s storage devices.

Warning

Driver update disks may disable conflicting kernel drivers. In rare cases, unloading a kernel module may cause installation errors.

24.3. Types of driver update

Red Hat, your hardware vendor, or a trusted third party provides the driver update as an ISO image file. Once you receive the ISO image file, choose the type of driver update.

Types of driver update

Automatic
The recommended driver update method; a storage device (including a CD, DVD, or USB flash drive) labeled OEMDRV is physically connected to the system. If the OEMDRV storage device is present when the installation starts, it is treated as a driver update disk, and the installation program automatically loads its drivers.
Assisted
The installation program prompts you to locate a driver update. You can use any local storage device with a label other than OEMDRV. The inst.dd boot option is specified when starting the installation. If you use this option without any parameters, the installation program displays all of the storage devices connected to the system, and prompts you to select a device that contains a driver update.
Manual
Manually specify a path to a driver update image or an RPM package. You can use any local storage device with a label other than OEMDRV, or a network location accessible from the installation system. The inst.dd=location boot option is specified when starting the installation, where location is the path to a driver update disk or ISO image. When you specify this option, the installation program attempts to load any driver updates found at the specified location. With manual driver updates, you can specify local storage devices, or a network location (HTTP, HTTPS or FTP server).
Note
  • You can use both inst.dd=location and inst.dd simultaneously, where location is the path to a driver update disk or ISO image. In this scenario, the installation program attempts to load any available driver updates from the location and also prompts you to select a device that contains the driver update.
  • Initialize the network using the ip= option when loading a driver update from a network location.

Limitations

On UEFI systems with the Secure Boot technology enabled, all drivers must be signed with a valid certificate. Red Hat drivers are signed by one of Red Hat’s private keys and authenticated by its corresponding public key in the kernel. If you load additional, separate drivers, verify that they are signed.

24.4. Preparing a driver update

This procedure describes how to prepare a driver update on a CD and DVD.

Prerequisites

  • You received the driver update ISO image from Red Hat, your hardware vendor, or a trusted third-party vendor.
  • You burned the driver update ISO image to a CD or DVD.
Warning

If only a single ISO image file ending in .iso is available on the CD or DVD, the burn process has not been successful. See your system’s burning software documentation for instructions on how to burn ISO images to a CD or DVD.

Procedure

  1. Insert the driver update CD or DVD into your system’s CD/DVD drive, and browse it using the system’s file manager tool.
  2. Verify that a single file rhdd3 is available. rhdd3 is a signature file that contains the driver description and a directory named rpms, which contains the RPM packages with the actual drivers for various architectures.

24.5. Performing an automatic driver update

This procedure describes how to perform an automatic driver update during installation.

Prerequisites

  • You have placed the driver update image on a standard disk partition with an OEMDRV label or burnt the OEMDRV driver update image to a CD or DVD. Advanced storage, such as RAID or LVM volumes, may not be accessible during the driver update process.
  • You have connected a block device with an OEMDRV volume label to your system, or inserted the prepared CD or DVD into your system’s CD/DVD drive before starting the installation process.

Procedure

  1. Once you have completed the prerequisite steps, the drivers are automatically loaded when the installation program starts, and installed on the system during the installation process.

24.6. Performing an assisted driver update

This procedure describes how to perform an assisted driver update during installation.

Prerequisite

You have connected a block device without an OEMDRV volume label to your system and copied the driver disk image to this device, or you have prepared a driver update CD or DVD and inserted it into your system’s CD/DVD drive before starting the installation process.

Note

If you burned an ISO image file to a CD or DVD but it does not have the OEMDRV volume label, you can use the inst.dd option with no arguments. The installation program provides an option to scan and select drivers from the CD or DVD. In this scenario, the installation program does not prompt you to select a driver update ISO image. Another scenario is to use the CD or DVD with the inst.dd=location boot option; this allows the installation program to automatically scan the CD or DVD for driver updates. For more information, see Section 24.7, “Performing a manual driver update”.

Procedure

  1. From the boot menu window, press the Tab key on your keyboard to display the boot command line.
  2. Append the inst.dd boot option to the command line and press Enter to execute the boot process.
  3. From the menu, select a local disk partition or a CD or DVD device. The installation program scans for ISO files, or driver update RPM packages.
  4. Optional: Select the driver update ISO file.

    Note

    This step is not required if the selected device or partition contains driver update RPM packages rather than an ISO image file, for example, an optical drive containing a driver update CD or DVD.

  5. Select the required drivers.

    1. Use the number keys on your keyboard to toggle the driver selection.
    2. Press c to install the selected driver. The selected driver is loaded and the installation process starts.

24.7. Performing a manual driver update

This procedure describes how to perform a manual driver update during installation.

Prerequisite

Place the driver update ISO image file on a USB flash drive or a web server, and connect it to your computer.

Procedure

  1. From the boot menu window, press the Tab key on your keyboard to display the boot command line.
  2. Append the inst.dd=location boot option to the command line, where location is a path to the driver update. Typically, the image file is located on a web server, for example, http://server.example.com/dd.iso, or on a USB flash drive, for example, /dev/sdb1. It is also possible to specify an RPM package containing the driver update, for example http://server.example.com/dd.rpm.
  3. Press Enter to execute the boot process. The drivers available at the specified location are automatically loaded and the installation process starts.

Additional resources

  • For more information about the inst.dd boot option, see the upstream inst.dd boot option content.
  • For more information about all boot options, see the upstream Boot Options content.

24.8. Disabling a driver

This procedure describes how to disable a malfunctioning driver.

Prerequisites

  • You have booted the installation program boot menu.

Procedure

  1. From the boot menu, press the Tab key on your keyboard to display the boot command line.
  2. Append the modprobe.blacklist=driver_name boot option to the command line.
  3. Replace driver_name with the name of the driver or drivers you want to disable, for example:

    modprobe.blacklist=ahci

    Drivers disabled using the modprobe.blacklist= boot option remain disabled on the installed system and appear in the /etc/modprobe.d/anaconda-blacklist.conf file.

  4. Press Enter to execute the boot process.

Chapter 25. Preparing to install from the network using PXE

This section describes how to configure TFTP and DHCP on a PXE server to enable PXE boot and network installation.

25.1. Network install overview

A network installation allows you to install Red Hat Enterprise Linux to a system that has access to an installation server. At a minimum, two systems are required for a network installation:

PXE Server: A system running a DHCP server, a TFTP server, and an HTTP, HTTPS, FTP, or NFS server. While each server can run on a different physical system, the procedures in this section assume a single system is running all servers.

Client: The system to which you are installing Red Hat Enterprise Linux. Once installation starts, the client queries the DHCP server, receives the boot files from the TFTP server, and downloads the installation image from the HTTP, HTTPS, FTP or NFS server. Unlike other installation methods, the client does not require any physical boot media for the installation to start.

Note

To boot a client from the network, configure it in BIOS/UEFI or a quick boot menu. On some hardware, the option to boot from a network might be disabled, or not available.

The workflow steps to prepare to install Red Hat Enterprise Linux from a network using PXE are as follows:

Steps

  1. Export the installation ISO image (or the installation tree) to an NFS, HTTPS, HTTP, or FTP server.
  2. Configure the TFTP server and DHCP server, and start the TFTP service on the PXE server.
  3. Boot the client, and start the installation.
Important

The GRUB2 boot loader supports a network boot from HTTP in addition to a TFTP server. Sending the boot files (the kernel and initial RAM disk - vmlinuz and initrd) over this protocol might be slow and result in timeout failures. An HTTP server does not carry this risk, but it is recommended that you use a TFTP server when sending the boot files.

Additional resources

25.2. Configuring a TFTP server for BIOS-based clients

This procedure describes how to configure a TFTP server and DHCP server, and start the TFTP service on the PXE server for BIOS-based AMD and Intel 64-bit systems.

Procedure

  1. As root, install the tftp-server package:

    # yum install tftp-server
  2. Allow incoming connections to the tftp service in the firewall:

    # firewall-cmd --add-service=tftp
    Note

    This command enables temporary access until the next server reboot. To enable permanent access, add the --permanent option to the command.

  3. Configure your DHCP server to use the boot images packaged with SYSLINUX. A sample configuration in the /etc/dhcp/dhcpd.conf file might look like:

    option space pxelinux;
    option pxelinux.magic code 208 = string;
    option pxelinux.configfile code 209 = text;
    option pxelinux.pathprefix code 210 = text;
    option pxelinux.reboottime code 211 = unsigned integer 32;
    option architecture-type code 93 = unsigned integer 16;
    
    subnet 10.0.0.0 netmask 255.255.255.0 {
    	option routers 10.0.0.254;
    	range 10.0.0.2 10.0.0.253;
    
    	class "pxeclients" {
    	  match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
    	  next-server 10.0.0.1;
    
    	  if option architecture-type = 00:07 {
    	    filename "uefi/shim.efi";
    	    } else {
    	    filename "pxelinux/pxelinux.0";
    	  }
    	}
    }
  4. Access the pxelinux.0 file from the SYSLINUX package in the Binary DVD ISO image file:

    # mount -t iso9660 /path_to_image/name_of_image.iso /mount_point -o loop,ro
    # cp -pr /mount_point/BaseOS/Packages/syslinux-tftpboot-version-architecture.rpm /publicly_available_directory
    # umount /mount_point
  5. Extract the package:

    # rpm2cpio syslinux-tftpboot-version-architecture.rpm | cpio -dimv
  6. Create a pxelinux/ directory within tftpboot/ and copy the required files, for example: pxelinux.0 libcom.c32, ldlinux.c32, vesamenu.c32 into it:

    # mkdir /var/lib/tftpboot/pxelinux
    # cp publicly_available_directory/tftpboot/pxelinux.0 /var/lib/tftpboot/pxelinux
  7. Create the directory pxelinux.cfg/ in the pxelinux/ directory:

    # mkdir /var/lib/tftpboot/pxelinux/pxelinux.cfg
  8. Add a default configuration file to the pxelinux.cfg/ directory. A sample configuration file at /var/lib/tftpboot/pxelinux/pxelinux.cfg/default might look like:

    default vesamenu.c32
    prompt 1
    timeout 600
    
    display boot.msg
    
    label linux
      menu label ^Install system
      menu default
      kernel images/RHEL-8.0/vmlinuz
      append initrd=images/RHEL-8.0/initrd.img ip=dhcp inst.repo=http://10.32.5.1/mnt/archive/RHEL-8/8.x/Server/x86_64/os/
    label vesa
      menu label Install system with ^basic video driver
      kernel images/RHEL-8.0/vmlinuz
      append initrd=images/RHEL-8.0/initrd.img ip=dhcp inst.xdriver=vesa nomodeset inst.repo=http://10.32.5.1/mnt/archive/RHEL-8/8.x/Server/x86_64/os/
    label rescue
      menu label ^Rescue installed system
      kernel images/RHEL-8.0/vmlinuz
      append initrd=images/RHEL-8.0/initrd.img rescue
    label local
      menu label Boot from ^local drive
      localboot 0xffff
    Note

    The inst.repo= option must be used to specify the installation program’s image as well as the installation source. The installation program cannot boot without this option.

  9. Create a subdirectory to store the boot image files in the /var/lib/tftpboot/ directory, and copy the boot image files to the directory. In this example, we use the directory /var/lib/tftpboot/pxelinux/images/RHEL-8.0/:

    # mkdir -p /var/lib/tftpboot/pxelinux/images/RHEL-8.0/
    # cp /path_to_x86_64_images/pxeboot/{vmlinuz,initrd.img} /var/lib/tftpboot/pxelinux/images/RHEL-8.0/
  10. Start and enable the dhcpd service:

    # systemctl start dhcpd
    # systemctl enable dhcpd
  11. Start and enable the xinetd service that manages the tftp service:

    # systemctl start xinetd
    # systemctl enable xinetd

    The PXE boot server is now ready to serve PXE clients. You can start the client (the system to which you are installing Red Hat Enterprise Linux), select PXE Boot when prompted to specify a boot source, and start the network installation.

25.3. Configuring a TFTP server for UEFI-based clients

This procedure describes how to configure a TFTP server and DHCP server, and start the TFTP service on the PXE server for UEFI-based AMD64, Intel 64, and 64-bit ARM systems.

Procedure

  1. As root, install the tftp-server package:

    # yum install tftp-server
  2. Allow incoming connections to the tftp service in the firewall:

    # firewall-cmd --add-service=tftp
    Note

    This command enables temporary access until the next server reboot. To enable permanent access, add the --permanent option to the command.

  3. Configure your DHCP server to use the boot images packaged with shim. A sample configuration in the /etc/dhcp/dhcpd.conf file might look like:

    option space pxelinux;
    option pxelinux.magic code 208 = string;
    option pxelinux.configfile code 209 = text;
    option pxelinux.pathprefix code 210 = text;
    option pxelinux.reboottime code 211 = unsigned integer 32;
    option architecture-type code 93 = unsigned integer 16;
    
    subnet 10.0.0.0 netmask 255.255.255.0 {
    	option routers 10.0.0.254;
    	range 10.0.0.2 10.0.0.253;
    
    	class "pxeclients" {
    	  match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
    	  next-server 10.0.0.1;
    
    	  if option architecture-type = 00:07 {
    	    filename "shim.efi";
    	  } else {
    	    filename "pxelinux/pxelinux.0";
    		}
      }
    }
  4. Access the shim.efi file from the shim package, and the grubx64.efi file from the grub2-efi package in the Binary DVD ISO image file:

    # mount -t iso9660 /path_to_image/name_of_image.iso /mount_point -o loop,ro
    # cp -pr /mount_point/BaseOS/Packages/shim-version-architecture.rpm /publicly_available_directory
    # cp -pr /mount_point/BaseOS/Packages/grub2-efi-version-architecture.rpm /publicly_available_directory
    # umount /mount_point
  5. Extract the packages:

    # rpm2cpio shim-version-architecture.rpm | cpio -dimv
    # rpm2cpio grub2-efi-version-architecture.rpm | cpio -dimv
  6. Copy the EFI boot images from your boot directory.

    # cp publicly_available_directory/boot/efi/EFI/redhat/shimx64.efi /var/lib/tftpboot/uefi/
    # cp publicly_available_directory/boot/efi/EFI/redhat/grubx64.efi /var/lib/tftpboot/uefi
    Important

    You must rename the shimx64.efi file to shim.efi after it is copied.

  7. Add a configuration file named grub.cfg to the tftpboot/ directory. A sample configuration file at /var/lib/tftpboot/uefi/grub.cfg may look like:

    set timeout=60
    menuentry 'RHEL 8' {
      linuxefi images/RHEL-8.0/vmlinuz ip=dhcp inst.repo=http://10.32.5.1/mnt/archive/RHEL-8.0/Server/x86_64/os/
      initrdefi images/RHEL-8.0/initrd.img
    }
    Note

    The inst.repo= option must be used to specify the installation program’s image as well as the installation source. The installation program cannot boot without this option.

  8. Create a subdirectory to store the boot image files in the /var/lib/tftpboot/ directory, and copy the boot image files to the directory. In this example, we use the directory /var/lib/tftpboot/images/RHEL-8.0/:

    # mkdir -p /var/lib/tftpboot/images/RHEL-8.0/
    # cp /path_to_x86_64_images/pxeboot/{vmlinuz,initrd.img} /var/lib/tftpboot/images/RHEL-8.0/
  9. Start and enable the dhcpd service:

    # systemctl start dhcpd
    # systemctl enable dhcpd
  10. Start and enable the xinetd service that manages the tftp service:

    # systemctl start xinetd
    # systemctl enable xinetd

    The PXE boot server is now ready to serve PXE clients. You can start the client (the system to which you are installing Red Hat Enterprise Linux), select PXE Boot when prompted to specify a boot source, and start the network installation.

Additional resources

25.4. Configuring a network server for IBM Power systems

This procedure describes how to configure a network boot server for IBM Power systems using GRUB2.

Procedure

  1. As root, install the tftp-server package:

    # yum install tftp-server
  2. Allow incoming connections to the tftp service in the firewall:

    # firewall-cmd --add-service=tftp
    Note

    This command enables temporary access until the next server reboot. To enable permanent access, add the --permanent option to the command.

  3. Create a GRUB2 network boot directory inside the tftp root.

    # grub2-mknetdir --net-directory=/var/lib/tftpboot
    Netboot directory for powerpc-ieee1275 created. Configure your DHCP server to point to /boot/grub2/powerpc-ieee1275/core.elf
    Note

    The command’s output informs you of the file name that needs to be configured in your DHCP configuration, described in this procedure.

    1. If the PXE server runs on an x86 machine, the grub2-ppc64-modules must be installed before creating a GRUB2 network boot directory inside the tftp root:

      # yum install grub2-ppc64-modules
  4. Create a GRUB2 configuration file: /var/lib/tftpboot/boot/grub2/grub.cfg. Below is an example configuration file:

    set default=0
    set timeout=5
    
    echo -e "\nWelcome to the Red Hat Enterprise Linux 8 installer!\n\n"
    
    menuentry 'Red Hat Enterprise Linux 8' {
      linux grub2-ppc64/vmlinuz ro ip=dhcp inst.repo=http://10.32.5.1/mnt/archive/RHEL-8.0/Server/ppc64/os/
      initrd grub2-ppc64/initrd.img
    }
    Note

    The inst.repo= option must be used to specify the installation program’s image as well as the installation source. The installation program cannot boot without this option.

  5. Mount the Binary DVD ISO image using the command:

    # mount -t iso9660 /path_to_image/name_of_iso/ /mount_point -o loop,ro
  6. Create a directory and copy the initrd.img and vmlinuz files from Binary DVD ISO image into it, for example:

    # cp /mount_point/ppc/ppc64/{initrd.img,vmlinuz} /var/lib/tftpboot/grub2-ppc64/
  7. Configure your DHCP server to use the boot images packaged with GRUB2. A sample configuration in the /etc/dhcp/dhcpd.conf file might look like:

    subnet 192.168.0.1 netmask 255.255.255.0 {
      allow bootp;
      option routers 192.168.0.5;
      group { #BOOTP POWER clients
        filename "boot/grub2/powerpc-ieee1275/core.elf";
        host client1 {
        hardware ethernet 01:23:45:67:89:ab;
        fixed-address 192.168.0.112;
        }
      }
    }
  8. Adjust the sample parameters (subnet, netmask, routers, fixed-address and hardware ethernet) to fit your network configuration. Note the file name parameter; this is the file name that was outputted by the grub2-mknetdir command earlier in this procedure.
  9. Start and enable the dhcpd service:

    # systemctl start dhcpd
    # systemctl enable dhcpd
  10. Start and enable xinetd service that manages the tftp service:

    # systemctl start xinetd
    # systemctl enable xinetd

    The PXE boot server is now ready to serve PXE clients. You can start the client (the system to which you are installing Red Hat Enterprise Linux), select PXE Boot when prompted to specify a boot source, and start the network installation.

Chapter 26. Boot options

This section contains information about some of the boot options that you can use to modify the default behavior of the installation program. For a full list of boot options, see the upstream boot option content.

26.1. Types of boot options

There are two types of boot options; those with an equals "=" sign, and those without an equals "=" sign. Boot options are appended to the boot command line and multiple options must be separated by a single space. Boot options that are specific to the installation program always start with inst.

Options with an equals "=" sign
You must specify a value for boot options that use the = symbol. For example, the inst.vncpassword= option must contain a value, in this case, a password. The correct syntax for this example is inst.vncpassword=password.
Options without an equals "=" sign
This boot option does not accept any values or parameters. For example, the rd.live.check option forces the installation program to verify the installation media before starting the installation. If this boot option is present, the verification is performed; if the boot option is not present, the verification is skipped.

26.2. Editing boot options

This section contains information about the different ways that you can edit boot options from the boot menu. The boot menu opens after you boot the installation media.

Editing the boot: prompt

When using the boot: prompt, the first option must always specify the installation program image file that you want to load. In most cases, you can specify the image using the keyword. You can specify additional options according to your requirements.

Prerequisites

  • You have created bootable installation media (USB, CD or DVD).
  • You have booted the installation from the media, and the installation boot menu is open.

Procedure

  1. With the boot menu open, press the Esc key on your keyboard.
  2. The boot: prompt is now accessible.
  3. Press the Tab key on your keyboard to display the help commands.
  4. Press the Enter key on your keyboard to start the installation with your options. To return from the boot: prompt to the boot menu, restart the system and boot from the installation media again.
Note

The boot: prompt also accepts dracut kernel options. A list of options is available in the dracut.cmdline(7) man page.

Editing the > prompt

You can use the > prompt to edit predefined boot options. For example, select Test this media and install Red Hat Enterprise Linux 8.0.0 from the boot menu to display a full set of options.

Note

This procedure is for BIOS-based AMD64 and Intel 64 systems.

Prerequisites

  • You have created bootable installation media (USB, CD or DVD).
  • You have booted the installation from the media, and the installation boot menu is open.

Procedure

  1. From the boot menu, select an option and press the Tab key on your keyboard. The > prompt is accessible and displays the available options.
  2. Append the options that you require to the > prompt.
  3. Press the Enter key on your keyboard to start the installation.
  4. Press the Esc key on your keyboard to cancel editing and return to the boot menu.

Editing the GRUB2 menu

The GRUB2 menu is available on UEFI-based AMD64, Intel 64, and 64-bit ARM systems.

Prerequisites

  • You have created bootable installation media (USB, CD or DVD).
  • You have booted the installation from the media, and the installation boot menu is open.

Procedure

  1. From the boot menu window, select an option and press the e key on your keyboard.
  2. When you finish editing, press F10 or Ctrl+X on your keyboard to start the installation using the specified options.

26.3. Installation source boot options

This section contains information about the various installation source boot options.

inst.repo=

The inst.repo= boot option specifies the installation source, that is, the location of images and packages. For example: inst.repo=cdrom. The target of the inst.repo= option must be one of the following installation media:

  • an installable tree, which is a directory structure containing the installation program images, packages, and repository data as well as a valid .treeinfo file
  • a DVD (a physical disk present in the system DVD drive)
  • an ISO image of the full Red Hat Enterprise Linux installation DVD, placed on a hard drive or a network location accessible to the system.

    You can use the inst.repo= boot option to configure different installation methods using different formats. The following table contains details of the inst.repo= boot option syntax:

    Table 26.1. Installation source boot options

    Installation sourceBoot option format

    Any CD/DVD drive

    inst.repo=cdrom

    Specific CD/DVD drive

    inst.repo=cdrom:device

    Hard Drive

    inst.repo=hd:device:/path

    HMC

    inst.repo=hmc

    HTTP Server

    inst.repo=http://host/path

    HTTPS Server

    inst.repo=https://host/path

    NFS Server

    inst.repo=nfs:[options:]server:/path

    Note

    The NFS Server option uses NFS protocol version 3 by default. To use a different version, add +nfsvers=X to the option.

    You can set disk device names with the following formats:

  • Kernel device name, for example /dev/sda1 or sdb2
  • File system label, for example LABEL=Flash or LABEL=RHEL8
  • File system UUID, for example UUID=8176c7bf-04ff-403a-a832-9557f94e61db

    Non-alphanumeric characters must be represented as \xNN, where NN is the hexadecimal representation of the character. For example, \x20 is a white space (" ").

inst.stage2=

The inst.stage2= boot option specifies the location of the installation program runtime image. This option expects a path to a directory containing a valid .treeinfo file. The location of the runtime image is read from the .treeinfo file. If the .treeinfo file is not available, the installation program attempts to load the image from LiveOS/squashfs.img.

You can use the inst.stage2= boot option multiple times to specify multiple HTTP or HTTPS sources. For example:

inst.stage2=host1/install.img inst.stage2=host2/install.img
inst.stage2=host3/install.img
Note

By default, the inst.stage2= boot option is used on the installation media and is set to a specific label, for example, inst.stage2=hd:LABEL=RHEL-8-0-0-BaseOS-x86_64. If you modify the default label of the file system containing the runtime image, or if you use a customized procedure to boot the installation system, you must verify that the inst.stage2= boot option is set to the correct value.

inst.dd=
The inst.dd= boot option is used to perform a driver update during the installation. See the Performing an advanced RHEL installation document for information on how to update drivers during installation.
inst.repo=hmc
When booting from a Binary DVD, the installation program prompts you to enter additional kernel parameters. To set the DVD as an installation source, append inst.repo=hmc to the kernel parameters. The installation program then enables SE and HMC file access, fetches the images for stage2 from the DVD, and provides access to the packages on the DVD for software selection. This option eliminates the requirement of an external network setup and expands the installation options.

Additional resources

26.4. Network boot options

This section contains information about commonly used network boot options.

Note

Initial network initialization is handled by dracut. For a complete list, see the dracut.cmdline(7) man page.

ip=

Use the ip= boot option to configure one or more network interfaces. To configure multiple interfaces, you can use the ip option multiple times - once for each interface. If you configure multiple interfaces, you must specify a primary boot interface using the bootdev option. Alternatively, you can use the ip option once, and then use Kickstart to set up further interfaces. This option accepts several different formats. The following tables contain information about the most common options.

Note

In the following tables:

  • The ip parameter specifies the client IP address. You can specify IPv6 addresses in square brackets, for example, [2001:DB8::1].
  • The gateway parameter is the default gateway. IPv6 addresses are also accepted.
  • The netmask parameter is the netmask to be used. This can be either a full netmask (for example, 255.255.255.0) or a prefix (for example, 64).
  • The hostname parameter is the host name of the client system. This parameter is optional.

Table 26.2. Network interface configuration boot option formats

Configuration methodBoot option format

Automatic configuration of any interface

ip=method

Automatic configuration of a specific interface

ip=interface:method

Static configuration

ip=ip::gateway:netmask:hostname:interface:none

Automatic configuration of a specific interface with an override

ip=ip::gateway:netmask:hostname:interface:method:mtu

Note

The method automatic configuration of a specific interface with an override brings up the interface using the specified method of automatic configuration, such as dhcp, but overrides the automatically-obtained IP address, gateway, netmask, host name or other specified parameters. All parameters are optional, so specify only the parameters that you want to override.

The method parameter can be any of the following:

Table 26.3. Automatic interface configuration methods

Automatic configuration methodValue

DHCP

dhcp

IPv6 DHCP

dhcp6

IPv6 automatic configuration

auto6

iSCSI Boot Firmware Table (iBFT)

ibft

Note
  • If you use a boot option that requires network access, such as inst.ks=http://host:/path, without specifying the ip option, the installation program uses ip=dhcp.
  • To connect to an iSCSI target automatically, you must activate a network device for accessing the target. The recommended way to activate a network is to use the ip=ibft boot option.
nameserver=
The nameserver= option specifies the address of the name server. You can use this option multiple times.
rd.neednet=
Typically, ip= options are applied only if the network is required by the installation (based on any other boot options that are used). You can use rd.neednet=1 to explicitly force the application of ip= options.
bootdev=
The bootdev= option specifies the boot interface. This option is mandatory if you use more than one ip option.
ifname=

The ifname= options assigns an interface name to a network device with a given MAC address. You can use this option multiple times. The syntax is ifname=interface:MAC. For example:

ifname=eth0:01:23:45:67:89:ab
Note

The ifname= option is the only supported way to set custom network interface names during installation.

inst.dhcpclass=
The inst.dhcpclass= option specifies the DHCP vendor class identifier. The dhcpd service sees this value as vendor-class-identifier. The default value is anaconda-$(uname -srm).
inst.waitfornet=
Using the inst.waitfornet=SECONDS boot option causes the installation system to wait for network connectivity before installation. The value given in the SECONDS argument specifies the maximum amount of time to wait for network connectivity before timing out and continuing the installation process even if network connectivity is not present.
vlan=

Use the vlan= option to configure a Virtual LAN (VLAN) device on a specified interface with a given name. The syntax is vlan=name:interface. For example:

vlan=vlan5:em1

This configures a VLAN device named vlan5 on the em1 interface. The name can take the following forms:

Table 26.4. VLAN device naming conventions

Naming schemeExample

VLAN_PLUS_VID

vlan0005

VLAN_PLUS_VID_NO_PAD

vlan5

DEV_PLUS_VID

em1.0005

DEV_PLUS_VID_NO_PAD

em1.5

bond=

Use the bond= option to configure a bonding device with the following syntax: bond=name[:slaves][:options]. Replace name with the bonding device name, slaves with a comma-separated list of physical (ethernet) interfaces, and options with a comma-separated list of bonding options. For example:

bond=bond0:em1,em2:mode=active-backup,tx_queues=32,downdelay=5000

For a list of available options, execute the modinfo bonding command. Using this option without any parameters assumes bond=bond0:eth0,eth1:mode=balance-rr.

team=

Use the team= option to configure a team device with the following syntax: team=master:slaves. Replace master with the name of the master team device and slaves with a comma-separated list of physical (ethernet) devices to be used as slaves in the team device. For example:

team=team0:em1,em2

Additional resources

26.5. Console boot options

This section contains information about configuring boot options for your console, monitor display, and keyboard.

console=
Use the console= option to specify a device that you want to use as the primary console. For example, to use a console on the first serial port, use console=ttyS0. Use this option in conjunction with the inst.text option. You can use the console= option multiple times. If you do, the boot message is displayed on all specified consoles, but only the last one is used by the installation program. For example, if you specify console=ttyS0 console=ttyS1, the installation program uses ttyS1.
noshell
Use the noshell option to disable access to the root shell during installation. This is useful with Kickstart installations.
inst.lang=
Use the inst.lang= option to set the language that you want to use during the installation. locale -a or localectl list-locales returns a list of locales.
inst.geoloc=

Use the inst.geoloc= option to configure geolocation usage in the installation program. Geolocation is used to preset the language and time zone, and uses the following syntax: inst.geoloc=value. The value can be any of the following parameters:

Table 26.5. Values for the inst.geoloc boot option

ValueBoot option format

Disable geolocation

inst.geoloc=0

Use the Fedora GeoIP API

inst.geoloc=provider_fedora_geoip

Use the Hostip.info GeoIP API

inst.geoloc=provider_hostip

If you do not specify the inst.geoloc= option, the installation program uses provider_fedora_geoip.

inst.keymap=
Use the inst.keymap= option to specify the keyboard layout that you want to use for the installation.
inst.text
Use the inst.text option to force the installation program to run in text mode instead of graphical mode.
inst.cmdline
Use the inst.cmdline option to force the installation program to run in command-line mode. This mode does not allow any interaction, and you must specify all options in a Kickstart file or on the command line.
inst.graphical
Use the inst.graphical option to force the installation program to run in graphical mode. This mode is the default.
inst.resolution=
Use the inst.resolution= option to specify the screen resolution in graphical mode. The format is NxM, where N is the screen width and M is the screen height (in pixels). The lowest supported resolution is 800x600.
inst.xdriver=
Use the inst.xdriver= option to specify the name of the X driver that you want to use both during installation and on the installed system.
inst.usefbx
Use the inst.usefbx option to prompt the installation program to use the frame buffer X driver instead of a hardware-specific driver. This option is equivalent to inst.xdriver=fbdev.
modprobe.blacklist=

Use the modprobe.blacklist= option to blacklist or completely disable one or more drivers. Drivers (mods) that you disable using this option cannot load when the installation starts, and after the installation finishes, the installed system retains these settings. You can find a list of the blacklisted drivers in the /etc/modprobe.d/ directory. Use a comma-separated list to disable multiple drivers. For example:

modprobe.blacklist=ahci,firewire_ohci
inst.sshd=0
By default, the sshd option is automatically started only on the IBM Z architecture. On other architectures, sshd is not started unless you use the inst.sshd option. Use the inst.sshd=0 option to prevent sshd from starting automatically on IBM Z.
inst.sshd

Use the inst.sshd option to start the sshd service during installation, so that you can connect to the system during the installation using SSH, and monitor the installation progress. For more information about SSH, see the ssh(1) man page. By default, the sshd option is automatically started only on the IBM Z architecture. On other architectures, sshd is not started unless you use the inst.sshd option.

Note

During installation, the root account has no password by default. You can set a root password during installation with the sshpw Kickstart command.

inst.kdump_addon=
Use the inst.kdump_addon= option to enable or disable the Kdump configuration screen (add-on) in the installation program. This screen is enabled by default; use inst.kdump_addon=off to disable it. Disabling the add-on disables the Kdump screens in both the graphical and text-based interface as well as the %addon com_redhat_kdump Kickstart command.

Additional resources

26.6. Debug boot options

This section contains information about the options that you can use when debugging issues.

inst.rescue=
Use the inst.rescue= option to run the rescue environment. The option is useful for trying to diagnose and fix systems.
inst.updates=

Use the inst.updates= option to specify the location of the updates.img file that you want to apply during installation. There are a number of sources for the updates.

Updates from a network

The easiest way to use inst.updates= is to specify the network location of updates.img. This does not require any modification to the installation tree. To use this method, edit the kernel command line to include inst.updates, for example:

inst.updates=http://some.website.com/path/to/updates.img
Updates from a disk image

You can also save an updates.img on a floppy drive or a USB key. This can be done only with an ext2 filesystem type of updates.img. To save the contents of the image on your floppy drive, insert the floppy disc and run the following command:

dd if=updates.img of=/dev/fd0 bs=72k count=20

To use a USB key or flash media, replace /dev/fd0 with the device name of your USB key.

Updates from an installation tree

If you are using a CD, hard drive, or HTTP install, you can save the updates.img in the installation tree so that all installations can detect the .img. Save the file in the images/ directory. The file name must be updates.img.

For NFS installs, there are two options: You can either save the image in the images/ directory, or in the RHupdates/ directory in the installation tree.

inst.loglevel=
Use the inst.loglevel= option to specify the minimum level of messages logged on a terminal. This concerns only terminal logging; log files always contain messages of all levels. Possible values for this option from the lowest to highest level are: debug, info, warning, error and critical. The default value is info, which means that by default, the logging terminal displays messages ranging from info to critical.
inst.syslog=
When installation starts, the inst.syslog= option sends log messages to the syslog process on the specified host. The remote syslog process must be configured to accept incoming connections.
inst.virtiolog=
Use the inst.virtiolog= option to specify the virtio port (a character device at /dev/virtio-ports/name) that you want to use for forwarding logs. The default value is org.fedoraproject.anaconda.log.0; if this port is present, it is used.
inst.nokill
The inst.nokill option is a debugging option that prevents the installation program from rebooting when a fatal error occurs, or at the end of the installation process. Use the inst.nokill option to capture installation logs which would be lost upon reboot.

Additional resources

26.7. Kickstart boot options

This section contains information about the Kickstart boot options.

inst.ks=

Use the inst.ks= boot option to define the location of a Kickstart file that you want to use to automate the installation. You can then specify locations using any of the inst.repo formats. You can use the option multiple times to specify multiple HTTP, HTTPS and FTP sources. If you specify multiple HTTP, HTTPS and FTP locations, the locations are run sequentially until one succeeds, for example:

inst.ks=host1/directory/ks.cfg inst.ks=host2/directory/ks.cfg inst.ks=host3/directory/ks.cfg

If you specify a device and not a path, the installation program looks for the Kickstart file in /ks.cfg on the device that you specify. If you use this option without specifying a device, the installation program uses the following option:

inst.ks=nfs:next-server:/filename

In the previous example, next-server is the DHCP next-server option or the IP address of the DHCP server itself, and filename is the DHCP filename option, or /kickstart/. If the given file name ends with the / character, ip-kickstart is appended. The following table contains an example.

Table 26.6. Default Kickstart file location

DHCP server addressClient addressKickstart file location

192.168.122.1

192.168.122.100

192.168.122.1:/kickstart/192.168.122.100-kickstart

If a volume with a label of OEMDRV is present, the installation program attempts to load a Kickstart file named ks.cfg. If your Kickstart file is in this location, you do not need to use the inst.ks= boot option.

inst.ks.all
All locations of type http, https or ftp that you specify with inst.ks are used sequentially until the Kickstart file is fetched. Other locations are ignored.
inst.ks.sendmac

Use the inst.ks.sendmac option to add headers to outgoing HTTP requests that contain the MAC addresses of all network interfaces. For example:

X-RHN-Provisioning-MAC-0: eth0 01:23:45:67:89:ab

This can be useful when using inst.ks=http to provision systems.

inst.ks.sendsn

Use the inst.ks.sendsn option to add a header to outgoing HTTP requests. This header contains the system serial number, read from /sys/class/dmi/id/product_serial. The header has the following syntax:

X-System-Serial-Number: R8VA23D

Additional resources

26.8. Advanced installation boot options

This section contains information about advanced installation boot options.

inst.kexec

The inst.kexec option allows the installation program to use the kexec system call at the end of the installation, instead of performing a reboot. The inst.kexec option loads the new system immediately, and bypasses the hardware initialization normally performed by the BIOS or firmware.

Important

This option is deprecated and available as a Technology Preview only. For information on Red Hat scope of support for Technology Preview features, see the Technology Preview Features Support Scope document.

When kexec is used, device registers which would normally be cleared during a full system reboot, might stay filled with data, which could potentially create issues for some device drivers.

inst.multilib

Use the inst.multilib boot option to configure the system for multilib packages, that is, to allow installing 32-bit packages on a 64-bit AMD64 or Intel 64 system. Normally, on an AMD64 or Intel 64 system, only packages for this architecture (marked as x86_64) and packages for all architectures (marked as noarch) are installed. When you use the inst.multilib boot option, packages for 32-bit AMD or Intel systems (marked as i686) are automatically installed.

This applies only to packages directly specified in the %packages section. If a package is installed as a dependency, only the exact specified dependency is installed. For example, if you are installing the bash package which depends on the glibc package, the former is installed in multiple variants, while the latter is installed only in variants that the bash package requires.

selinux=0

By default, the selinux=0 boot option operates in permissive mode in the installation program, and in enforcing mode in the installed system. The selinux=0 boot option disables the use of SELinux in the installation program and the installed system.

Note

The selinux=0 and inst.selinux=0 options are not the same. The selinux=0 option disables the use of SELinux in the installation program and the installed system. The inst.selinux=0 option disables SELinux only in the installation program. By default, SELinux operates in permissive mode in the installation program, so disabling SELinux has little effect.

inst.zram
The inst.zram option controls the usage of zRAM swap during installation. The option creates a compressed block device inside the system RAM and uses it for swap space instead of the hard drive. This allows the installation program to run with less available memory than is possible without compression, and it might also make the installation faster. By default, swap on zRAM is enabled on systems with 2 GiB or less RAM, and disabled on systems with more than 2 GiB of memory. You can use this option to change this behavior; on a system with more than 2 GiB RAM, use inst.zram=1 to enable the feature, and on systems with 2 GiB or less memory, use inst.zram=0 to disable the feature.

Additional resources

Chapter 27. Kickstart references

Appendix D. Kickstart script file format reference

This reference describes in detail the kickstart file format.

D.1. Kickstart file format

Kickstart scripts are plain text files that contain keywords recognized by the installation program, which serve as directions for the installation. Any text editor able to save files as ASCII text, such as Gedit or vim on Linux systems or Notepad on Windows systems, can be used to create and edit Kickstart files. The file name of your Kickstart configuration does not matter; however, it is recommended to use a simple name as you will need to specify this name later in other configuration files or dialogs.

Commands
Commands are keywords that serve as directions for installation. Each command must be on a single line. Commands can take options. Specifying commands and options is similar to using Linux commands in shell.
Sections
Certain special commands that begin with the percent % character start a section. Interpretation of commands in sections is different from commands placed outside sections. Every section must be finished with %end command.
Section types

The available sections are:

  • Add-on sections. These sections use the %addon addon_name command.
  • Package selection sections. Starts with %packages. Use it to list packages for installation, including indirect means such as package groups or modules.
  • Script sections. These start with %pre, %pre-install, %post, and %onerror. These sections are not required.
Command section
The command section is a term used for the commands in the Kickstart file that are not part of any script section or `%packages ` section.
Script section count and ordering
All sections except the command section are optional and can be present multiple times. When a particular type of script section is to be ecvaluated, all sections of that type present in the Kickstart are evaluated in order of appearance: two %post sections are evaluated one after another, in the order as they appear. However, you do not have to specify the various types of script sections in any order: it does not matter if there are %post sections before %pre sections.
Comments
Kickstart comments are lines starting with the hash # character. These lines are ignored by the installation program.

Items that are not required can be omitted. Omitting any required item results in the installation program changing to the interactive mode so that the the user can provide an answer to the related item, just as during a regular interactive installation. It is also possible to declare the kickstart script as non-interactive with the cmdline command. In non-interactive mode, any missing answer aborts the installation process.

D.2. Package selection in Kickstart

Kickstart uses sections started by the %packages command for selecting packages to install. You can install packages, groups, environments, module streams, and module profiles this way.

D.2.1. Package selection section

Use the %packages command to begin a Kickstart section which describes the software packages to be installed. The %packages section must end with the %end command.

You can specify packages by environment, group, module stream, module profile, or by their package names. Several environments and groups that contain related packages are defined. See the repository/repodata/*-comps-repository.architecture.xml file on the Red Hat Enterprise Linux 8 Installation DVD for a list of environments and groups.

The *-comps-repository.architecture.xml file contains a structure describing available environments (marked by the <environment> tag) and groups (the <group> tag). Each entry has an ID, user visibility value, name, description, and package list. If the group is selected for installation, the packages marked mandatory in the package list are always installed, the packages marked default are installed if they are not specifically excluded elsewhere, and the packages marked optional must be specifically included elsewhere even when the group is selected.

You can specify a package group or environment using either its ID (the <id> tag) or name (the <name> tag).

If you are not sure what package should be installed, Red Hat recommends you to select the Minimal Install environment. Minimal Install provides only the packages which are essential for running Red Hat Enterprise Linux 8. This will substantially reduce the chance of the system being affected by a vulnerability. If necessary, additional packages can be added later after the installation. For more details on Minimal Install, see the Installing the Minimum Amount of Packages Required section of the Security Hardening document. Note that Initial Setup can not run after a system is installed from a Kickstart file unless a desktop environment and the X Window System were included in the installation and graphical login was enabled.

Important

To install a 32-bit package on a 64-bit system:

  • specify the --multilib option for the %packages section
  • append the package name with the 32-bit architecture for which the package was built; for example, glibc.i686

D.2.2. Package selection commands

These commands can be used within the %packages section of a Kickstart file.

Specifying an environment

Specify an entire environment to be installed as a line starting with the @^ symbols:

%packages
@^Infrastructure Server
%end

This installs all packages which are part of the Infrastructure Server environment. All available environments are described in the repository/repodata/*-comps-repository.architecture.xml file on the Red Hat Enterprise Linux 8 Installation DVD.

Only a single environment should be specified in the Kickstart file. If more environments are specified, only the last specified environment is used.

Specifying groups

Specify groups, one entry to a line, starting with an @ symbol, and then the full group name or group id as given in the *-comps-repository.architecture.xml file. For example:

%packages
@X Window System
@Desktop
@Sound and Video
%end

The Core group is always selected - it is not necessary to specify it in the %packages section.

Specifying individual packages

Specify individual packages by name, one entry to a line. You can use the asterisk character (*) as a wildcard in package names. For example:

%packages
sqlite
curl
aspell
docbook*
%end

The docbook* entry includes the packages docbook-dtds and docbook-style that match the pattern represented with the wildcard.

Specifying profiles of module streams

Specify profiles for module streams, one entry to a line, using the syntax for profiles:

%packages
@module:stream/profile
%end

This installs all packages listed in the specified profile of the module stream.

  • When a module has a default stream specified, you can leave it out. When the default stream is not specified, you must specify it.
  • When a module stream has a default profile specified, you can leave it out. When the default profile is not specified, you must specify it.
  • Installing a module multiple times with different streams is not possible.
  • Installing multiple profiles of the same module and stream is possible.

Modules and groups use the same syntax starting with the @ symbol. When a module and a package group exist with the same name, the module takes precedence.

In Red Hat Enterprise Linux 8, modules are present only in the AppStream repository. To list available modules, use the yum module list command on an installed Red Hat Enterprise Linux 8 system.

It is also possible to enable module streams using the module Kickstart command and then install packages contained in the module stream by naming them directly.

Excluding environments, groups, or packages

Use a leading dash (-) to specify packages or groups to exclude from the installation. For example:

%packages
-@Graphical Administration Tools
-autofs
-ipa*compat
%end
Important

Installing all available packages using only * in a Kickstart file is not supported.

You can change the default behavior of the %packages section by using several options. Some options work for the entire package selection, others are used with only specific groups.

Additional resources

D.2.3. Common package selection options

The following options are available for the %packages sections. To use an option, append it to the start of the package selection section. For example:

%packages --multilib --ignoremissing
--default
Install the default set of packages. This corresponds to the package set which would be installed if no other selections were made in the Package Selection screen during an interactive installation.
--excludedocs
Do not install any documentation contained within packages. In most cases, this excludes any files normally installed in the /usr/share/doc directory, but the specific files to be excluded depend on individual packages.
--ignoremissing
Ignore any packages, groups, module streams, module profiles, and environments missing in the installation source, instead of halting the installation to ask if the installation should be aborted or continued.
--instLangs=
Specify a list of languages to install. Note that this is different from package group level selections. This option does not describe which package groups should be installed; instead, it sets RPM macros controlling which translation files from individual packages should be installed.
--multilib

Configure the installed system for multilib packages (that is, to allow installing 32-bit packages on a 64-bit system) and install packages specified in this section as such.

Normally, on an AMD64 and Intel 64 system, only packages for this architecture (marked as x86_64) and packages for all architectures (marked as noarch) would be installed. When you use this option, packages for 32-bit AMD and Intel systems (marked as i686) are automatically installed as well, if available.

This only applies to packages explicitly specified in the %packages section. Packages which are only being installed as dependencies without being specified in the Kickstart file are only installed in architecture versions in which they are needed, even if they are available for more architectures.

--nocore

Disables installation of the @Core package group which is otherwise always installed by default. Disabling the @Core package group should be only used for creating lightweight containers; installing a desktop or server system with --nocore will result in an unusable system.

Note

Using -@Core to exclude packages in the @Core package group does not work. The only way to exclude the @Core package group is with the --nocore option.

--excludeWeakdeps
Disables installation of packages from weak dependencies. These are packages linked to the selected package set by Recommends and Supplements flags. By default weak dependencies will be installed.
--retries=
Sets the number of times Yum will attempt to download packages (retries). The default value is 10. This option only applies during the installation, and will not affect Yum configuration on the installed system.
--timeout=
Sets the Yum timeout in seconds. The default value is 30. This option only applies during the installation, and will not affect Yum configuration on the installed system.

D.2.4. Options for specific package groups

The options in this list only apply to a single package group. Instead of using them at the %packages command in the Kickstart file, append them to the group name. For example:

%packages
@Graphical Administration Tools --optional
%end
--nodefaults
Only install the group’s mandatory packages, not the default selections.
--optional

Install packages marked as optional in the group definition in the *-comps-repository.architecture.xml file, in addition to installing the default selections.

Note that some package groups, such as Scientific Support, do not have any mandatory or default packages specified - only optional packages. In this case the --optional option must always be used, otherwise no packages from this group will be installed.

D.3. Pre-installation scripts in Kickstart

Pre-installation scripts are run immediately before installation begins.

D.3.1. Pre-installation script section

The %pre scripts are run on the system immediately after the Kickstart file has been loaded, but before it is completely parsed and installation begins. Each of these sections must start with %pre and end with %end.

The %pre script can be used for activation and configuration of networking and storage devices. It is also possible to run scripts, using interpreters available in the installation environment. Adding a %pre script can be useful if you have networking and storage that needs special configuration before proceeding with the installation, or have a script that, for example, sets up additional logging parameters or environment variables.

Debugging problems with %pre scripts can be difficult, so it is recommended only to use a %pre script when necessary.

Commands related to networking, storage, and file systems are available to use in the %pre script, in addition to most of the utilities in the installation environment /sbin and /bin directories.

You can access the network in the %pre section. However, the name service has not been configured at this point, so only IP addresses work, not URLs.

The %pre scripts ignore missing files for the %include commands. This is useful for generating the included files in the %pre section, and having them loaded later.

Note

Unlike the post-installation script, the pre-installation script is not run in the chroot environment.

D.3.2. Pre-installation Kickstart section options

The following options can be used to change the behavior of pre-installation scripts. To use an option, append it to the %pre line at the beginning of the script. For example:

%pre --interpreter=/usr/bin/python
-- Python script omitted --
%end
--interpreter=
Allows you to specify a different scripting language, such as Python. Any scripting language available on the system can be used; in most cases, these are /usr/bin/sh, /usr/bin/bash, and /usr/bin/python.
--erroronfail
Display an error and halt the installation if the script fails. The error message will direct you to where the cause of the failure is logged.
--log=

Logs the script’s output into the specified log file. For example:

%pre --log=/mnt/sysimage/root/ks-pre.log

D.4. Post-installation scripts in Kickstart

Post-installation scripts are run after the installation is complete, but before the system is rebooted for the first time. You can use this section to run tasks such as system subscription.

D.4.1. Post-installation script section

You have the option of adding commands to run on the system once the installation is complete, but before the system is rebooted for the first time. This section must start with %post and end with %end.

The %post section is useful for functions such as installing additional software or configuring an additional name server. The post-install script is run in a chroot environment, therefore, performing tasks such as copying scripts or RPM packages from the installation media do not work by default. You can change this behavior using the --nochroot option as described below. Then the %post script will run in the installation environment, not in chroot on the installed target system.

Because post-install script runs in a chroot environment, most systemctl commands will refuse to perform any action. For more information, see the Behavior of systemctl in a chroot Environment section of the Configuring and managing system administration document.

Note that during execution of the %post section, the installation media must be still inserted.

Important

If you configured the network with static IP information, including a name server, you can access the network and resolve IP addresses in the %post section. If you configured the network for DHCP, the /etc/resolv.conf file has not been completed when the installation executes the %post section. You can access the network, but you cannot resolve IP addresses. Thus, if you are using DHCP, you must specify IP addresses in the %post section.

D.4.2. Post-installation Kickstart section options

The following options can be used to change the behavior of post-installation scripts. To use an option, append it to the %post line at the beginning of the script. For example:

%post --interpreter=/usr/bin/python3
-- Python script omitted --
%end
--interpreter=

Allows you to specify a different scripting language, such as Python. For example:

%post --interpreter=/usr/bin/python3

Any scripting language available on the system can be used; in most cases, these are /usr/bin/sh, /usr/bin/bash, and /usr/bin/python3.

--nochroot

Allows you to specify commands that you would like to run outside of the chroot environment.

The following example copies the file /etc/resolv.conf to the file system that was just installed.

%post --nochroot
cp /etc/resolv.conf /mnt/sysimage/etc/resolv.conf
%end
--erroronfail
Display an error and halt the installation if the script fails. The error message will direct you to where the cause of the failure is logged.
--log=

Logs the script’s output into the specified log file. Note that the path of the log file must take into account whether or not you use the --nochroot option. For example, without --nochroot:

%post --log=/root/ks-post.log

and with --nochroot:

%post --nochroot --log=/mnt/sysimage/root/ks-post.log

D.4.3. Example: Mounting NFS in a post-install script

This example of a %post section mounts an NFS share and executes a script named runme located at /usr/new-machines/ on the share. Note that NFS file locking is not supported while in Kickstart mode, therefore the -o nolock option is required.

# Start of the %post section with logging into /root/ks-post.log
%post --log=/root/ks-post.log

# Mount an NFS share
mkdir /mnt/temp
mount -o nolock 10.10.0.2:/usr/new-machines /mnt/temp
openvt -s -w -- /mnt/temp/runme
umount /mnt/temp

# End of the %post section
%end

D.4.4. Example: Running subscription-manager as a post-install script

One of the most common uses of post-installation scripts in Kickstart installations is automatic registration of the installed system using Red Hat Subscription Manager. The following is an example of automatic subscription in a %post script:

%post --log=/root/ks-post.log
subscription-manager register --username=admin@example.com --password=secret --auto-attach
%end

The subscription-manager command-line script registers a system to a Red Hat Subscription Management server (Customer Portal Subscription Management, Satellite 6, or CloudForms System Engine). This script can also be used to assign or attach subscriptions automatically to the system that best-match that system. When registering to the Customer Portal, use the Red Hat Network login credentials. When registering to Satellite 6 or CloudForms System Engine, you may also need to specify more subscription-manager options like --serverurl, --org, --environment as well as credentials provided by your local administrator. Note that credentials in the form of an --org --activationkey combination is a good way to avoid exposing --username --password values in shared kickstart files.

Additional options can be used with the registration command to set a preferred service level for the system and to restrict updates and errata to a specific minor release version of RHEL for customers with Extended Update Support subscriptions that need to stay fixed on an older stream.

See also the How do I use subscription-manager in a kickstart file? article on the Red Hat Customer Portal for additional information about using subscription-manager in a Kickstart %post section.

D.5. Anaconda configuration section

Additional installation options can be configured in the %anaconda section of your Kickstart file. This section controls the behavior of the user interface of the installation system.

This section must be placed towards the end of the Kickstart file, after Kickstart commands, and must start with %anaconda and end with %end.

Currently, the only command that can be used in the %anaconda section is pwpolicy.

Example D.1. Sample %anaconda script

The following is an example %anaconda section:

%anaconda
pwpolicy root --minlen=10 --strict
%end

This example %anaconda section sets a password policy which requires that the root password be at least 10 characters long, and strictly forbids passwords which do not match this requirement.

D.6. Kickstart error handling section

Starting with Red Hat Enterprise Linux 7, Kickstart installations can contain custom scripts which are run when the installation program encounters a fatal error. For example, an error in a package that has been requested for installation, failure to start VNC when specified, or an error when scanning storage devices. Installation cannot continue after such an error has occured. The installation program will run all %onerror scripts in the order they are provided in the Kickstart file. In addition, %onerror scripts will be run in the event of a traceback.

Each %onerror script is required to end with %end.

Error handling sections accept the following options:

--erroronfail
Display an error and halt the installation if the script fails. The error message will direct you to where the cause of the failure is logged.
--interpreter=

Allows you to specify a different scripting language, such as Python. For example:

%onerror --interpreter=/usr/bin/python

Any scripting language available on the system can be used; in most cases, these are /usr/bin/sh, /usr/bin/bash, and /usr/bin/python.

--log=
Logs the script’s output into the specified log file.

D.7. Kickstart add-on sections

Starting with Red Hat Enterprise Linux 7, Kickstart installations support add-ons. These add-ons can expand the basic Kickstart (and Anaconda) functionality in many ways.

To use an add-on in your Kickstart file, use the %addon addon_name options command, and finish the command with an %end statement, similar to pre-installation and post-installation script sections. For example, if you want to use the Kdump add-on, which is distributed with Anaconda by default, use the following commands:

%addon com_redhat_kdump --enable --reserve-mb=auto
%end

The %addon command does not include any options of its own - all options are dependent on the actual add-on.

Appendix E. Kickstart commands and options reference

This reference is a complete list of all Kickstart commands supported by the Red Hat Enterprise Linux installation program program. The commands are sorted alphabetically in a few broad categories. If a command can fall under multiple categories, it is listed in all of them.

E.1. Kickstart changes

The folowing sections describe the changes in Kickstart commands and options in Red Hat Enterprise Linux 8.

E.1.1. auth or authconfig is deprecated in RHEL 8

The auth or authconfig Kickstart command is deprecated in Red Hat Enterprise Linux 8 because the authconfig tool and package have been removed.

Similarly to authconfig commands issued on command line, authconfig commands in Kickstart scripts now use the authselect-compat tool to run the new authselect tool. For a description of this compatibility layer and its known issues, see the manual page authselect-migration(7). The installation program will automatically detect use of the deprecated commands and install on the system the authselect-compat package to provide the compatibility layer.

E.1.2. Kickstart no longer supports Btrfs

The Btrfs file system is not supported in Red Hat Enterprise Linux 8. As a result, the Graphical User Interface (GUI) and the Kickstart commands no longer support Btrfs.

E.1.3. Using Kickstart files from previous RHEL releases

If you are using Kickstart files from previous RHEL releases, see the Repositories section of this document for more information about the Red Hat Enterprise Linux 8 BaseOS and AppStream repositories.

E.1.4. Deprecated Kickstart comands and options

The following Kickstart commands and options have been deprecated in Red Hat Enterprise Linux 8. Using them in Kickstart files will print a warning in the logs.

  • auth or authconfig - use authselect instead
  • device
  • deviceprobe
  • dmraid
  • install - use the subcommands or methods directly as commands
  • lilo
  • lilocheck
  • mouse
  • multipath
  • bootloader --upgrade
  • ignoredisk --interactive
  • partition --active
  • reboot --kexec

Where only specific options are listed, the base command and its other options are still available and not deprecated.

Note also you can turn the deprecated command warnings into errors with the inst.ksstrict boot option.

E.1.5. Removed Kickstart comands and options

The following Kickstart commands and options have been completely removed in Red Hat Enterprise Linux 8. Using them in Kickstart files will cause an error.

  • upgrade (This command had already previously been deprecated.)
  • btrfs
  • part/partition btrfs
  • part --fstype btrfs or partition --fstype btrfs
  • logvol --fstype btrfs
  • raid --fstype btrfs
  • unsupported_hardware

Where only specific options and values are listed, the base command and its other options are still available and not removed.

E.1.6. New Kickstart comands and options

The following commands and options have been added in Red Hat Enterprise Linux 8.

RHEL 8.0

  • authselect
  • module

E.2. Kickstart commands for installation program configuration and flow control

The Kickstart commands in this list control the mode and course of installation, and what happens at its end.

E.2.1. autostep

The autostep Kickstart command is optional. This option makes the installation program step through every screen, displaying each briefly. Normally, Kickstart installations skip unnecessary screens.

Options

  • --autoscreenshot - Take a screenshot at every step during installation. These screenshots are stored in /tmp/anaconda-screenshots/ during the installation, and after the installation finishes you can find them in /root/anaconda-screenshots.

    Each screen is only captured right before the installation program switches to the next one. This is important, because if you do not use all required Kickstart options and the installation therefore does not begin automatically, you can go to the screens which were not automatically configured, perform any configuration you want. Then, when you click Done to continue, the screen is captured including the configuration you just provided.

Notes

  • This option should not be used when deploying a system because it can disrupt package installation.

E.2.2. cdrom

The cdrom Kickstart command is optional. It performs the installation from the first optical drive on the system.

Syntax

cdrom

Notes

  • Previously, the cdrom command had to be used together with the install command. The install command has been deprecated and cdrom can be used on its own, because it implies install.
  • This command has no options.
  • To actually run the installation, one of cdrom, harddrive, hmc, nfs, liveimg, or url must be specified.

E.2.3. cmdline

The cmdline Kickstart command is optional. It performs the installation in a completely non-interactive command line mode. Any prompt for interaction halts the installation.

Notes

  • For a fully automatic installation, you must either specify one of the available modes (graphical, text, or cmdline) in the Kickstart file, or you must use the console= boot option. If no mode is specified, the system will use graphical mode if possible, or prompt you to choose from VNC and text mode.
  • This mode is useful on IBM Z systems with the x3270 terminal.

E.2.4. driverdisk

The driverdisk Kickstart command is optional. Use it to provide additional drivers to the installation program.

Driver disks can be used during Kickstart installations to provide additional drivers not included by default. You must copy the driver disks’s contents to the root directory of a partition on the system’s hard drive. Then, you must use the driverdisk command to specify that the installation program should look for a driver disk and its location.

Syntax

driverdisk [partition|--source=url|--biospart=biospart]

Options

You must specify the location of driver disk in one way out of these:

  • partition - Partition containing the driver disk. Note that the partition must be specified as a full path (for example, /dev/sdb1), not just the partition name (for example, sdb1).
  • --source= - URL for the driver disk. Examples include:

    driverdisk --source=ftp://path/to/dd.img
    driverdisk --source=http://path/to/dd.img
    driverdisk --source=nfs:host:/path/to/dd.img
  • --biospart= - BIOS partition containing the driver disk (for example, 82p2).

Notes

Driver disks can also be loaded from a hard disk drive or a similar device instead of being loaded over the network or from initrd. Follow this procedure:

  1. Load the driver disk on a hard disk drive, a USB or any similar device.
  2. Set the label, for example, DD, to this device.
  3. Add the following line to your Kickstart file:

    driverdisk LABEL=DD:/e1000.rpm

Replace DD with a specific label and replace dd.rpm with a specific name. Use anything supported by the inst.repo command instead of LABEL to specify your hard disk drive.

E.2.5. eula

The eula Kickstart command is optional. Use this option to accept the End User License Agreement (EULA) without user interaction. Specifying this option prevents Initial Setup from prompting you to accept the license agreement after you finish the installation and reboot the system for the first time. See the Completing initial setup section of the Performing a standard RHEL installation document for more information.

Options

  • --agreed (required) - Accept the EULA. This option must always be used, otherwise the eula command is meaningless.

E.2.6. firstboot

The firstboot Kickstart command is optional. It determines whether the Initial Setup application starts the first time the system is booted. If enabled, the initial-setup package must be installed. If not specified, this option is disabled by default.

Options

  • --enable or --enabled - Initial Setup is started the first time the system boots.
  • --disable or --disabled - Initial Setup is not started the first time the system boots.
  • --reconfig - Enable the Initial Setup to start at boot time in reconfiguration mode. This mode enables the language, mouse, keyboard, root password, security level, time zone and networking configuration options in addition to the default ones.

E.2.7. graphical

The graphical Kickstart command is optional. It performs the installation in graphical mode. This is the default.

Syntax

graphical options

Options

  • --non-interactive - Performs the installation in a completely non-interactive mode. This mode will terminate the installation when user interaction is required.

Notes

  • For a fully automatic installation, you must either specify one of the available modes (graphical, text, or cmdline) in the Kickstart file, or you must use the console= boot option. If no mode is specified, the system will use graphical mode if possible, or prompt you to choose from VNC and text mode.

E.2.8. halt

The halt Kickstart command is optional.

Halt the system after the installation has successfully completed. This is similar to a manual installation, where Anaconda displays a message and waits for the user to press a key before rebooting. During a Kickstart installation, if no completion method is specified, this option is used as the default.

Notes

  • The halt command is equivalent to the shutdown -H command. For more details, see the shutdown(8) man page.
  • For other completion methods, see the poweroff, reboot, and shutdown commands.

E.2.9. harddrive

The harddrive Kickstart command is optional. It performs the installation from a Red Hat installation tree or full installation ISO image on a local drive. The drive must contain a file system the installation program can mount: ext2, ext3, ext4, vfat, or xfs.

Syntax

harddrive

Options

  • --biospart= - BIOS partition to install from (such as 82).
  • --partition= - Partition to install from (such as sdb2).
  • --dir= - Directory containing the variant directory of the installation tree, or the ISO image of the full installation DVD.

Example

harddrive --partition=hdb2 --dir=/tmp/install-tree

Notes

  • Previously, the harddrive command had to be used together with the install command. The install command has been deprecated and harddrive can be used on its own, because it implies install.
  • To actually run the installation, one of cdrom, harddrive, hmc, nfs, liveimg, or url must be specified.

E.2.10. install (deprecated)

Important

The install Kickstart command is deprecated in Red Hat Enterprise Linux 8. Use its methods as separate commands.

The install Kickstart command is optional. It specifies the default installation mode.

Syntax

install
installation_method

Notes

  • The install command must be followed by an installation method command. The installation method command must be on a separate line.
  • The methods include:

    • cdrom
    • harddrive
    • hmc
    • nfs
    • liveimg
    • url

    For details about the methods, see their separate reference pages.

E.2.11. liveimg

The liveimg Kickstart command is optional. It performs the installation from a disk image instead of packages.

Syntax

liveimg --url=SOURCE [OPTIONS]

Mandatory options

  • --url= - The location to install from. Supported protocols are HTTP, HTTPS, FTP, and file.

Optional options

  • --url= - The location to install from. Supported protocols are HTTP, HTTPS, FTP, and file.
  • --proxy= - Specify an HTTP, HTTPS or FTP proxy to use while performing the installation.
  • --checksum= - An optional argument with the SHA256 checksum of the image file, used for verification.
  • --noverifyssl - Disable SSL verification when connecting to an HTTPS server.

Example

liveimg --url=file:///images/install/squashfs.img --checksum=03825f567f17705100de3308a20354b4d81ac9d8bed4bb4692b2381045e56197 --noverifyssl

Notes

  • The image can be the squashfs.img file from a live ISO image, a compressed tar file (.tar, .tbz, .tgz, .txz, .tar.bz2, .tar.gz, or .tar.xz.), or any file system that the installation media can mount. Supported file systems are ext2, ext3, ext4, vfat, and xfs.
  • When using the liveimg installation mode with a driver disk, drivers on the disk will not automatically be included in the installed system. If necessary, these drivers should be installed manually, or in the %post section of a kickstart script.
  • Previously, the liveimg command had to be used together with the install command. The install command has been deprecated and liveimg can be used on its own, because it implies install.
  • To actually run the installation, one of cdrom, harddrive, hmc, nfs, liveimg, or url must be specified.

E.2.12. logging

The logging Kickstart command is optional. It controls the error logging of Anaconda during installation. It has no effect on the installed system.

Syntax

logging [--host=host] [--port=port] [--level=debug|info|error|critical]

Optional options

  • --host= - Send logging information to the given remote host, which must be running a syslogd process configured to accept remote logging.
  • --port= - If the remote syslogd process uses a port other than the default, set it using this option.
  • --level= - Specify the minimum level of messages that appear on tty3. All messages are still sent to the log file regardless of this level, however. Possible values are debug, info, warning, error, or critical.

E.2.13. mediacheck

The mediacheck Kickstart command is optional. This command forces the installation program to perform a media check (rd.live.check) before starting the installation. This command requires that installations be attended, so it is disabled by default.

E.2.14. nfs

The nfs Kickstart command is optional. It performs the installation from a specified NFS server.

Syntax

nfs

Options

  • --server= - Server from which to install (host name or IP).
  • --dir= - Directory containing the variant directory of the installation tree.
  • --opts= - Mount options to use for mounting the NFS export. (optional)

Example

nfs --server=nfsserver.example.com --dir=/tmp/install-tree

Notes

  • Previously, the nfs command had to be used together with the install command. The install command has been deprecated and nfs can be used on its own, because it implies install.
  • To actually run the installation, one of cdrom, harddrive, hmc, nfs, liveimg, or url must be specified.

E.2.15. ostreesetup

The ostreesetup Kickstart command is optional. It is used to set up OStree-based installations.

Syntax

ostreesetup --osname OSNAME [--remote REMOTE] --url URL --ref REF [--nogpg]

Mandatory options:

  • --osname OSNAME - Management root for OS installation.
  • --url URL - URL of the repository to install from.
  • --ref REF - Name of the branch from the repository to be used for installation.

Optional options:

  • --remote REMOTE - Management root for OS installation.
  • --nogpg - Disable GPG key verification.

Notes

E.2.16. poweroff

The poweroff Kickstart command is optional. It shuts down and powers off the system after the installation has successfully completed. Normally during a manual installation, Anaconda displays a message and waits for the user to press a key before rebooting.

Notes

  • The poweroff option is equivalent to the shutdown -P command. For more details, see the shutdown(8) man page.
  • For other completion methods, see the halt, reboot, and shutdown Kickstart commands. The halt option is the default completion method if no other methods are explicitly specified in the Kickstart file.
  • The poweroff command is highly dependent on the system hardware in use. Specifically, certain hardware components such as the BIOS, APM (advanced power management), and ACPI (advanced configuration and power interface) must be able to interact with the system kernel. Consult your hardware documentation for more information on you system’s APM/ACPI abilities.

E.2.17. reboot

The reboot Kickstart command is optional. It instructs the installation program to reboot after the installation is successfully completed (no arguments). Normally, Kickstart displays a message and waits for the user to press a key before rebooting.

Options

  • --eject - Attempt to eject the bootable media (DVD, USB, or other media) before rebooting.
  • --kexec - Uses the kexec system call instead of performing a full reboot, which immediately loads the installed system into memory, bypassing the hardware initialization normally performed by the BIOS or firmware.

    Important

    This option is deprecated and available as a Technology Preview only. For information on Red Hat scope of support for Technology Preview features, see the Technology Preview Features Support Scope document.

    When kexec is used, device registers (which would normally be cleared during a full system reboot) might stay filled with data, which could potentially create issues for some device drivers.

Notes

  • Use of the reboot option might result in an endless installation loop, depending on the installation media and method.
  • The reboot option is equivalent to the shutdown -r command. For more details, see the shutdown(8) man page.
  • Specify reboot to automate installation fully when installing in command line mode on IBM Z.
  • For other completion methods, see the halt, poweroff, and shutdown Kickstart options. The halt option is the default completion method if no other methods are explicitly specified in the Kickstart file.

E.2.18. rescue

The rescue Kickstart command is optional. It automatically enters the installation program’s rescue mode. This gives you a chance to repair the system in case of any problems.

Syntax

rescue [--nomount|--romount]

Options

  • --nomount or --romount - Controls how the installed system is mounted in the rescue environment. By default, the installation program finds your system and mount it in read-write mode, telling you where it has performed this mount. You can optionally select to not mount anything (the --nomount option) or mount in read-only mode (the --romount option). Only one of these two options can be used.

E.2.19. shutdown

The shutdown Kickstart command is optional. It shuts down the system after the installation has successfully completed.

Notes

  • The shutdown Kickstart option is equivalent to the shutdown command. For more details, see the shutdown(8) man page.
  • For other completion methods, see the halt, poweroff, and reboot Kickstart options. The halt option is the default completion method if no other methods are explicitly specified in the Kickstart file.

E.2.20. sshpw

The sshpw Kickstart command is optional.

During the installation, you can interact with the installation program and monitor its progress over an SSH connection. Use the sshpw command to create temporary accounts through which to log on. Each instance of the command creates a separate account that exists only in the installation environment. These accounts are not transferred to the installed system.

Syntax

sshpw --username=name [options] password

Mandatory options

  • --username - Provides the name of the user. This option is required.
  • password - The password to use for the user. This option is required.

Optional options

  • --iscrypted - If this option is present, the password argument is assumed to already be encrypted. This option is mutually exclusive with --plaintext. To create an encrypted password, you can use Python:

    $ python3 -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'

    This generates a sha512 crypt-compatible hash of your password using a random salt.

  • --plaintext - If this option is present, the password argument is assumed to be in plain text. This option is mutually exclusive with --iscrypted
  • --lock - If this option is present, this account is locked by default. This means that the user will not be able to log in from the console.
  • --sshkey - If this is option is present, then the <password> string is interpreted as an ssh key value.

Notes

  • By default, the ssh server is not started during the installation. To make ssh available during the installation, boot the system with the kernel boot option inst.sshd.
  • If you want to disable root ssh access, while allowing another user ssh access, use the following:

    sshpw --username=example_username example_password --plaintext
    sshpw --username=root example_password --lock
  • To simply disable root ssh access, use the following:

    sshpw --username=root --lock

E.2.21. text

The text Kickstart command is optional. It performs the Kickstart installation in text mode. Kickstart installations are performed in graphical mode by default.

Syntax

text options

Options

  • --non-interactive - Performs the installation in a completely non-interactive mode. This mode will terminate the installation when user interaction is required.

Notes

  • Note that for a fully automatic installation, you must either specify one of the available modes (graphical, text, or cmdline) in the Kickstart file, or you must use the console= boot option. If no mode is specified, the system will use graphical mode if possible, or prompt you to choose from VNC and text mode.

E.2.22. url

The url Kickstart command is optional. It performs the installation from an installation tree image on a remote server using FTP, HTTP, or HTTPS.

Syntax

url --url=FROM [OPTIONS]

Mandatory options

  • --url= - The location to install from. Supported protocols are HTTP, HTTPS, FTP, and file.

Optional options

  • --mirrorlist= - The mirror URL to install from.
  • --proxy= - Specify an HTTP, HTTPS or FTP proxy to use while performing the installation.
  • --noverifyssl - Disable SSL verification when connecting to an HTTPS server.
  • --metalink=URL - Specify the metalink URL to install from. Variable substitution is done for $releasever and $basearch in the URL.
  • --sslcacert=path/to/SSLCACERT - Specify path to the file holding one or more SSL certificates to verify the repository host with.
  • --sslclientcert=path/to/SSLCLIENTCERT - Specify path to the SSL client certificate (PEM file) which should be used to connect to the repository.
  • --sslclientkey=path/to/SSLCLIENTKEY - Specify path to the private key file associated with the client certificate given with the --sslclientcert option.

Examples

  • To install from a HTTP server:

    url --url http://server/path
  • To install from a FTP server:

    url --url ftp://username:password@server/path
  • To install from a local file:

    liveimg --url=file:///images/install/squashfs.img --noverifyssl

Notes

  • Previously, the url command had to be used together with the install command. The install command has been deprecated and url can be used on its own, because it implies install.
  • To actually run the installation, one of cdrom, harddrive, hmc, nfs, liveimg, or url must be specified.

E.2.23. vnc

The vnc Kickstart command is optional. It allows the graphical installation to be viewed remotely through VNC.

This method is usually preferred over text mode, as there are some size and language limitations in text installations. With no additional options, this command starts a VNC server on the installation system with no password and displays the details required to connect to it.

Syntax

vnc [--host=host_name] [--port=port] [--password=password]

Options

  • --host= - Connect to the VNC viewer process listening on the given host name.
  • --port= - Provide a port that the remote VNC viewer process is listening on. If not provided, Anaconda uses the VNC default port of 5900.
  • --password= - Set a password which must be provided to connect to the VNC session. This is optional, but recommended.

E.2.24. %include

The %include Kickstart command is optional.

Use the %include /path/to/file command to include the contents of another file in the Kickstart file as though the contents were at the location of the %include command in the Kickstart file.

This inclusion is evaluated only after the %pre script sections and can thus be used for files generated by scripts in the %pre sections. To include files before evaluation of %pre sections, use the %ksappend command.

E.2.25. %ksappend

The %ksappend Kickstart command is optional.

Use the %ksappend /path/to/file command to include the contents of another file in the Kickstart file as though the contents were at the location of the %ksappend command in the Kickstart file.

This inclusion is evaluated before the %pre script sections, unlike inclusion with the %include command.

E.3. Kickstart commands for system configuration

The Kickstart commands in this list configure further details on the resulting system such as users, repositories, or services.

E.3.1. auth or authconfig (deprecated)

Important

Use the new authselect command instead of the deprecated auth or authconfig Kickstart command. auth and authconfig are available only for limited backwards compatibility.

The auth or authconfig Kickstart command is optional. It sets up the authentication options for the system using the authconfig tool, which can also be run on the command line after the installation finishes.

Syntax

authconfig [options]

Notes

  • Previously, the auth or authconfig Kickstart commands called the authconfig tool. This tool has been deprecated in Red Hat Enterprise Linux 8. These Kickstart commands now use the authselect-compat tool to call the new authselect tool. For a description of the compatibility layer and its known issues, see the manual page authselect-migration(7). The installation program will automatically detect use of the deprecated commands and install on the system the authselect-compat package to provide the compatibility layer.
  • Passwords are shadowed by default.
  • When using OpenLDAP with the SSL protocol for security, make sure that the SSLv2 and SSLv3 protocols are disabled in the server configuration. This is due to the POODLE SSL vulnerability (CVE-2014-3566). See https://access.redhat.com/solutions/1234843 for details.

E.3.2. authselect

The authselect Kickstart command is optional. It sets up the authentication options for the system using the authselect command, which can also be run on the command line after the installation finishes.

Syntax

authselect [options]

Notes

  • This command passes all options to the authselect command. Refer to the authselect(8) manual page and the authselect --help command for more details.
  • This command replaces the deprecated auth or authconfig commands deprecated in Red Hat Enterprise Linux 8 together with the authconfig tool.
  • Passwords are shadowed by default.
  • When using OpenLDAP with the SSL protocol for security, make sure that the SSLv2 and SSLv3 protocols are disabled in the server configuration. This is due to the POODLE SSL vulnerability (CVE-2014-3566). See https://access.redhat.com/solutions/1234843 for details.

E.3.3. firewall

The firewall Kickstart command is optional. It specifies the firewall configuration for the installed system.

Syntax

firewall --enabled|--disabled device [incoming] [options]

Mandatory options

  • --enabled or --enable - Reject incoming connections that are not in response to outbound requests, such as DNS replies or DHCP requests. If access to services running on this machine is needed, you can choose to allow specific services through the firewall.
  • --disabled or --disable - Do not configure any iptables rules.
  • device - the device for which to configure firewall.

Optional options

  • --trust - Listing a device here, such as em1, allows all traffic coming to and from that device to go through the firewall. To list more than one device, use the option more times, such as --trust em1 --trust em2. Do not use a comma-separated format such as --trust em1, em2.
  • incoming - Replace with one or more of the following to allow the specified services through the firewall.

    • --ssh
    • --smtp
    • --http
    • --ftp
  • --port= - You can specify that ports be allowed through the firewall using the port:protocol format. For example, to allow IMAP access through your firewall, specify imap:tcp. Numeric ports can also be specified explicitly; for example, to allow UDP packets on port 1234 through, specify 1234:udp. To specify multiple ports, separate them by commas.
  • --service= - This option provides a higher-level way to allow services through the firewall. Some services (like cups, avahi, and so on.) require multiple ports to be open or other special configuration in order for the service to work. You can specify each individual port with the --port option, or specify --service= and open them all at once.

    Valid options are anything recognized by the firewall-offline-cmd program in the firewalld package. If firewalld is running, firewall-cmd --get-services provides a list of known service names.

  • --use-system-defaults - Do nnt configure the firewall at all. This option instructs anaconda to do nothing and allows the system to rely on the defaults that were provided with the package or ostree. If this option is used with other options then all other options will be ignored.

E.3.4. group

The group Kickstart command is optional. It creates a new user group on the system.

group --name=name [--gid=gid]

Mandatory options

  • --name= - Provides the name of the group.

Optional options

  • --gid= - The group’s GID. If not provided, defaults to the next available non-system GID.

Notes

  • If a group with the given name or GID already exists, this command fails.
  • The user command can be used to create a new group for the newly created user.

E.3.5. keyboard (required)

The keyboard Kickstart command is required. It sets one or more available keyboard layouts for the system.

Options

  • --vckeymap= - Specify a VConsole keymap which should be used. Valid names correspond to the list of files in the /usr/lib/kbd/keymaps/xkb/ directory, without the .map.gz extension.
  • --xlayouts= - Specify a list of X layouts that should be used as a comma-separated list without spaces. Accepts values in the same format as setxkbmap(1), either in the layout format (such as cz), or in the layout (variant) format (such as cz (qwerty)).

    All available layouts can be viewed on the xkeyboard-config(7) man page under Layouts.

  • --switch= - Specify a list of layout-switching options (shortcuts for switching between multiple keyboard layouts). Multiple options must be separated by commas without spaces. Accepts values in the same format as setxkbmap(1).

    Available switching options can be viewed on the xkeyboard-config(7) man page under Options.

Notes

  • Either the --vckeymap= or the --xlayouts= option must be used.

Example

The following example sets up two keyboard layouts (English (US) and Czech (qwerty)) using the --xlayouts= option, and allows to switch between them using Alt+Shift:

keyboard --xlayouts=us,'cz (qwerty)' --switch=grp:alt_shift_toggle

E.3.6. lang (required)

The lang Kickstart command is required. It sets the language to use during installation and the default language to use on the installed system.

Options

  • --addsupport= - Add support for additional languages. Takes the form of comma-separated list without spaces. For example:

    lang en_US --addsupport=cs_CZ,de_DE,en_UK

Notes

+

  • Certain languages (for example, Chinese, Japanese, Korean, and Indic languages) are not supported during text-mode installation. If you specify one of these languages with the lang command, the installation process continues in English, but the installed system uses your selection as its default language.

Example

To set the language to English, the Kickstart file should contain the following line:

lang en_US

E.3.7. module

The module Kickstart command is optional. Use this command to enable a package module stream within kickstart script.

Syntax

module --name=NAME [--stream=STREAM]

Mandatory options

  • --name= - Specifies the name of the module to enable. Replace NAME with the actual name.

Optional options

  • --stream= - Specifies the name of the module stream to enable. Replace STREAM with the actual name.

    You do not need to specify this option for modules with a default stream defined. For modules without a default stream, this option is mandatory and leaving it out results in an error. Enabling a module multiple times with different streams is not possible.

Notes

  • Using a combination of this command and the %packages section allows you to install packages provided by the enabled module and stream combination, without specifying the module and stream explicitly. Modules must be enabled before package installation. After enabling a module with the module command, you can install the packages enabled by this module by listing them in the %packages section.
  • A single module command can enable only a single module and stream combination. To enable multiple modules, use multiple module commands. Enabling a module multiple times with different streams is not possible.
  • In Red Hat Enterprise Linux 8, modules are present only in the AppStream repository. To list available modules, use the yum module list command on an installed Red Hat Enterprise Linux 8 system with a valid subscription.

Additional resources

E.3.8. pwpolicy

The pwpolicy Kickstart command is optional. This command can be used to enforce a custom password policy, which specifies requirements for passwords created during installation, based on factors such as password length and strength.

Syntax

pwpolicy name [--minlen=length] [--minquality=quality] [--strict|--nostrict] [--emptyok|--noempty] [--changesok|--nochanges]

Mandatory options

  • name - Replace with either root, user or luks to enforce the policy for the root password, user passwords, or LUKS passphrase, respectively.

Optional options

  • --minlen= - Sets the minimum allowed password length, in characters. The default is 6.
  • --minquality= - Sets the minimum allowed password quality as defined by the libpwquality library. The default value is 1.
  • --strict - Enables strict password enforcement. Passwords which do not meet the requirements specified in --minquality= and --minlen= will not be accepted. This option is disabled by default.
  • --notstrict - Passwords which do not meet the minimum quality requirements specified by the --minquality= and -minlen= options will be allowed, after Done is clicked twice in the GUI. For text mode interface, a similar mechanism is used.
  • --emptyok - Allows the use of empty passwords. Enabled by default for user passwords.
  • --notempty - Disallows the use of empty passwords. Enabled by default for the root password and the LUKS passphrase.
  • --changesok - Allows changing the password in the user interface, even if the Kickstart file already specifies a password. Disabled by default.
  • --nochanges - Disallows changing passwords which are already set in the Kickstart file. Enabled by default.

Notes

  • This command can only be used inside the %anaconda section.
  • The libpwquality library is used to check minimum password requirements (length and quality). You can use the pwscore and pwmake commands provided by the libpwquality package to check the quality score of a password, or to create a random password with a given score. See the pwscore(1) and pwmake(1) man page for details about these commands.

E.3.9. repo

The repo Kickstart command is optional. It configures additional yum repositories that can be used as sources for package installation. You can add multiple repo lines.

Syntax

repo --name=repoid [--baseurl=url|--mirrorlist=url|--metalink=url] [options]

Mandatory options

  • --name= - The repository id. This option is required. If a repository has a name which conflicts with another previously added repository, it is ignored. Because the installation program uses a list of preset repositories, this means that you cannot add repositories with the same names as the preset ones.

URL options

These options are mutually exclusive and optional. The variables that can be used in yum repository configuration files are not supported here. You can use the strings $releasever and $basearch which are replaced by the respective values in the URL.

  • --baseurl= - The URL to the repository.
  • --mirrorlist= - The URL pointing at a list of mirrors for the repository.
  • --metalink= - The URL with metalink for the repository.

Optional options

  • --install - Save the provided repository configuration on the installed system in the /etc/yum.repos.d/ directory. Without using this option, a repository configured in a Kickstart file will only be available during the installation process, not on the installed system.
  • --cost= - An integer value to assign a cost to this repository. If multiple repositories provide the same packages, this number is used to prioritize which repository will be used before another. Repositories with a lower cost take priority over repositories with higher cost.
  • --excludepkgs= - A comma-separated list of package names that must not be pulled from this repository. This is useful if multiple repositories provide the same package and you want to make sure it comes from a particular repository. Both full package names (such as publican) and globs (such as gnome-*) are accepted.
  • --includepkgs= - A comma-separated list of package names and globs that are allowed to be pulled from this repository. Any other packages provided by the repository will be ignored. This is useful if you want to install just a single package or set of packages from a repository while excluding all other packages the repository provides.
  • --proxy=[protocol://][username[:password]@]host[:port] - Specify an HTTP/HTTPS/FTP proxy to use just for this repository. This setting does not affect any other repositories, nor how the install.img is fetched on HTTP installations.
  • --noverifyssl - Disable SSL verification when connecting to an HTTPS server.
  • --sslcacert=path/to/SSLCACERT - Specify path to the file holding one or more SSL certificates to verify the repository host with.
  • --sslclientcert=path/to/SSLCLIENTCERT - Specify path to the SSL client certificate (PEM file) which should be used to connect to the repository.
  • --sslclientkey=path/to/SSLCLIENTKEY - Specify path to the private key file associated with the client certificate given with the --sslclientcert option.

Notes

  • Repositories used for installation must be stable. The installation can fail if a repository is modified before the installation concludes.

E.3.10. rootpw (required)

The rootpw Kickstart command is required. It sets the system’s root password to the password argument.

Syntax

rootpw [--iscrypted|--plaintext] [--lock] password

Options

  • --iscrypted - If this option is present, the password argument is assumed to already be encrypted. This option is mutually exclusive with --plaintext. To create an encrypted password, you can use python:

    $ python -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'

    This generates a sha512 crypt-compatible hash of your password using a random salt.

  • --plaintext - If this option is present, the password argument is assumed to be in plain text. This option is mutually exclusive with --iscrypted.
  • --lock - If this option is present, the root account is locked by default. This means that the root user will not be able to log in from the console. This option will also disable the Root Password screens in both the graphical and text-based manual installation.

E.3.11. selinux

The selinux Kickstart command is optional. It sets the state of SELinux on the installed system. The default SELinux policy is enforcing.

Syntax

selinux [--disabled|--enforcing|--permissive]

Options

  • --enforcing - Enables SELinux with the default targeted policy being enforcing.
  • --permissive - Outputs warnings based on the SELinux policy, but does not actually enforce the policy.
  • --disabled - Disables SELinux completely on the system.

Additional resources

For more information regarding SELinux, see the Using SElinux document.

E.3.12. services

The services Kickstart command is optional. It modifies the default set of services that will run under the default systemd target. The list of disabled services is processed before the list of enabled services. Therefore, if a service appears on both lists, it will be enabled.

Syntax

services [--disabled=list] [--enabled=list]

Options

  • --disabled= - Disable the services given in the comma separated list.
  • --enabled= - Enable the services given in the comma separated list.

Notes

*Do not include spaces in the list of services. If you do, Kickstart will enable or disable only the services up to the first space. For example:

+

services --disabled=auditd, cups,smartd, nfslock

+ That disables only the auditd service. To disable all four services, this entry must include no spaces:

+

services --disabled=auditd,cups,smartd,nfslock

E.3.13. skipx

The skipx Kickstart command is optional. If present, X is not configured on the installed system.

If you install a display manager among your package selection options, this package creates an X configuration, and the installed system defaults to graphical.target. That overrides the effect of the skipx option.

E.3.14. sshkey

The sshkey Kickstart command is optional. It adds a SSH key to the authorized_keys file of the specified user on the installed system.

Syntax

sshkey --username=user KEY

Mandatory options

  • --username= - The user for which the key will be installed.
  • KEY - The SSH key.

E.3.15. syspurpose

The syspurpose Kickstart command is optional. Use it to set the system purpose which describes how the system will be used after installation. This information helps apply the correct subscription entitlement to the system.

Syntax

syspurpose [options]

Options

  • --role= - Set the intended system role. Available values are:

    • Red Hat Enterprise Linux Server
    • Red Hat Enterprise Linux Workstation
    • Red Hat Enterprise Linux Compute Node
  • --sla= - Set the Service Level Agreement. Available values are:

    • Premium
    • Standard
    • Self-Support
  • --usage= - The intended usage of the system. Available values are:

    • Production
    • Disaster Recovery
    • Development/Test
  • --addon= - Specifies additional layered products or features. You can use this option multiple times.

Notes

  • Enter the values with spaces and enclose them in double quotes:

    syspurpose --role="Red Hat Enterprise Linux Server"
  • While it is strongly recommended that you configure System Purpose, it is an optional feature of the Red Hat Enterprise Linux installation program. If you want to enable System Purpose after the installation completes, you can do so using the syspurpose command-line tool.

E.3.16. timezone (required)

The timezone Kickstart command is required. It sets the system time zone.

Syntax

timezone timezone [options]

Mandatory options

  • timezone - the time zone to set for the system.

Optional options

  • --utc - If present, the system assumes the hardware clock is set to UTC (Greenwich Mean) time.
  • --nontp - Disable the NTP service automatic starting.
  • --ntpservers= - Specify a list of NTP servers to be used as a comma-separated list without spaces.

Notes

In Red Hat Enterprise Linux 8, time zone names are validated using the pytz.all_timezones list, provided by the pytz package. In previous releases, the names were validated against pytz.common_timezones, which is a subset of the currently used list. Note that the graphical and text mode interfaces still use the more restricted pytz.common_timezones list; you must use a Kickstart file to use additional time zone definitions.

E.3.17. user

The user Kickstart command is optional. It creates a new user on the system.

Syntax

user --name=username [options]

Mandatory options

  • --name= - Provides the name of the user. This option is required.

Optional options

  • --gecos= - Provides the GECOS information for the user. This is a string of various system-specific fields separated by a comma. It is frequently used to specify the user’s full name, office number, and so on. See the passwd(5) man page for more details.
  • --groups= - In addition to the default group, a comma separated list of group names the user should belong to. The groups must exist before the user account is created. See the group command.
  • --homedir= - The home directory for the user. If not provided, this defaults to /home/username.
  • --lock - If this option is present, this account is locked by default. This means that the user will not be able to log in from the console. This option will also disable the Create User screens in both the graphical and text-based manual installation.
  • --password= - The new user’s password. If not provided, the account will be locked by default.
  • --iscrypted - If this option is present, the password argument is assumed to already be encrypted. This option is mutually exclusive with --plaintext. To create an encrypted password, you can use python:

    $ python -c 'import crypt,getpass;pw=getpass.getpass();print(crypt.crypt(pw) if (pw==getpass.getpass("Confirm: ")) else exit())'

    This generates a sha512 crypt-compatible hash of your password using a random salt.

  • --plaintext - If this option is present, the password argument is assumed to be in plain text. This option is mutually exclusive with --iscrypted
  • --shell= - The user’s login shell. If not provided, the system default is used.
  • --uid= - The user’s UID (User ID). If not provided, this defaults to the next available non-system UID.
  • --gid= - The GID (Group ID) to be used for the user’s group. If not provided, this defaults to the next available non-system group ID.

Notes

  • Consider using the --uid and --gid options to set IDs of regular users and their default groups at range starting at 5000 instead of 1000. That is because the range reserved for system users and groups, 0-999, might increase in the future and thus overlap with IDs of regular users.

    For changing the minimum UID and GID limits after the installation, which ensures that your chosen UID and GID ranges are applied automatically on user creation, see the Setting default permissions for new files using umask section of the Configuring basic system settings document.

  • Files and directories are created with various permissions, dictated by the application used to create the file or directory. For example, the mkdir command creates directories with all permissions enabled. However, applications are prevented from granting certain permissions to newly created files, as specified by the user file-creation mask setting.

    The user file-creation mask can be controlled with the umask command. The default setting of the user file-creation mask for new users is defined by the UMASK variable in the /etc/login.defs configuration file on the installed system. If unset, it defaults to 022. This means that by default when an application creates a file, it is prevented from granting write permission to users other than the owner of the file. However, this can be overridden by other settings or scripts. More information can be found in the Setting default permissions for new files using umask section of the Configuring basic system settings document.

E.3.18. xconfig

The xconfig Kickstart command is optional. It configures the X Window System.

Options

  • --startxonboot - Use a graphical login on the installed system.

Notes

  • Because Red Hat Enterprise Linux 8 does not include the KDE Desktop Environment, do not use the --defaultdesktop= documented in upstream.

E.4. Kickstart commands for network configuration

The Kickstart commands in this list let you configure networking on the system.

E.4.1. network

The network Kickstart command is optional. It configures network information for the target system and activates network devices in the installation environment.

The device specified in the first network command is activated automatically. Activation of the device can be also explicitly required by the --activate option.

Options

  • --activate - activate this device in the installation environment.

    If you use the --activate option on a device that has already been activated (for example, an interface you configured with boot options so that the system could retrieve the Kickstart file) the device is reactivated to use the details specified in the Kickstart file.

    Use the --nodefroute option to prevent the device from using the default route.

  • --no-activate - do not activate this device in the installation environment.

    By default, Anaconda activates the first network device in the Kickstart file regardless of the --activate option. You can disable the default setting by using the --no-activate option.

  • --bootproto= - One of dhcp, bootp, ibft, or static. The default option is dhcp; the dhcp and bootp options are treated the same. To disable ipv4 configuration of the device, use --noipv4 option.

    Note

    This option configures ipv4 configuration of the device. For ipv6 configuration use --ipv6 and --ipv6gateway options.

    The DHCP method uses a DHCP server system to obtain its networking configuration. The BOOTP method is similar, requiring a BOOTP server to supply the networking configuration. To direct a system to use DHCP:

    network --bootproto=dhcp

    To direct a machine to use BOOTP to obtain its networking configuration, use the following line in the Kickstart file:

    network --bootproto=bootp

    To direct a machine to use the configuration specified in iBFT, use:

    network --bootproto=ibft

    The static method requires that you specify at least the IP address and netmask in the Kickstart file. This information is static and is used during and after the installation.

    All static networking configuration information must be specified on one line; you cannot wrap lines using a backslash (\) as you can on a command line.

    network --bootproto=static --ip=10.0.2.15 --netmask=255.255.255.0 --gateway=10.0.2.254 --nameserver=10.0.2.1

    You can also configure multiple nameservers at the same time. To do so, use the --nameserver= option once, and specify each of their IP addresses, separated by commas:

    network --bootproto=static --ip=10.0.2.15 --netmask=255.255.255.0 --gateway=10.0.2.254 --nameserver=192.168.2.1,192.168.3.1
  • --device= - specifies the device to be configured (and eventually activated in Anaconda) with the network command.

    If the --device= option is missing on the first use of the network command, the value of the ksdevice= Anaconda boot option is used, if available. Note that this is considered deprecated behavior; in most cases, you should always specify a --device= for every network command.

    The behavior of any subsequent network command in the same Kickstart file is unspecified if its --device= option is missing. Make sure you specify this option for any network command beyond the first.

    You can specify a device to be activated in any of the following ways:

    • the device name of the interface, for example, em1
    • the MAC address of the interface, for example, 01:23:45:67:89:ab
    • the keyword link, which specifies the first interface with its link in the up state
    • the keyword bootif, which uses the MAC address that pxelinux set in the BOOTIF variable. Set IPAPPEND 2 in your pxelinux.cfg file to have pxelinux set the BOOTIF variable.

    For example:

    network --bootproto=dhcp --device=em1
  • --ip= - IP address of the device.
  • --ipv6= - IPv6 address of the device, in the form of address[/prefix length] - for example, 3ffe:ffff:0:1::1/128 `. If prefix is omitted, `64 is used. You can also use auto for automatic configuration, or dhcp for DHCPv6-only configuration (no router advertisements).
  • --gateway= - Default gateway as a single IPv4 address.
  • --ipv6gateway= - Default gateway as a single IPv6 address.
  • --nodefroute - Prevents the interface being set as the default route. Use this option when you activate additional devices with the --activate= option, for example, a NIC on a separate subnet for an iSCSI target.
  • --nameserver= - DNS name server, as an IP address. To specify more than one name server, use this option once, and separate each IP address with a comma.
  • --netmask= - Network mask for the installed system.
  • --hostname= - The host name for the installed system. The host name can either be a fully-qualified domain name (FQDN) in the format host_name.domainname, or a short host name with no domain. Many networks have a Dynamic Host Configuration Protocol (DHCP) service which automatically supplies connected systems with a domain name; to allow DHCP to assign the domain name, only specify a short host name.

    Important

    If your network does not provide a DHCP service, always use the FQDN as the system’s host name.

  • --ethtool= - Specifies additional low-level settings for the network device which will be passed to the ethtool program.
  • --onboot= - Whether or not to enable the device at boot time.
  • --dhcpclass= - The DHCP class.
  • --mtu= - The MTU of the device.
  • --noipv4 - Disable IPv4 on this device.
  • --noipv6 - Disable IPv6 on this device.
  • --bondslaves= - When this option is used, the bond device specified by the --device= option is created using slaves defined in the --bondslaves= option. For example:

    network --device=bond0 --bondslaves=em1,em2

    The above command creates a bond device named bond0 using the em1 and em2 interfaces as its slaves.

  • --bondopts= - a list of optional parameters for a bonded interface, which is specified using the --bondslaves= and --device= options. Options in this list must be separated by commas (“,”) or semicolons (“;”). If an option itself contains a comma, use a semicolon to separate the options. For example:

    network --bondopts=mode=active-backup,balance-rr;primary=eth1
    Important

    The --bondopts=mode= parameter only supports full mode names such as balance-rr or broadcast, not their numerical representations such as 0 or 3.

  • --vlanid= - Specifies virtual LAN (VLAN) ID number (802.1q tag) for the device created using the device specified in --device= as a parent. For example, network --device=em1 --vlanid=171 creates a virtual LAN device em1.171.
  • --interfacename= - Specify a custom interface name for a virtual LAN device. This option should be used when the default name generated by the --vlanid= option is not desirable. This option must be used along with --vlanid=. For example:

    network --device=em1 --vlanid=171 --interfacename=vlan171

    The above command creates a virtual LAN interface named vlan171 on the em1 device with an ID of 171.

    The interface name can be arbitrary (for example, my-vlan), but in specific cases, the following conventions must be followed:

    • If the name contains a dot (.), it must take the form of NAME.ID. The NAME is arbitrary, but the ID must be the VLAN ID. For example: em1.171 or my-vlan.171.
    • Names starting with vlan must take the form of vlanID - for example, vlan171.
  • --teamslaves= - Team device specified by the --device= option will be created using slaves specified in this option. Slaves are separated by commas. A slave can be followed by its configuration, which is a single-quoted JSON string with double quotes escaped by the \ character. For example:

    network --teamslaves="p3p1'{\"prio\": -10, \"sticky\": true}',p3p2'{\"prio\": 100}'"

    See also the --teamconfig= option.

  • --teamconfig= - Double-quoted team device configuration which is a JSON string with double quotes escaped by the \ character. The device name is specified by --device= option and its slaves and their configuration by --teamslaves= option. For example:

    network --device team0 --activate --bootproto static --ip=10.34.102.222 --netmask=255.255.255.0 --gateway=10.34.102.254 --nameserver=10.34.39.2 --teamslaves="p3p1'{\"prio\": -10, \"sticky\": true}',p3p2'{\"prio\": 100}'" --teamconfig="{\"runner\": {\"name\": \"activebackup\"}}"
  • --bridgeslaves= - When this option is used, the network bridge with device name specified using the --device= option will be created and devices defined in the --bridgeslaves= option will be added to the bridge. For example:

    network --device=bridge0 --bridgeslaves=em1
  • --bridgeopts= - An optional comma-separated list of parameters for the bridged interface. Available values are stp, priority, forward-delay, hello-time, max-age, and ageing-time. For information about these parameters, see the bridge setting table in the nm-settings(5) man page or at https://developer.gnome.org/NetworkManager/0.9/ref-settings.html.

    Also see the Configuring and managing networking document for general information about network bridging.

  • --bindto=mac - Bind the device configuration (ifcfg) file on the installed system to the device MAC address (HWADDR) instead of the default binding to the interface name (DEVICE). Note that this option is independent of the --device= option - --bindto=mac will be applied even if the same network command also specifies a device name, link, or bootif.

Notes

  • The ethN device names such as eth0 are no longer available in Red Hat Enterprise Linux 8 due to changes in the naming scheme. For more information about the device naming scheme, see the upstream document Predictable Network Interface Names.
  • If you used a Kickstart option or a boot option to specify an installation repository on a network, but no network is available at the start of the installation, the installation program displays the Network Configuration window to set up a network connection prior to displaying the Installation Summary window. For more details, see the Configuring network and host name options section of the Performing a standard RHEL installation document.

E.4.2. realm

The realm Kickstart command is optional. Use it to join an Active Directory or IPA domain. For more information about this command, see the join section of the realm(8) man page.

Syntax

realm join [options] domain

Options

  • --computer-ou=OU= - Provide the distinguished name of an organizational unit in order to create the computer account. The exact format of the distinguished name depends on the client software and membership software. The root DSE portion of the distinguished name can usually be left out.
  • --no-password - Join automatically without a password.
  • --one-time-password= - Join using a one-time password. This is not possible with all types of realm.
  • --client-software= - Only join realms which can run this client software. Valid values include sssd and winbind. Not all realms support all values. By default, the client software is chosen automatically.
  • --server-software= - Only join realms which can run this server software. Possible values include active-directory or freeipa.
  • --membership-software= - Use this software when joining the realm. Valid values include samba and adcli. Not all realms support all values. By default, the membership software is chosen automatically.

E.5. Kickstart commands for handling storage

The Kickstart commands in this section configure aspects of storage such as devices, disks, partitions, LVM, and filesystems.

E.5.1. device (deprecated)

The device Kickstart command is optional. Use it to load additional kernel modules.

On most PCI systems, the installation program automatically detects Ethernet and SCSI cards. However, on older systems and some PCI systems, Kickstart requires a hint to find the proper devices. The device command, which tells the installation program to install extra modules, uses the following format:

Syntax

device moduleName --opts=options

Options

  • moduleName - Replace with the name of the kernel module which should be installed.
  • --opts= - Options to pass to the kernel module. For example:

    device --opts="aic152x=0x340 io=11"

E.5.2. autopart

The autopart Kickstart command is optional. It automatically creates partitions.

The automatically created partitions are: a root (/) partition (1 GB or larger), a swap partition, and an appropriate /boot partition for the architecture. On large enough drives (50 GB and larger), this also creates a /home partition.

Options

  • --type= - Selects one of the predefined automatic partitioning schemes you want to use. Accepts the following values:

    • lvm: The LVM partitioning scheme.
    • plain: Regular partitions with no LVM.
    • thinp: The LVM Thin Provisioning partitioning scheme.
  • --fstype= - Selects one of the available file system types. The available values are ext2, ext3, ext4, xfs, and vfat. The default file system is xfs.
  • --nohome - Disables automatic creation of the /home partition.
  • --nolvm - Do not use LVM for automatic partitioning. This option is equal to --type=plain.
  • --noboot - Do not create a /boot partition.
  • --noswap - Do not create a swap partition.
  • --encrypted - Encrypts all partitions with Linux Unified Key Setup (LUKS). This is equivalent to checking the Encrypt partitions check box on the initial partitioning screen during a manual graphical installation.

    Note

    When encrypting one or more partitions, Anaconda attempts to gather 256 bits of entropy to ensure the partitions are encrypted securely. Gathering entropy can take some time - the process will stop after a maximum of 10 minutes, regardless of whether sufficient entropy has been gathered.

    The process can be sped up by interacting with the installation system (typing on the keyboard or moving the mouse). If you are installing in a virtual machine, you can also attach a virtio-rng device (a virtual random number generator) to the guest.

  • --luks-version=LUKS_VERSION - Specifies which version of LUKS format should be used to encrypt the filesystem. This option is only meaningful if --encrypted is specified.
  • --passphrase= - Provides a default system-wide passphrase for all encrypted devices.
  • --escrowcert=URL_of_X.509_certificate - Stores data encryption keys of all encrypted volumes as files in /root, encrypted using the X.509 certificate from the URL specified with URL_of_X.509_certificate. The keys are stored as a separate file for each encrypted volume. This option is only meaningful if --encrypted is specified.
  • --backuppassphrase - Adds a randomly-generated passphrase to each encrypted volume. Store these passphrases in separate files in /root, encrypted using the X.509 certificate specified with --escrowcert. This option is only meaningful if --escrowcert is specified.
  • --cipher= - Specifies the type of encryption to use if the Anaconda default aes-xts-plain64 is not satisfactory. You must use this option together with the --encrypted option; by itself it has no effect. Available types of encryption are listed in the Security hardening document, but Red Hat strongly recommends using either aes-xts-plain64 or aes-cbc-essiv:sha256.
  • --pbkdf=PBKDF - Sets Password-Based Key Derivation Function (PBKDF) algorithm for LUKS keyslot. See also the man page cryptsetup(8). This option is only meaningful if --encrypted is specified.
  • --pbkdf-memory=PBKDF_MEMORY - Sets the memory cost for PBKDF. See also the man page cryptsetup(8). This option is only meaningful if --encrypted is specified.
  • --pbkdf-time=PBKDF_TIME - Sets the number of milliseconds to spend with PBKDF passphrase processing. See also --iter-time in the man page cryptsetup(8). This option is only meaningful if --encrypted is specified, and is mutually exclusive with --pbkdf-iterations.
  • --pbkdf-iterations=PBKDF_ITERATIONS - Sets the number of iterations directly and avoids PBKDF benchmark. See also --pbkdf-force-iterations in the man page cryptsetup(8). This option is only meaningful if --encrypted is specified, and is mutually exclusive with --pbkdf-time.

Notes

  • The autopart option cannot be used together with the part/partition, raid, logvol, or volgroup options in the same Kickstart file.
  • The autopart command is not mandatory, but you must include it if there are no part of mount commands in your Kickstart script.
  • It is recommended to use the autopart --nohome Kickstart option when installing on a single FBA DASD of the CMS type. This ensures that the installation program does not create a separate /home partition. The installation then proceeds successfully.
  • If you lose the LUKS passphrase, any encrypted partitions and their data is completely inaccessible. There is no way to recover a lost passphrase. However, you can save encryption passphrases with the --escrowcert and create backup encryption passphrases with the --backuppassphrase options.

E.5.3. bootloader (required)

The bootloader Kickstart command is required. It specifies how the boot loader should be installed.

Syntax

bootloader [OPTIONS]

Options

  • --append= - Specifies additional kernel parameters. To specify multiple parameters, separate them with spaces. For example:

    bootloader --location=mbr --append="hdd=ide-scsi ide=nodma"

    The rhgb and quiet parameters are automatically added when the plymouth package is installed, even if you do not specify them here or do not use the --append= command at all. To disable this behavior, explicitly disallow installation of plymouth:

    %packages
    -plymouth
    %end

    This option is useful for disabling mechanisms which were implemented to mitigate the Meltdown and Spectre speculative execution vulnerabilities found in most modern processors (CVE-2017-5754, CVE-2017-5753, and CVE-2017-5715). In some cases, these mechanisms may be unnecessary, and keeping them enabled causes decreased performance with no improvement in security. To disable these mechanisms, add the options to do so into your Kickstart file - for example, bootloader --append="nopti noibrs noibpb" on AMD64/Intel 64 systems.

    Warning

    Ensure your system is not at risk of attack before disabling any of the vulnerability mitigation mechanisms. See the Red Hat vulnerability response article for information about the Meltdown and Spectre vulnerabilities.

  • --boot-drive= - Specifies which drive the boot loader should be written to, and therefore which drive the computer will boot from. If you use a multipath device as the boot drive, specify only one member of the device.

    Important

    The --boot-drive= option is currently being ignored in Red Hat Enterprise Linux installations on IBM Z systems using the zipl boot loader. When zipl is installed, it determines the boot drive on its own.

  • --leavebootorder - The installation program will add Red Hat Enterprise Linux 8 to the top of the list of installed systems in the boot loader, and preserve all existing entries as well as their order.
  • --driveorder= - Specifies which drive is first in the BIOS boot order. For example:

    bootloader --driveorder=sda,hda
  • --location= - Specifies where the boot record is written. Valid values are the following:

    • mbr - The default option. Depends on whether the drive uses the Master Boot Record (MBR) or GUID Partition Table (GPT) scheme:

      On a GPT-formatted disk, this option installs stage 1.5 of the boot loader into the BIOS boot partition.

      On an MBR-formatted disk, stage 1.5 is installed into the empty space between the MBR and the first partition.

    • partition - Install the boot loader on the first sector of the partition containing the kernel.
    • none - Do not install the boot loader.

    In most cases, this option does not need to be specified.

  • --nombr - Do not install the boot loader to the MBR.
  • --password= - If using GRUB2, sets the boot loader password to the one specified with this option. This should be used to restrict access to the GRUB2 shell, where arbitrary kernel options can be passed.

    If a password is specified, GRUB2 also asks for a user name. The user name is always root.

  • --iscrypted - Normally, when you specify a boot loader password using the --password= option, it is stored in the Kickstart file in plain text. If you want to encrypt the password, use this option and an encrypted password.

    To generate an encrypted password, use the grub2-mkpasswd-pbkdf2 command, enter the password you want to use, and copy the command’s output (the hash starting with grub.pbkdf2) into the Kickstart file. An example bootloader Kickstart entry with an encrypted password looks similar to the following:

    bootloader --iscrypted --password=grub.pbkdf2.sha512.10000.5520C6C9832F3AC3D149AC0B24BE69E2D4FB0DBEEDBD29CA1D30A044DE2645C4C7A291E585D4DC43F8A4D82479F8B95CA4BA4381F8550510B75E8E0BB2938990.C688B6F0EF935701FF9BD1A8EC7FE5BD2333799C98F28420C5CC8F1A2A233DE22C83705BB614EA17F3FDFDF4AC2161CEA3384E56EB38A2E39102F5334C47405E
  • --timeout= - Specifies the amount of time the boot loader waits before booting the default option (in seconds).
  • --default= - Sets the default boot image in the boot loader configuration.
  • --extlinux - Use the extlinux boot loader instead of GRUB2. This option only works on systems supported by extlinux.
  • --disabled — This option is a stronger version of --location=none. While --location=none simply disables boot loader installation, --disabled disables boot loader installation and also disables installation of the package containing the boot loader, thus saving space.

Notes

  • Red Hat recommends setting up a boot loader password on every system. An unprotected boot loader can allow a potential attacker to modify the system’s boot options and gain unauthorized access to the system.
  • In some cases, a special partition is required to install the boot loader on AMD64, Intel 64, and 64-bit ARM systems. The type and size of this partition depends on whether the disk you are installing the boot loader to uses the Master Boot Record (MBR) or a GUID Partition Table (GPT) schema. For more information, see the Configuring boot loader section of the Performing a standard RHEL installation document.
  • Device names in the sdX (or /dev/sdX) format are not guaranteed to be consistent across reboots, which can complicate usage of some Kickstart commands. When a command calls for a device node name, you can instead use any item from /dev/disk. For example, instead of:

    part / --fstype=xfs --onpart=sda1

    You can use an entry similar to one of the following:

    part / --fstype=xfs --onpart=/dev/disk/by-path/pci-0000:00:05.0-scsi-0:0:0:0-part1
    part / --fstype=xfs --onpart=/dev/disk/by-id/ata-ST3160815AS_6RA0C882-part1

    This way the command will always target the same storage device. This is especially useful in large storage environments. See the chapter Overview of persistent naming attributes in the Managing storage devices document for more in-depth information about different ways to consistently refer to storage devices.

  • The --upgrade option is deprecated in Red Hat Enterprise Linux 8.

E.5.4. clearpart

The clearpart Kickstart command is optional. It removes partitions from the system, prior to creation of new partitions. By default, no partitions are removed.

Options

  • --all - Erases all partitions from the system.

    This option will erase all disks which can be reached by the installation program, including any attached network storage. Use this option with caution.

    You can prevent clearpart from wiping storage you want to preserve by using the --drives= option and specifying only the drives you want to clear, by attaching network storage later (for example, in the %post section of the Kickstart file), or by blacklisting the kernel modules used to access network storage.

  • --drives= - Specifies which drives to clear partitions from. For example, the following clears all the partitions on the first two drives on the primary IDE controller:

    clearpart --drives=hda,hdb --all

    To clear a multipath device, use the format disk/by-id/scsi-WWID, where WWID is the world-wide identifier for the device. For example, to clear a disk with WWID 58095BEC5510947BE8C0360F604351918, use:

    clearpart --drives=disk/by-id/scsi-58095BEC5510947BE8C0360F604351918

    This format is preferable for all multipath devices, but if errors arise, multipath devices that do not use logical volume management (LVM) can also be cleared using the format disk/by-id/dm-uuid-mpath-WWID, where WWID is the world-wide identifier for the device. For example, to clear a disk with WWID 2416CD96995134CA5D787F00A5AA11017, use:

    clearpart --drives=disk/by-id/dm-uuid-mpath-2416CD96995134CA5D787F00A5AA11017

    Never specify multipath devices by device names like mpatha. Device names such as this are not specific to a particular disk. The disk named /dev/mpatha during installation might not be the one that you expect it to be. Therefore, the clearpart command could target the wrong disk.

  • --initlabel - Initializes a disk (or disks) by creating a default disk label for all disks in their respective architecture that have been designated for formatting (for example, msdos for x86). Because --initlabel can see all disks, it is important to ensure only those drives that are to be formatted are connected.

    clearpart --initlabel --drives=names_of_disks

    For example:

    clearpart --initlabel --drives=dasda,dasdb,dasdc
  • --list= - Specifies which partitions to clear. This option overrides the --all and --linux options if used. Can be used across different drives. For example:

    clearpart --list=sda2,sda3,sdb1
  • --disklabel=LABEL - Set the default disklabel to use. Only disklabels supported for the platform will be accepted. For example, on the 64-bit Intel and AMD architectures, the msdos and gpt disklabels are accepted, but dasd is not accepted.
  • --linux - Erases all Linux partitions.
  • --none (default) - Do not remove any partitions.
  • --cdl - Reformat any LDL DASDs to CDL format.

Notes

  • Device names in the sdX (or /dev/sdX) format are not guaranteed to be consistent across reboots, which can complicate usage of some Kickstart commands. When a command calls for a device node name, you can instead use any item from /dev/disk. For example, instead of:

    part / --fstype=xfs --onpart=sda1

    You could use an entry similar to one of the following:

    part / --fstype=xfs --onpart=/dev/disk/by-path/pci-0000:00:05.0-scsi-0:0:0:0-part1
    part / --fstype=xfs --onpart=/dev/disk/by-id/ata-ST3160815AS_6RA0C882-part1

    This way the command will always target the same storage device. This is especially useful in large storage environments. See the chapter Overview of persistent naming attributes in the Managing storage devices document for more in-depth information about different ways to consistently refer to storage devices.

  • If the clearpart command is used, then the part --onpart command cannot be used on a logical partition.

E.5.5. fcoe

The fcoe Kickstart command is optional. It specifies which FCoE devices should be activated automatically in addition to those discovered by Enhanced Disk Drive Services (EDD).

Syntax

fcoe --nic=name [options]

Options

  • --nic= (required) - The name of the device to be activated.
  • --dcb= - Establish Data Center Bridging (DCB) settings.
  • --autovlan - Discover VLANs automatically. This option is enabled by default.

E.5.6. ignoredisk

The ignoredisk Kickstart command is optional. It causes the installation program to ignore the specified disks.

This is useful if you use automatic partitioning and want to be sure that some disks are ignored. For example, without ignoredisk, attempting to deploy on a SAN-cluster the Kickstart would fail, as the installation program detects passive paths to the SAN that return no partition table.

Syntax

ignoredisk --drives=drive1,drive2,... | --only-use=drive

Options

  • --drives=driveN,…​ - Replace driveN with one of sda, sdb,…​, hda,…​ and so on.
  • --only-use - Specifies a list of disks for the installation program to use. All other disks are ignored. For example, to use disk sda during installation and ignore all othe