Anaconda/Kickstart-part3


Chapter 5. Post-installation Script


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. This section is useful for functions such as installing additional software and configuring an additional nameserver.



Postinstallation scripts should be closed with %end, though this is not yet required. It will be required in the future, however.



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.



If your script spawns a daemon process, you must make sure to close stdout and stderr. Doing so is standard procedure for creating daemons. If you do not close these file descriptors, the installation will appear hung as anaconda waits for an EOF from the script.



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.

--interpreter /usr/bin/python

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

--erroronfail

If the post-installation script fails, this option will cause an error dialog to be displayed and will halt installation. The error message will direct you to where the cause of the failure is logged.

--log=

Log all messages from the script to the given log file.

Examples

Run a script named runme from an NFS share:



%post

mkdir /mnt/temp

mount 10.10.0.2:/usr/new-machines /mnt/temp

open -s -w -- /mnt/temp/runme

umount /mnt/temp

%end

Copy the file /etc/resolv.conf to the file system that was just installed:



%post --nochroot

cp /etc/resolv.conf /mnt/sysimage/etc/resolv.conf

%end

Chapter 6. Making the Kickstart File Available

A kickstart file must be placed in one of the following locations:



On a boot diskette

On a boot CD-ROM

On a network

Normally a kickstart file is copied to the boot diskette, 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 Diskette

To perform a diskette-based kickstart installation, the kickstart file must be named ks.cfg and must be located in the boot diskette's top-level directory. Refer to the section Making an Installation Boot Diskette in the Red Hat Enterprise Linux Installation Guide for instruction on creating a boot diskette. Because the boot diskettes are in MS-DOS format, 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 diskette in Red Hat Enterprise Linux with the file system type vfat and use the cp command to copy the file on the diskette.



Creating a Kickstart Boot CD-ROM

To perform a CD-ROM-based kickstart installation, the kickstart file must be named ks.cfg and must be located in the boot CD-ROM's top-level directory. Since a CD-ROM is read-only, the file must be added to the directory used to create the image that is written to the CD-ROM. Refer to the Making an Installation Boot CD-ROM section in the Red Hat Enterprise Linux Installation Guide for instruction on creating a boot CD-ROM; however, before making the file.iso image file, copy the ks.cfg kickstart file to the isolinux/ directory.



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



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 7. Making the Installation Tree Available

The kickstart installation needs to access an installation tree. An installation tree is a copy of the binary Red Hat Enterprise Linux CD-ROMs with the same directory structure.



If you are performing a CD-based installation, insert the Red Hat Enterprise Linux CD-ROM #1 into the computer before starting the kickstart installation.



If you are performing a hard-drive installation, make sure the ISO images of the binary Red Hat Enterprise Linux CD-ROMs are on a hard drive in the computer.



If you are performing a network-based (NFS, FTP, or HTTP) installation, you must make the installation tree available over the network. Refer to the Preparing for a Network Installation section of the Red Hat Enterprise Linux Installation Guide for details.



Chapter 8. Starting a Kickstart Installation

To begin a kickstart installation, you must boot the system from a Red Hat Enterprise Linux boot diskette, Red Hat Enterprise Linux boot CD-ROM, 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.



Boot Diskette

If the kickstart file is located on a boot diskette as described in the Section called Creating a Kickstart Boot Diskette in Chapter 6, boot the system with the diskette in the drive, and enter the following command at the boot: prompt:



linux ks=floppy



CD-ROM #1 and Diskette

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



With Driver Disk

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



Boot CD-ROM

If the kickstart file is on a boot CD-ROM as described in the Section called Creating a Kickstart Boot CD-ROM in Chapter 6, 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 kickstart options:

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 file system on the diskette in /dev/fd0.

ks=floppy:/<path>



The installation program will look for the kickstart file on the diskette in /dev/fd0, as file <path>.

ks=hd:<device>:/<file>



The installation program will mount 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).

ks=bd:<biosdev>:/<path>



The installation program will mount the file system on the specified partition on the specified BIOS device <biosdev> (for example, ks=bd:80p3:/mydir/ks.cfg). Note this does not work for BIOS RAID sets.

ks=file:/<file>



The installation program will try to read the file <file> from the file system; 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 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 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. For more information, see Anaconda_Boot_Options.