Content Cleanup Required
Style Cleanup Required
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
What Kickstart Options Does Ubuntu Support?
At this point the source code is the best reference. See this folder to see which Kickstart commands are being translated into preseed commands. As a general rule of thumb, if there is a handler file present for a command then, it is at least minimally supported. For specific command options, such as what auth options are supported, look into the handler file e.g. auth.sh.
This is a rough list of options that are known to be unsupported. Note that support may have been added since this was last edited, so the source code is your best reference. In general kickseed will leave a message in the Installation Logs if you try something unsupported.
- 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
- Partitioning has some bugs
- Non-default authentication methods like NIS, LDAP, krb5, Hesiod, or Samba.
- Bootloader passwords. UPDATE: bootloader passwords appear to work with 7.10
Only ks= and ksdevice= boot parameters are supported. No Anaconda-specific boot parameters are supported
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:
- Create a kickstart file. Ubuntu includes a graphical utility for creating kickstart files, in the package 'system-config-kickstart'.
- Create a boot disk with the kickstart file, or make the kickstart file available on the network.
Start the kickstart installation by specifying the boot parameter ks=. For example:
linux initrd=initrd.gz -- ks=http://path/to/ks.cfg
Netboot on a machine with multiple NICs
If your machine has multiple network interfaces, you need to specify which interface should be used to retrieve the kickstart file. Here are some ways to do this in different scenarios
1. You know the name of the network interface
- # Provide the ksdevice= boot paramter
linux initrd=initrd.gz -- ks=http://path/to/ks.cfg ksdevice=eth0
2. You know the MAC address
- # Provide the BOOTIF= boot parameter, and set ksdevice=bootif
linux initrd=initrd.gz -- ks=http://path/to/ks.cfg ksdevice=bootif BOOTIF=01-18-03-73-0c-f2-51
3. You are using pxelinux or syslinux
# Use the IPAPPEND command and set ksdevice=bootif LABEL ubuntu12 MENU LABEL Ubuntu 12.04 KERNEL images/ubuntu/12.04/linux APPEND initrd=images/ubuntu/12.04/initrd.gz -- ks=http://path/to/ks ksdevice=bootif IPAPPEND 2
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 --
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 (You can also hold Alt and use the left/right arrow keys). For Ubuntu/Debian, the various terminals during installation are as follows:
- Alt-F1: The installer dialog
- Alt-F2: A convenience shell prompt (busybox)
- Alt-F3: A convenience shell prompt (busybox)
Alt-F4: Output of syslog (tail -f /var/log/syslog)
Note: These are different than the TTY's used during a Red Hat installation.
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 [Update: /media/cdrom in 14.04]. 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
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.
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.
- (the above link includes LVM syntax which isn't implemented in Ubuntu yet)
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
Response: 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 customized 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
Response: 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
1. 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)
Response: 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 )
2. 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.
Response: 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 )