|Red Hat Linux 6.2: The Official Red Hat Linux Reference Guide|
|Prev||Appendix F. Kickstart Installations||Next|
The following commands can be placed in a kickstart file.
Sets up the authentication options for the system. It's similar to the authconfig command that can be run after the install. By default, passwords are normally encrypted and are not shadowed.
Use md5 encryption for user passwords.
Turns on NIS support. By default, --enablenis uses whatever domain it finds on the network. A domain should almost always be set by hand (via --nisdomain).
NIS domain name to use for NIS services.
Server to use for NIS services (broadcasts by default).
Use shadow passwords.
Removes partitions from the system, prior to creation of new partitions. By default, no partitions are removed.
Erases Linux (type 0x82, 0x83, and 0xfd [RAID]) partitions
Erases all partitions from the system.
On most PCI systems, the installation program will autoprobe for Ethernet and SCSI cards properly. On older systems, and some PCI systems, kickstart needs a hint to find the proper devices, however. The device command tells Anaconda to install extra modules. It is of the form:
device <type> <moduleName> --opts <options>
<type> should be one of "scsi" or "eth", and <moduleName> is the name of the kernel module which should be installed.
Options to pass to the kernel module. Note that multiple options may be passed if put in quotes. For example:
--opts "aic152x=0x340 io=11"
During kickstart, driver disks can be used by copying the contents of a driver disk to the root directory of a partition on the system's hard drive and using the driverdisk command to tell the installation program where to look for it.
driverdisk <partition> [--type <fstype>]
<partition> is the partition containing the driver disk.
Filesystem type (for example, VFAT or ext2).
Tells the system to install a fresh system rather than upgrade an existing system. This is the default mode.
You must use one of the these three commands to specify what type of kickstart is being done:
Install from the NFS server specified.
Server from which to install (hostname or IP).
Directory containing the Red Hat installation tree.
nfs --server <server> --dir <dir>
Install from the first CD-ROM drive on the system.
Install from a Red Hat installation tree on a local drive, which must be either VFAT or ext2.
Partition to install from (such as, sdb2).
Directory containing the Red Hat installation tree.
harddrive --partition <partition> --dir <dir>
Sets system keyboard type. Here's the list of available keyboards on i386 and Alpha machines:
azerty, be-latin1, be2-latin1, fr-latin0, fr-latin1, fr-pc, fr, wangbe, ANSI-dvorak, dvorak-l, dvorak-r, dvorak, pc-dvorak-latin1, tr_f-latin5, trf, bg, cf, cz-lat2-prog, cz-lat2, defkeymap, defkeymap_V1.0, dk-latin1, dk. emacs, emacs2, es, fi-latin1, fi, gr-pc, gr, hebrew, hu101, is-latin1, it-ibm, it, it2, jp106, la-latin1, lt, lt.l4, nl, no-latin1, no, pc110, pl, pt-latin1, pt-old, ro, ru-cp1251, ru-ms, ru-yawerty, ru, ru1, ru2, ru_win, se-latin1, sk-prog-qwerty, sk-prog, sk-qwerty, tr_q-latin5, tralt, trf, trq, ua, uk, us, croat, cz-us-qwertz, de-latin1-nodeadkeys, de-latin1, de, fr_CH-latin1, fr_CH, hu, sg-latin1-lk450, sg-latin1, sg, sk-prog-qwertz, sk-qwertz, slovene
Here's the list for SPARC machines:
sun-pl-altgraph, sun-pl, sundvorak, sunkeymap, sunt4-es, sunt4-no-latin1, sunt5-cz-us, sunt5-de-latin1, sunt5-es, sunt5-fi-latin1, sunt5-fr-latin1, sunt5-ru, sunt5-uk, sunt5-us-cz
Sets the default language for the installed system. The language you specify will be used during the installation as well as to configure any language-specific aspect of the installed system. For example, to set the language to English, the kickstart file should contain the following line:
Valid languages codes are:
cs_CZ, en_US, fr_FR, de_DE, hu_HU, is_IS, id_ID, it_IT, ja_JP.ujis, no_NO, pl_PL, ro_RO, sk_SK, sl_SI, es_MX, ru_RU.KOI8-R, uk_UA
Specifies how the boot loader should be installed on the system. By default, LILO installs on the MBR of the first disk, and installs a dual-boot system if a DOS partition is found (the DOS/Windows system will boot if the user types dos at the LILO: prompt).
Specifies kernel parameters.
Use the linear LILO option; this is only for backwards compatibility (and linear is now used by default).
Specifies where the LILO boot record is written. Valid values are mbr (default), partition (installs the boot loader on the first sector of the partition containing the kernel), or none, which prevents any bootloader from being installed.
If this is present, the installation program checks for LILO on the MBR of the first hard drive, and reboots the system if it is found -- No installation is done in this case. This can prevent the kickstart from reinstalling an already installed system.
Configures the mouse for the system, both in GUI and text modes. Options are:
Device the mouse is on (such as --device ttyS0)
If present, the X Window System uses simultaneous left+right mouse buttons to emulate the middle button (should be used on two button mice).
After options, the mouse type may be specified as one of the following:
alpsps/2, ascii, asciips/2, atibm, generic, generic3, genericps/2, generic3ps/2, geniusnm, geniusnmps/2, geniusnsps/2, thinking, thinkingps/2, logitech, logitechcc, logibm, logimman, logimmanps/2, logimman+, logimman+ps/2, microsoft, msnew, msintelli, msintellips/2, msbm, mousesystems, mmseries, mmhittab, sun, none
If the mouse command is given without any arguments, or it is omitted, the installation program will attempt to autodetect the mouse (which works for most modern mice).
Configures network information for the system. If it is not given, and the kickstart installation does not require networking (in other words, it's not installed over NFS), networking is not configured for the system. If the installation does require networking, Anaconda assumes that the install should be done over eth0 via a dynamic IP address (BOOTP/DHCP), and configures the final, installed system to dynamically determine its IP address. The network command configures the networking information for the installation for network kickstarts as well as for the final, installed system.
One of dhcp, bootp, or static (defaults to DHCP, and dhcp and bootp are treated the same). Must be static for static IP information to be used.
IP address for machine to be installed.
Default gateway as an IP address.
Primary name server, as an IP address.
Netmask for the installed system
There are three different methods of network configuration:
The DHCP method uses a DHCP server system to obtain its networking configuration. As you might guess, the BOOTP method is similar, requiring a BOOTP server to supply the networking configuration.
The static method requires that you enter all the required networking information in the kickstart file. As the name implies, this information is static, and will be used during the installation, and after the installation as well.
To direct a system to use DHCP to obtain its networking configuration, use the following line:
network --bootproto dhcp
To direct a machine to use BOOTP to obtain its networking configuration, use the following line in the kickstart file:
network --bootproto bootp
The line for static networking is more complex, as you must include all network configuration information on one line. You'll need to specify:
gateway IP address
name server IP address
Here's an example static line:
network --bootproto static --ip 10.0.2.15 --netmask 255.255.255.0 --gateway 10.0.2.254 --nameserver 10.0.2.1
The entire network configuration must appear on one line! We've wrapped it here to make it easier to read.
There are two restrictions you must keep in mind should you use the static method:
All static networking configuration information must be specified on one line; you cannot wrap lines using a backslash, for example.
You can only specify one name server here. However, you can use the kickstart file's %post section (described in the section called %post -- Post-Installation Configuration Section) to add more name servers, if needed.
Create a partition on the system. Partition requests are of the form:
part <mntpoint> --size <size> [--grow] [--onpart <partc>] [--ondisk <disk>]
The <mntpoint> is where the partition will be mounted, and must be of one of the following forms:
(i.e. /, /usr, /home)
The partition will be used as swap space.
The partition will be used for software RAID (see the raid command later).
Sets the minimum size for the partition
Tells the partition to grow to fill available space (if any).
Tells the installation program to put the partition on the already existing device <part>. For example, partition /home --onpart hda1 will put /home on /dev/hda1, which must already exist.
Forces the partition to be created on a particular disk. For example, --ondisk sdb will put the partition on the second disk on the system.
All partitions created will be formatted as part of the installation process.
Assembles a software RAID device. This command is of the form:
raid <mntpoint> --level <level> --device <mddevice><partitions*>
The <mntpoint> is the location to mount the RAID filesystem. If it is /, the RAID level must be 1 unless a boot partition (/boot) is present in which the /boot partition has to be level 1 and the root (/) partition can be any of the available types. The <partitions*> (which denotes that multiple partitions can be listed) lists the RAID identifiers to add to the RAID array.
RAID level to use (0, 1, or 5).
Name of the RAID device to use (such as md0 or m1). RAID devices range from md0 to md7, and each may only be used once.
Here's an example of how to create a RAID level 1 partition for /, and a RAID level 5 for /usr, assuming there are three SCSI disks on the system. It also creates three swap partitions, one on each drive.
part raid.01 --size 60 --ondisk sda part raid.02 --size 60 --ondisk sdb part raid.03 --size 60 --ondisk sdc
part swap --size 128 --ondisk sda part swap --size 128 --ondisk sdb part swap --size 128 --ondisk sdc
part raid.11 --size 1 --grow --ondisk sda part raid.12 --size 1 --grow --ondisk sdb part raid.13 --size 1 --grow --ondisk sdc
raid / --level 1 --device md0 raid.01 raid.02 raid.03 raid /usr --level 5 --device md1 raid.11 raid.12 raid.13
Reboot after the installation is complete (no arguments). Normally, kickstart displays a message and waits for the user to press a key before rebooting.
usage: rootpw [--iscrypted] <password>
Set the system's root password to the <password> argument.
If this is present, the password argument is assumed to already be encrypted.
If present, X is not configured on the installed system.
timezone [--utc] <timezone>
Sets the system time zone to <timezone> which may be any of the time zones listed in "timeconfig".
If present, the system assumes the hardware clock is set to UTC (Greenwich Mean) time.
Tells the system to upgrade an existing system rather than install a fresh system.
Configures the X Window System. If this option is not given, the user will need to configure X manually during the installation, if X was installed; this option should not be used if X is not installed on the final system.
Don't probe the monitor.
Use card <card>; this card name should be from the list of cards in Xconfigurator. If this argument is not provided, Anaconda will probe the PCI bus for the card.
Use monitor <mon>; this monitor name should be from the list of monitors in Xconfigurator. This is ignored if --hsync or --vsync is provided; if no monitor information is provided, the monitor is probed via plug-and-play.
Specifies the horizontal sync frequency of the monitor.
Specifies the vertical sync frequency of the monitor.
Use a graphical login (runlevel 5) for the installed system.
If "zerombr" is specified, and "yes" is its sole argument, any invalid partition tables found on disks are initialized. This will destroy all of the contents of disks with invalid partition tables. This command should be used as:
No other format is effective.
Use the %packages command to begin a kickstart file section that lists the packages you'd like to install (this is for installations only, as package selection during upgrades is not supported).
Packages can be specified by component or by individual package name. The installation program defines several components that group together related packages. See the RedHat/base/comps file on any Red Hat Linux CD-ROM for a list of components. The components are defined by the lines that begin with a number followed by a space, and then the component name. Each package in that component is then listed, line-by-line. Individual packages lack the leading number found in front of component lines.
Additionally, there are three other types of lines in the comps file you may run across:
If a package name begins with an architecture type, you only need to type in the package name, not the architecture name. For example:
For i386: netscape-common you only need to use the netscape-common part for that specific package to be installed.
Lines that begin with a ?, are specific to the installation program. You do not have to do anything with these type of lines.
If a package name begins with --hide, you only need to type in the package name, minus the --hide. For example:
For --hide KDE Workstation you only need to use the KDE Workstation part for that specific package to be installed.
In most cases, it's only necessary to list the desired components and not individual packages. Note that the Base component is always selected by default, so it's not necessary to specify it in the %packages section.
Here's an example %packages selection:
%packages @ Networked Workstation @ C Development @ Web Server @ X Window System bsd-games
As you can see, components are specified, one to a line, starting with an @ symbol, a space, and then the full component name as given in the comps file. Specify individual packages with no additional characters (the bsd-games line in the example above is an individual package).
You can also direct the kickstart installation to use the workstation- and server-class installations. To do this, simply add one of the following lines to the %packages section:
@ Gnome Workstation @ KDE Workstation @ Server
You have the option of adding commands to run on the system once the installation is complete. This section must be at the end of the kickstart file and must start with the %post command. Note, you can access the network in the %post section; however, name service has not been configured at this point, so only IP addresses will work. Here's an example %post section:
%post # add comment to /etc/motd echo "Kickstart-installed Red Hat Linux `/bin/date`" > /etc/motd # add another nameserver echo "nameserver 10.10.0.2" >> /etc/resolv.conf
This section creates a message-of-the-day file containing the date the kickstart installation took place, and gets around the network command's "one name server only" limitation by adding another name server to /etc/resolv.conf.
Note that the post-install script is run in a chroot'ed environment; therefore performing tasks such as copying scripts or RPMs from the installation media will not work.
Allows you to specify commands that you would like to run outside of the chroot'ed environment.