28.10. Starting a Kickstart Installation
To begin a kickstart installation, you must boot the system from boot media you have made or the Red Hat Enterprise Linux CD-ROM #1, and enter a special boot command at the boot prompt. The installation program looks for a kickstart file if the ks command line argument is passed to the kernel.
The linux ks=floppy command also works if the ks.cfg file is located on a vfat or ext2 file system on a diskette and you boot from the Red Hat Enterprise Linux CD-ROM #1.
An alternate boot command is to boot off the Red Hat Enterprise Linux CD-ROM #1 and have the kickstart file on a vfat or ext2 file system on a diskette. To do so, enter the following command at the boot: prompt:
linux ks=hd:fd0:/ks.cfg
If you need to use a driver disk with kickstart, specify the dd option as well. For example, to boot off a boot diskette and use a driver disk, enter the following command at the boot: prompt:
linux ks=floppy dd
If the kickstart file is on a boot CD-ROM as described in Section 28.8.1, “Creating Kickstart Boot Media”, insert the CD-ROM into the system, boot the system, and enter the following command at the boot: prompt (where ks.cfg is the name of the kickstart file):
linux ks=cdrom:/ks.cfg
Other options to start a kickstart installation are as follows:
Do not automatically use the CD-ROM as the install source if we detect a Red Hat Enterprise Linux CD in your CD-ROM drive.
Make kickstart non-interactive.
Make kickstart non-interactive.
Start up pdb immediately.
Use a driver disk.
Sends a custom DHCP vendor class identifier. ISC's dhcpcd can inspect this value using "option vendor-class-identifier".
Comma separated list of nameservers to use for a network installation.
Same as 'dd'.
Turns on special features:
allows partitioning of removable media
prompts for a driver disk
Gateway to use for a network installation.
Force graphical install. Required to have ftp/http use GUI.
Prompt user for ISA devices configuration.
IP to use for a network installation, use 'dhcp' for DHCP.
Keyboard layout to use. Valid values are those which can be used for the 'keyboard' kickstart command.
The installation program looks for the kickstart file on the NFS server <server>, as file <path>. The installation program uses 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.
The installation program looks for the kickstart file on the HTTP server <server>, as file <path>. The installation program uses 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.
The installation program looks for the file ks.cfg on a vfat or ext2 file system on the diskette in /dev/fd0.
The installation program looks for the kickstart file on the diskette in /dev/fd0, as file <path>.
The installation program mounts the file system on <device> (which must be vfat or ext2), and look for the kickstart configuration file as <file> in that file system (for example, ks=hd:sda3:/mydir/ks.cfg).
The installation program tries to read the file <file> from the file system; no mounts are done. This is normally used if the kickstart file is already on the initrd image.
The installation program looks for the kickstart file on CD-ROM, as file <path>.
If ks is used alone, the installation program configures the Ethernet card to use DHCP. The kickstart file is read from the "bootServer" from the DHCP response as if it is an NFS server sharing the kickstart file. By default, the bootServer is the same as the DHCP server. The name of the kickstart file is one of the following:
If DHCP is specified and the boot file begins with a /, the boot file provided by DHCP is looked for on the NFS server.
If DHCP is specified and the boot file begins with something other than a /, the boot file provided by DHCP is looked for in the /kickstart directory on the NFS server.
If DHCP did not specify a boot file, 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.
The installation program uses 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.
Adds HTTP headers to ks=http:// request that can be helpful for provisioning systems. Includes MAC address of all nics in CGI environment variables of the form: "X-RHN-Provisioning-MAC-0: eth0 01:23:45:67:89:ab".
Language to use for the installation. This should be a language which is valid to be used with the 'lang' kickstart command.
Set the minimum level required for messages to be logged. Values for <level> are debug, info, warning, error, and critical. The default value is info.
Force GUI installer to run at 640x480.
Activates loader code to give user option of testing integrity of install source (if an ISO-based method).
Do a CDROM based installation.
Use <path> for an FTP installation.
Use <path> on <dev> for a hard drive installation.
Use <path> for an HTTP installation.
Use <path> for an NFS installation.
Netmask to use for a network installation.
If GUI fails exit.
Do not load the VGA16 framebuffer required for doing text-mode installation in some languages.
Do not load support for firewire devices.
Disable IPv6 networking during installation.
A debugging option that prevents anaconda from terminating all running programs when a fatal error occurs.
Don't automatically mount any installed Linux partitions in rescue mode.
Do not auto-probe network devices.
Do not attempt to load support for parallel ports.
Don't pass keyboard/mouse info to stage 2 installer, good for testing keyboard and mouse config screens in stage2 installer during network installs.
Ignore PCMCIA controller in system.
Do not attempt to detect hw, prompts user instead.
Do not put a shell on tty2 during install.
Do not auto-probe storage devices (SCSI, IDE, RAID).
Do not load USB support (helps if install hangs early sometimes).
Do not load usbstorage module in loader. May help with device ordering on SCSI systems.
Run rescue environment.
Run installer in mode specified, '1024x768' for example.
Turns on serial console support.
Skips DDC probe of monitor, may help if it's hanging system.
Once installation is up and running, send log messages to the syslog process on <host>, and optionally, on port <port>. Requires the remote syslog process to accept connections (the -r option).
Force text mode install.
Prompt for floppy containing updates (bug fixes).
Image containing updates over FTP.
Image containing updates over HTTP.
Don't require an /etc/redhat-release that matches the expected syntax to upgrade.
Enable vnc-based installation. You will need to connect to the machine using a vnc client application.
Once installation is up and running, connect to the vnc client named <host>, and optionally use port <port>.
Requires 'vnc' option to be specified as well.
Enable a password for the vnc connection. This will prevent someone from inadvertently connecting to the vnc-based installation.
Requires 'vnc' option to be specified as well.