How to use Kickstart (Anaconda's remote control)


Anaconda is an extremely flexible install program used by the Fedora Project and Red Hat Enterprise Linux. In addition to supporting installation from local media (like a hard drive, CD/DVD, or USB key), Anaconda can also install from network sources like FTP, HTTP, or NFS. It also features an automated mechanism, called kickstart, which lets users perform scripted hands-off installations. With support for VNC calls, an administrator has a powerful utility for remote server installation. This article will explore a couple methods that use the Anaconda installer remotely, monitoring the install progress in real time.


Anaconda is primarily Python-based, with some modules written in C. It has two stages. The first stage loads all the kernel modules so that the second stage can be mounted with access to the installation source. In the second stage, the python installer executes and the X Window install screens become visible (if it is a graphical install). If this was a local installation, the user would start answering questions about the install source, timezone, keyboard, and more. For remote installs this information is provided before the second stage using Anaconda command line options. These options can be specified using the GRUB boot loader and will depend on the network configuration and remote install type (interactive or kickstart).

Grub Modifications

The first step is to copy the initrd.img (RAM disk) and vmlinuz (kernel) files from the installation source (isolinux directory) to the /boot directory of the target remote server. You will need to be root to do this. You can find the isolinux directory in the root directory of the first Fedora CD.

NOTE: You may need to mount the .iso to get to these files.

Create a new entry in /etc/grub.conf to pass Anaconda's command line options from GRUB. The following table describes some of the Anaconda command line options:

Option Description
lowres Force GUI installer to run at 640x480.
vnc Enable VNC-based installation. You will need to connect to the machine using a VNC client application.
vncpassword=<password> Enable a password for the VNC connection. This will prevent someone from inadvertantly connecting to the VNC-based installation. Requires 'vnc' option to be specified as well.
vncconnect=<host>[:<port>] Once installation is up and running, connect to the VNC client named <host>, and optionally use port <port>. Requires 'vnc' option to be specified as well.
ks=cdrom: Kickstart from CDROM.
ks=nfs:<path> Kickstart from NFS.
ks=<url> Kickstart via HTTP.
lang=<lang> Language to use for the installation. This should be a language which is valid to be used with the 'lang' kickstart command.
keymap=<keymap> Keyboard layout to use. Valid values are those which can be used for the 'keyboard' kickstart command.
dns=<dns> Comma separated list of nameservers to use for a network installation.
method=hd://<dev>/<path> Use <path> for an NFS installation.
method=<cdrom> Do a CDROM based installation.

For interactive remote installs, use the lang, keymap, method, vnc, vncconnect and ip options. For example, an interactive remote install using a http source tree and dynamic ip assignment would be similar to the following:

title Red Hat Enterprise Linux AS (2.6.9-5.ELsmp)
        root (hd0,0)
        kernel /vmlinuz-2.6.9-5.ELsmp ro root=/dev/VolGroup00/LogVol00
        initrd /initrd-2.6.9-5.ELsmp.img
title Remote Install
        root (hd0,0)
        kernel /vmlinuz_remote lang=en_US keymap=us method=http://<server>/<path_to_tree>/i386/tree vnc vncconnect= ip=dhcp
        initrd /initrd_remote.img
NOTE: vncconnect defaults to port 5500. If you are running a firewall, make sure the observing server allows access to this port. If vncconnect is not specified, anaconda will accept vncclient connections on its hostname without a password.

We can reduce the amount of Anaconda options passed when performing a remote kickstart since most of the information Anaconda needs is already in the kickstart configuration:

title Remote Install
        root (hd0,0)
        kernel /vmlinuz_remote ks=http://<server>/<path_to_file>/<kickstart_config> vnc vncconnect=<observing_ip>
        initrd /initrd_remote.img

# Barebones demo remote kickstart configuration

network --bootproto dhcp
url --url http://<server>/<path_to_tree>/i386/tree
lang en_US
langsupport --default en_US en_US
keyboard us
mouse none
zerombr yes
clearpart --all
part pv.01 --size=1000 --grow
part /boot --fstype=ext3 --size=200
part swap --size=1000   --maxsize=2000
volgroup myvg pv.01
logvol / --vgname=myvg --name=rootvol --size=1000 --grow
bootloader --location mbr
timezone America/New_York
auth --enablemd5 --enableshadow
rootpw --iscrypted <encryptedpasswdstring>
selinux --permissive
firewall --enabled --http --ssh --smtp

%packages --resolvedeps

@ Base


echo << /etc/motd
echo "Remote kickstart on $(date +'%Y-%m-%d')" << /etc/motd
echo << /etc/motd
NOTE: You can insert the root password in a kickstart file as clear text or you can specify an encrypted password. To use an unencrypted password in the kickstart configuration file, use the rootpw keyword, followed by the clear text password:
rootpw mypasswd
if you would rather use an encrypted password, use grub-md5-crypt or the openssl passwd module to generate MD5-hashed passwords. For example, to generate an encrypted password using openssl enter the following:
openssl passwd -1 -salt "shaker" "your_password"
Entries in the /etc/shadow file also contain MD5-hashed passwords. Now add the --iscrypted option and encrypted password to the kickstart file as follows:
rootpw --iscrypted encryptedpasswdstring

Save the new grub.conf file without restarting the remote server. GRUB offers a safety precaution that we will take advantage of in the next section.


GRUB boots one or more entries when a default boot entry fails. Usually the fallback entries are kernel entries that the system expects will boot successfully in case we boot to a kernel that does not agree with the system. For a remote install, GRUB only needs to set the default entry and boot to it once.

Rather then modifying the grub.conf file, save the default entry with the GRUB command line tool and then boot to it. As root, enter the command grub from the command line. This will load a bash-like grub tool. GRUB entries are indexed from 0. If the remote install is the second entry in grub.conf, then enter the following commands:

grub> savedefault --default=1 --once
grub> quit

GRUB will now only boot to the remote install entry one time.

grub> help savedefault
savedefault: savedefault [--stage2=STAGE2_FILE] [--default=DEFAULT] [--once]
   Save DEFAULT as the default boot entry in STAGE2_FILE. If
   '--once' is specified, the default is reset after the next reboot.

So when we save the default grub entry to boot to, the --once flag will reset the default after the next reboot. This helps if the boot was not successful so we can go back to a known good boot entry.

NOTE: Resist the temptation to use GRUB's fallback mechanism as a substitute for testing your install. It's always a good idea to test your remote install in an environment where you are physically present. Your remote install could be waiting for an answer needed for the second stage that will never be provided if you have a misspelled or missing argument. Debugging these types of errors is much easier in a physically available testing environment.

Flip The Switch

Fire up vncviewer on your observing system like so:

vncviewer --listen

Now reboot the server so the client can accept the VNC connection:

shutdown -r now

It takes a few minutes for the remote server to reboot and for the kernel params to be read and excuted--you may feel like a NASA engineer sitting in Houston Control Center waiting for Space Shuttle re-entry. When the wait is over, the Anaconda loader will start and hit the second stage where the actual vnc connection becomes active. When the VNC connection is made, a VNC window will open on the observing system. Now you can interact with the remote install or, in the case of a remote kickstart, monitor the install progress.


Your remote install should now be well on its way to successful completion. Go grab you favorite beverage and use those extra install discs as a coaster.

Original article: Red Hat Magazine
Original author: Shannon Hughes