Automating the Installation with Kickstart
Kickstart installations offer a means to automate the installation process, either partially or fully. Kickstart files contain answers to all questions normally asked by the installation program, such as what time zone do you want the system to use, how should the drives be partitioned or which packages should be installed. Providing a prepared Kickstart file when the installation begins therefore allows the you to perform the installation automatically, without need for any intervention from the user. This is especially useful when deploying Fedora on a large number of systems at once.
All Kickstart scripts and the log files of their execution are stored in the
/tmp directory to assist with debugging installation issues.
How to Perform a Kickstart Installation
Kickstart installations can be performed using a local DVD, a local hard drive, or via NFS, FTP, HTTP, or HTTPS.
To use Kickstart, you must:
Create a Kickstart file.
Create boot media or configure a network boot (PXE) server which will be used to begin the installation. Note that live media can not be used for Kickstart installations - use installation media that can boot directly into the installer, such as the standard or netinstall ISO image from the Server edition.
Make the Kickstart file available on removable media, a hard drive, or a network location.
Start the Kickstart installation by booting the installer and using a boot option to tell the installer where to find the Kickstart file.
This chapter explains these steps in detail.
Creating a Kickstart File
The Kickstart file itself is a plain text file, containing keywords listed in Kickstart Syntax Reference, 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 recommended approach to creating Kickstart files is to perform a manual installation on one system first. After the installation completes, all choices made during the installation are saved into a file named
anaconda-ks.cfg, located in the
/root/ directory on the installed system. You can then copy this file, make any changes you need, and use the resulting configuration file in further installations.
When creating a Kickstart file, keep in mind the following:
Lines starting with a pound sign (
#) are treated as comments and are ignored.
Sections must be specified in order. Items within the sections do not have to be in a specific order unless otherwise specified. The correct section order is:
The command section which contains actual Kickstart commands and options as listed in Kickstart Syntax Reference. Note that some commands, such as install, are mandatory, but most commands are optional.
The %packages section which contains a list of packages and package groups to be installed. See %packages (required) - Package Selection for details.
The %pre and %post sections, containing a pre-installation and post-installation scripts. These two sections can be in any order and are not mandatory. See %pre (optional) - Pre-installation Script and %post (optional) - Post-installation Script for details.
The %packages, %pre and %post sections must end with %end, otherwise the installation program will refuse the Kickstart file. The main command section has no special ending statement.
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 will continue. Note that if the system you are installing has no display, you will not be able to see the prompt, and the installation will appear to have failed.
Verifying the Kickstart File
When creating or customizing your kickstart file, it is useful to verify that it is valid before attempting to use it in an installation. Fedora includes the ksvalidator command line utility which can be used to do this. This tool is a part of the pykickstart package. To install this package, execute the following command:
# dnf install pykickstart
After installing the package, you can validate a Kickstart file using the following command:
$ ksvalidator /path/to/kickstart.ks
Replace /path/to/kickstart.ks with the path to the Kickstart file you want to verify.
For more information about this tool, see the
ksvalidator(1) man page.
Keep in mind that the validation tool has its limitations. The Kickstart file can be very complicated; ksvalidator can make sure the syntax is correct and that the file does not include removed options, but it cannot guarantee the installation will be successful. It also does not attempt to validate the %pre, %post and %packages sections of the Kickstart file.
Making the Kickstart File Available
Once you create a Kickstart file, you can place it in one of the following locations:
On removable media, such as a DVD or USB flash drive connected to the installation system
On a hard drive connected to the installation system
On a network share reachable from the installation system
Normally, a Kickstart file is copied to removable media or a hard drive, or made available on the network. Placing the file in a network location complements the usual approach to Kickstart installations, which is also network-based: the system is booted using a PXE server, the Kickstart file is downloaded from a network share, and software packages specified in the file are downloaded from remote repositories.
Setting Up an Installation Server offers some additional information about preparing for a network-based installation.
Starting the Kickstart Installation
Once you have everything ready - you have created a valid Kickstart file and you have either local boot media or a PXE server available, you can start the Kickstart installation. You need to use the inst.ks= boot option either in the boot menu (when booting from local media), or add this option to your PXE server configuration. For information about boot options used in Kickstart installations, see Kickstart Boot Options.
Want to help? Learn how to contribute to Fedora Docs ›