Kickstart compatibility is available as of Hoary. Contact ColinWatson for help, requests for improvement, etc.

Ubuntu Kickstart documentation

What are Kickstart Installations?

Many system administrators would prefer to use an automated installation method to install Ubuntu on their machines. The preseeding feature of debian-installer answers this need, and is available in Hoary. However, some people want to deploy networks including other GNU/Linux distributions. Red Hat's Kickstart tool is a popular system here. The goal of the Kickstart compatibility project is to allow Kickstart to be used as a layer on top of debian-installer preseeding.

Using Kickstart, a system administrator can create a single file containing the answers to all the questions that would normally be asked during a typical Ubuntu installation. Kickstart files can be kept on a single server system, and read by individual computers during the installation. This installation method can support the use of a single kickstart file to install Ubuntu on multiple machines, making it ideal for network and system administrators.

Kickstart lets you automate most of an Ubuntu installation, including:

• Language selection
• Mouse configuration
• Keyboard selection
• Boot loader installation
• Disk partitioning
• Network configuration
• NIS, LDAP, Kerberos, Hesiod, and Samba authentication
• Firewall configuration
• Custom package selection
• X Window System configuration

How Do You Perform a Kickstart Installation?

Kickstart installations can be performed using a local CD-ROM, a local hard drive, or via NFS, FTP, or HTTP.

To use kickstart, you must:

1. Create a kickstart file. Ubuntu includes a graphical utility for creating kickstart files, in the package 'system-config-kickstart'.
2. Create a boot disk with the kickstart file or make the kickstart file available on the network.

3. Start the kickstart installation. You specify a kickstart installation with the boot parameter ks=, ie linux ks=http://path/to/ks.cfg.

Using a proxy / cache during the Kickstart

For HTTP proxy during the initial installation, add the variable http_proxy=http://proxyhost:port to the file isolinux/isolinux.cfg with the parameter append e.g.

APPEND http_proxy="http://192.168.0.11:8080" ks=cdrom:/ks.cfg file=/cdrom/preseed/kubuntu.seed initrd=/install/initrd.gz quiet --

Installation Logs

If installation is successful, logs generated are stored at /var/log/installer/, such as /var/log/installer/syslog. If installation is not successful, then the logs exist in the locations they were created during installation, such as /var/log/syslog.

Syslog entries are tagged kickseed, and can be accessed as so

$ cd /var/log/installer
$ cat syslog | grep kickseed
Jun 16 23:04:18 kickseed: Downloading kickstart file from http://10.0.1.0/ks.ubuntu-12.04
Jun 16 23:04:18 kickseed: Reading kickstart file from /var/spool/kickseed/fetch/http/10.0.1.0/ks.ubuntu-12.04
Jun 16 23:04:18 kickseed: Running pre script /var/spool/kickseed/parse/pre.section using interpreter /bin/sh:
Jun 16 23:04:18 kickseed: %pre script exited with error code 127
Jun 16 23:04:18 kickseed: Unrecognised kickstart command: logging
Jun 16 23:04:18 kickseed: Unrecognised kickstart command: selinux

During installation, multiple terminals are active. Using Alt-Function keys lets you switch TTY's. For CentOS, the various terminals are as follows:

• Alt-F1: The installer dialog when using text or cmdline mode
• Alt-F2: A shell prompt
• Alt-F3: The install log displaying messages from install program
• Alt-F4: The system log displaying messages from kernel, etc.
• Alt-F5: All other messages
• Alt-F7: The installer dialog when using the graphical installer

These TTYs appear to also be used in Ubuntu's Kickstart, although their purposes may be slightly different.

Target Filesystems

When running a command outside of the chroot, the installation filesystem is located at /target. From within the chroot environment, the CD is mounted in /cdrom. Guides for RHEL may mention /mnt/sysimage, but the correct path for Ubuntu is /target. The following example will place a new file on the installation filesystem.

%post --nochroot
touch /target/my_installation_files
%end

Post Installation Scripts

The output of the postinstall script is shown in tty4. Also, read section on Target Filesystems.

Integration with Preseed

While Debian's preseed can fully automate the entire Ubuntu installation, the official Red Hat kickstart language cannot. For this reason, Ubuntu kickstart includes a special command preseed which allows using preseed options inside a Kickstart file. Here is an example of mixing kickstart syntax with some preseed syntax.

# Kickstart syntax: Configure authentication 
auth --useshadow --enablemd5

# Ubuntu Kickstart Syntax: Use an option only available via preseed to tell 
# Ubuntu's installer not to make a non-root user during installation
preseed passwd/make-user boolean false

# Ubuntu Kickstart Syntax: Check "Install any security updates automatically"
preseed pkgsel/update-policy select unattended-upgrades

Status update

This section is retained for historical purposes. See the installation manual links at the top of this page for current information.

Added here because it took much searching to retrieve this information! This is from a mailing list post by ColinWatson:

At the moment, (Kickstart compatibility is) in the unhappy state where the source is the best documentation; I intend to rectify this before the Hoary release. All the same, the system-config-kickstart package is in Hoary and can generate working Kickstart files for at least some configurations. You boot the installer with a "ks=<whatever>" kernel argument, the same as with Red Hat. "ks=http://<server>/<path>", "ks=ftp://<server>/<path>", and "ks=nfs:<server>:/<path>" all work and are convenient, although you can also put the Kickstart file on a CD or a floppy or whatever if you want.

Things I know of that you should avoid for the time being:

• Firewalling support. Only 'firewall --disabled' works for now.

• NFS installation. You can retrieve the Kickstart file over NFS using 'ks=nfs:<server>:/<path>', but booting with plain 'ks' doesn't work, nor does retrieving the base system over nfs.

• RAID/LVM partitioning isn't handled. There are some other bugs and unimplemented bits in partition handling too.
• No support for non-default authentication methods like NIS, LDAP, krb5, Hesiod, or Samba.
• No support for bootloader passwords.

UPDATE: bootloader passwords appear to work with 7.10 in my testing

In general at the moment it's liable to fall over and leave a note in /var/log/syslog if you try to do something unsupported. I intend to make this more robust soon.

Bug reports about Kickstart support would definitely be appreciated, the sooner the better. If there are particular unimplemented features you really need, I'd like to know about those too so that I can bump them up my priority list.

Links

• http://fedora.redhat.com/projects/config-tools/redhat-config-kickstart.html

• http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/ch-ksconfig.html

• http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/ch-kickstart2.html

• http://www.linuxdocs.org/HOWTOs/KickStart-HOWTO.html

• http://www.centos.org/docs/4/html/rhel-sag-en-4/s1-kickstart2-options.html

  • (the above link includes LVM syntax which isn't implemented in Ubuntu yet)

Ideas

1. Maybe it would be possible to create near zero questions (apart from maybe some minimal hardware specifics) installer cds, to have specifics system needs tailored for certain organizations, uses, etc, specifically targetting special needs per usage domain: Almost automatic installer cd for libraries, schools, webhosting servers, router machines and other network appliances as some first examples. -- SivanGreen

This is the *whole point* of Kickstart and other similar automatic installation methods. "Ideas" shouldn't be requests for documentation. Note that automatic installation scripts almost always need to be customised somewhat for the local environment. -- ColinWatson

2. At a later stage, maybe create a special software piece that would be shipped with Ubuntu (or be part of the launchpad infrastructure) to allow people to use a user-friendly interface (Web??) to create their specific Kickstart Ubuntu installer cd , which would set up their specific system needs as per their organization, the system could possibley be also used for storage of such "System Templates" so whenever a sysadmin has finished installing a master copy of his desried configuration, and finished all adding extra packages and functionalities, he could store it in a "repository" of some sort, later to be used in data emergency situations, new hardware that is introduced into the organization etc. People who are willing to store their "System Templates" could be a helping hand to other clients of this system as they would be able to take other's templates as a basing ground and build on it. --SivanGreen

system-config-kickstart is a good start here, and sysadmins generally have their own arrangements for storing Kickstart files. It remains to be seen how derived distributions (which I assume you're referring to by the Launchpad comment) will handle this; I suspect Kickstart will not really be appropriate for them, since it makes assumptions directed at fully automatic installations. -- ColinWatson

3. Is it possible to make kickstart set up it's NIS-configuration post packet-installation? As for now it hangs forever at package-configuration when auth --enablenis is selected because it tries to update the NIS-server when installing packages which adds additional users/groups. Also is it possible to make the %POST-script actually run after package-installation, now it runs after base-system is installed, but before package-installation. This makes it impossible to set up autofs in the %POST-section because autofs-installation (after reboot) will halt if /etc/auto.master etc. already exist. -- Leitet

4. It would help to make kickstart able to make use of existing web and ftp proxies. According to Ubuntu's Apt-Get HowTo, the line to add in apt.conf would be Acquire::http::Proxy "http://yourproxyaddress:proxyport"; -- Lars Noodén

Feature Requests

Request from an Ubuntu reseller: We really need LVM functionality ASAP, (and to a lesser extent an option to create an unused parition). We want to install LVM by default on the machines we sell, but setting up our partitioning scheme each time is a hastle. Also, we want our customers to be able to reinstall without going through about 15 steps to do the partitioning during install. We have added a link to the link section that shows Red Hat kickstart LVM syntax. -- Michael Pardee (groovix.com)

In reply to Michael Pardee

Hi mate, why don't you use a preseed file along the kickstart? This way you can remove the lvms and vgs during the installation without having to do it manually, and you can set up new lvms as redhat does. ( gettons )

The Ubuntu installer should generate a kickstart file similar to the /root/anaconda-ks.cfg generated by Anaconda. This helps a lot when you have to reproduce complex disk setups. You simply install a box by hand and then use the generated kickstart file on all the others.

I am afraid it doesn't generate any kickstart file at the end of the installation process. Is there any way to force it doing this? ( 08-06-10 )

CategoryInstallation