Kickstart Instructions by ashrafp



Hands-Off Fedora Installs with Kickstart
by Ethan McCallum

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.

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

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

GED                                                                                             Page 1 of 8

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

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

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

Installation Type

The first entries are the installation type and source.

GED                                                                                           Page 2 of 8

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

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


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

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.

GED                                                                                          Page 3 of 8

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

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.

GED                                                                                              Page 4 of 8

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

Time Zone

Set the machine's time zone with the timezone directive:

timezone America/Chicago

Valid time zones are in the TZ column of the file /usr/share/zoneinfo/

Boot Loader

The bootloader directive sets the location of the GRUB boot loader. The sample ks.cfg
places it in the master boot record (MBR):

bootloader --location=mbr

If you don't want a boot loader, specify --location=none. Remove an old boot loader
from the MBR with the separate zerombr directive.


Disk setup is the most complex part of a ks.cfg because there are so many machine- and
environment-dependent choices. Note that the sample ks.cfg clears existing partitions on
the target machine, so be sure to backup any valuable data.

clearpart     removes disk partitions.

clearpart --all --drives=sda --initlabel

clearpart   can remove just Linux partitions (--linux) or all existing partitions (--all).
It removes partitions from all drives unless you've added the --drives flag. The --
initlabel flag works for previously unused disks or disks with foreign partition
schemes: it clears out the old partitions and sets up a scheme that Linux can understand.

Omit clearpart to preserve existing partition boundaries.

GED                                                                                          Page 5 of 8

part sets up partitions. The sample ks.cfg uses a simple two-partition layout and has a
separate swap partition:

part /boot --fstype ext3 --size=100 --ondisk=sda --asprimary
part / --fstype ext3 --size=1024 --grow --ondisk=sda --asprimary
part swap --size=128 --grow --size=256 --ondisk=sda --asprimary

The first parameter specifies the mount point, here /boot, /, and swap. (Linux doesn't
really mount swap space, but that's a minor technicality.) Set the file-system type with the
--fstype flag. The sample uses ext3. Other options include ext2 and vfat (aka
Windows). Swap doesn't use a file-system type.

Specify a partition's size in megabytes using the --size flag. Specify the partition's
physical disk with the optional --ondisk flag. Mark your primary partitions with --

part's --onpart   and --noformat flags preserve existing partitions between Kickstart
installs. For example, the following would mount the preexisting hda7 as /home:

part /home --fstype ext3 --size 1024 --onpart hda7 --noformat

Note that this won't shuffle data to another part of the disk if other partition sizes change;
it simply tells Kickstart to leave hda7's partition boundaries intact and to skip creating a
new file system there using mkfs.

The following is a simple one-disk LVM setup:

part /boot --fstype ext3 --size=75 --asprimary
part pv.00 --size=1 --grow --asprimary

volgroup vgroot pv.00
logvol / --name=root.fs --vgname=vgroot --size=1024
logvol swap --name=swap.vol --vgname=vgroot --size=256

The second part directive sets up a partition as an LVM physical volume (PV). The --
grow flag grows this partition to the maximum allowable size, so that you needn't know
the disk's size ahead of time. part still requires a size, though, so it uses a bogus PV
partition size of 1MB.

logvol   is LVM's part equivalent: it accepts the logical volume's mount point and size,
in addition to the volume group to which it belongs. logvol's --name flag names the

Note that the generated /root/anaconda-ks.cfg on the target host has a commented-out
disk layout.


GED                                                                                              Page 6 of 8

The reboot directive forces the target host to reboot when the installation completes.
Don't forget to remove the installation media, lest the machine reboot right back into the

Package Selection

The %packages directive specifies which RPMs to install on the target host. You may
select packages individually or en masse as groups. To specify a group, prefix the name
with the @ symbol and a space. Precede a name with a minus symbol (-) to exclude that
package from the group.

@ dialup

The Fedora/base/comps.xml file, from the install media, defines package groups. I'll
describe this file in greater detail in a future article.

Kickstart installs packages in addition to those you select in order to resolve
dependencies. Use %packages's --ignoredeps flag to ignore package dependencies.

Package selection is another area in which it is easiest to perform a manual installation
once, then mine the resultant /root/anaconda-ks.cfg file for information.

Build the Target Machine: Run the Kickstart

The hard work is done. Now boot the target machine from the Fedora media. At the
boot: prompt, enter:

linux ks=http://build-server/kickstart/ks.cfg

You will receive an error if the boot media does not match the version of Fedora you're
trying to install.

Unless you have DHCP available on the target machine's network, the installation will
pause for you to enter its IP configuration. This is fine for small deployments and
experiments, but a full, hands-off Kickstart infrastructure calls for DHCP or bootp.

The installation will also pause for input if any required directives are missing from

Troubleshooting a Failed Install

The installer's error reporting can be cryptic. Messages refer to lines in Anaconda's
underlying Python scripts, not your ks.cfg.

GED                                                                                          Page 7 of 8

Include the interactive directive to step through the installation using values from
ks.cfg as the defaults. You cannot test the root password this way, though; you must enter
that manually.

Going Beyond

My Kickstart R&D has certainly paid off: I no longer have to click through the full
Fedora installer and I can grab a tea while Kickstart does the hard work. Hopefully, this
article will help jump-start your own Kickstart projects.

There is a lot more to Kickstart than what I have described here. It supports several
customization points, including home-grown RPMs and pre-/post-install scripts. I'll cover
these and more in a future article.


      Sample ks.cfg
      If you've installed redhat-config-kickstart RPM, the Kickstart
       documentation is available on your machine in HTML form. They are also
       available online in Chapter 7 of the Red Hat 9 Customization Guide.
      The Fedora Mirrors page has a list of mirror sites from which to download the
       install tree.

Ethan would like to thank Scott Wheeler for reviewing this article.

Ethan McCallum keeps himself busy with with Unix/Linux, and C++, and Java.

GED                                                                                          Page 8 of 8

To top