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
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. 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 --
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.
On most of the guides about kickstart they say that, when you're working outside the chroot environment, that the mount point of your new Ubuntu installation is on /mnt/sysimage, but in Ubuntu it's /target. So when you want to remove for example /etc/dhcp.conf you need to run the following command: rm /target/etc/dhcp.conf.
- The post install script runs right before the reboot in the installation.
- The output of the postinstall script is shown in tty4.
From within the chroot environment, the CD is mounted in /cdrom
- (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
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
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 )