oreilly.comSafari Books Online.Conferences.


Hands-Off Fedora Installs with Kickstart

by Q Ethan McCallum

Editor's note: Ethan has collected this series and other information into Managing RPM-Based Systems with Kickstart and Yum. This series continues in Advanced Linux Installations and Upgrades with Kickstart and Pre-patched Kickstart Installs.

If you've installed Red Hat's Fedora OS, you've likely noticed the Anaconda installer's polished and friendly user interface. It's certainly helpful, but I still don't want to click through it every time I (re)build a machine. Kickstart's automated installs give my mousing finger a rest.

Kickstart isn't only for large server farms. Someone building a couple of oft-recycled machines, such as in a lab environment, can benefit from fast, consistent, unattended OS installs. Additionally, people who are just experimenting with Linux can rely on Kickstart as a way to start fresh when their tinkering goes awry.

In this article, I'll explain how to set up a basic Kickstart environment and perform an install. I tested this process extensively on Fedora Core 1 and briefly on FC2. It may work for Red Hat 9, as well.

Before You Start

A Kickstart install involves three participants: a target machine uses a config file to set system parameters and determine what RPMs to pull from the installation media. (The config file may have any name; this article will refer to it as ks.cfg.)

There are several ways to connect those pieces: the target machine can fetch the RPMs from a local disk, NFS server, FTP server, and so on. The config file can come from the aforementioned places or from the boot media, and it may exist in a different place than the installation media.

Related Reading

Learning Red Hat Enterprise Linux & Fedora
By Bill McCarty

Such flexibility makes it difficult to explain a "typical" Kickstart process in detail. This article demonstrates just one method, using a web server to host the install media and config file. This is likely the easiest and least intrusive method to experiment with Kickstart. It should also scale as your Kickstart experiment matures into a formal infrastructure.

To that end, the setup described in this article requires:

  • The Fedora install files, which you'll copy to the web server's file system.
  • A target machine on which you will install Fedora. Using virtual hardware, such as VMware or Bochs, will simplify your experiment.
  • Bootable media that matches the version of Fedora you plan to install. Choose from install CD 1, diskettes (images/bootdisk.img and images/drvnet.img from the install media), or a bootable CD made from images/boot.iso.
  • A source machine to host the install files and Kickstart config, and run the web server.

Some of these require additional explanation and I'll describe them in turn.

The Source Machine: Setting up the Install Tree

The target machine will fetch its install files and ks.cfg from a web server running on the source machine. The source machine needn't run Linux, but it must have roughly 2.2G disk space available. The web server must listen on port 80 due to a limitation in Kickstart's HTTP code.

Create a directory FC1-install under the document root and populate it with the Fedora directory from the install media. Use your preferred download tool (say, wget) to grab the tree from a Fedora mirror site or copy the contents from the install CDs or ISOs. Be sure to maintain the directory structure in this latter case. There are myriad ways to do this, such as:

$ cd /mnt/cdrom
$ cp -a Fedora /...docroot.../FC1-install

Finally, create a subdirectory kickstart under the doc root to host the Kickstart config files.

Creating the Kickstart Config File, ks.cfg

ks.cfg makes unattended installs possible. It holds canned responses to the questions posed during an interactive install. The examples assume you've saved this file under the web server's document root as kickstart/ks.cfg.

There are several ways to create ks.cfg. (I did warn you that Kickstart was flexible.) If you're plotting a clone farm, build one machine to your specs and use /root/anaconda-ks.cfg on that host as a starting point for the others.

Barring that, use the redhat-config-kickstart GUI (from the redhat-config-kickstart package). This tool doesn't support LVM for disk layout, but is a valuable learning tool nonetheless. You can hand-edit the generated ks.cfg to use LVM (described below).

You can also create or edit ks.cfg using any text editor, provided you know the directives. Here's a walk through the directives in the sample ks.cfg.

You probably already have the redhat-config-language, hwdata, and tzdata RPMs installed already. They are not required, but include files that simplify hand-editing ks.cfg.

Installation Type

The first entries are the installation type and source.

url --url http://kickstart-server/FC1-install

The type may be install or upgrade. The url directive specifies an HTTP installation and indicates the URL of the install media. (The directory Fedora, from the install media, must be a subdirectory of the URI part of the URL.) Other installation sources include cdrom for swapping CDs or DVDs, nfs for mounting the install media from an NFS share, and the self-explanatory ftp.

Languages and Input

lang and mouse indicate the language and mouse type, respectively, to use during the installation.

lang en_US.UTF-8
mouse generic3ps/2

The sample ks.cfg uses U.S. English with the Unicode (UTF-8) character set, and a generic PS2 mouse with three buttons.

Refer to /usr/share/redhat-config-language/locale-list for the list of valid languages.

The values of lang and mouse don't matter for unattended installations.

langsupport and keyboard set the runtime (installed) language support and keyboard type, respectively.

langsupport --default en_US.UTF-8 en_US.UTF-8
keyboard us

Specify a single language (en_US) or multiple languages with a default (--default en_US en_UK). Specifying just the default (--default en_US) installs support for all languages.


For a workstation build you'll likely want to configure your video card and monitor, using xconfig.

xconfig --card "VMWare" --videoram 16384 --hsync 31.5-37.9
        --vsync 50-70 --resolution 800x600 --depth 16

(We've split the above line for readability; it should be a single line in ks.cfg..)

xconfig takes the card's name (listed in /usr/share/hwdata/Cards) and video RAM in kilobytes. The remaining parameters specify the monitor's horizontal and vertical sync rates, resolution, and color depth in bits.

Use the skipx directive to skip this step (say, for headless servers). You can manually configure X later.


The network directive sets the target host's runtime network configuration. This may be different than the build-time IP. For example, you may use separate networks to build (DHCP-enabled) and deploy machines (static IPs).

network --device eth0 --bootproto static --ip
        --netmask --gateway
        --hostname fc1-test

This line configures the interface eth0 with a static IP address of Notice that the nameserver selection accepts a comma-separated list of IP addresses.

Configure other interfaces by specifying different devices with --device. You needn't supply any network information when --bootproto is dhcp or bootp.

The network configuration will differ for each host in a clone farm, so you can't use the same file for the entire group. I'll present ideas on how to handle this situation in a future article.

Authentication and Security

Set the root password with the rootpw directive.

rootpw --iscrypted $1$NaCl$X5jRlREy9DqNTCXjHp075/

The --iscrypted flag indicates an MD5-hashed password. You can find a password's encrypted form any number of ways, such as copying an existing entry from /etc/shadow or using OpenSSL's passwd module:

$ openssl passwd -1 -salt "NaCl" "don't use this"

Without the --iscrypted flag the specified password will be used as-is, such as:

rootpw plain_text

On the subject of passwords, authconfig determines how to authenticate users. The following line sets the target host to use MD5-hashed passwords from the local /etc/passwd and /etc/shadow files:

authconfig --enableshadow --enablemd5

There are other authentication options, such as NIS, LDAP, or Kerberos 5.

The firewall directive sets up a rudimentary ruleset, useful for a machine that will talk to the outside world:

firewall --enabled --trust=eth0 --http --ssh

Here, traffic from interface eth0 will be implicitly trusted. The firewall will permit incoming SSH (port 22/tcp) and HTTP (80/tcp) traffic on all interfaces.

Specify firewall --disabled to manually configure the firewall later or to skip it altogether.

Pages: 1, 2

Next Pagearrow

Sponsored by: