Credits to the Fedora Kickstart Guide, as most of this guide is from it.

The AnonOS Project uses Kickstart configs with livecd-tools to build releases. They can be reviewed here.

To learn how to actually build a liveCD with those kickstarts, go to developing.

Creating a kickstart file

First, be aware of the following issues when you are creating your kickstart file:

While not strictly required, there is a natural order for sections that should be followed. Items within the sections do not have to be in a specific order (unless otherwise noted). The section order is:

• Command section -- More info here. You must include the required options.
• The %packages section -- This is where you place added packages. More info here.
• The %pre, %post, and %traceback sections -- These sections can be in any order and are not required.
• The %packages, %pre, %post and %traceback sections are all required to be closed with %end
• Items that are not required can be omitted.
• Lines starting with a pound sign (#) are treated as comments and are ignored.

Adding Packages

Use the %packages command to begin a kickstart file section that lists the packages you would like to install.

Packages can be specified by group or by individual package name. livecd-creator defines several groups that contain related packages. Refer to the repodata/*comps.xml file here. for a list of groups.

Each group has an id, user visibility value, name, description, and package list. In the package list, the packages marked as mandatory are always installed if the group is selected, the packages marked default are selected by default if the group is selected, and the packages marked optional must be specifically selected even if the group is selected to be installed.

In most cases, it is only necessary to list the desired groups and not individual packages. Note that the Core and Base groups are always selected by default, so it is not necessary to specify them in the %packages section.

The %packages section is required to be closed with %end. Also, multiple %packages sections may be given. This may be handy if the kickstart file is used as a template and pulls in various other files with the %include mechanism.

Here is an example %packages selection:

%packages @X Window System @GNOME Desktop Environment @Graphical Internet @Sound and Video dhcp %end

As you can see, groups are specified, one to a line, starting with an @ symbol followed by the full group name as given in the comps.xml file. Groups can also be specified using the id for the group, such as gnome-desktop. Specify individual packages with no additional characters (the dhcp line in the example above is an individual package).

Additionally, individual packages may be specified using globs. For instance:

%packages vim* kde-i18n-* %end

This would install all packages whose names start with "vim" or "kde-i18n-".

You can also specify which packages not to install from the default package list:

%packages -autofs %end

The following options are available for the %packages option:

--default

Install the default package set. This corresponds to the package set that would be installed if no other selections were made on the package customization screen during an interactive install.

--excludedocs

Do not install any of the documentation from any packages. For the most part, this means files in /usr/share/doc* will not get installed though it could mean other files as well, depending on how the package was built.

--ignoremissing

Ignore any packages or groups specified in the packages section that are not found in any configured repository. The default behavior is to halt the installation and ask the user if the installation should be aborted or continued. This option allows fully automated installation even in the error case. It is used as follows:

%packages --ignoremissing

--instLangs=

Specify the list of languages that should be installed. This is different from the package group level selections, though. This option does not specify what package groups should be installed. Instead, it controls which translation files from individual packages should be installed by setting RPM macros. Note: this option is not supported by anaconda at the moment, but is recognized by pykickstart for use in such tools as livecd-creator.

--nobase

Don't select the Base group by default. This is useful if you are putting together an extremely minimal system. However with this option, it is very easy to end up with a system that does not fully boot to a login prompt as you will need to list all the packages required to get that much functionality.

In addition, group lines in the %packages section can take options as well:

--nodefaults

Only install the group's mandatory packages, not the default selections.

--optional

In addition to the mandatory and default packages, also install the optional packages. This means all packages in the group will be installed.

Pre-installation scripts

You can add commands to run on the system immediately after the ks.cfg has been parsed and the lang, keyboard, and url options have been processed. This section must be at the end of the kickstart file (after the commands) and must start with the %pre command. You can access the network in the %pre section; however, name service has not been configured at this point, so only IP addresses will work.

Preinstallation scripts are required to be closed with %end.

WARNING: If your script spawns a daemon process, you must make sure to close stdout and stderr. Doing so is standard procedure for creating daemons. If you do not close these file descriptors, the installation will appear hung as anaconda waits for an EOF from the script.

Note that the pre-install script is not run in the chroot environment.

--interpreter /usr/bin/python

Allows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice.

--erroronfail

If the pre-installation script fails, this option will cause an error dialog to be displayed and will halt installation. The error message will direct you to where the cause of the failure is logged.

--log=

Log all messages from the script to the given log file.