26.2. How Do You Perform a Kickstart Installation?
- Create a Kickstart file.
- Make the Kickstart file available on removable media, a hard drive or a network location.
- Create boot media, which will be used to begin the installation.
- Make the installation source available.
- Start the Kickstart installation.
26.2.1. Creating a Kickstart File
anaconda-ks.cfg, located in the /root/ directory on the installed system. You can then copy this file, make any changes you need, and use the resulting configuration file in further installations.
Important
- Sections must be specified in order. Items within the sections do not have to be in a specific order unless otherwise specified. The section order is:
- Command section - See Section 26.3.1, “Kickstart Commands and Options” for a list of Kickstart options. You must include the required options.Add-ons for Anaconda which expand the functionality of the installer can also be used in the command section by using the
%addon addon_namecommand. See Section 26.3.7, “Kickstart Add-ons” for details. - The
%packagessection - See Section 26.3.2, “Package Selection” for details. - The
%preand%postsections, and the%onerrorsection - these sections can be in any order and are not required. See Section 26.3.3, “Pre-installation Script”, Section 26.3.5, “Post-installation Script” and Section 26.3.6, “Kickstart error handling” for details.
Important
Sections%addon,%packages,%onerror,%preand%postmust end with%end, otherwise the installation program will refuse the Kickstart file. - Items that are not required can be omitted.
- Omitting any required item results in the installation program prompting the user for an answer to the related item, just as the user would be prompted during a typical installation. Once the answer is given, the installation continues unattended (unless it finds another missing item).
- Lines starting with a pound (also known as number) sign (
#) are treated as comments and are ignored.
26.2.2. Maintaining the Kickstart File
26.2.2.1. Verifying the Kickstart File
root:
#yum install pykickstart
$ksvalidator /path/to/kickstart.ks
ksvalidator(1) man page.
Important
%pre, %post and %packages sections of the Kickstart file.
26.2.2.2. Changes in Kickstart Syntax
ksverdiff command to display the differences between two versions of the Kickstart syntax. This is useful when updating an existing Kickstart file to be used with a new release. To display a list of changes in syntax between Red Hat Enterprise Linux 6 and 7, use the following command:
$ksverdiff -f RHEL6 -t RHEL7
-f option specifies the release to start the comparison with, and the -t option to specify the release to end with. For additional information, see the ksverdiff(1) man page.
26.2.3. Making the Kickstart File Available
- On removable media, such as a DVD or USB flash drive
- On a hard drive connected to the installation system
- On a network share reachable from the installation system
26.2.4. Making the Installation Source Available
26.2.5. Starting the Kickstart Installation
Note
inst.ks= boot option, name the file ks.cfg and place it on a storage volume labeled OEMDRV.
inst.ks=location when booting the installation system, replacing location with the location of your Kickstart file. The exact way to specify the boot option depends on your system's architecture - see Chapter 22, Boot Options for details.
26.2.5.1. Starting the Kickstart Installation Manually
boot: prompt) will be required.
Procedure 26.1. Starting the Kickstart Installation Using a Boot Option
- Boot the system using either local media (a CD, DVD, or a USB flash drive). For architecture-specific instructions, see:
- Chapter 7, Booting the Installation on 64-bit AMD, Intel, and ARM systems for 64-bit AMD, Intel, and ARM systems
- Chapter 12, Booting the Installation on IBM Power Systems for IBM Power Systems servers
- At the boot prompt, specify the
inst.ks=boot option and the location of the Kickstart file. If the Kickstart file is in a network location, you must also configure the network using theip=option. In some cases, theinst.repo=option is also necessary in order to access a software source from which necessary packages will be installed.For details about boot options and valid syntax, see Chapter 22, Boot Options. - Start the installation by confirming your added boot options.
26.2.5.2. Starting the Kickstart Installation Automatically
Note
Procedure 26.2. Starting the Kickstart Installation by Editing Boot Loader Configuration
- 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
defaultor based on your system's IP address. In this case, add theinst.ks=option to theappendline in the installation entry. A sampleappendline in the configuration file looks similar to the following:append initrd=initrd.img inst.ks=http://10.32.5.1/mnt/archive/RHEL-7/7.x/Server/x86_64/kickstarts/ks.cfg
- On systems using the GRUB2 boot loader (64-bit AMD, Intel, and 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 thekernelline in the installation entry. A samplekernelline in the configuration file will look similar to the following:kernel vmlinuz inst.ks=http://10.32.5.1/mnt/archive/RHEL-7/7.x/Server/x86_64/kickstarts/ks.cfg
- Boot the installation from the network server. For architecture-specific instructions, see:
- Section 7.1.2, “Booting from the Network Using PXE” for 64-bit AMD, Intel, and ARM systems
- Section 12.3, “Booting from the Network Using an Installation Server” for IBM Power Systems servers

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.