Performing an advanced RHEL 8 installation
Installing RHEL using Kickstart
Abstract
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Providing feedback on Red Hat documentation
We appreciate your feedback on our documentation. Let us know how we can improve it.
Submitting feedback through Jira (account required)
- Log in to the Jira website.
- Click Create in the top navigation bar.
- Enter a descriptive title in the Summary field.
- Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
- Click Create at the bottom of the dialogue.
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
- 64-bit IBM Z architectures
For installation instructions on IBM Power Servers, see IBM installation documentation. To ensure that your system is supported for installing RHEL, see https://catalog.redhat.com and https://access.redhat.com/articles/rhel-limits.
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
Depending on your requirements, you can install Red Hat Enterprise Linux using several methods. Review the following sections to determine the best installation method for your requirements.
2.1. Available installation methods
You can install Red Hat Enterprise Linux using any of the following methods:
- GUI-based installations
- System or cloud image-based installations
- Advanced installations
GUI-based installations
You can choose from the following GUI-based installation methods:
- Install RHEL using an ISO image from the Customer Portal: Install Red Hat Enterprise Linux by downloading the DVD ISO image file from the Customer Portal. Registration is performed after the installation completes. This installation method is supported by the GUI and Kickstart.
- Register and install RHEL from the Content Delivery Network: Register your system, attach subscriptions, and install Red Hat Enterprise Linux from the Content Delivery Network (CDN). This installation method supports Boot ISO and DVD ISO image files; however, the Boot ISO image file is recommended as the installation source defaults to CDN for the Boot ISO image file. After registering the system, the installer downloads and installs packages from the CDN. This installation method is also supported by Kickstart.
- Perform a remote RHEL installation using VNC: The RHEL installation program offers two Virtual Network Computing (VNC) installation modes: Direct and Connect. After a connection is established, the two modes do not differ. The mode you select depends on your environment.
- Install RHEL from the network using PXE : With a network installation using preboot execution environment (PXE), you can 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.
System or cloud image-based installations
You can use system or cloud image-based installation methods only in virtual and cloud environments. To perform a system or cloud image-based installation, use Red Hat Image Builder. Image builder creates customized system images of Red Hat Enterprise Linux, including the system images for cloud deployment.
For more information about installing RHEL using Image builder, see Composing a customized RHEL system image.
Advanced installations
You can choose from the following advanced installation methods:
- Perform an automated RHEL installation using Kickstart: Kickstart is an automated process that helps you install the operating system by specifying all your requirements and configurations in a file. The Kickstart file contains RHEL installation options, for example, the time zone, drive partitions, or packages to be installed. Providing a prepared Kickstart file completes installation without the need for any user intervention. This is useful when deploying Red Hat Enterprise Linux on a large number of systems at once.
- Register and install RHEL from the Content Delivery Network: Register and install Red Hat Enterprise Linux on all architectures from the Content Delivery Network (CDN). Registration is performed before the installation packages are downloaded and installed from CDN. This installation method is supported by the graphical user interface and Kickstart.
Part I. Performing an automated installation using Kickstart
Chapter 3. Kickstart installation basics
The following provides basic information about Kickstart and how to use it to automate installing Red Hat Enterprise Linux.
3.1. What are Kickstart installations
Kickstart provides a way to automate the RHEL installation process, either partially or fully.
Kickstart files contain some or all of the RHEL installation options. For example, the time zone, how the drives should be partitioned, or which packages should be installed. Providing a prepared Kickstart file allows an installation without the need for any user intervention. This is especially useful when deploying Red Hat Enterprise Linux on a large number of systems at once.
Kickstart files also provide more options regarding software selection. When installing Red Hat Enterprise Linux manually using the graphical installation interface, the 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 supports 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 log files of their execution are stored in the /tmp
directory of the newly installed system to assist with debugging installation issues. The kickstart used for installation as well as the Anaconda generated output kickstart are stored in /root
on the target system and that logs from kickstart scriptlet execution are stored in /var/log/anaconda
.
In previous versions of Red Hat Enterprise Linux, Kickstart could be used for upgrading systems. 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 Upgrading from RHEL 7 to RHEL 8 and Considerations in adopting RHEL.
3.2. Automated installation workflow
Kickstart installations can be performed using a local DVD, a local hard drive, or a NFS, FTP, HTTP, or HTTPS server. This section provides a high level overview of Kickstart usage.
- Create a Kickstart file. You can write it by hand, copy a Kickstart file saved after a manual installation, or use an online generator tool to create the file, and edit it afterward. See Creating Kickstart files.
- Make the Kickstart file available to the installation program on removable media, a hard drive or a network location using an HTTP(S), FTP, or NFS server. See Making Kickstart files available to the installation program.
- Create the boot medium which will be used to begin the installation.See Creating a bootable installation medium and Preparing to install from the network using PXE.
- Make the installation source available to the installation program. See Creating installation sources for Kickstart installations.
- Start the installation using the boot medium and the Kickstart file. See Starting Kickstart installations.
If the Kickstart file contains all mandatory commands and sections, the installation finishes automatically. If one or more of these mandatory parts are missing, or if an error occurs, the installation requires manual intervention to finish.
If you plan to install a Beta release of Red Hat Enterprise Linux, on systems having UEFI Secure Boot enabled, then first disable the UEFI Secure Boot option and then begin the installation.
UEFI Secure Boot requires that the operating system kernel is signed with a recognized private key, which the system’s firmware verifies using the corresponding public key. For Red Hat Enterprise Linux Beta releases, the kernel is signed with a Red Hat Beta-specific private key, which the system fails to recognize by default. As a result, the system fails to boot the installation media.
Chapter 4. Creating Kickstart files
You can create a Kickstart file using the following methods:
- Use the online Kickstart configuration tool.
- Copy the Kickstart file created as a result of a manual installation.
- Write the entire Kickstart file manually.
Convert the Red Hat Enterprise Linux 7 Kickstart file for Red Hat Enterprise Linux 8 installation.
For more information about the conversion tool, see Kickstart generator lab.
- In case of virtual and cloud environment, create a custom system image, using Image Builder.
Note that some highly specific installation options can be configured only by manual editing of the Kickstart file.
4.1. Creating a Kickstart file with the Kickstart configuration tool
Users with a Red Hat Customer Portal account can use the Kickstart Generator 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.
Prerequisites
- You have a Red Hat Customer Portal account and an active Red Hat subscription.
Procedure
- Open the Kickstart generator lab information page at https://access.redhat.com/labsinfo/kickstartconfig.
- Click the Go to Application button to the left of heading and wait for the next page to load.
- Select Red Hat Enterprise Linux 8 in the drop-down menu and wait for the page to update.
Describe the system to be installed using the fields in the form.
You can use the links on the left side of the form to quickly navigate between sections of the form.
To download the generated Kickstart file, click the red Download button at the top of the page.
Your web browser saves the file.
4.2. Creating a Kickstart file by performing a manual installation
The recommended approach to creating Kickstart files is to use the file created by a manual installation of Red Hat Enterprise Linux. After an installation completes, all choices made during the installation are saved into a Kickstart file named anaconda-ks.cfg
, located in the /root/
directory on the installed system. You can use this file to reproduce the installation in the same way as before. Alternatively, copy this file, make any changes you need, and use the resulting configuration file for further installations.
Procedure
Install RHEL. For more details, see Performing a standard RHEL 8 installation.
During the installation, create a user with administrator privileges.
- Finish the installation and reboot into the installed system.
- Log into the system with the administrator account.
Copy the file
/root/anaconda-ks.cfg
to a location of your choice.ImportantThe file contains information about users and passwords.
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.
Additional resources
4.3. Converting a Kickstart file from previous RHEL installation
You can use the Kickstart Converter tool to convert a RHEL 7 Kickstart file for use in a RHEL 8 or 9 installation or convert a RHEL 8 Kickstart file for use it in RHEL 9. For more information about the tool and how to use it to convert a RHEL Kickstart file, see https://access.redhat.com/labs/kickstartconvert/
4.4. Creating a custom image using Image Builder
You can use Red Hat Image Builder to create a customized system image for virtual and cloud deployments.
For more information about creating customized images, using Image Builder, see Composing a customized RHEL system image document.
Chapter 5. Making Kickstart files available to the installation program
The following provides information about making the Kickstart file available to the installation program on the target system.
5.1. Ports for network-based installation
The following table lists the ports that must be open on the server for providing the files for each type of network-based installation.
Table 5.1. Ports for network-based installation
Protocol used | Ports to open |
---|---|
HTTP | 80 |
HTTPS | 443 |
FTP | 21 |
NFS | 2049, 111, 20048 |
TFTP | 69 |
Additional resources
5.2. Making a Kickstart file available on an NFS server
This procedure describes how to store 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 for the Kickstart file.
Prerequisites
- You have an administrator-level access to a server with Red Hat Enterprise Linux 8 on the local network.
- The system to be installed can connect to the server.
- The firewall on the server allows connections from the system you are installing to. See Ports for Network based Installation for more information.
Procedure
Install the
nfs-utils
package by running the following command as root:# yum install nfs-utils
- Copy the Kickstart file to a directory on the NFS server.
Open the
/etc/exports
file using a text editor and add a line with the following syntax:/exported_directory/ clients
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 *
-
Save the
/etc/exports
file and exit the text editor. 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.
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.
Additional resources
5.3. Making a Kickstart file available on an HTTP or HTTPS server
This procedure describes how to store the Kickstart script file on an HTTP or HTTPS server. This method enables you to install multiple systems from a single source without having to use physical media for the Kickstart file.
Prerequisites
- You have an administrator-level access to a server with Red Hat Enterprise Linux 8 on the local network.
- The system to be installed can connect to the server.
- The firewall on the server allows connections from the system you are installing to. See Ports for Network based Installation for more information.
Procedure
To store the Kickstart file on an HTTP, install the
httpd
package:# yum install httpd
To store the Kickstart file on an HTTPS, install
httpd
andmod_ssl
packages:# yum install httpd mod_ssl
WarningIf 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.
ImportantIf you use an HTTPS server with a self-signed certificate, you must boot the installation program with the
inst.noverifyssl
option.-
Copy the Kickstart file to the HTTP(S) server into a subdirectory of the
/var/www/html/
directory. Start the httpd service:
# systemctl start httpd.service
The Kickstart file is now accessible and ready to be used for installation.
NoteWhen specifying the location of the Kickstart file, use
http://
orhttps://
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 ismyserver.example.com
, and you have copied the Kickstart file as/var/www/html/rhel8-install/my-ks.cfg
, specifyhttp://myserver.example.com/rhel8-install/my-ks.cfg
as the file location.
Additional resources
5.4. Making a Kickstart file available on an FTP server
This procedure describes how to store the Kickstart script file on an FTP server. This method enables you to install multiple systems from a single source without having to use physical media for the Kickstart file.
Prerequisites
- You have an administrator-level access to a server with Red Hat Enterprise Linux 8 on the local network.
- The system to be installed can connect to the server.
- The firewall on the server allows connections from the system you are installing to. See Ports for Network based Installation for more information.
Procedure
Install the
vsftpd
package by running the following command as root:# yum install vsftpd
Open and edit the
/etc/vsftpd/vsftpd.conf
configuration file in a text editor.-
Change the line
anonymous_enable=NO
toanonymous_enable=YES
-
Change the line
write_enable=YES
towrite_enable=NO
. Add lines
pasv_min_port=min_port
andpasv_max_port=max_port
. Replacemin_port
andmax_port
with the port number range used by FTP server in passive mode, for example,10021
and10031
.This step can be necessary in network environments featuring various firewall/NAT setups.
Optionally, add custom changes to your configuration. For available options, see the vsftpd.conf(5) man page. This procedure assumes that default options are used.
WarningIf you configured SSL/TLS security in your
vsftpd.conf
file, ensure 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/1234773 for details.
-
Change the line
Configure the server firewall.
Enable the firewall:
# systemctl enable firewalld # systemctl start firewalld
Enable in your firewall the FTP port and port range from previous step:
# firewall-cmd --add-port min_port-max_port/tcp --permanent # firewall-cmd --add-service ftp --permanent # firewall-cmd --reload
Replace min_port-max_port with the port numbers you entered into the
/etc/vsftpd/vsftpd.conf
configuration file.
-
Copy the Kickstart file to the FTP server into the
/var/ftp/
directory or its subdirectory. Make sure that the correct SELinux context and access mode is set on the file:
# restorecon -r /var/ftp/your-kickstart-file.ks # chmod 444 /var/ftp/your-kickstart-file.ks
Start the
vsftpd
service:# systemctl start vsftpd.service
If the service was running before you changed the
/etc/vsftpd/vsftpd.conf
file, restart the service to load the edited file:# systemctl restart vsftpd.service
Enable the
vsftpd
service to start during the boot process:# systemctl enable vsftpd
The Kickstart file is now accessible and ready to be used for installations by systems on the same network.
NoteWhen configuring the installation source, use
ftp://
as the protocol, the server’s host name or IP address, and the path of the Kickstart file, relative to the FTP server root. For example, if the server’s host name ismyserver.example.com
and you have copied the file to/var/ftp/my-ks.cfg
, specifyftp://myserver.example.com/my-ks.cfg
as the installation source.
5.5. Making a Kickstart file available on a local volume
This procedure describes how to store the Kickstart script file on a volume on the system to be installed. This method enables you to bypass the need for another system.
Prerequisites
- You have a drive that can be moved to the machine to be installed, such as a USB stick.
-
The drive contains a partition that can be read by the installation program. The supported types are
ext2
,ext3
,ext4
,xfs
, andfat
. - The drive is connected to the system and its volumes are mounted.
Procedure
List volume information and note the UUID of the volume to which you want to copy the Kickstart file.
# lsblk -l -p -o name,rm,ro,hotplug,size,type,mountpoint,uuid
- Navigate to the file system on the volume.
- Copy the Kickstart file to this file system.
-
Make a note of the string to use later with the
inst.ks=
option. This string is in the formhd:UUID=volume-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. Replace volume-UUID with the UUID you noted earlier. Unmount all drive volumes:
# umount /dev/xyz ...
Add all the volumes to the command, separated by spaces.
5.6. 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 have a drive that can be moved to the machine to be installed, such as a USB stick.
-
The drive contains a partition that can be read by the installation program. The supported types are
ext2
,ext3
,ext4
,xfs
, andfat
. - The drive is connected to the system and its volumes are mounted.
Procedure
List volume information to which you want to copy the Kickstart file.
# lsblk -l -p
- Navigate to the file system on the volume.
- Copy the Kickstart file into the root of this file system.
-
Rename the Kickstart file to
ks.cfg
. Rename the volume as
OEMDRV
:For
ext2
,ext3
, andext4
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.
Unmount all drive volumes:
# umount /dev/xyz ...
Add all the volumes to the command, separated by spaces.
Chapter 6. Creating installation sources for Kickstart installations
This section describes how to create an installation source for the Boot ISO image using the DVD ISO image that contains the required repositories and software packages.
6.1. Types of installation source
You can use one of the following installation sources for minimal boot images:
- DVD: Burn the DVD ISO image to a DVD. The DVD will be automatically used as the installation source (software package source).
Hard drive or USB drive: Copy the 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 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
, andvfat (FAT32)
.
WarningOn 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. Note that the FAT32 file system cannot store files larger than 4 GiB.
In Red Hat Enterprise Linux 8, you can enable installation from a directory on a local hard drive. To do so, you need to copy the contents of the DVD ISO image to a directory on a hard drive and then specify the directory as the installation source instead of the ISO image. For example:
inst.repo=hd:<device>:<path to the directory>
-
Hard drive limitation: The 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
Network location: Copy the DVD ISO image or the installation tree (extracted contents of the DVD ISO image) to a network location and perform the installation over the network using the following protocols:
- NFS: The DVD ISO image is in a Network File System (NFS) share.
- HTTPS, HTTP or FTP: The installation tree is on a network location that is accessible over HTTP, HTTPS or FTP.
6.2. Ports for network-based installation
The following table lists the ports that must be open on the server for providing the files for each type of network-based installation.
Table 6.1. Ports for network-based installation
Protocol used | Ports to open |
---|---|
HTTP | 80 |
HTTPS | 443 |
FTP | 21 |
NFS | 2049, 111, 20048 |
TFTP | 69 |
Additional resources
6.3. Creating an 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.
Prerequisites
- You have an administrator-level access to a server with Red Hat Enterprise Linux 8, and this server is on the same network as the system to be installed.
- You have downloaded a Binary DVD image. For more information, see Downloading the installation ISO image.
- You have created a bootable CD, DVD, or USB device from the image file. For more information, see Creating installation media.
- You have verified that your firewall allows the system you are installing to access the remote installation source. For more information, see Ports for network-based installation.
Procedure
Install the
nfs-utils
package:# yum install nfs-utils
- Copy the DVD ISO image to a directory on the NFS server.
Open the
/etc/exports
file using a text editor and add a line with the following syntax:/exported_directory/ clients
- Replace /exported_directory/ with the full path to the directory with the ISO image.
Replace clients with one of the following:
- The host name or IP address of the target system
- The subnetwork that all target systems can use to access the ISO image
-
To allow any system with network access to the NFS server to use the ISO image, the asterisk sign (
*
)
See the
exports(5)
man page for detailed information about the format of this field.For example, a basic configuration that makes the
/rhel8-install/
directory available as read-only to all clients is:/rhel8-install *
-
Save the
/etc/exports
file and exit the text editor. Start the nfs service:
# systemctl start nfs-server.service
If the service was running before you changed the
/etc/exports
file, reload the NFS server configuration:# systemctl reload nfs-server.service
The ISO image is now accessible over NFS and ready to be used as an installation source.
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.
6.4. Creating an installation source using HTTP or HTTPS
You can create an installation source for a network-based installation using an installation tree, which is a directory containing extracted contents of the DVD ISO image and a valid .treeinfo
file. The installation source is accessed over HTTP or HTTPS.
Prerequisites
- You have an administrator-level access to a server with Red Hat Enterprise Linux 8, and this server is on the same network as the system to be installed.
- You have downloaded a Binary DVD image. For more information, see Downloading the installation ISO image.
- You have created a bootable CD, DVD, or USB device from the image file. For more information, see Creating installation media.
- You have verified that your firewall allows the system you are installing to access the remote installation source. For more information, see Ports for network-based installation.
-
The
httpd
package is installed. -
The
mod_ssl
package is installed, if you use thehttps
installation source.
If your Apache web server configuration enables SSL security, prefer to enable the TLSv1.3 protocol. By default, TLSv1.2 is enabled and you may use the TLSv1 (LEGACY) protocol.
If you use an HTTPS server with a self-signed certificate, you must boot the installation program with the noverifyssl
option.
Procedure
- Copy the DVD ISO image to the HTTP(S) server.
Create a suitable directory for mounting the DVD ISO image, for example:
# mkdir /mnt/rhel8-install/
Mount the DVD ISO image to the directory:
# mount -o loop,ro -t iso9660 /image_directory/image.iso /mnt/rhel8-install/
Replace /image_directory/image.iso with the path to the DVD ISO image.
Copy the files from the mounted image to the HTTP(S) server root.
# cp -r /mnt/rhel8-install/ /var/www/html/
This command creates the
/var/www/html/rhel8-install/
directory with the content of the image. Note that some other copying methods might skip the.treeinfo
file which is required for a valid installation source. Entering thecp
command for entire directories as shown in this procedure copies.treeinfo
correctly.Start the
httpd
service:# systemctl start httpd.service
The installation tree is now accessible and ready to be used as the installation source.
NoteWhen configuring the installation source, use
http://
orhttps://
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 use HTTP, the server host name ismyserver.example.com
, and you have copied the files from the image to/var/www/html/rhel8-install/
, specifyhttp://myserver.example.com/rhel8-install/
as the installation source.
Additional resources
6.5. Creating an installation source using FTP
You can create an installation source for a network-based installation using an installation tree, which is a directory containing extracted contents of the DVD ISO image and a valid .treeinfo
file. The installation source is accessed over FTP.
Prerequisites
- You have an administrator-level access to a server with Red Hat Enterprise Linux 8, and this server is on the same network as the system to be installed.
- You have downloaded a Binary DVD image. For more information, see Downloading the installation ISO image.
- You have created a bootable CD, DVD, or USB device from the image file. For more information, see Creating installation media.
- You have verified that your firewall allows the system you are installing to access the remote installation source. For more information, see Ports for network-based installation.
-
The
vsftpd
package is installed.
Procedure
Open and edit the
/etc/vsftpd/vsftpd.conf
configuration file in a text editor.-
Change the line
anonymous_enable=NO
toanonymous_enable=YES
-
Change the line
write_enable=YES
towrite_enable=NO
. Add lines
pasv_min_port=<min_port>
andpasv_max_port=<max_port>
. Replace <min_port> and <max_port> with the port number range used by FTP server in passive mode, for example,10021
and10031
.This step might be necessary in network environments featuring various firewall/NAT setups.
Optional: Add custom changes to your configuration. For available options, see the vsftpd.conf(5) man page. This procedure assumes that default options are used.
WarningIf you configured SSL/TLS security in your
vsftpd.conf
file, ensure 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/1234773 for details.
-
Change the line
Configure the server firewall.
Enable the firewall:
# systemctl enable firewalld
Start the firewall:
# systemctl start firewalld
Configure the firewall to allow the FTP port and port range from the previous step:
# firewall-cmd --add-port min_port-max_port/tcp --permanent # firewall-cmd --add-service ftp --permanent
Replace <min_port> and <max_port> with the port numbers you entered into the
/etc/vsftpd/vsftpd.conf
configuration file.Reload the firewall to apply the new rules:
# firewall-cmd --reload
- Copy the DVD ISO image to the FTP server.
Create a suitable directory for mounting the DVD ISO image, for example:
# mkdir /mnt/rhel8-install
Mount the DVD ISO image to the directory:
# mount -o loop,ro -t iso9660 /image-directory/image.iso /mnt/rhel8-install
Replace
/image-directory/image.iso
with the path to the DVD ISO image.Copy the files from the mounted image to the FTP server root:
# mkdir /var/ftp/rhel8-install # cp -r /mnt/rhel8-install/ /var/ftp/
This command creates the
/var/ftp/rhel8-install/
directory with the content of the image. Note that some copying methods can skip the.treeinfo
file which is required for a valid installation source. Entering thecp
command for whole directories as shown in this procedure will copy.treeinfo
correctly.Make sure that the correct SELinux context and access mode is set on the copied content:
# restorecon -r /var/ftp/rhel8-install # find /var/ftp/rhel8-install -type f -exec chmod 444 {} \; # find /var/ftp/rhel8-install -type d -exec chmod 755 {} \;
Start the
vsftpd
service:# systemctl start vsftpd.service
If the service was running before you changed the
/etc/vsftpd/vsftpd.conf
file, restart the service to load the edited file:# systemctl restart vsftpd.service
Enable the
vsftpd
service to start during the boot process:# systemctl enable vsftpd
The installation tree is now accessible and ready to be used as the installation source.
NoteWhen configuring the installation source, use
ftp://
as the protocol, the server host name or IP address, and the directory in which you have stored the files from the ISO image, relative to the FTP server root. For example, if the server host name ismyserver.example.com
and you have copied the files from the image to/var/ftp/rhel8-install/
, specifyftp://myserver.example.com/rhel8-install/
as the installation source.
Chapter 7. 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.
7.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 and the form of boot prompt depends on your system’s architecture. For detailed information, see the Boot options for RHEL installer guide.
Prerequisites
- You have a Kickstart file ready in a location accessible from the system to be installed.
Procedure
- Boot the system using a local media (a CD, DVD, or a USB flash drive).
At the boot prompt, specify the required boot options.
-
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. -
Add the
inst.ks=
boot option and the location of the Kickstart file. -
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.
For information about editing boot options, see Editing boot options.
-
If the Kickstart file or a required repository is in a network location, you may need to configure the network using the
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.
If you have installed a Red Hat Enterprise Linux Beta release, on systems having UEFI Secure Boot enabled, then add the Beta public key to the system’s Machine Owner Key (MOK) list. For more information about UEFI Secure Boot and Red Hat Enterprise Linux Beta releases, see Booting a beta system with UEFI secure boot.
7.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 64-bit IBM Z).
Prerequisites
- You have a Kickstart file ready in a location accessible from the system to be installed.
- You have a PXE server that can be used to boot the system and begin the installation.
Procedure
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 theinst.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
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.
If you have installed a Red Hat Enterprise Linux Beta release, on systems having UEFI Secure Boot enabled, then add the Beta public key to the system’s Machine Owner Key (MOK) list. For more information about UEFI Secure Boot and Red Hat Enterprise Linux Beta releases, see Booting a beta system with UEFI secure boot.
Additional resources
- For information about setting up a PXE server, see Preparing for network install.
7.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 have a volume prepared with label
OEMDRV
and the Kickstart file present in its root asks.cfg
. - A drive containing this volume is available on the system as the installation program boots.
Procedure
- Boot the system using a local media (a CD, DVD, or a USB flash drive).
At the boot prompt, specify the required boot options.
-
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. 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.For more information about installation sources, see Kickstart commands for installation program configuration and flow control.
-
If a required repository is in a network location, you may need to configure the network using the
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.
If you have installed a Red Hat Enterprise Linux Beta release, on systems having UEFI Secure Boot enabled, then add the Beta public key to the system’s Machine Owner Key (MOK) list. For more information about UEFI Secure Boot and Red Hat Enterprise Linux Beta releases, see Booting a beta system with UEFI Secure Boot.
Chapter 8. Consoles and logging during installation
The Red Hat Enterprise Linux installer uses the tmux terminal multiplexer to display and control several windows in addition to the main interface. Each of these windows serve a different purpose; they display several different logs, which can be used to troubleshoot issues during the installation process. 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.
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.
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 five available windows; their contents are described in the following table, along with keyboard shortcuts. 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, Alt+ Tab, and Ctrl+b p to switch to the next or previous tmux window, respectively.
Table 8.1. Available tmux windows
Shortcut | Contents |
---|---|
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 |
Ctrl+b 3 |
Installation log; displays messages stored in |
Ctrl+b 4 |
Storage log; displays messages related to storage devices and configuration, stored in |
Ctrl+b 5 |
Program log; displays messages from utilities executed during the installation process, stored in |
Chapter 9. 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.
9.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
9.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. Use the -v RHEL8
option in the ksvalidator
command to acknowledge new commands of the RHEL8 class.
Procedure
Run
ksvalidator
on your Kickstart file:$ ksvalidator -v RHEL8 /path/to/kickstart.ks
Replace /path/to/kickstart.ks with the path to the Kickstart file you want to verify.
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) man page
Part II. Registering and installing RHEL from the Content Delivery Network
Chapter 10. Registering and installing RHEL from the CDN using Kickstart
This section contains information about how to register your system, attach RHEL subscriptions, and install from the Red Hat Content Delivery Network (CDN) using Kickstart.
10.1. Registering and installing RHEL from the CDN
Use this procedure to register your system, attach RHEL subscriptions, and install from the Red Hat Content Delivery Network (CDN) using the rhsm
Kickstart command, which supports the syspurpose
command as well as Red Hat Insights. The rhsm
Kickstart command removes the requirement of using custom %post
scripts when registering the system.
The CDN feature is supported by the Boot ISO and DVD ISO image files. However, it is recommended that you use the Boot ISO image file as the installation source defaults to CDN for the Boot ISO image file.
Prerequisites
- Your system is connected to a network that can access the CDN.
- You have created a Kickstart file and made it available to the installation program on removable media, a hard drive, or a network location using an HTTP(S), FTP, or NFS server.
- The Kickstart file is in a location that is accessible by the system that is to be installed.
- You have created the boot media used to begin the installation and made the installation source available to the installation program.
- The installation source repository used after system registration is dependent on how the system was booted. For more information, see the Installation source repository after system registration section in the Performing a standard RHEL 8 installation document.
- Repository configuration is not required in a Kickstart file as your subscription governs which CDN subset and repositories the system can access.
Procedure
- Open the Kickstart file.
Edit the file to add the
rhsm
Kickstart command and its options to the file:- Organization (required)
Enter the organization id. An example is:
--organization=1234567
NoteFor security reasons, Red Hat username and password account details are not supported by Kickstart when registering and installing from the CDN.
- Activation Key (required)
Enter the Activation Key. You can enter multiple keys as long as the activation keys are registered to your subscription. An example is:
--activation-key="Test_key_1" --activation-key="Test_key_2"
- Red Hat Insights (recommended)
Connect the target system to Red Hat Insights.
NoteRed Hat Insights is a Software-as-a-Service (SaaS) offering that provides continuous, in-depth analysis of registered Red Hat-based systems to proactively identify threats to security, performance and stability across physical, virtual and cloud environments, and container deployments. Unlike manual installation using the installer GUI, connecting to Red Hat Insights is not enabled by default when using Kickstart.
An example is:
--connect-to-insights
- HTTP proxy (optional)
Set the HTTP proxy. An example is:
--proxy="user:password@hostname:9000"
NoteOnly the hostname is mandatory. If the proxy is required to run on a default port with no authentication, then the option is:
--proxy="hostname"
- System Purpose (optional)
Set the System Purpose role, SLA, and usage using the command:
subscription-manager syspurpose role ₋₋set="Red Hat Enterprise Linux Server" --sla="Premium" --usage="Production"
- Example
The following example displays a minimal Kickstart file with all
rhsm
Kickstart command options.graphical lang en_US.UTF-8 keyboard us rootpw 12345 timezone America/New_York zerombr clearpart --all --initlabel autopart syspurpose --role="Red Hat Enterprise Linux Server" --sla="Premium" --usage="Production" rhsm --organization="12345" --activation-key="test_key" --connect-to-insights --proxy="user:password@hostname:9000" reboot %packages vim %end
- Save the Kickstart file and start the installation process.
Additional resources
- Configuring System Purpose
- Starting Kickstart installations
- Red Hat Insights product documentation
- Understanding Activation Keys
-
For information about setting up an HTTP proxy for Subscription Manager, see the
PROXY CONFIGURATION
section in thesubscription-manager
man page.
10.2. Verifying your system registration from the CDN
Use this procedure to verify that your system is registered to the CDN.
Prerequisites
- You have completed the registration and installation process as documented in Register and install using CDN.
- You have started the Kickstart installation as documented in Starting Kickstart installations.
- The installed system has rebooted and a terminal window is open.
Procedure
From the terminal window, log in as a
root
user and verify the registration:# subscription-manager list
The output displays the attached subscription details, for example:
Installed Product Status Product Name: Red Hat Enterprise Linux for x86_64 Product ID: 486 Version: X Arch: x86_64 Status: Subscribed Status Details Starts: 11/4/2019 Ends: 11/4/2020
To view a detailed report, run the command:
# subscription-manager list --consumed
10.3. Unregistering your system from the CDN
Use this procedure to unregister your system from the Red Hat CDN.
Prerequisites
- You have completed the registration and installation process as documented in Registering and installing RHEL from the CDN.
- You have started the Kickstart installation as documented in Starting Kickstart installations.
- The installed system has rebooted and a terminal window is open.
Procedure
From the terminal window, log in as a
root
user and unregister:# subscription-manager unregister
The attached subscription is unregistered from the system and the connection to CDN is removed.
Part III. Performing a remote RHEL installation by using VNC
Chapter 11. Performing a remote RHEL installation by using VNC
This section describes how to perform a remote RHEL installation using Virtual Network Computing (VNC).
11.1. Overview
The graphical user interface is the recommended method of installing RHEL when you boot the system from a CD, DVD, or USB flash drive, or from a network using PXE. However, many enterprise systems, for example, IBM Power Systems and 64-bit IBM Z, are located in remote data center environments that are run autonomously and are not connected to a display, keyboard, and mouse. These systems are often referred to as headless systems and they are typically controlled over a network connection. The RHEL installation program includes a Virtual Network Computing (VNC) installation that runs the graphical installation on the target machine, but control of the graphical installation is handled by another system on the network. The RHEL installation program offers two VNC installation modes: Direct and Connect. Once a connection is established, the two modes do not differ. The mode you select depends on your environment.
- Direct mode
- In Direct mode, the RHEL installation program is configured to start on the target system and wait for a VNC viewer that is installed on another system before proceeding. As part of the Direct mode installation, the IP address and port are displayed on the target system. You can use the VNC viewer to connect to the target system remotely using the IP address and port, and complete the graphical installation.
- Connect mode
- In Connect mode, the VNC viewer is started on a remote system in listening mode. The VNC viewer waits for an incoming connection from the target system on a specified port. When the RHEL installation program starts on the target system, the system host name and port number are provided by using a boot option or a Kickstart command. The installation program then establishes a connection with the listening VNC viewer using the specified system host name and port number. To use Connect mode, the system with the listening VNC viewer must be able to accept incoming network connections.
11.2. Considerations
Consider the following items when performing a remote RHEL installation using VNC:
VNC client application: A VNC client application is required to perform both a VNC Direct and Connect installation. VNC client applications are available in the repositories of most Linux distributions, and free VNC client applications are also available for other operating systems such as Windows. The following VNC client applications are available in RHEL:
-
tigervnc
is independent of your desktop environment and is installed as part of thetigervnc
package. -
vinagre
is part of the GNOME desktop environment and is installed as part of thevinagre
package.
-
A VNC server is included in the installation program and does not need to be installed.
Network and firewall:
- If the target system is not allowed inbound connections by a firewall, then you must use Connect mode or disable the firewall. Disabling a firewall can have security implications.
- If the system that is running the VNC viewer is not allowed incoming connections by a firewall, then you must use Direct mode, or disable the firewall. Disabling a firewall can have security implications. See the Security hardening document for more information about configuring the firewall.
- Custom Boot Options: You must specify custom boot options to start a VNC installation and the installation instructions might differ depending on your system architecture.
-
VNC in Kickstart installations: You can use VNC-specific commands in Kickstart installations. Using only the
vnc
command runs a RHEL installation in Direct mode. Additional options are available to set up an installation using Connect mode.
11.3. Performing a remote RHEL installation in VNC Direct mode
Use this procedure to perform a remote RHEL installation in VNC Direct mode. Direct mode expects the VNC viewer to initiate a connection to the target system that is being installed with RHEL. In this procedure, the system with the VNC viewer is called the remote system. You are prompted by the RHEL installation program to initiate the connection from the VNC viewer on the remote system to the target system.
This procedure uses TigerVNC as the VNC viewer. Specific instructions for other viewers might differ, but the general principles apply.
Prerequisites
- You have installed a VNC viewer on a remote system as a root user.
- You have set up a network boot server and booted the installation on the target system.
Procedure
-
From the RHEL boot menu on the target system, press the
Tab
key on your keyboard to edit the boot options. Append the
inst.vnc
option to the end of the command line.If you want to restrict VNC access to the system that is being installed, add the
inst.vncpassword=PASSWORD
boot option to the end of the command line. Replace PASSWORD with the password you want to use for the installation. The VNC password must be between 6 and 8 characters long.ImportantUse a temporary password for the
inst.vncpassword=
option. It should not be an existing or root password.
- Press Enter to start the installation. The target system initializes the installation program and starts the necessary services. When the system is ready, a message is displayed providing the IP address and port number of the system.
- Open the VNC viewer on the remote system.
- Enter the IP address and the port number into the VNC server field.
- Click Connect.
- Enter the VNC password and click OK. A new window opens with the VNC connection established, displaying the RHEL installation menu. From this window, you can install RHEL on the target system using the graphical user interface.
11.4. Performing a remote RHEL installation in VNC Connect mode
Use this procedure to perform a remote RHEL installation in VNC Connect mode. In Connect mode, the target system that is being installed with RHEL initiates a connect to the VNC viewer that is installed on another system. In this procedure, the system with the VNC viewer is called the remote system.
This procedure uses TigerVNC as the VNC viewer. Specific instructions for other viewers might differ, but the general principles apply.
Prerequisites
- You have installed a VNC viewer on a remote system as a root user.
- You have set up a network boot server to start the installation on the target system.
- You have configured the target system to use the boot options for a VNC Connect installation.
- You have verified that the remote system with the VNC viewer is configured to accept an incoming connection on the required port. Verification is dependent on your network and system configuration. For more information, see Security hardening and Securing networks.
Procedure
Start the VNC viewer on the remote system in listening mode by running the following command:
$ vncviewer -listen PORT
- Replace PORT with the port number used for the connection.
The terminal displays a message indicating that it is waiting for an incoming connection from the target system.
TigerVNC Viewer 64-bit v1.8.0 Built on: 2017-10-12 09:20 Copyright (C) 1999-2017 TigerVNC Team and many others (see README.txt) See http://www.tigervnc.org for information about TigerVNC. Thu Jun 27 11:30:57 2019 main: Listening on port 5500
- Boot the target system from the network.
-
From the RHEL boot menu on the target system, press the
Tab
key on your keyboard to edit the boot options. -
Append the
inst.vnc inst.vncconnect=HOST:PORT
option to the end of the command line. - Replace HOST with the IP address of the remote system that is running the listening VNC viewer, and PORT with the port number that the VNC viewer is listening on.
- Press Enter to start the installation. The system initializes the installation program and starts the necessary services. When the initialization process is finished, the installation program attempts to connect to the IP address and port provided.
- When the connection is successful, a new window opens with the VNC connection established, displaying the RHEL installation menu. From this window, you can install RHEL on the target system using the graphical user interface.
Part IV. Advanced configuration options
Chapter 12. Configuring System Purpose
You use System Purpose to record the intended use of a Red Hat Enterprise Linux 8 system. Setting System Purpose enables the entitlement server to auto-attach the most appropriate subscription. This section describes how to configure System Purpose using Kickstart.
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.
12.1. Overview
You can enter System Purpose data in one of the following ways:
- During image creation
- During a GUI installation when using the Connect to Red Hat screen to register your system and attach your Red Hat subscription
-
During a Kickstart installation when using the
syspurpose Kickstart
command -
After installation using the
syspurpose
command-line (CLI) tool
To record the intended purpose of your system, you can configure the following components of System Purpose. The selected values are used by the entitlement server upon registration to attach the most suitable subscription for your system.
- 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
- Development/Test
- Disaster Recovery
12.2. Configuring System Purpose in a Kickstart file
Follow the steps in this procedure to configure System Purpose during the installation. To do so, use the syspurpose
Kickstart command in the Kickstart configuration file.
Even though System Purpose is an optional feature of the Red Hat Enterprise Linux installation program, we strongly recommend that you configure System Purpose to auto-attach the most appropriate subscription.
You can also enable System Purpose after the installation is complete. To do so use the syspurpose
command-line tool. The syspurpose
tool commands are different from the syspurpose
Kickstart commands.
The following actions are available for the syspurpose
Kickstart command:
- role
Set the intended role of the system. This action uses the following format:
syspurpose --role=
The assigned role 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 assigned sla can be:
-
Premium
-
Standard
-
Self-Support
-
- usage
Set the intended usage of the system. This action uses the following format:
syspurpose --usage=
The assigned usage can be:
-
Production
-
Development/Test
-
Disaster Recovery
-
- addon
Any additional layered products or features. To add multiple items specify
--addon
multiple times, once per layered product/feature. This action uses the following format:syspurpose --addon=
12.3. Additional resources
Chapter 13. Updating drivers during installation
This section describes how to complete a driver update during the Red Hat Enterprise Linux installation process.
This is an optional step of the installation process. Red Hat recommends that you do not perform a driver update unless it is necessary.
Prerequisites
- 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.
13.1. 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.
Driver update disks may disable conflicting kernel drivers. In rare cases, unloading a kernel module may cause installation errors.
13.2. 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 theOEMDRV
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
. Theinst.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. Theinst.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).
-
You can use both
inst.dd=location
andinst.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.
13.3. Preparing a driver update
This procedure describes how to prepare a driver update on a CD and DVD.
Prerequisites
- You have received the driver update ISO image from Red Hat, your hardware vendor, or a trusted third-party vendor.
- You have burned the driver update ISO image to a CD or DVD.
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
- Insert the driver update CD or DVD into your system’s CD/DVD drive, and browse it using the system’s file manager tool.
-
Verify that a single file
rhdd3
is available.rhdd3
is a signature file that contains the driver description and a directory namedrpms
, which contains the RPM packages with the actual drivers for various architectures.
13.4. 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 theOEMDRV
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
- When you complete the prerequisite steps, the drivers load automatically when the installation program starts and installs during the system’s installation process.
13.5. Performing an assisted driver update
This procedure describes how to perform an assisted driver update during installation.
Prerequisites
-
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 or DVD drive before starting the installation process.
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 Performing a manual driver update.
Procedure
- From the boot menu window, press the Tab key on your keyboard to display the boot command line.
-
Append the
inst.dd
boot option to the command line and press Enter to execute the boot process. - 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.
Optional: Select the driver update ISO file.
NoteThis 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.
Select the required drivers.
- Use the number keys on your keyboard to toggle the driver selection.
- Press c to install the selected driver. The selected driver is loaded and the installation process starts.
13.6. Performing a manual driver update
This procedure describes how to perform a manual driver update during installation.
Prerequisites
- You have placed the driver update ISO image file on a USB flash drive or a web server and connected it to your computer.
Procedure
- From the boot menu window, press the Tab key on your keyboard to display the boot command line.
-
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. - Press Enter to execute the boot process. The drivers available at the specified location are automatically loaded and the installation process starts.
Additional resources
13.7. Disabling a driver
This procedure describes how to disable a malfunctioning driver.
Prerequisites
- You have booted the installation program boot menu.
Procedure
- From the boot menu, press the Tab key on your keyboard to display the boot command line.
-
Append the
modprobe.blacklist=driver_name
boot option to the command line. 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.- Press Enter to execute the boot process.
Chapter 14. Preparing to install from the network using HTTP
As an administrator of a server on a local network, you can configure an HTTP server to enable HTTP boot and network installation for other systems on your network.
14.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:
- Server
- A system running a DHCP server, an HTTP, HTTPS, FTP, or NFS server, and in the PXE boot case, a TFTP server. Although 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 HTTP or 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.
To boot a client from the network, enable network boot in the firmware or in a quick boot menu on the client. 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 HTTP or PXE are as follows:
Steps
- Export the installation ISO image or the installation tree to an NFS, HTTPS, HTTP, or FTP server.
- Configure the HTTP or TFTP server and DHCP server, and start the HTTP or TFTP service on the server.
- Boot the client and start the installation.
You can choose between the following network boot protocols:
- HTTP
- Red Hat recommends using HTTP boot if your client UEFI supports it. HTTP boot is usually more reliable.
- PXE (TFTP)
- PXE boot is more widely supported by client systems, but sending the boot files over this protocol might be slow and result in timeout failures.
14.2. Configuring the DHCPv4 server for HTTP and PXE boot
Enable the DHCP version 4 (DHCPv4) service on your server, so that it can provide network boot functionality.
Prerequisites
You are preparing network installation over the IPv4 protocol.
For IPv6, see Configuring the DHCPv6 server for HTTP and PXE boot instead.
Find the network addresses of the server.
In the following examples, the server has a network card with this configuration:
- IPv4 address
- 192.168.124.2/24
- IPv4 gateway
- 192.168.124.1
Procedure
Install the DHCP server:
yum install dhcp-server
Set up a DHCPv4 server. Enter the following configuration in the
/etc/dhcp/dhcpd.conf
file. Replace the addresses to match your network card.option architecture-type code 93 = unsigned integer 16; subnet 192.168.124.0 netmask 255.255.255.0 { option routers 192.168.124.1; option domain-name-servers 192.168.124.1; range 192.168.124.100 192.168.124.200; class "pxeclients" { match if substring (option vendor-class-identifier, 0, 9) = "PXEClient"; next-server 192.168.124.2; if option architecture-type = 00:07 { filename "redhat/EFI/BOOT/BOOTX64.EFI"; } else { filename "pxelinux/pxelinux.0"; } } class "httpclients" { match if substring (option vendor-class-identifier, 0, 10) = "HTTPClient"; option vendor-class-identifier "HTTPClient"; filename "http://192.168.124.2/redhat/EFI/BOOT/BOOTX64.EFI"; } }
Start the DHCPv4 service:
# systemctl enable --now dhcpd
14.3. Configuring the DHCPv6 server for HTTP and PXE boot
Enable the DHCP version 6 (DHCPv4) service on your server, so that it can provide network boot functionality.
Prerequisites
You are preparing network installation over the IPv6 protocol.
For IPv4, see Configuring the DHCPv4 server for HTTP and PXE boot instead.
Find the network addresses of the server.
In the following examples, the server has a network card with this configuration:
- IPv6 address
- fd33:eb1b:9b36::2/64
- IPv6 gateway
- fd33:eb1b:9b36::1
Procedure
Install the DHCP server:
yum install dhcp-server
Set up a DHCPv6 server. Enter the following configuration in the
/etc/dhcp/dhcpd6.conf
file. Replace the addresses to match your network card.option dhcp6.bootfile-url code 59 = string; option dhcp6.vendor-class code 16 = {integer 32, integer 16, string}; subnet6 fd33:eb1b:9b36::/64 { range6 fd33:eb1b:9b36::64 fd33:eb1b:9b36::c8; class "PXEClient" { match substring (option dhcp6.vendor-class, 6, 9); } subclass "PXEClient" "PXEClient" { option dhcp6.bootfile-url "tftp://[fd33:eb1b:9b36::2]/redhat/EFI/BOOT/BOOTX64.EFI"; } class "HTTPClient" { match substring (option dhcp6.vendor-class, 6, 10); } subclass "HTTPClient" "HTTPClient" { option dhcp6.bootfile-url "http://[fd33:eb1b:9b36::2]/redhat/EFI/BOOT/BOOTX64.EFI"; option dhcp6.vendor-class 0 10 "HTTPClient"; } }
Start the DHCPv6 service:
# systemctl enable --now dhcpd6
If DHCPv6 packets are dropped by the RP filter in the firewall, check its log. If the log contains the
rpfilter_DROP
entry, disable the filter using the following configuration in the/etc/firewalld/firewalld.conf
file:IPv6_rpfilter=no
14.4. Configuring the HTTP server for HTTP boot
You must install and enable the httpd
service on your server so that the server can provide HTTP boot resources on your network.
Prerequisites
Find the network addresses of the server.
In the following examples, the server has a network card with the
192.168.124.2
IPv4 address.
Procedure
Install the HTTP server:
# yum install httpd
Create the
/var/www/html/redhat/
directory:# mkdir -p /var/www/html/redhat/
- Download the RHEL DVD ISO file. See All Red Hat Enterprise Linux Downloads.
Create a mount point for the ISO file:
# mkdir -p /var/www/html/redhat/iso/
Mount the ISO file:
# mount -o loop,ro -t iso9660 path-to-RHEL-DVD.iso /var/www/html/redhat/iso
Copy the boot loader, kernel, and
initramfs
from the mounted ISO file into your HTML directory:# cp -r /var/www/html/redhat/iso/images /var/www/html/redhat/ # cp -r /var/www/html/redhat/iso/EFI /var/www/html/redhat/
Make the boot loader configuration editable:
# chmod 644 /var/www/html/redhat/EFI/BOOT/grub.cfg
Edit the
/var/www/html/redhat/EFI/BOOT/grub.cfg
file and replace its content with the following:set default="1" function load_video { insmod efi_gop insmod efi_uga insmod video_bochs insmod video_cirrus insmod all_video } load_video set gfxpayload=keep insmod gzio insmod part_gpt insmod ext2 set timeout=60 # END /etc/grub.d/00_header # search --no-floppy --set=root -l 'RHEL-9-3-0-BaseOS-x86_64' # BEGIN /etc/grub.d/10_linux # menuentry 'Install Red Hat Enterprise Linux 9.3' --class fedora --class gnu-linux --class gnu --class os { linuxefi ../../images/pxeboot/vmlinuz inst.repo=http://192.168.124.2/redhat/iso quiet initrdefi ../../images/pxeboot/initrd.img } menuentry 'Test this media & install Red Hat Enterprise Linux 9.3' --class fedora --class gnu-linux --class gnu --class os { linuxefi ../../images/pxeboot/vmlinuz inst.repo=http://192.168.124.2/redhat/iso quiet initrdefi ../../images/pxeboot/initrd.img } submenu 'Troubleshooting -->' { menuentry 'Install Red Hat Enterprise Linux 9.3 in text mode' --class fedora --class gnu-linux --class gnu --class os { linuxefi ../../images/pxeboot/vmlinuz inst.repo=http://192.168.124.2/redhat/iso inst.text quiet initrdefi ../../images/pxeboot/initrd.img } menuentry 'Rescue a Red Hat Enterprise Linux system' --class fedora --class gnu-linux --class gnu --class os { linuxefi ../../images/pxeboot/vmlinuz inst.repo=http://192.168.124.2/redhat/iso inst.rescue quiet initrdefi ../../images/pxeboot/initrd.img } }
In this file, replace the following strings:
- RHEL-9-3-0-BaseOS-x86_64 and Red Hat Enterprise Linux 9.3
- Edit the version number to match the version of RHEL that you downloaded.
- 192.168.124.2
- Replace with the IP address to your server.
Make the EFI boot file executable:
# chmod 755 /var/www/html/redhat/EFI/BOOT/BOOTX64.EFI
Open ports in the firewall to allow HTTP (80), DHCP (67, 68) and DHCPv6 (546, 547) traffic:
# firewall-cmd --zone public \ --add-port={80/tcp,67/udp,68/udp,546/udp,547/udp}
NoteThis command enables temporary access until the next server reboot. To enable permanent access, add the
--permanent
option to the command.Reload firewall rules:
# firewall-cmd --reload
Start the HTTP server:
# systemctl enable --now httpd
Make the
html
directory and its content readable and executable:# chmod -cR u=rwX,g=rX,o=rX /var/www/html
Restore the SELinux context of the
html
directory:# restorecon -FvvR /var/www/html
Chapter 15. 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.
15.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:
- Server
- A system running a DHCP server, an HTTP, HTTPS, FTP, or NFS server, and in the PXE boot case, a TFTP server. Although 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 HTTP or 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.
To boot a client from the network, enable network boot in the firmware or in a quick boot menu on the client. 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 HTTP or PXE are as follows:
Steps
- Export the installation ISO image or the installation tree to an NFS, HTTPS, HTTP, or FTP server.
- Configure the HTTP or TFTP server and DHCP server, and start the HTTP or TFTP service on the server.
- Boot the client and start the installation.
You can choose between the following network boot protocols:
- HTTP
- Red Hat recommends using HTTP boot if your client UEFI supports it. HTTP boot is usually more reliable.
- PXE (TFTP)
- PXE boot is more widely supported by client systems, but sending the boot files over this protocol might be slow and result in timeout failures.
15.2. Configuring the DHCPv4 server for HTTP and PXE boot
Enable the DHCP version 4 (DHCPv4) service on your server, so that it can provide network boot functionality.
Prerequisites
You are preparing network installation over the IPv4 protocol.
For IPv6, see Configuring the DHCPv6 server for HTTP and PXE boot instead.
Find the network addresses of the server.
In the following examples, the server has a network card with this configuration:
- IPv4 address
- 192.168.124.2/24
- IPv4 gateway
- 192.168.124.1
Procedure
Install the DHCP server:
yum install dhcp-server
Set up a DHCPv4 server. Enter the following configuration in the
/etc/dhcp/dhcpd.conf
file. Replace the addresses to match your network card.option architecture-type code 93 = unsigned integer 16; subnet 192.168.124.0 netmask 255.255.255.0 { option routers 192.168.124.1; option domain-name-servers 192.168.124.1; range 192.168.124.100 192.168.124.200; class "pxeclients" { match if substring (option vendor-class-identifier, 0, 9) = "PXEClient"; next-server 192.168.124.2; if option architecture-type = 00:07 { filename "redhat/EFI/BOOT/BOOTX64.EFI"; } else { filename "pxelinux/pxelinux.0"; } } class "httpclients" { match if substring (option vendor-class-identifier, 0, 10) = "HTTPClient"; option vendor-class-identifier "HTTPClient"; filename "http://192.168.124.2/redhat/EFI/BOOT/BOOTX64.EFI"; } }
Start the DHCPv4 service:
# systemctl enable --now dhcpd
15.3. Configuring the DHCPv6 server for HTTP and PXE boot
Enable the DHCP version 6 (DHCPv4) service on your server, so that it can provide network boot functionality.
Prerequisites
You are preparing network installation over the IPv6 protocol.
For IPv4, see Configuring the DHCPv4 server for HTTP and PXE boot instead.
Find the network addresses of the server.
In the following examples, the server has a network card with this configuration:
- IPv6 address
- fd33:eb1b:9b36::2/64
- IPv6 gateway
- fd33:eb1b:9b36::1
Procedure
Install the DHCP server:
yum install dhcp-server
Set up a DHCPv6 server. Enter the following configuration in the
/etc/dhcp/dhcpd6.conf
file. Replace the addresses to match your network card.option dhcp6.bootfile-url code 59 = string; option dhcp6.vendor-class code 16 = {integer 32, integer 16, string}; subnet6 fd33:eb1b:9b36::/64 { range6 fd33:eb1b:9b36::64 fd33:eb1b:9b36::c8; class "PXEClient" { match substring (option dhcp6.vendor-class, 6, 9); } subclass "PXEClient" "PXEClient" { option dhcp6.bootfile-url "tftp://[fd33:eb1b:9b36::2]/redhat/EFI/BOOT/BOOTX64.EFI"; } class "HTTPClient" { match substring (option dhcp6.vendor-class, 6, 10); } subclass "HTTPClient" "HTTPClient" { option dhcp6.bootfile-url "http://[fd33:eb1b:9b36::2]/redhat/EFI/BOOT/BOOTX64.EFI"; option dhcp6.vendor-class 0 10 "HTTPClient"; } }
Start the DHCPv6 service:
# systemctl enable --now dhcpd6
If DHCPv6 packets are dropped by the RP filter in the firewall, check its log. If the log contains the
rpfilter_DROP
entry, disable the filter using the following configuration in the/etc/firewalld/firewalld.conf
file:IPv6_rpfilter=no
15.4. Configuring a TFTP server for BIOS-based clients
Use this procedure 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.
All configuration files in this section are examples. Configuration details vary and are dependent on the architecture and specific requirements.
Procedure
As root, install the following package.
# yum install tftp-server
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. - Depending on the location of the installation ISO file, you might have to allow incoming connections for HTTP or other services.
-
This command enables temporary access until the next server reboot. To enable permanent access, add the
Access the
pxelinux.0
file from theSYSLINUX
package in the DVD ISO image file, where my_local_directory is the name of the directory that you create:# 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 /my_local_directory
# umount /mount_point
Extract the package:
# rpm2cpio syslinux-tftpboot-version-architecture.rpm | cpio -dimv
Create a
pxelinux/
directory intftpboot/
and copy all the files from the directory into thepxelinux/
directory:# mkdir /var/lib/tftpboot/pxelinux
# cp /my_local_directory/tftpboot/* /var/lib/tftpboot/pxelinux
Create the directory
pxelinux.cfg/
in thepxelinux/
directory:# mkdir /var/lib/tftpboot/pxelinux/pxelinux.cfg
Create a configuration file named
default
and add it to thepxelinux.cfg/
directory as shown in the following example:default vesamenu.c32 prompt 1 timeout 600 display boot.msg label linux menu label ^Install system menu default kernel images/RHEL-8/vmlinuz append initrd=images/RHEL-8/initrd.img ip=dhcp inst.repo=http://192.168.124.2/RHEL-8/x86_64/iso-contents-root/ label vesa menu label Install system with ^basic video driver kernel images/RHEL-8/vmlinuz append initrd=images/RHEL-8/initrd.img ip=dhcp inst.xdriver=vesa nomodeset inst.repo=http://192.168.124.2/RHEL-8/x86_64/iso-contents-root/ label rescue menu label ^Rescue installed system kernel images/RHEL-8/vmlinuz append initrd=images/RHEL-8/initrd.img inst.rescue inst.repo=http:///192.168.124.2/RHEL-8/x86_64/iso-contents-root/ label local menu label Boot from ^local drive localboot 0xffff
Note-
The installation program cannot boot without its runtime image. Use the
inst.stage2
boot option to specify location of the image. Alternatively, you can use theinst.repo=
option to specify the image as well as the installation source. -
The installation source location used with
inst.repo
must contain a valid.treeinfo
file. -
When you select the RHEL8 installation DVD as the installation source, the
.treeinfo
file points to the BaseOS and the AppStream repositories. You can use a singleinst.repo
option to load both repositories.
-
The installation program cannot boot without its runtime image. Use the
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, the directory is/var/lib/tftpboot/pxelinux/images/RHEL-8/
:# mkdir -p /var/lib/tftpboot/pxelinux/images/RHEL-8/ # cp /path_to_x86_64_images/pxeboot/{vmlinuz,initrd.img} /var/lib/tftpboot/pxelinux/images/RHEL-8/
Start and enable the
tftp.socket
service:# systemctl enable --now tftp.socket
The PXE boot server is now ready to serve PXE clients. You can start the client, which is 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.
15.5. Configuring a TFTP server for UEFI-based clients
Use this procedure 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.
- All configuration files in this section are examples. Configuration details vary and are dependent on the architecture and specific requirements.
-
Red Hat Enterprise Linux 8 UEFI PXE boot supports a lowercase file format for a MAC-based grub menu file. For example, the MAC address file format for grub2 is
grub.cfg-01-aa-bb-cc-dd-ee-ff
Procedure
As root, install the following package.
# yum install tftp-server
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. - Depending on the location of the installation ISO file, you might have to allow incoming connections for HTTP or other services.
-
This command enables temporary access until the next server reboot. To enable permanent access, add the
Access the EFI boot image files from the DVD ISO image:
# mount -t iso9660 /path_to_image/name_of_image.iso /mount_point -o loop,ro
Copy the EFI boot images from the DVD ISO image:
# mkdir /var/lib/tftpboot/redhat # cp -r /mount_point/EFI /var/lib/tftpboot/redhat/ # umount /mount_point
Fix the permissions of the copied files:
# chmod -R 755 /var/lib/tftpboot/redhat/
Replace the content of
/var/lib/tftpboot/redhat/EFI/BOOT/grub.cfg
with the following example:set timeout=60 menuentry 'RHEL 8' { linuxefi images/RHEL-8/vmlinuz ip=dhcp inst.repo=http://192.168.124.2/RHEL-8/x86_64/iso-contents-root/ initrdefi images/RHEL-8/initrd.img }
Note-
The installation program cannot boot without its runtime image. Use the
inst.stage2
boot option to specify location of the image. Alternatively, you can use theinst.repo=
option to specify the image as well as the installation source. -
The installation source location used with
inst.repo
must contain a valid.treeinfo
file. -
When you select the RHEL8 installation DVD as the installation source, the
.treeinfo
file points to the BaseOS and the AppStream repositories. You can use a singleinst.repo
option to load both repositories.
-
The installation program cannot boot without its runtime image. Use the
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, the directory is/var/lib/tftpboot/images/RHEL-8/
:# mkdir -p /var/lib/tftpboot/images/RHEL-8/ # cp /path_to_x86_64_images/pxeboot/{vmlinuz,initrd.img} /var/lib/tftpboot/images/RHEL-8/
Start and enable the
tftp.socket
service:# systemctl enable --now tftp.socket
The PXE boot server is now ready to serve PXE clients. You can start the client, which is 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
15.6. Configuring a network server for IBM Power systems
Use this procedure to configure a network boot server for IBM Power systems using GRUB2.
All configuration files in this section are examples. Configuration details vary and are dependent on the architecture and specific requirements.
Procedure
As root, install the following packages:
# yum install tftp-server dhcp-server
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. - Depending on the location of the installation ISO file, you might have to allow incoming connections for HTTP or other services.
-
This command enables temporary access until the next server reboot. To enable permanent access, add the
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
NoteThe command output informs you of the file name that needs to be configured in your DHCP configuration, described in this procedure.
If the PXE server runs on an x86 machine, the
grub2-ppc64-modules
must be installed before creating aGRUB2
network boot directory inside the tftp root:# yum install grub2-ppc64-modules
Create a GRUB2 configuration file:
/var/lib/tftpboot/boot/grub2/grub.cfg
as shown in the following example: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://192.168.124.2/RHEL-8/x86_64/iso-contents-root/ initrd grub2-ppc64/initrd.img }
Note-
The installation program cannot boot without its runtime image. Use the
inst.stage2
boot option to specify location of the image. Alternatively, you can use theinst.repo=
option to specify the image as well as the installation source. -
The installation source location used with
inst.repo
must contain a valid.treeinfo
file. -
When you select the RHEL8 installation DVD as the installation source, the
.treeinfo
file points to the BaseOS and the AppStream repositories. You can use a singleinst.repo
option to load both repositories.
-
The installation program cannot boot without its runtime image. Use the
Mount the DVD ISO image using the command:
# mount -t iso9660 /path_to_image/name_of_iso/ /mount_point -o loop,ro
Create a directory and copy the
initrd.img
andvmlinuz
files from DVD ISO image into it, for example:# cp /mount_point/ppc/ppc64/{initrd.img,vmlinuz} /var/lib/tftpboot/grub2-ppc64/
Configure your DHCP server to use the boot images packaged with
GRUB2
as shown in the following example. Note that if you already have a DHCP server configured, then perform this step on the DHCP server.TODO: This DHCP configuration must be different from the other, regular BIOS and UEFI entries, right?
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; } } }
-
Adjust the sample parameters
subnet
,netmask
,routers
,fixed-address
andhardware ethernet
to fit your network configuration. Note thefile name
parameter; this is the file name that was outputted by thegrub2-mknetdir
command earlier in this procedure. On the DHCP server, start and enable the
dhcpd
service. If you have configured a DHCP server on the localhost, then start and enable thedhcpd
service on the localhost.# systemctl enable --now dhcpd
Start and enable the
tftp.socket
service:# systemctl enable --now tftp.socket
The PXE boot server is now ready to serve PXE clients. You can start the client, which is 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 16. Creating a remote repository
Follow the steps in this procedure to create an installation source for a network-based installation using a remote repository containing extracted contents of the DVD ISO image. The installation source is accessed over HTTP or HTTPS.
Prerequisites
- You have a Red Hat Enterprise Linux 8 installation DVD/ISO image.
- You have several servers running Red Hat Enterprise Linux.
16.1. Installing Apache on RHEL
This procedure will help you install Apache on Red Hat Enterprise Linux 8.
Prerequisites
- You have access to a repo with Apache webserver.
Procedure
Install the httpd package
# yum install httpd
Run, then enable the Apache webserver. These commands will also start the webserver after reboot.
# systemctl enable httpd # systemctl start httpd
Insert any website files you may have.
# echo Apache on RHEL {ProductNumber} > /var/www/html/index.html
Update the firewall.
# firewall-cmd --add-service=http --permanent # firewall-cmd --add-service=http
Access the website.
http://<the-apache-ip-address> http://<the-apache-hostname>
16.2. Creating a remote repository
Multiple Red Hat Enterprise Linux servers may access a single Red Hat Enterprise Linux repository on the network. This requires a running web server, most likely this will be Apache.
Prerequisites
- You have a Red Hat Enterprise Linux 8 installation DVD/ISO image.
- You have several servers running Red Hat Enterprise Linux.
Procedure
Mount and copy the content of downloaded DVD.
mkdir /mnt/rhel{ProductNumber} mount -o loop,ro rhel-{ProductNumber}-x86_64-dvd.iso /mnt/rhel{ProductNumber}/ cp -r /mnt/rhel{ProductNumber}/ /var/www/html/ umount /mnt/rhel{ProductNumber}
The next step is performed on the client side, not on the server where Apache is installed.
Create a repo file for both BaseOS and AppStream repositories.
vi /etc/yum.repos.d/rhel_http_repo.repo [BaseOS_repo_http] name=RHEL_8_x86_64_HTTP BaseOS baseurl="http://myhost/rhel8/BaseOS" gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release [AppStream_repo_http] name=RHEL_8_x86_64_HTTP AppStream baseurl="http://myhost/rhel8/AppStream" gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release [root@localhost ~]# yum repolist Updating Subscription Management repositories. Unable to read consumer identity This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Last metadata expiration check: 0:08:33 ago on Út 23. července 2019, 16:48:09 CEST. repo id repo name status AppStream_repo_http RHEL_8_x86_64_HTTP AppStream 4,672 BaseOS_repo_http RHEL_8_x86_64_HTTP BaseOS 1,658 [root@localhost ~]#
Chapter 17. Boot options
This section describes contains 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.
17.1. Types of boot options
The two types of boot options are those with an equals "=" sign, and those without an equals "=" sign. Boot options are appended to the boot command line and you can append multiple options separated by 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, theinst.vncpassword=
option must contain a value, in this example, a password. The correct syntax for this example isinst.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 installation program performs the verification and if the boot option is not present, the verification is skipped.
17.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.
17.2.1. Editing the boot: prompt in BIOS
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
- With the boot menu open, press the Esc key on your keyboard.
-
The
boot:
prompt is now accessible. - Press the Tab key on your keyboard to display the help commands.
-
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.
The boot:
prompt also accepts dracut
kernel options. A list of options is available in the dracut.cmdline(7)
man page.
17.2.2. Editing predefined boot options using the > prompt
In BIOS-based AMD64 and Intel 64 systems, you can use the >
prompt to edit predefined boot options. To display a full set of options, select Test this media and install RHEL 8
from the boot menu.
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
-
From the boot menu, select an option and press the Tab key on your keyboard. The
>
prompt is accessible and displays the available options. -
Append the options that you require to the
>
prompt. - Press Enter to start the installation.
- Press Esc to cancel editing and return to the boot menu.
17.2.3. Editing the GRUB2 menu for the UEFI-based systems
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
- From the boot menu window, select the required option and press e.
-
On UEFI systems, the kernel command line starts with
linuxefi
. Move the cursor to the end of thelinuxefi
kernel command line. -
Edit the parameters as required. For example, to configure one or more network interfaces, add the
ip=
parameter at the end of thelinuxefi
kernel command line, followed by the required value. - When you finish editing, press Ctrl+X to start the installation using the specified options.
17.3. Installation source boot options
This section describes various installation source boot options.
- inst.repo=
The
inst.repo=
boot option specifies the installation source, that is, the location providing the package repositories and a valid.treeinfo
file that describes them. For example:inst.repo=cdrom
. The target of theinst.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.
Use the
inst.repo=
boot option to configure different installation methods using different formats. The following table contains details of theinst.repo=
boot option syntax:Table 17.1. Types and format for the inst.repo= boot option and installation source
Source type Boot option format Source format CD/DVD drive
inst.repo=cdrom:<device>
Installation DVD as a physical disk. [a]
Mountable device (HDD and USB stick)
inst.repo=hd:<device>:/<path>
Image file of the installation DVD.
NFS Server
inst.repo=nfs:[options:]<server>:/<path>
Image file of the installation DVD, or an installation tree, which is a complete copy of the directories and files on the installation DVD. [b]
HTTP Server
inst.repo=http://<host>/<path>
Installation tree that is a complete copy of the directories and files on the installation DVD.
HTTPS Server
inst.repo=https://<host>/<path>
FTP Server
inst.repo=ftp://<username>:<password>@<host>/<path>
HMC
inst.repo=hmc
[a] If device is left out, installation program automatically searches for a drive containing the installation DVD.[b] The NFS Server option uses NFS protocol version 3 by default. To use a different version, addnfsvers=X
to options, replacing X with the version number that you want to use.
-
an installable tree, which is a directory structure containing the installation program images, packages, and repository data as well as a valid
Set disk device names with the following formats:
-
Kernel device name, for example
/dev/sda1
orsdb2
-
File system label, for example
LABEL=Flash
orLABEL=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.addrepo=
Use the
inst.addrepo=
boot option to add an additional repository that you can use as another installation source along with the main repository (inst.repo=
). You can use theinst.addrepo=
boot option multiple times during one boot. The following table contains details of theinst.addrepo=
boot option syntax.NoteThe
REPO_NAME
is the name of the repository and is required in the installation process. These repositories are only used during the installation process; they are not installed on the installed system.
For more information about unified ISO, see Unified ISO.
Table 17.2. Installation sources and boot option format
Installation source | Boot option format | Additional information |
---|---|---|
Installable tree at a URL |
| Looks for the installable tree at a given URL. |
Installable tree at an NFS path |
|
Looks for the installable tree at a given NFS path. A colon is required after the host. The installation program passes everything after |
Installable tree in the installation environment |
|
Looks for the installable tree at the given location in the installation environment. To use this option, the repository must be mounted before the installation program attempts to load the available software groups. The benefit of this option is that you can have multiple repositories on one bootable ISO, and you can install both the main repository and additional repositories from the ISO. The path to the additional repositories is |
Hard Drive |
| Mounts the given <device> partition and installs from the ISO that is specified by the <path>. If the <path> is not specified, the installation program looks for a valid installation ISO on the <device>. This installation method requires an ISO with a valid installable tree. |
- inst.stage2=
The
inst.stage2=
boot option specifies the location of the installation program’s runtime image. This option expects the path to a directory that contains a valid.treeinfo
file and reads the runtime image location from the.treeinfo
file. If the.treeinfo
file is not available, the installation program attempts to load the image fromimages/install.img
.When you do not specify the
inst.stage2
option, the installation program attempts to use the location specified with theinst.repo
option.Use this option when you want to manually specify the installation source in the installation program at a later time. For example, when you want to select the Content Delivery Network (CDN) as an installation source. The installation DVD and Boot ISO already contain a suitable
inst.stage2
option to boot the installation program from the respective ISO.If you want to specify an installation source, use the
inst.repo=
option instead.NoteBy 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-x-0-0-BaseOS-x86_64
. If you modify the default label of the file system that contains the runtime image, or if you use a customized procedure to boot the installation system, verify that theinst.stage2=
boot option is set to the correct value.- inst.noverifyssl
Use the
inst.noverifyssl
boot option to prevent the installer from verifying SSL certificates for all HTTPS connections with the exception of additional Kickstart repositories, where--noverifyssl
can be set per repository.For example, if your remote installation source is using self-signed SSL certificates, the
inst.noverifyssl
boot option enables the installer to complete the installation without verifying the SSL certificates.Example when specifying the source using
inst.stage2=
inst.stage2=https://hostname/path_to_install_image/ inst.noverifyssl
Example when specifying the source using
inst.repo=
inst.repo=https://hostname/path_to_install_repository/ inst.noverifyssl
- inst.stage2.all
Use the
inst.stage2.all
boot option to specify several HTTP, HTTPS, or FTP sources. You can use theinst.stage2=
boot option multiple times with theinst.stage2.all
option to fetch the image from the sources sequentially until one succeeds. For example:inst.stage2.all inst.stage2=http://hostname1/path_to_install_tree/ inst.stage2=http://hostname2/path_to_install_tree/ inst.stage2=http://hostname3/path_to_install_tree/
- inst.dd=
-
The
inst.dd=
boot option is used to perform a driver update during the installation. For more information about how to update drivers during installation, see the Performing an advanced RHEL 8 installation document. - inst.repo=hmc
-
This option eliminates the requirement of an external network setup and expands the installation options. 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 the
inst.repo=hmc
option to the kernel parameters. The installation program then enables support element (SE) and hardware management console (HMC) file access, fetches the images for stage2 from the DVD, and provides access to the packages on the DVD for software selection. - inst.proxy=
The
inst.proxy=
boot option is used when performing an installation from a HTTP, HTTPS, and FTP protocol. For example:[PROTOCOL://][USERNAME[:PASSWORD]@]HOST[:PORT]
- inst.nosave=
Use the
inst.nosave=
boot option to control the installation logs and related files that are not saved to the installed system, for exampleinput_ks
,output_ks
,all_ks
,logs
andall
. You can combine multiple values separated by a comma. For example,inst.nosave=Input_ks,logs
NoteThe
inst.nosave
boot option is used for excluding files from the installed system that cannot be removed by a Kickstart %post script, such as logs and input/output Kickstart results.input_ks
- Disables the ability to save the input Kickstart results.
output_ks
- Disables the ability to save the output Kickstart results generated by the installation program.
all_ks
- Disables the ability to save the input and output Kickstart results.
logs
- Disables the ability to save all installation logs.
all
- Disables the ability to save all Kickstart results, and all logs.
- inst.multilib
-
Use the
inst.multilib
boot option to set DNF’smultilib_policy
to all, instead of best. - inst.memcheck
-
The
inst.memcheck
boot option performs a check to verify that the system has enough RAM to complete the installation. If there is not enough RAM, the installation process is stopped. The system check is approximate and memory usage during installation depends on the package selection, user interface, for example graphical or text, and other parameters. - inst.nomemcheck
-
The
inst.nomemcheck
boot option does not perform a check to verify if the system has enough RAM to complete the installation. Any attempt to perform the installation with less than the recommended minimum amount of memory is unsupported, and might result in the installation process failing.
17.4. Network boot options
If your scenario requires booting from an image over the network instead of booting from a local image, you can use the following options to customize network booting.
Initialize the network with the dracut
tool. For complete list of dracut
options, see the dracut.cmdline(7)
man page.
- ip=
Use the
ip=
boot option to configure one or more network interfaces. To configure multiple interfaces, use one of the following methods;-
use the
ip
option multiple times, once for each interface; to do so, use therd.neednet=1
option, and specify a primary boot interface using thebootdev
option. -
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.
-
use the
In the following tables:
-
The
ip
parameter specifies the client IP address andIPv6
requires square brackets, for example 192.0.2.1 or [2001:db8::99]. -
The
gateway
parameter is the default gateway.IPv6
requires square brackets. -
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 17.3. Boot option formats to configure the network interface
Boot option format Configuration method ip=method
Automatic configuration of any interface
ip=interface:method
Automatic configuration of a specific interface
ip=ip::gateway:netmask:hostname:interface:none
Static configuration, for example, IPv4:
ip=192.0.2.1::192.0.2.254:255.255.255.0:server.example.com:enp1s0:none
IPv6:
ip=[2001:db8::1]::[2001:db8::fffe]:64:server.example.com:enp1s0:none
ip=ip::gateway:netmask:hostname:interface:method:mtu
Automatic configuration of a specific interface with an override
Configuration methods for the automatic interface
The method
automatic configuration of a specific interface with an override
opens the interface using the specified method of automatic configuration, such asdhcp
, 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:- 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 theip
option, the default value of theip
option isip=dhcp
.. -
To connect to an iSCSI target automatically, activate a network device for accessing the target by using the
ip=ibft
boot option.
- nameserver=
The
nameserver=
option specifies the address of the name server. You can use this option multiple times.NoteThe
ip=
parameter requires square brackets. However, an IPv6 address does not work with square brackets. An example of the correct syntax to use for an IPv6 address isnameserver=2001:db8::1
.- bootdev=
-
The
bootdev=
option specifies the boot interface. This option is mandatory if you use more than oneip
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 isifname=interface:MAC
. For example:ifname=eth0:01:23:45:67:89:ab
NoteThe
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. Thedhcpd
service sees this value asvendor-class-identifier
. The default value isanaconda-$(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 theSECONDS
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 isvlan=name:interface
. For example:vlan=vlan5:enp0s1
This configures a VLAN device named
vlan5
on theenp0s1
interface. The name can take the following forms:
-
VLAN_PLUS_VID:
vlan0005
-
VLAN_PLUS_VID_NO_PAD:
vlan5
-
DEV_PLUS_VID:
enp0s1.0005
DEV_PLUS_VID_NO_PAD:
enp0s1.5
- bond=
Use the
bond=
option to configure a bonding device with the following syntax:bond=name[:interfaces][:options]
. Replace name with the bonding device name, interfaces with a comma-separated list of physical (Ethernet) interfaces, and options with a comma-separated list of bonding options. For example:bond=bond0:enp0s1,enp0s2:mode=active-backup,tx_queues=32,downdelay=5000
For a list of available options, execute the
modinfo
bonding command.- team=
Use the
team=
option to configure a team device with the following syntax:team=name:interfaces
. Replace name with the desired name of the team device and interfaces with a comma-separated list of physical (Ethernet) devices to be used as underlying interfaces in the team device. For example:team=team0:enp0s1,enp0s2
- bridge=
Use the
bridge=
option to configure a bridge device with the following syntax:bridge=name:interfaces
. Replace name with the desired name of the bridge device and interfaces with a comma-separated list of physical (Ethernet) devices to be used as underlying interfaces in the bridge device. For example:bridge=bridge0:enp0s1,enp0s2
Additional resources
17.5. Console boot options
This section describes how to configure 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, useconsole=ttyS0
. When using theconsole=
argument, the installation starts with a text UI. If you must use theconsole=
option multiple times, the boot message is displayed on all specified console. However, the installation program uses only the last specified console. For example, if you specifyconsole=ttyS0 console=ttyS1
, the installation program usesttyS1
. - inst.lang=
-
Use the
inst.lang=
option to set the language that you want to use during the installation. To view the list of locales, enter the commandlocale -a | grep _
or thelocalectl list-locales | grep _
command. - inst.singlelang
-
Use the
inst.singlelang
option to install in single language mode, which results in no available interactive options for the installation language and language support configuration. If a language is specified using theinst.lang
boot option or thelang
Kickstart command, then it is used. If no language is specified, the installation program defaults toen_US.UTF-8
. - 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
. Thevalue
can be any of the following parameters:-
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 default option isprovider_fedora_geoip
.
-
Disable geolocation:
- inst.keymap=
-
Use the
inst.keymap=
option to specify the keyboard layout to use for the installation. - 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. The graphical mode is the default. - inst.text
-
Use the
inst.text
option to force the installation program to run in text mode instead of graphical mode. - inst.noninteractive
-
Use the
inst.noninteractive
boot option to run the installation program in a non-interactive mode. User interaction is not permitted in the non-interactive mode, andinst.noninteractive
you can use theinst.nointeractive
option with a graphical or text installation. When you use theinst.noninteractive
option in text mode, it behaves the same as theinst.cmdline
option. - inst.resolution=
-
Use the
inst.resolution=
option to specify the screen resolution in graphical mode. The format isNxM
, where N is the screen width and M is the screen height (in pixels). The recommended resolution is 1024x768. - inst.vnc
-
Use the
inst.vnc
option to run the graphical installation using Virtual Network Computing (VNC). You must use a VNC client application to interact with the installation program. When VNC sharing is enabled, multiple clients can connect. A system installed using VNC starts in text mode. - inst.vncpassword=
-
Use the
inst.vncpassword=
option to set a password on the VNC server that is used by the installation program. - inst.vncconnect=
-
Use the
inst.vncconnect=
option to connect to a listening VNC client at the given host location, for example,inst.vncconnect=<host>[:<port>]
The default port is 5900. You can use this option by entering the commandvncviewer -listen
. - inst.xdriver=
-
Use the
inst.xdriver=
option to specify the name of the X driver 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 theinst.xdriver=fbdev
option. - modprobe.blacklist=
Use the
modprobe.blacklist=
option to blocklist or completely disable one or more drivers. Drivers (mods) that you disable using this option cannot load when the installation starts. After the installation finishes, the installed system retains these settings. You can find a list of the blocklisted drivers in the/etc/modprobe.d/
directory. Use a comma-separated list to disable multiple drivers. For example:modprobe.blacklist=ahci,firewire_ohci
- inst.xtimeout=
-
Use the
inst.xtimeout=
option to specify the timeout in seconds for starting X server. - inst.sshd
Use the
inst.sshd
option to start thesshd
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 thessh(1)
man page. By default, thesshd
option is automatically started only on the 64-bit IBM Z architecture. On other architectures,sshd
is not started unless you use theinst.sshd
option.NoteDuring 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; useinst.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.
17.6. Debug boot options
This section describes the options you can use when debugging issues.
- inst.rescue
-
Use the
inst.rescue
option to run the rescue environment for diagnosing and fixing systems. For example, you can repair a filesystem in rescue mode. - inst.updates=
Use the
inst.updates=
option to specify the location of theupdates.img
file that you want to apply during installation. Theupdates.img
file can be derived from one of several sources.Table 17.4.
updates.img
file sourcesSource Description Example Updates from a network
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 includeinst.updates
.inst.updates=http://website.com/path/to/updates.img
.Updates from a disk image
Save an
updates.img
on a floppy drive or a USB key. This can be done only with anext2
filesystem type ofupdates.img
. To save the contents of the image on your floppy drive, insert the floppy disc and run the 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 flash drive.Updates from an installation tree
If you are using a CD, hard drive, HTTP, or FTP install, save the
updates.img
in the installation tree so that all installations can detect the.img
file. The file name must beupdates.img
.For NFS installs, save the file in the
images/
directory, or in theRHupdates/
directory.- inst.loglevel=
Use the
inst.loglevel=
option to specify the minimum level of messages logged on a terminal. This option applies only to 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
-
critical
-
The default value is info
, which means that by default, the logging terminal displays messages ranging from info
to critical
.
- inst.syslog=
-
Sends log messages to the
syslog
process on the specified host when the installation starts. You can useinst.syslog=
only if the remotesyslog
process is configured to accept incoming connections. - inst.virtiolog=
-
Use the
inst.virtiolog=
option to specify which virtio port (a character device at/dev/virtio-ports/name
) to use for forwarding logs. The default value isorg.fedoraproject.anaconda.log.0
. - inst.zram=
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 using the hard drive. This setup allows the installation program to run with less available memory and improve installation speed. You can configure the
inst.zram=
option using the following values:- inst.zram=1 to enable zRAM swap, regardless of system memory size. By default, swap on zRAM is enabled on systems with 2 GiB or less RAM.
- inst.zram=0 to disable zRAM swap, regardless of system memory size. By default, swap on zRAM is disabled on systems with more than 2 GiB of memory.
- rd.live.ram
-
Copies the
stage 2
image inimages/install.img
into RAM. Note that this increases the memory required for installation by the size of the image which is usually between 400 and 800MB. - inst.nokill
- Prevent the installation program from rebooting when a fatal error occurs, or at the end of the installation process. Use it capture installation logs which would be lost upon reboot.
- inst.noshell
- Prevent a shell on terminal session 2 (tty2) during installation.
- inst.notmux
- Prevent the use of tmux during installation. The output is generated without terminal control characters and is meant for non-interactive uses.
- inst.remotelog=
-
Sends all the logs to a remote
host:port
using a TCP connection. The connection is retired if there is no listener and the installation proceeds as normal.
17.7. Storage boot options
This section describes the options you can specify to customize booting from a storage device.
- inst.nodmraid
-
Disables
dmraid
support.
Use this option with caution. If you have a disk that is incorrectly identified as part of a firmware RAID array, it might have some stale RAID metadata on it that must be removed using the appropriate tool such as, dmraid
or wipefs
.
- inst.nompath
- Disables support for multipath devices. Use this option only if your system has a false-positive that incorrectly identifies a normal block device as a multipath device.
Use this option with caution. Do not use this option with multipath hardware. Using this option to install to a single path of a multipath device is not supported.
- inst.gpt
-
Forces the installation program to install partition information to a GUID Partition Table (GPT) instead of a Master Boot Record (MBR). This option is not valid on UEFI-based systems, unless they are in BIOS compatibility mode. Normally, BIOS-based systems and UEFI-based systems in BIOS compatibility mode attempt to use the MBR schema for storing partitioning information, unless the disk is 2^32 sectors in size or larger. Disk sectors are typically 512 bytes in size, meaning that this is usually equivalent to 2 TiB. The
inst.gpt
boot option allows a GPT to be written to smaller disks. - inst.wait_for_disks=
-
Use the
inst.wait_for_disks=
option to specify the number of seconds installation program to wait for disk devices to appear at the beginning of the installation. Use this option when you use theOEMDRV-labeled
device to automatically load the Kickstart file or the kernel drivers but the device takes longer time to appear during the boot process. By default, installation program waits for5
seconds. Use0
seconds to minimize the delay.
17.8. Kickstart boot options
This section describes the boot options you can add in the Kickstart file to automate an installation.
- inst.ks=
-
Defines the location of a Kickstart file to use to automate the installation. You can specify locations using any of the
inst.repo
formats. If you specify a device and not a path, the installation program looks for the Kickstart file in/ks.cfg
on the specified device.
If you use this option without specifying a device, the installation program uses the following value for the 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 17.5. Default Kickstart file location
DHCP server address | Client address | Kickstart 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
-
Specify the
inst.ks.all
option to sequentially try multiple Kickstart file locations provided by multipleinst.ks
options. The first successful location is used. This applies only to locations of typehttp
,https
orftp
, 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
17.9. Advanced installation boot options
This section contains information about advanced installation boot options.
- inst.kexec
Runs the
kexec
system call at the end of the installation, instead of performing a reboot. Theinst.kexec
option loads the new system immediately, and bypasses the hardware initialization normally performed by the BIOS or firmware.ImportantThis option is deprecated and available as a Technology Preview only. For information about 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. This can potentially create issues for certain device drivers.- inst.multilib
Configures the system for multilib packages 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 thebash
package that depends on theglibc
package, thebash
package is installed in multiple variants, while theglibc
package is installed only in variants that the bash package requires.- selinux=0
Disables the use of SELinux in the installation program and the installed system. By default, SELinux operates in permissive mode in the installation program, and in enforcing mode in the installed system.
NoteThe inst.selinux=0 and selinux=0 options are not the same: * inst.selinux=0: disable SELinux only in the installation program. * selinux=0: disable the use of SELinux in the installation program and the installed system. Disabling SELinux causes events not to be logged.
- inst.nonibftiscsiboot
- Places the boot loader on iSCSI devices that were not configured in the iSCSI Boot Firmware Table (iBFT).
17.10. Deprecated boot options
This section contains information about deprecated boot options. These options are still accepted by the installation program but they are deprecated and are scheduled to be removed in a future release of Red Hat Enterprise Linux.
- method
-
The
method
option is an alias forinst.repo
. - dns
-
Use
nameserver
instead ofdns
. Note that nameserver does not accept comma-separated lists; use multiple nameserver options instead. - netmask, gateway, hostname
-
The
netmask
,gateway
, andhostname
options are provided as part of theip
option. - ip=bootif
-
A PXE-supplied
BOOTIF
option is used automatically, so there is no requirement to useip=bootif
. - ksdevice
Table 17.6. Values for the ksdevice boot option
Value Information Not present
N/A
ksdevice=link
Ignored as this option is the same as the default behavior
ksdevice=bootif
Ignored as this option is the default if
BOOTIF=
is presentksdevice=ibft
Replaced with
ip=ibft
. Seeip
for detailsksdevice=<MAC>
Replaced with
BOOTIF=${MAC/:/-}
ksdevice=<DEV>
Replaced with
bootdev
17.11. Removed boot options
This section contains the boot options that have been removed from Red Hat Enterprise Linux.
dracut
provides advanced boot options. For more information about dracut
, see the dracut.cmdline(7)
man page.
- askmethod, asknetwork
-
initramfs
is completely non-interactive, so theaskmethod
andasknetwork
options have been removed. Useinst.repo
or specify the appropriate network options. - blacklist, nofirewire
-
The
modprobe
option now handles blocklisting kernel modules. Usemodprobe.blacklist=<mod1>,<mod2>
. You can blocklist the firewire module by usingmodprobe.blacklist=firewire_ohci
. - inst.headless=
-
The
headless=
option specified that the system that is being installed to does not have any display hardware, and that the installation program is not required to look for any display hardware. - inst.decorated
-
The
inst.decorated
option was used to specify the graphical installation in a decorated window. By default, the window is not decorated, so it does not have a title bar, resize controls, and so on. This option was no longer required. - repo=nfsiso
-
Use the
inst.repo=nfs:
option. - serial
-
Use the
console=ttyS0
option. - updates
-
Use the
inst.updates
option. - essid, wepkey, wpakey
- Dracut does not support wireless networking.
- ethtool
- This option was no longer required.
- gdb
-
This option was removed because many options are available for debugging dracut-based
initramfs
. - inst.mediacheck
-
Use the
dracut option rd.live.check
option. - ks=floppy
-
Use the
inst.ks=hd:<device>
option. - display
-
For a remote display of the UI, use the
inst.vnc
option. - utf8
- This option was no longer required because the default TERM setting behaves as expected.
- noipv6
-
ipv6 is built into the kernel and cannot be removed by the installation program. You can disable ipv6 by using
ipv6.disable=1
. This setting is used by the installed system. - upgradeany
- This option was no longer required because the installation program no longer handles upgrades.
Chapter 18. Booting a beta system with UEFI Secure Boot
To enhance the security of your operating system, use the UEFI Secure Boot feature for signature verification when booting a Red Hat Enterprise Linux Beta release on systems having UEFI Secure Boot enabled.
18.1. UEFI Secure Boot and RHEL Beta releases
UEFI Secure Boot requires that the operating system kernel is signed with a recognized private key. UEFI Secure Boot then verifies the signature using the corresponding public key.
For Red Hat Enterprise Linux Beta releases, the kernel is signed with a Red Hat Beta-specific private key. UEFI Secure Boot attempts to verify the signature using the corresponding public key, but because the hardware does not recognize the Beta private key, Red Hat Enterprise Linux Beta release system fails to boot. Therefore, to use UEFI Secure Boot with a Beta release, add the Red Hat Beta public key to your system using the Machine Owner Key (MOK) facility.
18.2. Adding a Beta public key for UEFI Secure Boot
This section contains information about how to add a Red Hat Enterprise Linux Beta public key for UEFI Secure Boot.
Prerequisites
- The UEFI Secure Boot is disabled on the system.
- The Red Hat Enterprise Linux Beta release is installed, and Secure Boot is disabled even after system reboot.
- You are logged in to the system, and the tasks in the Initial Setup window are complete.
Procedure
Begin to enroll the Red Hat Beta public key in the system’s Machine Owner Key (MOK) list:
#
mokutil --import /usr/share/doc/kernel-keys/$(uname -r)/kernel-signing-ca.cer$(uname -r)
is replaced by the kernel version - for example, 4.18.0-80.el8.x86_64.- Enter a password when prompted.
- Reboot the system and press any key to continue the startup. The Shim UEFI key management utility starts during the system startup.
- Select Enroll MOK.
- Select Continue.
- Select Yes and enter the password. The key is imported into the system’s firmware.
- Select Reboot.
- Enable Secure Boot on the system.
18.3. Removing a Beta public key
If you plan to remove the Red Hat Enterprise Linux Beta release, and install a Red Hat Enterprise Linux General Availability (GA) release, or a different operating system, then remove the Beta public key.
The procedure describes how to remove a Beta public key.
Procedure
Begin to remove the Red Hat Beta public key from the system’s Machine Owner Key (MOK) list:
#
mokutil --reset- Enter a password when prompted.
- Reboot the system and press any key to continue the startup. The Shim UEFI key management utility starts during the system startup.
- Select Reset MOK.
- Select Continue.
- Select Yes and enter the password that you had specified in step 2. The key is removed from the system’s firmware.
- Select Reboot.
Part V. Kickstart references
Appendix A. Kickstart script file format reference
This reference describes in detail the kickstart file format.
A.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.
-
Add-on sections. These sections use the
- 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 evaluated, 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 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.
If user interaction is needed during kickstart installation in text or graphical mode, enter only the windows where updates are mandatory to complete the installation. Entering spokes might lead to resetting the kickstart configuration. Resetting of the configuration applies specifically to the kickstart commands related to storage after entering the Installation Destination window.
A.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.
A.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.
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
A.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 therepository/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 packagesdocbook-dtds
anddocbook-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
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
A.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, 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, you can install only the x86_64 and the noarch packages. However, with the --multilib option, you can automatically install the 32-bit AMD and the i686 Intel system packages available, if any.
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.User can configure Anaconda to install packages in
multilib
mode during the installation of the system. Use one of the following options to enablemultilib
mode:Configure Kickstart file with the following lines:
%packages --multilib --default %end
- Add the inst.multilib boot option during booting the installation image.
--nocore
Disables installation of the
@Core
package group which is otherwise always installed by default. Disabling the@Core
package group with--nocore
should be only used for creating lightweight containers; installing a desktop or server system with--nocore
will result in an unusable system.Notes-
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. -
The
@Core
package group is defined as a minimal set of packages needed for installing a working system. It is not related in any way to core packages as defined in the Package Manifest and Scope of Coverage Details.
-
Using
--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.
A.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.
The --nodefaults
and --optional
options cannot be used together. You can install only mandatory packages during the installation using --nodefaults
and install the optional packages on the installed system post installation.
A.3. Scripts in Kickstart file
A kickstart file can include the following scripts:
-
%pre
-
%pre-install
-
%post
This section provides the following details about the scripts:
- Execution time
- Types of commands that can be included in the script
- Purpose of the script
- Script options
A.3.1. %pre script
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.
The %pre
section of Kickstart is executed at the stage of installation which happens after the installer image (inst.stage2
) is fetched: it means after root switches to the installer environment (the installer image) and after the Anaconda
installer itself starts. Then the configuration in %pre
is applied and can be used to fetch packages from installation repositories configured, for example, by URL in Kickstart. However, it cannot be used to configure network to fetch the image (inst.stage2
) from network.
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 script does not run in the chroot environment.
A.3.1.1. %pre script 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/libexec/platform-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/libexec/platform-python
.Note that the
platform-python
interpreter uses Python version 3.6. You must change your Python scripts from previous RHEL versions for the new path and version. Additionally,platform-python
is meant for system tools: Use thepython36
package outside the installation environment. For more details about Python in Red Hat Enterprise Linux, see\ Introduction to Python in Configuring basic system settings.--erroronfail
-
Displays an error and halts the installation if the script fails. The error message will direct you to where the cause of the failure is logged. The installed system might get into an unstable and unbootable state. You can use the
inst.nokill
option to debug the script. --log=
Logs the script’s output into the specified log file. For example:
%pre --log=/tmp/ks-pre.log
A.3.2. %pre-install script
The commands in the pre-install
script are run after the following tasks are complete:
- System is partitioned
- Filesystems are created and mounted under /mnt/sysroot
- Network has been configured according to any boot options and kickstart commands
Each of the %pre-install
sections must start with %pre-install
and end with %end
.
The %pre-install
scripts can be used to modify the installation, and to add users and groups with guaranteed IDs before package installation.
It is recommended to use the %post
scripts for any modifications required in the installation. Use the %pre-install
script only if the %post
script falls short for the required modifications.
Note: The pre-install
script does not run in chroot environment.
A.3.2.1. %pre-install script section options
The following options can be used to change the behavior of pre-install
scripts. To use an option, append it to the %pre-install
line at the beginning of the script. For example:
%pre-install --interpreter=/usr/libexec/platform-python -- Python script omitted -- %end
Note that you can have multiple %pre-install
sections, with same or different interpreters. They are evaluated in their order of appearance in the Kickstart file.
--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/libexec/platform-python
.Note that the
platform-python
interpreter uses Python version 3.6. You must change your Python scripts from previous RHEL versions for the new path and version. Additionally,platform-python
is meant for system tools: Use thepython36
package outside the installation environment. For more details about Python in Red Hat Enterprise Linux, see Introduction to Python in Configuring basic system settings.--erroronfail
-
Displays an error and halts the installation if the script fails. The error message will direct you to where the cause of the failure is logged. The installed system might get into an unstable and unbootable state. You can use the
inst.nokill
option to debug the script. --log=
Logs the script’s output into the specified log file. For example:
%pre-install --log=/mnt/sysroot/root/ks-pre.log
A.3.3. %post script
The %post script is a post-installation script that is 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.
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.
Note that during execution of the %post
section, the installation media must be still inserted.
A.3.3.1. %post script 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/libexec/platform-python -- Python script omitted -- %end
--interpreter=
Allows you to specify a different scripting language, such as Python. For example:
%post --interpreter=/usr/libexec/platform-python
Any scripting language available on the system can be used; in most cases, these are
/usr/bin/sh
,/usr/bin/bash
, and/usr/libexec/platform-python
.Note that the
platform-python
interpreter uses Python version 3.6. You must change your Python scripts from previous RHEL versions for the new path and version. Additionally,platform-python
is meant for system tools: Use thepython36
package outside the installation environment. For more details about Python in Red Hat Enterprise Linux, see Introduction to Python in Configuring basic system settings.--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/sysroot/etc/resolv.conf %end
--erroronfail
-
Displays an error and halts the installation if the script fails. The error message will direct you to where the cause of the failure is logged. The installed system might get into an unstable and unbootable state. You can use the
inst.nokill
option to debug the script. --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/sysroot/root/ks-post.log
A.3.3.2. 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
A.3.3.3. 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.
A.4. 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 A.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.
A.5. 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
-
Displays an error and halts the installation if the script fails. The error message will direct you to where the cause of the failure is logged. The installed system might get into an unstable and unbootable state. You can use the
inst.nokill
option to debug the script. --interpreter=
Allows you to specify a different scripting language, such as Python. For example:
%onerror --interpreter=/usr/libexec/platform-python
Any scripting language available on the system can be used; in most cases, these are
/usr/bin/sh
,/usr/bin/bash
, and/usr/libexec/platform-python
.Note that the
platform-python
interpreter uses Python version 3.6. You must change your Python scripts from previous RHEL versions for the new path and version. Additionally,platform-python
is meant for system tools: Use thepython36
package outside the installation environment. For more details about Python in Red Hat Enterprise Linux, see Introduction to Python in Configuring basic system settings.--log=
- Logs the script’s output into the specified log file.
A.6. 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 B. Kickstart commands and options reference
This reference is a complete list of all Kickstart commands supported by the Red Hat Enterprise Linux installation 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.
B.1. Kickstart changes
The following sections describe the changes in Kickstart commands and options in Red Hat Enterprise Linux 8.
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.
Kickstart no longer supports Btrfs
The Btrfs file system is not supported from Red Hat Enterprise Linux 8. As a result, the Graphical User Interface (GUI) and the Kickstart commands no longer support Btrfs.
Using Kickstart files from previous RHEL releases
If you are using Kickstart files from previous RHEL releases, see the Repositories section of the Considerations in adopting RHEL 8 document for more information about the Red Hat Enterprise Linux 8 BaseOS and AppStream repositories.
B.1.1. Deprecated Kickstart commands and options
The following Kickstart commands and options have been deprecated in Red Hat Enterprise Linux 8.
Where only specific options are listed, the base command and its other options are still available and not deprecated.
-
auth
orauthconfig
- useauthselect
instead -
device
-
deviceprobe
-
dmraid
-
install
- use the subcommands or methods directly as commands -
multipath
-
bootloader --upgrade
-
ignoredisk --interactive
-
partition --active
-
reboot --kexec
-
syspurpose
- usesubscription-manager syspurpose
instead
Except the auth
or authconfig
command, using the commands in Kickstart files prints a warning in the logs.
You can turn the deprecated command warnings into errors with the inst.ksstrict
boot option, except for the auth
or authconfig
command.
B.1.2. Removed Kickstart commands 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.
-
device
-
deviceprobe
-
dmraid
-
install
- use the subcommands or methods directly as commands -
multipath
-
bootloader --upgrade
-
ignoredisk --interactive
-
partition --active
-
harddrive --biospart
-
upgrade
(This command had already previously been deprecated.) -
btrfs
-
part/partition btrfs
-
part --fstype btrfs
orpartition --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.
B.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.
B.2.1. 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 theinstall
command. Theinstall
command has been deprecated andcdrom
can be used on its own, because it impliesinstall
. - This command has no options.
-
To actually run the installation, you must specify one of
cdrom
,harddrive
,hmc
,nfs
,liveimg
,ostreesetup
,rhsm
, orurl
unless theinst.repo
option is specified on the kernel command line.
B.2.2. 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.
Syntax
cmdline
Notes
-
For a fully automatic installation, you must either specify one of the available modes (
graphical
,text
, orcmdline
) in the Kickstart file, or you must use theconsole=
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 command has no options.
- This mode is useful on 64-bit IBM Z systems with the x3270 terminal.
B.2.3. 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 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:
- Load the driver disk on a hard disk drive, a USB or any similar device.
- Set the label, for example, DD, to this device.
Add the following line to your Kickstart file:
driverdisk LABEL=DD:/e1000.rpm
Replace DD with a specific label and replace e1000.rpm with a specific name. Use anything supported by the inst.repo
command instead of LABEL to specify your hard disk drive.
B.2.4. 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.
Syntax
eula [--agreed]
Options
-
--agreed
(required) - Accept the EULA. This option must always be used, otherwise theeula
command is meaningless.
B.2.5. 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.
Syntax
firstboot OPTIONS
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 root password, time & date, and networking & host name configuration options in addition to the default ones.
B.2.6. graphical
The graphical
Kickstart command is optional. It performs the installation in graphical mode. This is the default.
Syntax
graphical [--non-interactive]
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
, orcmdline
) in the Kickstart file, or you must use theconsole=
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.
B.2.7. 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.
Syntax
halt
Notes
-
The
halt
command is equivalent to theshutdown -H
command. For more details, see the shutdown(8) man page. -
For other completion methods, see the
poweroff
,reboot
, andshutdown
commands. - This command has no options.
B.2.8. 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 be formatted with a file system the installation program can mount: ext2
, ext3
, ext4
, vfat
, or xfs
.
Syntax
harddrive OPTIONS
Options
-
--partition=
- Partition to install from (such assdb2
). -
--dir=
- Directory containing thevariant
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 theinstall
command. Theinstall
command has been deprecated andharddrive
can be used on its own, because it impliesinstall
. -
To actually run the installation, you must specify one of
cdrom
,harddrive
,hmc
,nfs
,liveimg
,ostreesetup
,rhsm
, orurl
unless theinst.repo
option is specified on the kernel command line.
B.2.9. install (deprecated)
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.
-
B.2.10. 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 areHTTP
,HTTPS
,FTP
, andfile
.
Optional options
-
--url=
- The location to install from. Supported protocols areHTTP
,HTTPS
,FTP
, andfile
. -
--proxy=
- Specify anHTTP
,HTTPS
orFTP
proxy to use while performing the installation. -
--checksum=
- An optional argument with theSHA256
checksum of the image file, used for verification. -
--noverifyssl
- Disable SSL verification when connecting to anHTTPS
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 areext2
,ext3
,ext4
,vfat
, andxfs
. -
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. -
To actually run the installation, you must specify one of
cdrom
,harddrive
,hmc
,nfs
,liveimg
,ostreesetup
,rhsm
, orurl
unless theinst.repo
option is specified on the kernel command line. -
Previously, the
liveimg
command had to be used together with theinstall
command. Theinstall
command has been deprecated andliveimg
can be used on its own, because it impliesinstall
.
B.2.11. logging
The logging
Kickstart command is optional. It controls the error logging of Anaconda during installation. It has no effect on the installed system.
Logging is supported over TCP only. For remote logging, ensure that the port number that you specify in --port=
option is open on the remote server. The default port is 514.
Syntax
logging OPTIONS
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 aredebug
,info
,warning
,error
, orcritical
.
B.2.12. mediacheck
The mediacheck
Kickstart command is optional. This command forces the installation program to perform a media check before starting the installation. This command requires that installations be attended, so it is disabled by default.
Syntax
mediacheck
Notes
-
This Kickstart command is equivalent to the
rd.live.check
boot option. - This command has no options.
B.2.13. nfs
The nfs
Kickstart command is optional. It performs the installation from a specified NFS server.
Syntax
nfs OPTIONS
Options
-
--server=
- Server from which to install (host name or IP). -
--dir=
- Directory containing thevariant
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 theinstall
command. Theinstall
command has been deprecated andnfs
can be used on its own, because it impliesinstall
. -
To actually run the installation, you must specify one of
cdrom
,harddrive
,hmc
,nfs
,liveimg
,ostreesetup
,rhsm
, orurl
unless theinst.repo
option is specified on the kernel command line.
B.2.14. 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
- A remote repository location. -
--nogpg
- Disable GPG key verification.
Notes
- For more information about the OStree tools, see the upstream documentation: https://ostreedev.github.io/ostree/
B.2.15. 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.
Syntax
poweroff
Notes
-
The
poweroff
option is equivalent to theshutdown -P
command. For more details, see the shutdown(8) man page. -
For other completion methods, see the
halt
,reboot
, andshutdown
Kickstart commands. Thehalt
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 about you system’s APM/ACPI abilities. - This command has no options.
B.2.16. 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.
Syntax
reboot OPTIONS
Options
-
--eject
- Attempt to eject the bootable media (DVD, USB, or other media) before rebooting. --kexec
- Uses thekexec
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.ImportantThis option is deprecated and available as a Technology Preview only. For information about 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 theshutdown -r
command. For more details, see the shutdown(8) man page. -
Specify
reboot
to automate installation fully when installing in command line mode on 64-bit IBM Z. -
For other completion methods, see the
halt
,poweroff
, andshutdown
Kickstart options. Thehalt
option is the default completion method if no other methods are explicitly specified in the Kickstart file.
B.2.17. rhsm
The rhsm
Kickstart command is optional. It instructs the installation program to register and install RHEL from the CDN.
The rhsm
Kickstart command removes the requirement of using custom %post
scripts when registering the system.
Options
-
--organization=
- Uses the organization id to register and install RHEL from the CDN. -
--activation-key=
- Uses the activation key to register and install RHEL from the CDN. Option can be used multiple times, once per activation key, as long as the activation keys used are registered to your subscription. -
--connect-to-insights
- Connects the target system to Red Hat Insights. -
--proxy=
- Sets the HTTP proxy.
To switch the installation source repository to the CDN by using the
rhsm
Kickstart command, you must meet the following conditions:-
On the kernel command line, you have used
inst.stage2=<URL>
to fetch the installation image but have not specified an installation source usinginst.repo=
. -
In the Kickstart file, you have not specified an installation source by using the
url
,cdrom
,harddrive
,liveimg
,nfs
andostree
setup commands.
-
On the kernel command line, you have used
-
An installation source URL specified using a boot option or included in a Kickstart file takes precedence over the CDN, even if the Kickstart file contains the
rhsm
command with valid credentials. The system is registered, but it is installed from the URL installation source. This ensures that earlier installation processes operate as normal.
B.2.18. shutdown
The shutdown
Kickstart command is optional. It shuts down the system after the installation has successfully completed.
Syntax
shutdown
Notes
-
The
shutdown
Kickstart option is equivalent to theshutdown
command. For more details, see the shutdown(8) man page. -
For other completion methods, see the
halt
,poweroff
, andreboot
Kickstart options. Thehalt
option is the default completion method if no other methods are explicitly specified in the Kickstart file. - This command has no options.
B.2.19. 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
=name - 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 makessh
available during the installation, boot the system with the kernel boot optioninst.sshd
. If you want to disable root
ssh
access, while allowing another userssh
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 example_password --lock
B.2.20. 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 [--non-interactive]
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
, orcmdline
) in the Kickstart file, or you must use theconsole=
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.
B.2.21. url
The url
Kickstart command is optional. It is used to install from an installation tree image on a remote server by using the FTP, HTTP, or HTTPS protocol. You can only specify one URL.
You must specify one of the --url
, --metalink
or --mirrorlist
options.
Syntax
url
--url=FROM
[OPTIONS]
Options
-
--url=FROM
- Specifies theHTTP
,HTTPS
,FTP
, orfile
location to install from. -
--mirrorlist=
- Specifies the mirror URL to install from. -
--proxy=
- Specifies anHTTP
,HTTPS
, orFTP
proxy to use during the installation. -
--noverifyssl
- Disables SSL verification when connecting to anHTTPS
server. -
--metalink=URL
- Specifies the metalink URL to install from. Variable substitution is done for$releasever
and$basearch
in the URL.
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
Notes
-
Previously, the
url
command had to be used together with theinstall
command. Theinstall
command has been deprecated andurl
can be used on its own, because it impliesinstall
. -
To actually run the installation, you must specify one of
cdrom
,harddrive
,hmc
,nfs
,liveimg
,ostreesetup
,rhsm
, orurl
unless theinst.repo
option is specified on the kernel command line.
B.2.22. 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.
Additional resources
B.2.23. %include
The %include
Kickstart command is optional.
Use the %include
command to include the contents of another file in the Kickstart file as if 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 to include files generated by scripts in the %pre
sections. To include files before evaluation of %pre
sections, use the %ksappend
command.
Syntax
%include path/to/file
B.2.24. %ksappend
The %ksappend
Kickstart command is optional.
Use the %ksappend
command to include the contents of another file in the Kickstart file as if 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.
Syntax
%ksappend path/to/file
B.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.
B.3.1. auth or authconfig (deprecated)
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
orauthconfig
Kickstart commands called theauthconfig
tool. This tool has been deprecated in Red Hat Enterprise Linux 8. These Kickstart commands now use theauthselect-compat
tool to call the newauthselect
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 theauthselect-compat
package to provide the compatibility layer. - Passwords are shadowed by default.
-
When using OpenLDAP with the
SSL
protocol for security, make sure that theSSLv2
andSSLv3
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.
B.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 theauthselect --help
command for more details. -
This command replaces the deprecated
auth
orauthconfig
commands deprecated in Red Hat Enterprise Linux 8 together with theauthconfig
tool. - Passwords are shadowed by default.
-
When using OpenLDAP with the
SSL
protocol for security, make sure that theSSLv2
andSSLv3
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.
B.3.3. firewall
The firewall
Kickstart command is optional. It specifies the firewall configuration for the installed system.
Syntax
firewall --enabled|--disabled [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.
Optional options
-
--trust
- Listing a device here, such asem1
, 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
. -
--remove-service
- Do not allow services through the firewall. 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, specifyimap:tcp
. Numeric ports can also be specified explicitly; for example, to allow UDP packets on port 1234 through, specify1234: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 (likecups
,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 thefirewalld
service is running,firewall-cmd --get-services
provides a list of known service names.-
--use-system-defaults
- Do not 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.
B.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.
B.3.5. keyboard (required)
The keyboard
Kickstart command is required. It sets one or more available keyboard layouts for the system.
Syntax
keyboard --vckeymap|--xlayouts OPTIONS
Options
-
--vckeymap=
- Specify aVConsole
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 assetxkbmap(1)
, either in thelayout
format (such ascz
), or in thelayout (variant)
format (such ascz (qwerty)
).All available layouts can be viewed on the
xkeyboard-config(7)
man page underLayouts
.--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 assetxkbmap(1)
.Available switching options can be viewed on the
xkeyboard-config(7)
man page underOptions
.
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
B.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.
Syntax
lang language [--addsupport=language,...]
Mandatory options
-
language
- Install support for this language and set it as system default.
Optional 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
-
The
locale -a | grep _
orlocalectl list-locales | grep _
commands return a list of supported locales. -
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
B.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 themodule
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 multiplemodule
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
B.3.8. 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 aspublican
) and globs (such asgnome-*
) 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 theinstall.img
is fetched on HTTP installations. -
--noverifyssl
- Disable SSL verification when connecting to anHTTPS
server.
Notes
- Repositories used for installation must be stable. The installation can fail if a repository is modified before the installation concludes.
B.3.9. 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
Mandatory options
-
password - Password specification. Either plain text or encrypted string. See
--iscrypted
and--plaintext
below.
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.
B.3.10. 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
B.3.11. 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
B.3.12. 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.
Syntax
skipx
Notes
- This command has no options.
B.3.13. 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 "ssh_key"
Mandatory options
-
--username=
- The user for which the key will be installed. - ssh_key - The complete SSH key fingerprint. It must be wrapped with quotes.
B.3.14. 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.
Red Hat Enterprise Linux 8.6 and later enables you to manage and display system purpose attributes with a single module by making the role
, service-level
, usage
, and addons
subcommands available under one subscription-manager syspurpose
module. Previously, system administrators used one of four standalone syspurpose
commands to manage each attribute. This standalone syspurpose
command is deprecated starting with RHEL 8.6 and is planned to be removed in RHEL 9. Red Hat will provide bug fixes and support for this feature during the current release lifecycle, but this feature will no longer receive enhancements. Starting with RHEL 9, the single subscription-manager syspurpose
command and its associated subcommands is the only way to use system purpose.
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.
Red Hat Enterprise Linux 8.6 and later enables you to manage and display system purpose attributes with a single module by making the role
, service-level
, usage
, and addons
subcommands available under one subscription-manager syspurpose
module. Previously, system administrators used one of four standalone syspurpose
commands to manage each attribute. This standalone syspurpose
command is deprecated starting with RHEL 8.6 and is planned to be removed in RHEL 9. Red Hat will provide bug fixes and support for this feature during the current release lifecycle, but this feature will no longer receive enhancements. Starting with RHEL 9, the single subscription-manager syspurpose
command and its associated subcommands is the only way to use system purpose.
B.3.15. 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.common_timezones
list, provided by the pytz package.
B.3.16. 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 thepasswd(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 thegroup
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 at5000
instead of1000
. 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 theuser file-creation mask
setting.The
user file-creation mask
can be controlled with theumask
command. The default setting of theuser file-creation mask
for new users is defined by theUMASK
variable in the/etc/login.defs
configuration file on the installed system. If unset, it defaults to022
. 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.
B.3.17. xconfig
The xconfig
Kickstart command is optional. It configures the X Window System.
Syntax
xconfig [--startxonboot]
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.
B.4. Kickstart commands for network configuration
The Kickstart commands in this list let you configure networking on the system.
B.4.1. network (optional)
Use the optional network
Kickstart command to configure network information for the target system and activate the network devices in the installation environment. The device specified in the first network
command is activated automatically. You can also explicitly require a device to be activated using the --activate
option.
Syntax
network OPTIONS
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 ofdhcp
,bootp
,ibft
, orstatic
. The default option isdhcp
; thedhcp
andbootp
options are treated the same. To disableipv4
configuration of the device, use--noipv4
option.NoteThis 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 thenetwork
command.If the
--device=
option is missing on the first use of thenetwork
command, the value of theinst.ks.device=
Anaconda boot option is used, if available. Note that this is considered deprecated behavior; in most cases, you should always specify a--device=
for everynetwork
command.The behavior of any subsequent
network
command in the same Kickstart file is unspecified if its--device=
option is missing. Verify you specify this option for anynetwork
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 theup
state -
the keyword
bootif
, which uses the MAC address that pxelinux set in theBOOTIF
variable. SetIPAPPEND 2
in yourpxelinux.cfg
file to have pxelinux set theBOOTIF
variable.
For example:
network --bootproto=dhcp --device=em1
-
the device name of the interface, for example,
--ipv4-dns-search
/--ipv6-dns-search
- Set the DNS search domains manually. You must use these options together with--device
options and mirror their respective NetworkManager properties, for example:network --device ens3 --ipv4-dns-search domain1.example.com,domain2.example.com
-
--ipv4-ignore-auto-dns
/--ipv6-ignore-auto-dns
- Set to ignore the DNS settings from DHCP. You must use these options together with--device
options and these options do not require any arguments. -
--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 useauto
for automatic configuration, ordhcp
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=
- Used to configure the target system’s host name. The host name can either be a fully qualified domain name (FQDN) in the formathostname.domainname
, or a short host name without the domain. 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.When using static IP and host name configuration, it depends on the planned system use case whether to use a short name or FQDN. Red Hat Identity Management configures FQDN during provisioning but some 3rd party software products may require short name. In either case, to ensure availability of both forms in all situations, add an entry for the host in
/etc/hosts
in the formatIP FQDN short-alias
.The value
localhost
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.Host names can only contain alphanumeric characters and
-
or.
. Host name should be equal to or less than 64 characters. Host names cannot start or end with-
and.
. To be compliant with DNS, each part of a FQDN should be equal to or less than 63 characters and the FQDN total length, including dots, should not exceed 255 characters.If you only want to configure the target system’s host name, use the
--hostname
option in thenetwork
command and do not include any other option.If you provide additional options when configuring the host name, the
network
command configures a device using the options specified. If you do not specify which device to configure using the--device
option, the default--device link
value is used. Additionally, if you do not specify the protocol using the--bootproto
option, the device is configured to use DHCP by default.-
--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 secondary devices defined in the--bondslaves=
option. For example:network --device=bond0 --bondslaves=em1,em2
The above command creates a bond device named
bond0
using theem1
andem2
interfaces as its secondary devices.--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
ImportantThe
--bondopts=mode=
parameter only supports full mode names such asbalance-rr
orbroadcast
, not their numerical representations such as0
or3
. For the list of available and supported modes, see Configuring and Managing Networking Guide.-
--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 deviceem1.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 theem1
device with an ID of171
.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 ofNAME.ID
. The NAME is arbitrary, but the ID must be the VLAN ID. For example:em1.171
ormy-vlan.171
. -
Names starting with
vlan
must take the form ofvlanID
- for example,vlan171
.
-
If the name contains a dot (
--teamslaves=
- Team device specified by the--device=
option will be created using secondary devices specified in this option. Secondary devices are separated by commas. A secondary device 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 secondary devices 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 arestp
,priority
,forward-delay
,hello-time
,max-age
, andageing-time
. For information about these parameters, see the bridge setting table in thenm-settings(5)
man page or at Network Configuration Setting Specification.Also see the Configuring and managing networking document for general information about network bridging.
-
--bindto=mac
- Bind the device configuration 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 samenetwork
command also specifies a device name,link
, orbootif
.
Notes
-
The
ethN
device names such aseth0
are no longer available in Red Hat Enterprise Linux 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 8 installation document.
B.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
Mandatory options
-
domain
- The domain to join.
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 includesssd
andwinbind
. 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 includeactive-directory
orfreeipa
. -
--membership-software=
- Use this software when joining the realm. Valid values includesamba
andadcli
. Not all realms support all values. By default, the membership software is chosen automatically.
B.5. Kickstart commands for handling storage
The Kickstart commands in this section configure aspects of storage such as devices, disks, partitions, LVM, and filesystems.
The sdX
(or /dev/sdX
) format does not guarantee consistent device names across reboots, which can complicate the usage of some Kickstart commands. When a command requires a device node name, you can use any item from /dev/disk
as an alternative. For example, instead of using the following device name:
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
By using this approach, the command always targets the same storage device. This is especially useful in large storage environments. To explore the available device names on the system, you can use the ls -lR /dev/disk
command during the interactive installation. For more information about different ways to consistently refer to storage devices, see Overview of persistent naming attributes.
B.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"
B.5.2. autopart
The autopart
Kickstart command is optional. It automatically creates partitions.
The automatically created partitions are: a root (/
) partition (1 GiB or larger), a swap
partition, and an appropriate /boot
partition for the architecture. On large enough drives (50 GiB and larger), this also creates a /home
partition.
Syntax
autopart OPTIONS
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.
For a description of the available partition schemes, see Section C.1, “Supported device types”.
-
-
--fstype=
- Selects one of the available file system types. The available values areext2
,ext3
,ext4
,xfs
, andvfat
. The default file system isxfs
. For information about these file systems, see Section C.2, “Supported file systems”. -
--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.NoteWhen 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 defaultaes-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 eitheraes-xts-plain64
oraes-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 thepart/partition
,raid
,logvol
, orvolgroup
options in the same Kickstart file. -
The
autopart
command is not mandatory, but you must include it if there are nopart
ormount
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. -
Ensure that the disk sector sizes are consistent when using
autopart
,autopart --type=lvm
, orautopart=thinp
.
B.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
andquiet
parameters are automatically added when theplymouth
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 ofplymouth
:%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.WarningEnsure 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 the device using its disk/by-id/dm-uuid-mpath-WWID name.ImportantThe
--boot-drive=
option is currently being ignored in Red Hat Enterprise Linux installations on 64-bit IBM Z systems using thezipl
boot loader. Whenzipl
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.
This option is applicable for Power systems only and UEFI systems should not use this option.
--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 withgrub.pbkdf2
) into the Kickstart file. An examplebootloader
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 8 installation document.
The
sdX
(or/dev/sdX
) format does not guarantee consistent device names across reboots, which can complicate the usage of some Kickstart commands. When a command requires a device node name, you can use any item from/dev/disk
as an alternative. For example, instead of using the following device name: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
By using this approach, the command always targets the same storage device. This is especially useful in large storage environments. To explore the available device names on the system, you can use the
ls -lR /dev/disk
command during the interactive installation. For more information about different ways to consistently refer to storage devices, see Overview of persistent naming attributes.-
The
--upgrade
option is deprecated in Red Hat Enterprise Linux 8.
B.5.4. zipl
The zipl
Kickstart command is optional. It specifies the ZIPL configuration for 64-bit IBM Z.
Options
-
--secure-boot
- Enables secure boot if it is supported by the installing system.
When installed on a system that is later than IBM z14, the installed system cannot be booted from an IBM z14 or earlier model.
-
--force-secure-boot
- Enables secure boot unconditionally.
Installation is not supported on IBM z14 and earlier models.
-
--no-secure-boot
- Disables secure boot.
Secure Boot is not supported on IBM z14 and earlier models. Use --no-secure-boot
if you intend to boot the installed system on IBM z14 and earlier models.
B.5.5. 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.
Syntax
clearpart OPTIONS
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 blocklisting 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 WWID58095BEC5510947BE8C0360F604351918
, 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 WWID2416CD96995134CA5D787F00A5AA11017
, 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, theclearpart
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. Disks cleared byclearpart
will have the label created even in case the--initlabel
is not used.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, themsdos
andgpt
disklabels are accepted, butdasd
is not accepted. -
--linux
- Erases all Linux partitions. -
--none
(default) - Do not remove any partitions. -
--cdl
- Reformat any LDL DASDs to CDL format.
Notes
The
sdX
(or/dev/sdX
) format does not guarantee consistent device names across reboots, which can complicate the usage of some Kickstart commands. When a command requires a device node name, you can use any item from/dev/disk
as an alternative. For example, instead of using the following device name: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
By using this approach, the command always targets the same storage device. This is especially useful in large storage environments. To explore the available device names on the system, you can use the
ls -lR /dev/disk
command during the interactive installation. For more information about different ways to consistently refer to storage devices, see Overview of persistent naming attributes.-
If the
clearpart
command is used, then thepart --onpart
command cannot be used on a logical partition.
B.5.6. 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.
B.5.7. 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 ofsda
,sdb
,…,hda
,… and so on. --only-use=driveN,…
- Specifies a list of disks for the installation program to use. All other disks are ignored. For example, to use disksda
during installation and ignore all other disks:ignoredisk --only-use=sda
To include a multipath device that does not use LVM:
ignoredisk --only-use=disk/by-id/dm-uuid-mpath-2416CD96995134CA5D787F00A5AA11017
To include a multipath device that uses LVM:
ignoredisk --only-use==/dev/disk/by-id/dm-uuid-mpath-
bootloader --location=mbr
You must specify only one of the --drives
or --only-use
.
Notes
-
The
--interactive
option is deprecated in Red Hat Enterprise Linux 8. This option allowed users to manually navigate the advanced storage screen. To ignore a multipath device that does not use logical volume management (LVM), use the format
disk/by-id/dm-uuid-mpath-WWID
, where WWID is the world-wide identifier for the device. For example, to ignore a disk with WWID2416CD96995134CA5D787F00A5AA11017
, use:ignoredisk --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, theclearpart
command could target the wrong disk. The
sdX
(or/dev/sdX
) format does not guarantee consistent device names across reboots, which can complicate the usage of some Kickstart commands. When a command requires a device node name, you can use any item from/dev/disk
as an alternative. For example, instead of using the following device name: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
By using this approach, the command always targets the same storage device. This is especially useful in large storage environments. To explore the available device names on the system, you can use the
ls -lR /dev/disk
command during the interactive installation. For more information about different ways to consistently refer to storage devices, see Overview of persistent naming attributes.
B.5.8. iscsi
The iscsi
Kickstart command is optional. It specifies additional iSCSI storage to be attached during installation.
Syntax
iscsi --ipaddr=address [OPTIONS]
Mandatory options
-
--ipaddr=
(required) - the IP address of the target to connect to.
Optional options
-
--port=
(required) - the port number. If not present,--port=3260
is used automatically by default. -
--target=
- the target IQN (iSCSI Qualified Name). -
--iface=
- bind the connection to a specific network interface instead of using the default one determined by the network layer. Once used, it must be specified in all instances of theiscsi
command in the entire Kickstart file. -
--user=
- the user name required to authenticate with the target -
--password=
- the password that corresponds with the user name specified for the target -
--reverse-user=
- the user name required to authenticate with the initiator from a target that uses reverse CHAP authentication -
--reverse-password=
- the password that corresponds with the user name specified for the initiator
Notes
-
If you use the
iscsi
command, you must also assign a name to the iSCSI node, using theiscsiname
command. Theiscsiname
command must appear before theiscsi
command in the Kickstart file. -
Wherever possible, configure iSCSI storage in the system BIOS or firmware (iBFT for Intel systems) rather than use the
iscsi
command. Anaconda automatically detects and uses disks configured in BIOS or firmware and no special configuration is necessary in the Kickstart file. -
If you must use the
iscsi
command, ensure that networking is activated at the beginning of the installation, and that theiscsi
command appears in the Kickstart file before you refer to iSCSI disks with commands such asclearpart
orignoredisk
.
B.5.9. iscsiname
The iscsiname
Kickstart command is optional. It assigns a name to an iSCSI node specified by the iscsi
command.
Syntax
iscsiname
iqname
Options
-
iqname
- Name to assign to the iSCSI node.
Notes
-
If you use the
iscsi
command in your Kickstart file, you must specifyiscsiname
earlier in the Kickstart file.
B.5.10. logvol
The logvol
Kickstart command is optional. It creates a logical volume for Logical Volume Management (LVM).
Syntax
logvol mntpoint --vgname=name --name=name [OPTIONS]
Mandatory options
mntpoint
The mount point where the partition is mounted. Must be of one of the following forms:
/path
For example,
/
or/home
swap
The partition is used as swap space.
To determine the size of the swap partition automatically, use the
--recommended
option:swap --recommended
To determine the size of the swap partition automatically and also allow extra space for your system to hibernate, use the
--hibernation
option:swap --hibernation
The size assigned will be equivalent to the swap space assigned by
--recommended
plus the amount of RAM on your system.For the swap sizes assigned by these commands, see Recommended Partitioning Scheme for AMD64, Intel 64, and 64-bit ARM systems.
--vgname=name
- Name of the volume group.
--name=name
- Name of the logical volume.
Optional options
--noformat
- Use an existing logical volume and do not format it.
--useexisting
- Use an existing logical volume and reformat it.
--fstype=
-
Sets the file system type for the logical volume. Valid values are
xfs
,ext2
,ext3
,ext4
,swap
, andvfat
. --fsoptions=
Specifies a free form string of options to be used when mounting the filesystem. This string will be copied into the
/etc/fstab
file of the installed system and should be enclosed in quotes.NoteIn the EFI system partition (
/boot/efi
), anaconda hard codes the value and ignores the users specified--fsoptions
values.--mkfsoptions=
Specifies additional parameters to be passed to the program that makes a filesystem on this partition. No processing is done on the list of arguments, so they must be supplied in a format that can be passed directly to the mkfs program. This means multiple options should be comma-separated or surrounded by double quotes, depending on the filesystem. For example,
part /opt/foo1 --size=512 --fstype=ext4 --mkfsoptions="-O ^has_journal,^flex_bg,^metadata_csum"
part /opt/foo2 --size=512 --fstype=xfs --mkfsoptions="-m bigtime=0,finobt=0"
For details, see the man pages of the filesystems you are creating. For example, mkfs.ext4
or mkfs.xfs
.
--fsprofile=
-
Specifies a usage type to be passed to the program that makes a filesystem on this partition. A usage type defines a variety of tuning parameters to be used when making a filesystem. For this option to work, the filesystem must support the concept of usage types and there must be a configuration file that lists valid types. For
ext2
,ext3
, andext4
, this configuration file is/etc/mke2fs.conf
. --label=
- Sets a label for the logical volume.
--grow
- Extends the logical volume to occupy the available space (if any), or up to the maximum size specified, if any. The option must be used only if you have pre-allocated a minimum storage space in the disk image, and would want the volume to grow and occupy the available space. In a physical environment, this is an one-time-action. However, in a virtual environment, the volume size increases as and when the virtual machine writes any data to the virtual disk.
--size=
-
The size of the logical volume in MiB. This option cannot be used together with the
--percent=
option. --percent=
The size of the logical volume, as a percentage of the free space in the volume group after any statically-sized logical volumes are taken into account. This option cannot be used together with the
--size=
option.ImportantWhen creating a new logical volume, you must either specify its size statically using the
--size=
option, or as a percentage of remaining free space using the--percent=
option. You cannot use both of these options on the same logical volume.--maxsize=
-
The maximum size in MiB when the logical volume is set to grow. Specify an integer value here such as
500
(do not include the unit). --recommended
Use this option when creating a logical volume to determine the size of this volume automatically, based on your system’s hardware.
For details about the recommended scheme, see Recommended Partitioning Scheme for AMD64, Intel 64, and 64-bit ARM systems.
--resize
-
Resize a logical volume. If you use this option, you must also specify
--useexisting
and--size
. --encrypted
Specifies that this logical volume should be encrypted with Linux Unified Key Setup (LUKS), using the passphrase provided in the
--passphrase=
option. If you do not specify a passphrase, the installation program uses the default, system-wide passphrase set with theautopart --passphrase
command, or stops the installation and prompts you to provide a passphrase if no default is set.NoteWhen 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.--passphrase=
-
Specifies the passphrase to use when encrypting this logical volume. You must use this option together with the
--encrypted
option; it has no effect by itself. --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 eitheraes-xts-plain64
oraes-cbc-essiv:sha256
. --escrowcert=URL_of_X.509_certificate
-
Store 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. --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. --backuppassphrase
-
Add 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. --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
. --thinpool
-
Creates a thin pool logical volume. (Use a mount point of
none
) --metadatasize=size
- Specify the metadata area size (in MiB) for a new thin pool device.
--chunksize=size
- Specify the chunk size (in KiB) for a new thin pool device.
--thin
-
Create a thin logical volume. (Requires use of
--poolname
) --poolname=name
-
Specify the name of the thin pool in which to create a thin logical volume. Requires the
--thin
option. --profile=name
-
Specify the configuration profile name to use with thin logical volumes. If used, the name will also be included in the metadata for the given logical volume. By default, the available profiles are
default
andthin-performance
and are defined in the/etc/lvm/profile/
directory. See thelvm(8)
man page for additional information. --cachepvs=
- A comma-separated list of physical volumes which should be used as a cache for this volume.
--cachemode=
Specify which mode should be used to cache this logical volume - either
writeback
orwritethrough
.NoteFor more information about cached logical volumes and their modes, see the
lvmcache(7)
man page.--cachesize=
-
Size of cache attached to the logical volume, specified in MiB. This option requires the
--cachepvs=
option.
Notes
Do not use the dash (
-
) character in logical volume and volume group names when installing Red Hat Enterprise Linux using Kickstart. If this character is used, the installation finishes normally, but the/dev/mapper/
directory will list these volumes and volume groups with every dash doubled. For example, a volume group namedvolgrp-01
containing a logical volume namedlogvol-01
will be listed as/dev/mapper/volgrp—01-logvol—01
.This limitation only applies to newly created logical volume and volume group names. If you are reusing existing ones using the
--noformat
option, their names will not be changed.-
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.
Examples
Create the partition first, create the logical volume group, and then create the logical volume:
part pv.01 --size 3000
volgroup myvg pv.01
logvol / --vgname=myvg --size=2000 --name=rootvol
Create the partition first, create the logical volume group, and then create the logical volume to occupy 90% of the remaining space in the volume group:
part pv.01 --size 1 --grow
volgroup myvg pv.01
logvol / --vgname=myvg --name=rootvol --percent=90
Additional resources
B.5.11. mount
The mount
Kickstart command is optional. It assigns a mount point to an existing block device, and optionally reformats it to a given format.
Syntax
mount [OPTIONS] device mountpoint
Mandatory options:
-
device
- The block device to mount. -
mountpoint
- Where to mount thedevice
. It must be a valid mount point, such as/
or/usr
, ornone
if the device is unmountable (for exampleswap
).
Optional options:
-
--reformat=
- Specifies a new format (such asext4
) to which the device should be reformatted. -
--mkfsoptions=
- Specifies additional options to be passed to the command which creates the new file system specified in--reformat=
. The list of options provided here is not processed, so they must be specified in a format that can be passed directly to themkfs
program. The list of options should be either comma-separated or surrounded by double quotes, depending on the file system. See themkfs
man page for the file system you want to create (for examplemkfs.ext4(8)
ormkfs.xfs(8)
) for specific details. -
--mountoptions=
- Specifies a free form string that contains options to be used when mounting the file system. The string will be copied to the/etc/fstab
file on the installed system and should be enclosed in double quotes. See themount(8)
man page for a full list of mount options, andfstab(5)
for basics.
Notes
-
Unlike most other storage configuration commands in Kickstart,
mount
does not require you to describe the entire storage configuration in the Kickstart file. You only need to ensure that the described block device exists on the system. However, if you want to create the storage stack with all the devices mounted, you must use other commands such aspart
to do so. -
You can not use
mount
together with other storage-related commands such aspart
,logvol
, orautopart
in the same Kickstart file.
B.5.12. nvdimm
The nvdimm
Kickstart command is optional. It performs an action on Non-Volatile Dual In-line Memory Module (NVDIMM) devices.
Syntax
nvdimm action [OPTIONS]
Actions
reconfigure
- Reconfigure a specific NVDIMM device into a given mode. Additionally, the specified device is implicitly marked as to be used, so a subsequentnvdimm use
command for the same device is redundant. This action uses the following format:nvdimm reconfigure [--namespace=NAMESPACE] [--mode=MODE] [--sectorsize=SECTORSIZE]
--namespace=
- The device specification by namespace. For example:nvdimm reconfigure --namespace=namespace0.0 --mode=sector --sectorsize=512
-
--mode=
- The mode specification. Currently, only the valuesector
is available. --sectorsize=
- Size of a sector for sector mode. For example:nvdimm reconfigure --namespace=namespace0.0 --mode=sector --sectorsize=512
The supported sector sizes are 512 and 4096 bytes.
use
- Specify a NVDIMM device as a target for installation. The device must be already configured to the sector mode by thenvdimm reconfigure
command. This action uses the following format:nvdimm use [--namespace=NAMESPACE|--blockdevs=DEVICES]
--namespace=
- Specifies the device by namespace. For example:nvdimm use --namespace=namespace0.0
--blockdevs=
- Specifies a comma-separated list of block devices corresponding to the NVDIMM devices to be used. The asterisk*
wildcard is supported. For example:nvdimm use --blockdevs=pmem0s,pmem1s
nvdimm use --blockdevs=pmem*
Notes
-
By default, all NVDIMM devices are ignored by the installation program. You must use the
nvdimm
command to enable installation on these devices.
B.5.13. part or partition
The part
or partition
Kickstart command is required. It creates a partition on the system.
Syntax
part|partition mntpoint [OPTIONS]
Options
mntpoint - Where the partition is mounted. The value must be of one of the following forms:
/path
For example,
/
,/usr
,/home
swap
The partition is used as swap space.
To determine the size of the swap partition automatically, use the
--recommended
option:swap --recommended
The size assigned will be effective but not precisely calibrated for your system.
To determine the size of the swap partition automatically but also allow extra space for your system to hibernate, use the
--hibernation
option:swap --hibernation
The size assigned will be equivalent to the swap space assigned by
--recommended
plus the amount of RAM on your system.For the swap sizes assigned by these commands, see Section C.4, “Recommended partitioning scheme” for AMD64, Intel 64, and 64-bit ARM systems.
raid.id
The partition is used for software RAID (see
raid
).pv.id
The partition is used for LVM (see
logvol
).biosboot
The partition will be used for a BIOS Boot partition. A 1 MiB BIOS boot partition is necessary on BIOS-based AMD64 and Intel 64 systems using a GUID Partition Table (GPT); the boot loader will be installed into it. It is not necessary on UEFI systems. See also the
bootloader
command./boot/efi
An EFI System Partition. A 50 MiB EFI partition is necessary on UEFI-based AMD64, Intel 64, and 64-bit ARM; the recommended size is 200 MiB. It is not necessary on BIOS systems. See also the
bootloader
command.
--size=
- The minimum partition size in MiB. Specify an integer value here such as500
(do not include the unit).ImportantIf the
--size
value is too small, the installation fails. Set the--size
value as the minimum amount of space you require. For size recommendations, see Section C.4, “Recommended partitioning scheme”.--grow
- Tells the partition to grow to fill available space (if any), or up to the maximum size setting, if one is specified.NoteIf you use
--grow=
without setting--maxsize=
on a swap partition, Anaconda limits the maximum size of the swap partition. For systems that have less than 2 GiB of physical memory, the imposed limit is twice the amount of physical memory. For systems with more than 2 GiB, the imposed limit is the size of physical memory plus 2GiB.-
--maxsize=
- The maximum partition size in MiB when the partition is set to grow. Specify an integer value here such as500
(do not include the unit). -
--noformat
- Specifies that the partition should not be formatted, for use with the--onpart
command. --onpart=
or--usepart=
- Specifies the device on which to place the partition. Uses an existing blank device and format it to the new specified type. For example:partition /home --onpart=hda1
puts
/home
on/dev/hda1
.These options can also add a partition to a logical volume. For example:
partition pv.1 --onpart=hda2
The device must already exist on the system; the
--onpart
option will not create it.It is also possible to specify an entire drive, rather than a partition, in which case Anaconda will format and use the drive without creating a partition table. Note, however, that installation of GRUB2 is not supported on a device formatted in this way, and must be placed on a drive with a partition table.
partition pv.1 --onpart=hdb
--ondisk=
or--ondrive=
- Creates a partition (specified by thepart
command) on an existing disk.This command always creates a partition. Forces the partition to be created on a particular disk. For example,--ondisk=sdb
puts the partition on the second SCSI disk on the system.To specify a multipath device that does not use logical volume management (LVM), use the format
disk/by-id/dm-uuid-mpath-WWID
, where WWID is the world-wide identifier for the device. For example, to specify a disk with WWID2416CD96995134CA5D787F00A5AA11017
, use:part / --fstype=xfs --grow --asprimary --size=8192 --ondisk=disk/by-id/dm-uuid-mpath-2416CD96995134CA5D787F00A5AA11017
WarningNever 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, thepart
command could target the wrong disk.-
--asprimary
- Forces the partition to be allocated as a primary partition. If the partition cannot be allocated as primary (usually due to too many primary partitions being already allocated), the partitioning process fails. This option only makes sense when the disk uses a Master Boot Record (MBR); for GUID Partition Table (GPT)-labeled disks this option has no meaning. -
--fsprofile=
- Specifies a usage type to be passed to the program that makes a filesystem on this partition. A usage type defines a variety of tuning parameters to be used when making a filesystem. For this option to work, the filesystem must support the concept of usage types and there must be a configuration file that lists valid types. Forext2
,ext3
,ext4
, this configuration file is/etc/mke2fs.conf
. --mkfsoptions=
- Specifies additional parameters to be passed to the program that makes a filesystem on this partition. This is similar to--fsprofile
but works for all filesystems, not just the ones that support the profile concept. No processing is done on the list of arguments, so they must be supplied in a format that can be passed directly to the mkfs program. This means multiple options should be comma-separated or surrounded by double quotes, depending on the filesystem. For example,part /opt/foo1 --size=512 --fstype=ext4 --mkfsoptions="-O ^has_journal,^flex_bg,^metadata_csum"
part /opt/foo2 --size=512 --fstype=xfs --mkfsoptions="-m bigtime=0,finobt=0"
For details, see the man pages of the filesystems you are creating. For example, mkfs.ext4
or mkfs.xfs
.
-
--fstype=
- Sets the file system type for the partition. Valid values arexfs
,ext2
,ext3
,ext4
,swap
,vfat
,efi
andbiosboot
. --fsoptions
- Specifies a free form string of options to be used when mounting the filesystem. This string will be copied into the/etc/fstab
file of the installed system and should be enclosed in quotes.NoteIn the EFI system partition (
/boot/efi
), anaconda hard codes the value and ignores the users specified--fsoptions
values.-
--label=
- assign a label to an individual partition. --recommended
- Determine the size of the partition automatically.For details about the recommended scheme, see Section C.4, “Recommended partitioning scheme” for AMD64, Intel 64, and 64-bit ARM.
ImportantThis option can only be used for partitions which result in a file system such as the
/boot
partition andswap
space. It cannot be used to create LVM physical volumes or RAID members.-
--onbiosdisk
- Forces the partition to be created on a particular disk as discovered by the BIOS. --encrypted
- Specifies that this partition should be encrypted with Linux Unified Key Setup (LUKS), using the passphrase provided in the--passphrase
option. If you do not specify a passphrase, Anaconda uses the default, system-wide passphrase set with theautopart --passphrase
command, or stops the installation and prompts you to provide a passphrase if no default is set.NoteWhen 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=
- Specifies the passphrase to use when encrypting this partition. You must use this option together with the--encrypted
option; by itself it has no effect. -
--cipher=
- Specifies the type of encryption to use if the Anaconda defaultaes-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 eitheraes-xts-plain64
oraes-cbc-essiv:sha256
. -
--escrowcert=URL_of_X.509_certificate
- Store data encryption keys of all encrypted partitions 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 partition. This option is only meaningful if--encrypted
is specified. -
--backuppassphrase
- Add a randomly-generated passphrase to each encrypted partition. 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. -
--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
. -
--resize=
- Resize an existing partition. When using this option, specify the target size (in MiB) using the--size=
option and the target partition using the--onpart=
option.
Notes
-
The
part
command is not mandatory, but you must include eitherpart
,autopart
ormount
in your Kickstart script. -
The
--active
option is deprecated in Red Hat Enterprise Linux 8. - If partitioning fails for any reason, diagnostic messages appear on virtual console 3.
-
All partitions created are formatted as part of the installation process unless
--noformat
and--onpart
are used. The
sdX
(or/dev/sdX
) format does not guarantee consistent device names across reboots, which can complicate the usage of some Kickstart commands. When a command requires a device node name, you can use any item from/dev/disk
as an alternative. For example, instead of using the following device name: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
By using this approach, the command always targets the same storage device. This is especially useful in large storage environments. To explore the available device names on the system, you can use the
ls -lR /dev/disk
command during the interactive installation. For more information about different ways to consistently refer to storage devices, see Overview of persistent naming attributes.-
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.
B.5.14. raid
The raid
Kickstart command is optional. It assembles a software RAID device.
Syntax
raid mntpoint --level=level --device=device-name partitions*
Options
mntpoint - Location where the RAID file system is mounted. If it is
/
, the RAID level must be 1 unless a boot partition (/boot
) is present. If a boot partition is present, the/boot
partition must be level 1 and the root (/
) partition can be any of the available types. The partitions* (which denotes that multiple partitions can be listed) lists the RAID identifiers to add to the RAID array.Important-
On IBM Power Systems, if a RAID device has been prepared and has not been reformatted during the installation, ensure that the RAID metadata version is
0.90
or1.0
if you intend to put the/boot
and PReP partitions on the RAID device. Themdadm
metadata versions1.1
and1.2
are not supported for the/boot
and PReP partitions. -
The
PReP
Boot partitions are not required on PowerNV systems.
-
On IBM Power Systems, if a RAID device has been prepared and has not been reformatted during the installation, ensure that the RAID metadata version is
--level=
- RAID level to use (0, 1, 4, 5, 6, or 10).See Section C.3, “Supported RAID types” for information about various available RAID levels.
--device=
- Name of the RAID device to use - for example,--device=root
.ImportantDo not use
mdraid
names in the form ofmd0
- these names are not guaranteed to be persistent. Instead, use meaningful names such asroot
orswap
. Using meaningful names creates a symbolic link from/dev/md/name
to whichever/dev/mdX
node is assigned to the array.If you have an old (v0.90 metadata) array that you cannot assign a name to, you can specify the array by a filesystem label or UUID. For example,
--device=LABEL=root
or--device=UUID=93348e56-4631-d0f0-6f5b-45c47f570b88
.You can use the UUID of the file system on the RAID device or UUID of the RAID device itself. The UUID of the RAID device should be in the
8-4-4-4-12
format. UUID reported by mdadm is in the8:8:8:8
format which needs to be changed. For example93348e56:4631d0f0:6f5b45c4:7f570b88
should be changed to93348e56-4631-d0f0-6f5b-45c47f570b88
.-
--chunksize=
- Sets the chunk size of a RAID storage in KiB. In certain situations, using a different chunk size than the default (512 Kib
) can improve the performance of the RAID. -
--spares=
- Specifies the number of spare drives allocated for the RAID array. Spare drives are used to rebuild the array in case of drive failure. -
--fsprofile=
- Specifies a usage type to be passed to the program that makes a filesystem on this partition. A usage type defines a variety of tuning parameters to be used when making a filesystem. For this option to work, the filesystem must support the concept of usage types and there must be a configuration file that lists valid types. For ext2, ext3, and ext4, this configuration file is/etc/mke2fs.conf
. -
--fstype=
- Sets the file system type for the RAID array. Valid values arexfs
,ext2
,ext3
,ext4
,swap
, andvfat
. --fsoptions=
- Specifies a free form string of options to be used when mounting the filesystem. This string will be copied into the/etc/fstab
file of the installed system and should be enclosed in quotes.NoteIn the EFI system partition (
/boot/efi
), anaconda hard codes the value and ignores the users specified--fsoptions
values.--mkfsoptions=
- Specifies additional parameters to be passed to the program that makes a filesystem on this partition. No processing is done on the list of arguments, so they must be supplied in a format that can be passed directly to the mkfs program. This means multiple options should be comma-separated or surrounded by double quotes, depending on the filesystem. For example,part /opt/foo1 --size=512 --fstype=ext4 --mkfsoptions="-O ^has_journal,^flex_bg,^metadata_csum"
part /opt/foo2 --size=512 --fstype=xfs --mkfsoptions="-m bigtime=0,finobt=0"
For details, see the man pages of the filesystems you are creating. For example, mkfs.ext4
or mkfs.xfs
.
-
--label=
- Specify the label to give to the filesystem to be made. If the given label is already in use by another filesystem, a new label will be created. -
--noformat
- Use an existing RAID device and do not format the RAID array. -
--useexisting
- Use an existing RAID device and reformat it. --encrypted
- Specifies that this RAID device should be encrypted with Linux Unified Key Setup (LUKS), using the passphrase provided in the--passphrase
option. If you do not specify a passphrase, Anaconda uses the default, system-wide passphrase set with theautopart --passphrase
command, or stops the installation and prompts you to provide a passphrase if no default is set.NoteWhen 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. -
--cipher=
- Specifies the type of encryption to use if the Anaconda defaultaes-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 eitheraes-xts-plain64
oraes-cbc-essiv:sha256
. -
--passphrase=
- Specifies the passphrase to use when encrypting this RAID device. You must use this option together with the--encrypted
option; by itself it has no effect. -
--escrowcert=URL_of_X.509_certificate
- Store the data encryption key for this device in a file in/root
, encrypted using the X.509 certificate from the URL specified with URL_of_X.509_certificate. This option is only meaningful if--encrypted
is specified. -
--backuppassphrase
- Add a randomly-generated passphrase to this device. Store the passphrase in a file in/root
, encrypted using the X.509 certificate specified with--escrowcert
. This option is only meaningful if--escrowcert
is specified. -
--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
.
Example
The following example shows how to create a RAID level 1 partition for /
, and a RAID level 5 for /home
, assuming there are three SCSI disks on the system. It also creates three swap partitions, one on each drive.
part raid.01 --size=6000 --ondisk=sda
part raid.02 --size=6000 --ondisk=sdb
part raid.03 --size=6000 --ondisk=sdc
part swap --size=512 --ondisk=sda
part swap --size=512 --ondisk=sdb
part swap --size=512 --ondisk=sdc
part raid.11 --size=1 --grow --ondisk=sda
part raid.12 --size=1 --grow --ondisk=sdb
part raid.13 --size=1 --grow --ondisk=sdc
raid / --level=1 --device=rhel8-root --label=rhel8-root raid.01 raid.02 raid.03
raid /home --level=5 --device=rhel8-home --label=rhel8-home raid.11 raid.12 raid.13
Notes
-
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.
B.5.15. reqpart
The reqpart
Kickstart command is optional. It automatically creates partitions required by your hardware platform. These include a /boot/efi
partition for systems with UEFI firmware, a biosboot
partition for systems with BIOS firmware and GPT, and a PRePBoot
partition for IBM Power Systems.
Syntax
reqpart [--add-boot]
Options
-
--add-boot
- Creates a separate/boot
partition in addition to the platform-specific partition created by the base command.
Notes
-
This command cannot be used toegether with
autopart
, becauseautopart
does everything thereqpart
command does and, in addition, creates other partitions or logical volumes such as/
andswap
. In contrast withautopart
, this command only creates platform-specific partitions and leaves the rest of the drive empty, allowing you to create a custom layout.
B.5.16. snapshot
The snapshot
Kickstart command is optional. Use it to create LVM thin volume snapshots during the installation process. This enables you to back up a logical volume before or after the installation.
To create multiple snapshots, add the snaphost
Kickstart command multiple times.
Syntax
snapshot vg_name/lv_name --name=snapshot_name --when=pre-install|post-install
Options
-
vg_name/lv_name
- Sets the name of the volume group and logical volume to create the snapshot from. -
--name=snapshot_name
- Sets the name of the snapshot. This name must be unique within the volume group. -
--when=pre-install|post-install
- Sets if the snapshot is created before the installation begins or after the installation is completed.
B.5.17. volgroup
The volgroup
Kickstart command is optional. It creates a Logical Volume Management (LVM) group.
Syntax
volgroup name [OPTIONS] [partition*]
Mandatory options
- name - Name of the new volume group.
Options
- partition - Physical volume partitions to use as backing storage for the volume group.
-
--noformat
- Use an existing volume group and do not format it. --useexisting
- Use an existing volume group and reformat it. If you use this option, do not specify a partition. For example:volgroup rhel00 --useexisting --noformat
-
--pesize=
- Set the size of the volume group’s physical extents in KiB. The default value is 4096 (4 MiB), and the minimum value is 1024 (1 MiB). -
--reserved-space=
- Specify an amount of space to leave unused in a volume group in MiB. Applicable only to newly created volume groups. -
--reserved-percent=
- Specify a percentage of total volume group space to leave unused. Applicable only to newly created volume groups.
Notes
Create the partition first, then create the logical volume group, and then create the logical volume. For example:
part pv.01 --size 10000
volgroup my_volgrp pv.01
logvol / --vgname=my_volgrp --size=2000 --name=root
Do not use the dash (
-
) character in logical volume and volume group names when installing Red Hat Enterprise Linux using Kickstart. If this character is used, the installation finishes normally, but the/dev/mapper/
directory will list these volumes and volume groups with every dash doubled. For example, a volume group namedvolgrp-01
containing a logical volume namedlogvol-01
will be listed as/dev/mapper/volgrp--01-logvol--01
.This limitation only applies to newly created logical volume and volume group names. If you are reusing existing ones using the
--noformat
option, their names will not be changed.
B.5.18. zerombr
The zerombr
Kickstart command is optional. The zerombr
initializes any invalid partition tables that are found on disks and destroys all of the contents of disks with invalid partition tables. This command is required when performing an installation on an 64-bit IBM Z system with unformatted Direct Access Storage Device (DASD) disks, otherwise the unformatted disks are not formatted and used during the installation.
Syntax
zerombr
Notes
-
On 64-bit IBM Z, if
zerombr
is specified, any Direct Access Storage Device (DASD) visible to the installation program which is not already low-level formatted is automatically low-level formatted with dasdfmt. The command also prevents user choice during interactive installations. -
If
zerombr
is not specified and there is at least one unformatted DASD visible to the installation program, a non-interactive Kickstart installation exits unsuccessfully. -
If
zerombr
is not specified and there is at least one unformatted DASD visible to the installation program, an interactive installation exits if the user does not agree to format all visible and unformatted DASDs. To circumvent this, only activate those DASDs that you will use during installation. You can always add more DASDs after installation is complete. - This command has no options.
B.5.19. zfcp
The zfcp
Kickstart command is optional. It defines a Fibre channel device.
This option only applies on 64-bit IBM Z. All of the options described below must be specified.
Syntax
zfcp --devnum=devnum [--wwpn=wwpn --fcplun=lun]
Options
-
--devnum=
- The device number (zFCP adapter device bus ID). -
--wwpn=
- The device’s World Wide Port Name (WWPN). Takes the form of a 16-digit number, preceded by0x
. -
--fcplun=
- The device’s Logical Unit Number (LUN). Takes the form of a 16-digit number, preceded by0x
.
It is sufficient to specify an FCP device bus ID if automatic LUN scanning is available and when installing 8 or later releases. Otherwise all three parameters are required. Automatic LUN scanning is available for FCP devices operating in NPIV mode if it is not disabled through the zfcp.allow_lun_scan
module parameter (enabled by default). It provides access to all SCSI devices found in the storage area network attached to the FCP device with the specified bus ID.
Example
zfcp --devnum=0.0.4000 --wwpn=0x5005076300C213e9 --fcplun=0x5022000000000000
zfcp --devnum=0.0.4000
B.6. Kickstart commands for addons supplied with the RHEL installation program
The Kickstart commands in this section are related to add-ons supplied by default with the Red Hat Enterprise Linux installation program: Kdump and OpenSCAP.
B.6.1. %addon com_redhat_kdump
The %addon com_redhat_kdump
Kickstart command is optional. This command configures the kdump kernel crash dumping mechanism.
Syntax
%addon com_redhat_kdump [OPTIONS]
%end
The syntax for this command is unusual because it is an add-on rather than a built-in Kickstart command.
Notes
Kdump is a kernel crash dumping mechanism that allows you to save the contents of the system’s memory for later analysis. It relies on kexec
, which can be used to boot a Linux kernel from the context of another kernel without rebooting the system, and preserve the contents of the first kernel’s memory that would otherwise be lost.
In case of a system crash, kexec
boots into a second kernel (a capture kernel). This capture kernel resides in a reserved part of the system memory. Kdump then captures the contents of the crashed kernel’s memory (a crash dump) and saves it to a specified location. The location cannot be configured using this Kickstart command; it must be configured after the installation by editing the /etc/kdump.conf
configuration file.
For more information about Kdump, see the Installing kdump chapter of the Managing, monitoring and updating the kernel document.
Options
-
--enable
- Enable kdump on the installed system. -
--disable
- Disable kdump on the installed system. --reserve-mb=
- The amount of memory you want to reserve for kdump, in MiB. For example:%addon com_redhat_kdump --enable --reserve-mb=128
%end
You can also specify
auto
instead of a numeric value. In that case, the installation program will determine the amount of memory automatically based on the criteria described in the Memory requirements for kdump section of the Managing, monitoring and updating the kernel document.If you enable kdump and do not specify a
--reserve-mb=
option, the valueauto
will be used.-
--enablefadump
- Enable firmware-assisted dumping on systems which allow it (notably, IBM Power Systems servers).
B.6.2. %addon org_fedora_oscap
The %addon org_fedora_oscap
Kickstart command is optional.
The OpenSCAP installation program add-on is used to apply SCAP (Security Content Automation Protocol) content - security policies - on the installed system. This add-on has been enabled by default since Red Hat Enterprise Linux 7.2. When enabled, the packages necessary to provide this functionality will automatically be installed. However, by default, no policies are enforced, meaning that no checks are performed during or after installation unless specifically configured.
Applying a security policy is not necessary on all systems. This command should only be used when a specific policy is mandated by your organization rules or government regulations.
Unlike most other commands, this add-on does not accept regular options, but uses key-value pairs in the body of the %addon
definition instead. These pairs are whitespace-agnostic. Values can be optionally enclosed in single quotes ('
) or double quotes ("
).
Syntax
%addon org_fedora_oscap
key = value%end
Keys
The following keys are recognized by the add-on:
content-type
Type of the security content. Possible values are
datastream
,archive
,rpm
, andscap-security-guide
.If the
content-type
isscap-security-guide
, the add-on will use content provided by the scap-security-guide package, which is present on the boot media. This means that all other keys exceptprofile
will have no effect.content-url
- Location of the security content. The content must be accessible using HTTP, HTTPS, or FTP; local storage is currently not supported. A network connection must be available to reach content definitions in a remote location.
datastream-id
-
ID of the data stream referenced in the
content-url
value. Used only ifcontent-type
isdatastream
. xccdf-id
- ID of the benchmark you want to use.
content-path
- Path to the datastream or the XCCDF file which should be used, given as a relative path in the archive.
profile
-
ID of the profile to be applied. Use
default
to apply the default profile. fingerprint
-
A MD5, SHA1 or SHA2 checksum of the content referenced by
content-url
. tailoring-path
- Path to a tailoring file which should be used, given as a relative path in the archive.
Examples
The following is an example
%addon org_fedora_oscap
section which uses content from the scap-security-guide on the installation media:Example B.1. Sample OpenSCAP Add-on Definition Using SCAP Security Guide
%addon org_fedora_oscap
content-type = scap-security-guide profile = xccdf_org.ssgproject.content_profile_pci-dss%end
The following is a more complex example which loads a custom profile from a web server:
Example B.2. Sample OpenSCAP Add-on Definition Using a Datastream
%addon org_fedora_oscap
content-type = datastream content-url = http://www.example.com/scap/testing_ds.xml datastream-id = scap_example.com_datastream_testing xccdf-id = scap_example.com_cref_xccdf.xml profile = xccdf_example.com_profile_my_profile fingerprint = 240f2f18222faa98856c3b4fc50c4195%end
Additional resources
B.7. Commands used in Anaconda
The pwpolicy
command is an Anaconda UI specific command that can be used only in the %anaconda
section of the kickstart file.
B.7.1. pwpolicy
The pwpolicy
Kickstart command is optional. Use this command to enforce a custom password policy during installation. The policy requires you to create passwords for the root, users, or the luks user accounts. The factors such as password length and strength decide the validity of a password.
Syntax
pwpolicy name [--minlen=length] [--minquality=quality] [--strict|--notstrict] [--emptyok|--notempty] [--changesok|--nochanges]
Mandatory options
-
name - Replace with either
root
,user
orluks
to enforce the policy for theroot
password, user passwords, or LUKS passphrase, respectively.
Optional options
-
--minlen=
- Sets the minimum allowed password length, in characters. The default is6
. -
--minquality=
- Sets the minimum allowed password quality as defined by thelibpwquality
library. The default value is1
. -
--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
-
The
pwpolicy
command is an Anaconda-UI specific command that can be used only in the%anaconda
section of the kickstart file. -
The
libpwquality
library is used to check minimum password requirements (length and quality). You can use thepwscore
andpwmake
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 thepwscore(1)
andpwmake(1)
man page for details about these commands.
B.8. Kickstart commands for system recovery
The Kickstart command in this section repairs an installed system.
B.8.1. rescue
The rescue
Kickstart command is optional. It provides a shell environment with root privileges and a set of system management tools to repair the installation and to troubleshoot the issues like:
- Mount file systems as read-only
- Blocklist or add a driver provided on a driver disc
- Install or upgrade system packages
- Manage partitions
The Kickstart rescue mode is different from the rescue mode and emergency mode, which are provided as part of the systemd and service manager.
The rescue
command does not modify the system on its own. It only sets up the rescue environment by mounting the system under /mnt/sysimage in a read-write mode. You can choose not to mount the system, or to mount it in read-only mode.
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.
Notes
To run a rescue mode, make a copy of the Kickstart file, and include the rescue
command in it.
Using the rescue
command causes the installer to perform the following steps:
-
Run the
%pre
script. Set up environment for rescue mode.
The following kickstart commands take effect:
- updates
- sshpw
- logging
- lang
- network
Set up advanced storage environment.
The following kickstart commands take effect:
- fcoe
- iscsi
- iscsiname
- nvdimm
- zfcp
Mount the system
rescue [--nomount|--romount]
Run %post script
This step is run only if the installed system is mounted in read-write mode.
- Start shell
- Reboot system
Appendix C. Partitioning reference
C.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 theBIOS Boot
andEFI 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. 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.
The installation program does not support overprovisioned LVM thin pools.
C.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. The XFS filesystem cannot be shrunk to get free space. - ext4
-
The
ext4
file system is based on theext3
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 singleext4
file system is 50 TB. - ext3
-
The
ext3
file system is based on theext2
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.NoteSupport for
VFAT
file system is not available for Linux system partitions. For example,/
,/var
,/usr
and so on.- 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.
C.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 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.
- RAID 0
- 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.
- RAID 1
- 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.
- RAID 4
- 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.
- RAID 5
- 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.
- RAID 6
- 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.
- RAID 10
- 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.
C.4. Recommended partitioning scheme
Red Hat recommends that you create separate file systems at the following mount points. However, if required, you can also create the file systems at /usr
, /var
, and /tmp
mount points.
-
/boot
-
/
(root) -
/home
-
swap
-
/boot/efi
-
PReP
This partition scheme is recommended for bare metal deployments and it does not apply to virtual and cloud deployments.
/boot
partition - recommended size at least 1 GiBThe partition mounted on
/boot
contains the operating system kernel, which allows your system to boot Red Hat Enterprise Linux 8, along with files used during the bootstrap process. Due to the limitations of most firmwares, creating a small partition to hold these is recommended. In most scenarios, a 1 GiB boot partition is adequate. Unlike other mount points, using an LVM volume for/boot
is not possible -/boot
must be located on a separate disk partition.WarningNormally, the
/boot
partition is created automatically by the installation program. However, if the/
(root) partition is larger than 2 TiB and (U)EFI is used for booting, you need to create a separate/boot
partition that is smaller than 2 TiB to boot the machine successfully.NoteIf you have a RAID card, be aware that some BIOS types do not support booting from the RAID card. In such a case, the
/boot
partition must be created on a partition outside of the RAID array, such as on a separate hard drive.root
- recommended size of 10 GiBThis is where "
/
", or the root directory, is located. The root directory is the top-level of the directory structure. By default, all files are written to this file system unless a different file system is mounted in the path being written to, for example,/boot
or/home
.While a 5 GiB root file system allows you to install a minimal installation, it is recommended to allocate at least 10 GiB so that you can install as many package groups as you want.
ImportantDo not confuse the
/
directory with the/root
directory. The/root
directory is the home directory of the root user. The/root
directory is sometimes referred to as slash root to distinguish it from the root directory./home
- recommended size at least 1 GiB-
To store user data separately from system data, create a dedicated file system for the
/home
directory. Base the file system size on the amount of data that is stored locally, number of users, and so on. You can upgrade or reinstall Red Hat Enterprise Linux 8 without erasing user data files. If you select automatic partitioning, it is recommended to have at least 55 GiB of disk space available for the installation, to ensure that the/home
file system is created. swap
partition - recommended size at least 1 GiBSwap file systems support virtual memory; data is written to a swap file system when there is not enough RAM to store the data your system is processing. Swap size is a function of system memory workload, not total system memory and therefore is not equal to the total system memory size. It is important to analyze what applications a system will be running and the load those applications will serve in order to determine the system memory workload. Application providers and developers can provide guidance.
When the system runs out of swap space, the kernel terminates processes as the system RAM memory is exhausted. Configuring too much swap space results in storage devices being allocated but idle and is a poor use of resources. Too much swap space can also hide memory leaks. The maximum size for a swap partition and other additional information can be found in the
mkswap(8)
manual page.The following table provides the recommended size of a swap partition depending on the amount of RAM in your system and if you want sufficient memory for your system to hibernate. If you let the installation program partition your system automatically, the swap partition size is established using these guidelines. Automatic partitioning setup assumes hibernation is not in use. The maximum size of the swap partition is limited to 10 percent of the total size of the hard drive, and the installation program cannot create swap partitions more than 1TiB. To set up enough swap space to allow for hibernation, or if you want to set the swap partition size to more than 10 percent of the system’s storage space, or more than 1TiB, you must edit the partitioning layout manually.
Table C.1. Recommended system swap space
Amount of RAM in the system | Recommended swap space | Recommended swap space if allowing for hibernation |
---|---|---|
Less than 2 GiB | 2 times the amount of RAM | 3 times the amount of RAM |
2 GiB - 8 GiB | Equal to the amount of RAM | 2 times the amount of RAM |
8 GiB - 64 GiB | 4 GiB to 0.5 times the amount of RAM | 1.5 times the amount of RAM |
More than 64 GiB | Workload dependent (at least 4GiB) | Hibernation not recommended |
/boot/efi
partition - recommended size of 200 MiB- UEFI-based AMD64, Intel 64, and 64-bit ARM require a 200 MiB EFI system partition. The recommended minimum size is 200 MiB, the default size is 600 MiB, and the maximum size is 600 MiB. BIOS systems do not require an EFI system partition.
At the border between each range, for example, a system with 2 GiB, 8 GiB, or 64 GiB of system RAM, discretion can be exercised with regard to chosen swap space and hibernation support. If your system resources allow for it, increasing the swap space can lead to better performance.
Distributing swap space over multiple storage devices - particularly on systems with fast drives, controllers and interfaces - also improves swap space performance.
Many systems have more partitions and volumes than the minimum required. Choose partitions based on your particular system needs.
- Only assign storage capacity to those partitions you require immediately. You can allocate free space at any time, to meet needs as they occur.
- If you are unsure about how to configure partitions, accept the automatic default partition layout provided by the installation program.
PReP
boot partition - recommended size of 4 to 8 MiB-
When installing Red Hat Enterprise Linux on IBM Power System servers, the first partition of the hard drive should include a
PReP
boot partition. This contains the GRUB2 boot loader, which allows other IBM Power Systems servers to boot Red Hat Enterprise Linux.
C.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 aMySQL
database, having a separate mount point for/var/lib/mysql
allows you to preserve the database during a re-installation without having to restore it from backup afterward. 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 for information about various system directories and their contents.
- Each kernel requires approximately: 60MiB (initrd 34MiB, 11MiB vmlinuz, and 5MiB System.map)
- For rescue mode: 100MiB (initrd 76MiB, 11MiB vmlinuz, and 5MiB System map)
When
kdump
is enabled in system it will take approximately another 40MiB (another initrd with 33MiB)The default partition size of 1 GiB for
/boot
should suffice for most common use cases. However, it is recommended that you increase the size of this partition if you are planning on retaining multiple kernel releases or errata kernels.-
The
/var
directory holds content for a number of applications, including the Apache web server, and is used by the YUM package manager to temporarily store downloaded package updates. Make sure that the partition or volume containing/var
has at least 5 GiB. -
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 GiB for minimal installations, and at least 10 GiB 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 aDevice is busy
error when powering off or rebooting.This limitation only applies to
/usr
or/var
, not to directories under them. For example, a separate partition for/var/www
works without issues.ImportantSome security policies require the separation of
/usr
and/var
, even though it makes administration more complex.-
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 cannot 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 plan to alter 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. Note that you cannot create a BIOS Boot or EFI System Partition in graphical installation if your system does not require one - in that case, they are 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
.
Additional resources
C.6. Supported hardware storage
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.
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.
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. 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.