Kickstart

+ Red Hat, Inc. +

      1801 Varsity Drive
+      Raleigh NC 27606-2072 USA
+      Phone: +1 919 754 3700
+      Phone: 888 733 4281
+      Fax: +1 919 754 3701
+      PO Box 13588
+      Research Triangle Park NC 27709 USA
+

kickstart(EN)-7.3-HTML-RHI (2002-04-01T16:30-0500) +

Copyright © 2002 by Red Hat, Inc. This material may be distributed only + subject to the terms and conditions set forth in the Open Publication + License, V1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). +

Distribution of substantively modified versions of this document is + prohibited without the explicit permission of the copyright holder. +

Distribution of the work or derivative of the work in any standard (paper) + book form for commercial purposes is prohibited unless prior permission is + obtained from the copyright holder. +

The admonition graphics (note, tip, important, caution, and warning) were + created by Marianne Pecci <goddess@ipass.net>. They may be + redistributed with explicit permission from Marianne Pecci and Red Hat, Inc. +

Red Hat, Red Hat Network, the Red Hat "Shadow Man" logo, RPM, Maximum RPM, the RPM logo, Linux + Library, PowerTools, Linux Undercover, RHmember, RHmember More, Rough Cuts, + Rawhide and all Red Hat-based trademarks and logos are trademarks or registered + trademarks of Red Hat, Inc. in the United States and other countries. +

Linux is a registered trademark of Linus Torvalds. +

Motif and UNIX are registered trademarks of The Open Group. +

Intel and Pentium are a registered trademarks of Intel + Corporation. Itanium and Celeron are trademarks of Intel Corporation. +

AMD, AMD Athlon, AMD Duron, and AMD K6 are trademarks of Advanced Micro + Devices, Inc. +

Netscape is a registered trademark of Netscape Communications Corporation in + the United States and other countries. +

Windows is a registered trademark of Microsoft Corporation. +

SSH and Secure Shell are trademarks of SSH Communications Security, Inc. +

FireWire is a trademark of Apple Computer Corporation. +

S/390 and zSeries are trademarks of International Business Machines Corporation. +

All other trademarks and copyrights referred to are the property of their + respective owners. +

Chapter 1. Introduction

What are Kickstart Installations?

Many system administrators would prefer to use an automated installation + method to install Red Hat Linux on their machines. To answer this need, Red Hat + created the kickstart installation method. 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 Red Hat Linux + installation. +

Kickstart files can be kept on 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 Red Hat Linux on + multiple machines, making it ideal for network and system + administrators. +

Kickstart lets you automate most of a Red Hat Linux installation, including: +

Language selection
Mouse configuration
Keyboard selection
Boot loader installation
Disk partitioning
Network configuration
NIS, LDAP, Kerberos, Hesiod, and Samba authentication
Firewall configuration
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.
Create a boot disk with the kickstart file or make the kickstart + file available on the network.
Start the kickstart installation.

Chapter 2. Creating the Kickstart File

The kickstart file is a simple text file, containing a list of items, each + identified by a keyword. You can create it by editing a copy of the + sample.ks file found in the + RH-DOCS directory of the Red Hat Linux Documentation + CD, using the Kickstart Configurator + application, or writing it from scratch. The Red Hat Linux installation program + also creates a sample kickstart file based on the options that you + selected during installation. It is written to the file + /root/anaconda-ks.cfg. You should be able to edit + it with any text editor or word processor that can save files as ASCII + text. +

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

Items must be specified in order. That + order is: +
- Command section — Refer to Chapter 3 for a list of kickstart + options. You must include the required options. +
- The %packages section — Refer to the Section called %packages — Package Selection in Chapter 3 for details. +
- The %pre and %post + sections — These two sections can be in any + order and are not required. Refer to the Section called %pre — Pre-Installation Configuration + Section in Chapter 3 + and the Section called %post — Post-Installation Configuration + Section in Chapter 3 for + details. +
Items that are not required can be omitted. +
Omitting any required item will result in the installation program + prompting the user for an answer to the related item, just as the + user would be prompted during a typical installation. Once the + answer is given, the installation will continue unattended (unless + it finds another missing item). +
Lines starting with a pound sign ("#") are treated as comments and + are ignored. +
For kickstart upgrades, the following items are + required: +
- Language
- Installation method
- Device specification (if device is needed to perform + installation)
- Keyboard setup
- The upgrade keyword
- LILO configuration
If any other items are specified for an upgrade, those items will be + ignored (note that this includes package selection). +

Chapter 3. Kickstart Options

The following options can be placed in a kickstart file. If you prefer + to use a graphical interface for creating your kickstart file, you can + use the Kickstart Configurator + application. +

`autostep`

autostep (optional): Similar to interactive except it goes to the + next screen for you. It is used mostly for debugging. +

`auth`

auth or authconfig (required)

Sets up the authentication options for the system. It's similar + to the authconfig command, which can be run + after the install. By default, passwords are normally encrypted + and are not shadowed. +

--enablemd5

Use md5 encryption for user passwords. +

--enablenis

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). +

--nisdomain

NIS domain name to use for NIS services. +

--nisserver

Server to use for NIS services (broadcasts by default). +

--useshadow or --enableshadow

Use shadow passwords.

--enableldap

Turns on LDAP support in + /etc/nsswitch.conf, allowing your + system to retrieve information about users (UIDs, home + directories, shells, etc.) from an LDAP directory. To + use this option, you must have the + nss_ldap package installed. You + must also specify a server and a base DN with + --ldapserver= and + --ldapbasedn=. +

--enableldapauth

Use LDAP as an authentication method. This enables the + pam_ldap module for authentication + and changing passwords, using an LDAP directory. To use + this option, you must have the + nss_ldap package installed. You + must also specify a server and a base DN with + --ldapserver= and + --ldapbasedn=. +

--ldapserver=

If you specified either --enableldap + or --enableldapauth, the name of the + LDAP server to use. This option is set in the + /etc/ldap.conf file. +

--ldapbasedn=

If you specified either --enableldap + or --enableldapauth, the DN (distinguished + name) in your LDAP directory tree + under which user information is stored. This option is + set in the /etc/ldap.conf file. +

--enableldaptls

Use TLS (Transport Layer Security) lookups. This option + allows LDAP to send encrypted usernames and passwords + to an LDAP server before authentication. +

--enablekrb5

Use Kerberos 5 for authenticating users. Kerberos + itself does not know about home directories, UIDs, or + shells. So if you enable Kerberos you will need to + make users' accounts known to this workstation by + enabling LDAP, NIS, or Hesiod or by using + the /usr/sbin/useradd command + to make their accounts known to this workstation. If + you use this option, you must have the + pam_krb5 package installed. +

--krb5realm

The Kerberos 5 realm to which your workstation belongs.

--krb5kdc

The KDC (or KDCs) that serve requests for the realm. If + you have multiple KDCs in your realm, separate their + names with commas (,).

--krb5adminserver

The KDC in your realm that is also running kadmind. + This server handles password changing and other + administrative requests. This server must be run on the + master KDC if you have more than one KDC. +

--enablehesiod

Enable Hesiod support for looking up user home + directories, UIDs, and shells. More information on + setting up and using Hesiod on your network is in + /usr/share/doc/glibc-2.x.x/README.hesiod, + which is included in the glibc + package. Hesiod is an extension of DNS that uses DNS + records to store information about users, groups, and + various other items. +

--hesiodlhs

The Hesiod LHS ("left-hand side") option, set in + /etc/hesiod.conf. This option is + used by the Hesiod library to determine the name to + search DNS for when looking up information, similar to + LDAP's use of a base DN. +

--hesiodrhs

The Hesiod RHS ("right-hand side") option, set in + /etc/hesiod.conf. This option is + used by the Hesiod library to determine the name to + search DNS for when looking up information, similar to + LDAP's use of a base DN. +

Tip

	Tip
	To look up user information for "jim", the Hesiod + library looks up + jim.passwd<LHS><RHS>, + which should resolve to a TXT record that looks like + what his passwd entry would look like + (`jim::501:501:Jungle + Jim:/home/jim:/bin/bash`). For + groups, the situation is identical, except + jim.group<LHS><RHS>* + would be used. + Looking up users and groups by number is handled by + making "501.uid" a CNAME for "jim.passwd", and + "501.gid" a CNAME for "jim.group". Note that the LHS + and RHS do not have periods [.] put in + front of them when the library determines the name for + which to search, so the LHS and RHS usually begin with + periods. +

To look up user information for "jim", the Hesiod + library looks up + jim.passwd<LHS><RHS>, + which should resolve to a TXT record that looks like + what his passwd entry would look like + (jim:*:501:501:Jungle + Jim:/home/jim:/bin/bash). For + groups, the situation is identical, except + jim.group<LHS><RHS> + would be used. +

Looking up users and groups by number is handled by + making "501.uid" a CNAME for "jim.passwd", and + "501.gid" a CNAME for "jim.group". Note that the LHS + and RHS do not have periods [.] put in + front of them when the library determines the name for + which to search, so the LHS and RHS usually begin with + periods. +

--enablesmbauth

Enables authentication of users against an SMB server + (typically a Samba or Windows server). SMB + authentication support does not know about home + directories, UIDs, or shells. So if you enable it you + will need to make users' accounts known to the + workstation by enabling LDAP, NIS, or Hesiod or by using + the /usr/sbin/useradd command to make + their accounts known to the workstation. To use this + option, you must have the pam_smb + package installed. +

--smbservers=

The name of the server(s) to use for SMB + authentication. To specify more than one server, + separate the names with commas (,). +

--smbworkgroup=

The name of the workgroup for the SMB servers.

--enablecache

Enables the nscd service. The + nscd service caches information about + users, groups, and various other types of information. + Caching is especially helpful if you choose to + distribute information about users and groups over your + network using NIS, LDAP, or hesiod. +

`bootloader`

bootloader (required)

Specifies how the boot loader should be installed and whether + the boot loader should be LILO or GRUB. +

--append: Specifies kernel parameters.
--location=: Specifies where the boot record is written. Valid + values are the following: mbr + (the default), partition + (installs the boot loader on the first sector of the + partition containing the kernel), or + none (do not install the boot + loader). +
--password=mypassword: If using GRUB, sets the GRUB boot loader password to + mypassword. This should be + used to restrict access to the GRUB shell where + arbitrary kernel options can be passed. +
--md5pass=mypassword: If using GRUB, similar to --password + except mypassword should be + the password already encrypted. +
--useLilo: Use LILO instead of GRUB as the boot loader. +
--linear: If using LILO, use the linear LILO + option; this is only for backwards compatibility (and + linear is now used by default). +
--nolinear: If using LILO, use the nolinear LILO + option; linear is the default. +
--lba32: If using LILO, force use of lba32 mode instead of + autodetecting. +
--upgrade + [1]: Upgrade the existing boot loader configuration. This + option is only available for upgrades. +

`clearpart`

clearpart (optional)

Removes partitions from the system, prior to creation of new + partitions. By default, no partitions are removed. +

--linux: Erases all Linux partitions.
--all: Erases all partitions from the system.
--drives: Specifies which drives to clear partitions from.
--initlabel: Initializes the disk label to the default for your + architecture (msdos for x86 and + gpt for Itanium). It is useful so + that the installation program does not ask if it should + initialize the disk label if installing to a brand new + hard drive. +

	Note
	If the `clearpart` command, then the + `--onpart` command cannot be used on a logical + partition. +

`device`

device (optional)

On most PCI systems, the installation program will autoprobe for + Ethernet and SCSI cards properly. On older systems and some PCI + systems, however, kickstart needs a hint to find the proper + devices. The device command, which tells + Anaconda to install extra modules, is + in this format: +

device <type> <moduleName> --opts <options>

<type> should be + scsi or eth, and + <moduleName> is the name of the + kernel module which should be installed. +

--opts

Options to pass to the kernel module. Note that multiple + options may be passed if they are put in quotes. For + example: +

--opts "aic152x=0x340 io=11"

`deviceprobe`

deviceprobe (optional): Forces a probe of the PCI bus and loads modules for all the + devices found if a module is available. +

`driverdisk`

driverdisk (optional)

Driver disks can be used during kickstart installations. You + will need to copy the driver disk's contents to the root + directory of a partition on the system's hard drive. Then you + will need to use the driverdisk command to + tell the installation program where to look for the driver disk. +

driverdisk <partition> [--type <fstype>]

<partition> is the partition + containing the driver disk. +

--type: Filesystem type (for example, vfat, ext2, or ext3).

`firewall`

firewall (optional)

Firewall options can be configured in kickstart. This + configuration corresponds to the Firewall + Configuration screen in the installation program. +

firewall [--high | --medium | --disabled] [--trust <device>] [--dhcp] [--ssh]	[--telnet] [--smtp] [--http] [--ftp] [--port <portspec>]

Levels of security

Choose one of the following levels of security:

--high
--medium
--disabled

--trust + <device>

Listing a device here, such as eth0, allows all traffic coming + from that device to go through the firewall. To list more than + one device, use --trust eth0 --trust eth1. Do + NOT use a comma-separated format such as --trust eth0, + eth1. +

Allow incoming

Enabling these options allow the specified services to pass + through the firewall.

--dhcp
--ssh
--telnet
--smtp
--http
--ftp

--port <portspec>

You can specify that ports be allowed through the firewall using + the port:protocol format. For example, if you wanted to allow + IMAP access through your firewall, you can specify + imap:tcp. You can also specify numeric ports + explicitly; for example, to allow UDP packets on port 1234 + through, specify 1234:udp. To specify + multiple ports, separate them by commas. +

`install`

install (optional): Tells the system to install a fresh system rather than upgrade + an existing system. This is the default mode. +

Installation Methods

You must use one of these four commands to specify what type of + kickstart installation is being performed: +

nfs

Install from the NFS server specified. +

--server + <server>
Server from which to install (hostname or IP).
--dir <dir>
Directory containing the Red Hat installation tree.

For example:

nfs --server <server> --dir <dir>

cdrom

Install from the first CD-ROM drive on the system.

For example: +

cdrom

harddrive

Install from a Red Hat installation tree on a local drive, which + must be either vfat or ext2. +

--partition <partition>
Partition to install from (such as, sdb2).
--dir <dir> +
Directory containing the Red Hat installation tree. +

For example:

harddrive --partition <partition> --dir <dir>

url

Install from a Red Hat installation tree on a remote server via FTP + or HTTP.

For example:

url --url http://<server>/<dir>

url --url ftp://<username>:<password>@<server>/<dir>

`interactive`

interactive (optional): Uses the information provided in the kickstart file during the + installation, but allow for inspection and modification of the + values given. You will be presented with each screen of the + installation program with the values from the kickstart + file. Either accept the values by clicking + Next or change the values and click + Next to continue. See also + the Section called autostep. +

`keyboard`

keyboard (required)

Sets system keyboard type. Here is the list of available + keyboards on i386, Itanium, 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, br-abnt2, 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 is 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

`lang`

lang (required) + +

Sets the language to use during installation. For example, to + set the language to English, the kickstart file should contain + the following line: +

lang en_US

Valid language codes are the following (please note that these + are subject to change at any time): +

cs_CZ, da_DK, en_US, fr_FR, de_DE, is_IS, it_IT, ja_JP.eucJP, 
+ko_KR.eucKR, no_NO, pt_PT, ru_RU.koi8r, sl_SI, es_ES, sv_SE, uk_UA

`langsupport`

langsupport (required)

Sets the language(s) to install on the system. The same + language codes used with lang can be used + with langsupport. +

If you just want to install one language, specify it. For + example, to install and use the French language + fr_FR: +

langsupport fr_FR

--default: If you want to install language support for more than + one language, you must specify a default. +

For example, to install English and French and use English as the + default language: +

langsupport --default en_US fr_FR

If you use --default with only one language, + all languages will be installed with the specified language set + to the default. +

`lilo`

lilo (replaced by bootloader)

	Warning
	This option has been replaced by `bootloader` + and is only available for backwards compatibility. Refer to + the Section called `bootloader`. +

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). +

--append + <params>: Specifies kernel parameters.
--linear: Use the linear LILO option; this is + only for backwards compatibility (and linear is now used + by default). +
--nolinear: Use the nolinear LILO option; linear + is now used by default. +
--location=: Specifies where the LILO boot record is written. Valid + values are the following: mbr + (the default) or partition + (installs the boot loader on the first sector of the + partition containing the kernel). If no location is + specified, LILO is not installed. +
--lba32: Forces the use of lba32 mode instead of autodetecting.

`lilocheck`

lilocheck (optional): If lilocheck is present, the installation + program checks for LILO on the MBR of the first hard drive, and + reboots the system if it is found — in this case, no + installation is performed. This can prevent kickstart from + reinstalling an already installed system. +

`mouse`

mouse (required)

Configures the mouse for the system, both in GUI and text + modes. Options are: +

--device + <dev>

Device the mouse is on (such as --device ttyS0).

--emulthree

If present, simultaneous clicks on the left and right + mouse buttons will be recognized as the middle mouse + button by the X Window System. This option should + be used if you have a two button mouse. +

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, genericusb, generic3usb, 
+geniusnm, geniusnmps/2,geniusprops/2, geniusscrollps/2, 
+geniusscrollps/2+, thinking, thinkingps/2, logitech, 
+logitechcc, logibm, logimman, logimmanps/2, logimman+, 
+logimman+ps/2, logimmusb, microsoft, msnew, msintelli, 
+msintellips/2, msintelliusb, 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. This procedure works for most + modern mice. +

`network`

network (optional)

Configures network information for the system. If the kickstart + installation does not require networking (in other words, it is + not installed over NFS, HTTP, or FTP), networking is not + configured for the system. If the installation does require + networking and network information is not provided in the + kickstart file, the Red Hat Linux installation program assumes that the + installation should be done over eth0 via a dynamic IP address + (BOOTP/DHCP), and configures the final, installed system to + determine its IP address dynamically. The + network option configures networking + information for kickstart installations via a network as well as + for the installed system. +

--bootproto

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. +

--device <device>

Used to select a specific Ethernet device for + installation. Note that using + --device + <device> will not be + effective unless the kickstart file is a local file + (such as ks=floppy), since the + installation program will configure the network to find + the kickstart file. Example: +

network --bootproto dhcp --device eth0

--ip

IP address for the machine to be installed.

--gateway

Default gateway as an IP address.

--nameserver

Primary nameserver, as an IP address.

--nodns

Do not configure any DNS server.

--netmask

Netmask for the installed system.

--hostname

Hostname for the installed system.

There are three different methods of network configuration:

DHCP
BOOTP
static

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 must specify: +

IP address
Netmask
Gateway IP address
Nameserver IP address

Here is 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}

If you use the static method, be aware of the following two + restrictions:

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 nameserver 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. +

`part`

part or partition (required for installs, ignored for + upgrades)

Creates a partition on the system.

The <mntpoint> is where the + partition will be mounted and must be of one of the following + forms: +

/<mntpoint>

For example, /, + /usr, /home +

swap

The partition will be used as swap space.

To determine the size of the swap partition + automatically, use the + --recommended[1] option:

swap --recommended

The minimum size of the automatically-generated swap + partition will be no smaller than the amount of RAM in the + system and no bigger than twice the amount of RAM in the + system.

raid.<id>

The partition will be used for software RAID (see the + the Section called raid below). +

--size <size>

The minimum partition size in megabytes. Specify an + integer value here such as 500. Do not append the number + with MB. +

--grow

Tells the partition to grow to fill available space (if + any), or up to the maximum size setting. +

--maxsize <size>

The maximum partition size in megabytes when the + partition is set to grow. Specify an integer value here, + and do not append the number with MB. +

--noformat

Tells the installation program not to format the + partition, for use with the --onpart + command. +

--onpart <part> or + --usepart <part>

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. If you use --onpart, you still + must specify a size with --size for + the file to be parsed correctly. The size will be + ignored since the partition already exists. +

--ondisk + <disk> or + --ondrive <drive>

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. +

--asprimary

Forces automatic allocation of the partition as a + primary partition or the partitioning will fail. +

--bytes-per-inode=<N>

<N> represents the + number of bytes per inode on the filesystem when it is + created. It must be given in decimal format. This + option is useful for applications where you want to + increase the number of inodes on the filesystem. +

--type=<X> + (replaced by fstype)

This option is no longer available. Use + fstype. +

--fstype

Sets the filesystem type for the partition. Valid + values are ext2, + ext3, + swap, and + vfat. +

--start

Specifies the starting cylinder for the partition. It + requires that a drive be specified with + --ondisk or + ondrive. It also requires that the + ending cylinder be specified with + --end or the partition size be + specified with --size. +

--end

Specifies the ending cylinder for the partition. It + requires that the starting cylinder be specified with + --start. +

--badblocks

Specifies that the partition should be checked for bad + sectors. +

All partitions created will be formatted as part of the + installation process unless --noformat and + --onpart are used. +

	Note
	If partitioning fails for any reason, diagnostic messages will + appear on virtual console 3. +

`raid`

raid (optional)

Assembles a software RAID device. This command is of the form:

raid <mntpoint> --level <level> --device <mddevice><partitions*>

The <mntpoint> is the location + where the RAID filesystem is mounted. If it is + /, the RAID level must be 1 unless a boot + partition (/boot) is present. If a boot + partition is present, the /boot partition + must 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. +

--level <level>: RAID level to use (0, 1, or 5).
--device <mddevice>: Name of the RAID device to use (such as md0 or md1). + RAID devices range from md0 to md7, and each may only be + used once. +
--spares=N: Specifies that there should be N spare drives allocated + for the RAID array. Spare drives are used to rebuild the + array in case of drive failure. +
--fstype: Sets the filesystem type for the RAID array. Valid values + are ext2, ext3, swap, and vfat. +
--noformat: Do not format the RAID array.

The following example shows 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`

reboot (optional): Reboot after the installation is complete (no + arguments). Normally, kickstart displays a message and waits for + the user to press a key before rebooting. +

`rootpw`

rootpw (required)

rootpw [--iscrypted] <password>

Sets the system's root password to the + <password> argument.

--iscrypted: If this is present, the password argument is assumed to + already be encrypted.

`skipx`

skipx (optional): If present, X is not configured on the installed system.

`text`

text (optional): Perform the kickstart installation in text mode. Kickstart + installations are performed in graphical mode by default.

`timezone`

timezone (required)

timezone [--utc] <timezone>

Sets the system time zone to + <timezone> which may be any of + the time zones listed by timeconfig. +

--utc: If present, the system assumes the hardware clock is set + to UTC (Greenwich Mean) time. +

`upgrade`

upgrade (optional): Tells the system to upgrade an existing system rather than + install a fresh system. +

`xconfig`

xconfig (optional)

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. +

--noprobe: Do not probe the monitor.
--card <card>: 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. Since AGP is part of the PCI bus, + AGP cards will be detected if supported. The probe order + is determined by the PCI scan order of the motherboard. +
--videoram <vram>: Specify the amount of video RAM the video card has.
--monitor <mon>: 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 installation + program tries to probe for it automatically. +
--hsync <sync>: Specifies the horizontal sync frequency of the monitor.
--vsync <sync>: Specifies the vertical sync frequency of the monitor.
--defaultdesktop=GNOME or + --defaultdesktop=KDE: Sets the default desktop to either GNOME or KDE (and + assumes that GNOME and/or KDE has been installed through + %packages). +
--startxonboot: Use a graphical login on the installed system.
--resolution <res>: Specify the default resolution for the X Window System + on the installed system. Valid values are 640x480, + 800x600, 1024x768, 1152x864, 1280x1024, 1400x1050, + 1600x1200. Be sure to specify a resolution that is + compatible with the video card and monitor. +
--depth <cdepth>: Specify the default color depth for the X Window System + on the installed system. Valid values are 8, 16, 24, and + 32. Be sure to specify a color depth that is + compatible with the video card and monitor. +

`zerombr` — Partition Table + Initialization

zerombr (optional)

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 in the following format: +

zerombr yes

No other format is effective. +

`%packages` — Package Selection

Use the %packages command to begin a kickstart file + section that lists the packages you would like to install (this is for + installations only, as package selection during upgrades is not + supported). +

Use the %packages --resolvedeps[1] to install the listed packages and automatically + resolve package dependencies. +

Use the %packages --ignoredeps[1] to ignore the unresolved dependencies and + install the listed packages without the dependencies. +

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: +

Architecture specific (i386:, ia64:, alpha:, and sparc64:)

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: apmd you only + need to use the apmd part for + that specific package to be installed. +

Lines beginning with ?

Lines that begin with a ? are used by the + installation program and should not be altered. +

Lines beginning with --hide

If a package name begins with --hide, you + only need to type in the package name, without the + --hide. For example: +

For --hide Network Server you only need to + use the Network Server part for that + specific package to be installed. +

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

Here is an example %packages selection: +

%packages
+@ Network Managed Workstation
+@ Development
+@ Web Server
+@ X Window System
+ImageMagick

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 + ImageMagick line in the example above is an + individual package). +

You can also direct the kickstart installation to install the + default packages for a workstation (KDE or GNOME) or server + installation (or choose an everything installation to install all + packages). To do this, simply add one of the + following lines to the %packages section: +

@ GNOME
+@ KDE
+@ Server
+@ Everything

`%pre` — Pre-Installation Configuration + Section

You can add commands to run on the system immediately after the + ks.cfg has been parsed. This section must be at + the end of the kickstart file (after the commands) and must start with + the %pre command. Note that 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. Here is an example + %pre section: +

%pre
+	
+# 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. It also gets around the + network command's limitation of only one name + server by adding another nameserver to + /etc/resolv.conf. +

	Note
	Note that the pre-install script is not run in the change root + environment. +

`%post` — Post-Installation Configuration + Section

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

If you configured the network with static IP information, including + a nameserver, you can access the network and resolve IP addresses in + the %post section. If you configured the network + for DHCP, the /etc/resolv.conf file has not + been completed when the installation executes the + %post section. You can access the network, + but you can not resolve IP addresses. Thus, if you are using DHCP, + you must specify IP addresses in the %post + section. +

Here is an example %post section that creates a + message of the day file containing the date that the kickstart + installation took place, and gets around the + network command's limitation of one nameserver + only by adding another nameserver to + /etc/resolv.conf. +

%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

	Note
	The post-install script is run in a chroot environment; therefore, + performing tasks such as copying scripts or RPMs from the + installation media will not work. +

--nochroot

Allows you to specify commands that you would like to run + outside of the chroot environment. +

The following example copies the file + /etc/resolv.conf to the filesystem that was + just installed. +
%post --nochroot +cp /etc/resolv.conf /mnt/sysimage/etc/resolv.conf
+

--interpreter /usr/bin/perl

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

The following example uses a Perl script to replace + /etc/HOSTNAME. +

%post --interpreter /usr/bin/perl
+
+# replace /etc/HOSTNAME
+open(HN, ">HOSTNAME");
+print HN "1.2.3.4 an.ip.address\n";

`%include` — Include Contents of Another File + Section [1]

Use the %include + /path/to/file command to include + the contents of another file in the kickstart file as though the + contents were at the location of the %include + command in the kickstart file. +

Chapter 4. Where to Put A Kickstart File

A kickstart file must be placed in one of two locations: +

On a boot disk
On a network

Normally a kickstart file is copied to the boot disk, or made + available on the network. The network-based approach is most commonly + used, as most kickstart installations tend to be performed on + networked computers. +

Let us take a more in-depth look at where the kickstart + file may be placed. +

Creating a Kickstart Boot Disk

To perform a diskette-based kickstart installation, the kickstart file + must be named ks.cfg and must be located in the + boot disk's top-level directory. Note that the Red Hat Linux boot disks are in + MS-DOS format, so it is easy to copy the kickstart file under Linux + using the mcopy command: +

mcopy ks.cfg a:

Alternatively, you can use Windows to copy the file. You can also + mount the MS-DOS boot disk and cp the file + over. +

Making the Kickstart File Available on the Network

Network installations using kickstart are quite common, + because system administrators can easily + automate the installation on many networked computers quickly and + painlessly. In general, the approach most commonly used is for the + administrator to have both a BOOTP/DHCP server and an NFS server on + the local network. The BOOTP/DHCP server is used to give the client + system its networking information, while the actual files used during + the installation are served by the NFS server. Often, these two + servers run on the same physical machine, but they are not required + to. +

To perform a network-based kickstart installation, you must have a + BOOTP/DHCP server on your network, and it must include configuration + information for the machine on which you are attempting to install + Red Hat Linux. The BOOTP/DHCP server will provide the client with its + networking information as well as the location of the kickstart file. +

If a kickstart file is specified by the BOOTP/DHCP server, the client + system will attempt an NFS mount of the file's path, and will copy the + specified file to the client, using it as the kickstart file. The + exact settings required vary depending on the BOOTP/DHCP server you + use. +

Here is an example of a line from the dhcpd.conf + file for the DHCP server shipped with Red Hat Linux: +

filename "/usr/new-machine/kickstart/";
+next-server blarg.redhat.com;

Note that you should replace the value after + filename with the name of the + kickstart file (or the directory in which the kickstart file + resides) and the value after + next-server + with the NFS server name. +

If the filename returned by the BOOTP/DHCP server ends with a slash + ("/"), then it is interpreted as a path only. In this case, the + client system mounts that path using NFS, and searches for a + particular file. The filename the client searches for is: +

<ip-addr>-kickstart

The <ip-addr> + section of the filename should be replaced with the client's IP + address in dotted decimal notation. For example, the filename for a + computer with an IP address of 10.10.0.1 would be + 10.10.0.1-kickstart. +

Note that if you do not specify a server name, then the client system + will attempt to use the server that answered the BOOTP/DHCP request as + its NFS server. If you do not specify a path or filename, the client + system will try to mount /kickstart from the + BOOTP/DHCP server, and will try to find the kickstart file using the + same + <ip-addr>-kickstart + filename as described above. +

Chapter 5. Starting a Kickstart Installation

To begin a kickstart installation, you must boot the system from a Red Hat Linux + boot diskette or the CD-ROM and enter a special boot command at the boot prompt. If the + kickstart file is located on a boot diskette that was created from the + boot.img or bootnet.img image + file, the correct boot command would be: +

boot: linux ks=floppy

The linux ks=floppy command also works if the + ks.cfg file is located on a vfat or ext2 filesystem on a + floppy diskette and you boot from the Red Hat Linux CD-ROM. +

An alternate boot command for booting off the Red Hat Linux CD-ROM and having the + kickstart file on a vfat or ext2 filesystem on a floppy diskette is: +

boot: linux ks=hd:fd0/ks.cfg

If you need to use a driver disk with kickstart, you can still have the + kickstart file on a floppy disk: +

boot: linux ks=floppy dd

The Red Hat Linux installation program looks for a kickstart file if the + ks command line argument is passed to the kernel. + The command line argument can take a number of forms: +

ks=nfs:<server>/<path>

The installation program will look for the kickstart file on the NFS + server <server>, as file + <path>. The installation program + will use DHCP to configure the Ethernet card. For example, if your + NFS server is server.example.com and the kickstart file is in the + NFS share /mydir/ks.cfg, the correct boot command would be + ks=nfs:server.example.com:/mydir/ks.cfg. +

ks=http:<server>/<path>

The installation program will look for the kickstart file on the HTTP + server <server>, as file + <path>. The installation program + will use DHCP to configure the Ethernet card. For example, if your + HTTP server is server.example.com and the kickstart file is in the + HTTP directory /mydir/ks.cfg, the correct boot command would be + ks=http:server.example.com:/mydir/ks.cfg. +

ks=floppy

The installation program looks for the file + ks.cfg on a vfat or ext2 filesystem on the floppy in + drive /dev/fd0. +

ks=hd:<device>/<file>

The installation program will mount the filesystem on + <device> (which must be vfat or + ext2), and look for the kickstart configuration file as + <file> in that filesystem (for + example, ks=hd:sda3/mydir/ks.cfg). +

ks=file:/<file>

The installation program will try to read the file + <file> from the filesystem; no + mounts will be done. This is normally used if the kickstart file + is already on the initrd image. +

ks=cdrom:/<path>

The installation program will look for the kickstart file on + CD-ROM, as file <path>. +

ks

If ks is used alone, the installation program + will configure the Ethernet card in the system using DHCP. The + system will use the "bootServer" from the DHCP response as an NFS + server to read the kickstart file from (by default, this is the + same as the DHCP server). The name of the kickstart file is one + of the following: +

If DHCP is specified and the bootfile begins with a + /, the bootfile provided by DHCP is looked for + on the NFS server. +
If DHCP is specified and the bootfile begins with + something other then a /, + the bootfile provided by DHCP is looked for in the + /kickstart directory on the NFS server. +
If DHCP did not specify a bootfile, then the installation + program tries to read the file + /kickstart/1.2.3.4-kickstart, where + 1.2.3.4 is the numeric IP address + of the machine being installed. +

ksdevice=<device>

The installation program will use this network device to connect + to the network. For example, to start a kickstart installation + with the kickstart file on an NFS server that is connected to the + system through the eth1 device, use the command + ks=nfs:<server:>/<path> + ksdevice=eth1 at the boot: prompt. +

Notes