| Installation GuideYou can use a kickstart file to install every available package by specifying * in the %packages section. Red Hat does not support this type of installation. In previous releases of Red Hat Enterprise Linux, this functionality was provided by @Everything, but this is not included in Red Hat Enterprise Linux 6. 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). You can specify packages by group or by their package names. The installation program defines several groups that contain related packages. Refer to the variant/repodata/comps-*.xmlmandatory in the package list are always installed, the packages marked default are installed if they are not specifically excluded elsewhere, and the packages marked optional must be specifically included elsewhere even when the group is selected. Specify groups, one entry to a line, starting with an @ symbol, a space, and then the full group name or group id as given in the comps.xml file. For example: %packages @ X Window System @ Desktop @ Sound and Video Note that the Core and Base groups are always selected by default, so it is not necessary to specify them in the %packages section. Specify individual packages by name, one entry to a line. You can use asterisks as wildcards to glob package names in entries. For example: sqlitecurlaspelldocbook* The docbook* entry includes the packages docbook-dtds, docbook-simple, docbook-slides and others that match the pattern represented with the wildcard. Use a leading dash to specify packages or groups to exclude from the installation. For example: -@ Graphical Internet -autofs-ipa*fonts To install a 32-bit package on a 64-bit system, you will need to append the package name with the 32-bit architecture the package was built for. For example: glibc.i686 Using a kickstart file to install every available package by specifying * will introduce package and file conflicts onto the installed system. Packages known to cause such problems are assigned to the @Conflicts (variant) group, where variant is Client, ComputeNode, Server or Workstation. If you specify * in a kickstart file, be sure to exclude @Conflicts (variant) or the installation will fail: *-@Conflicts (Server) Note that Red Hat does not support the use of * in a kickstart file, even if you exclude @Conflicts (variant). The following options are available for the %packages option: --nobaseDo not install the @Base group. Use this option to perform a minimal installation, for example, for a single-purpose server or desktop appliance. --resolvedepsThe --resolvedeps option has been deprecated. Dependencies are now always resolved automatically. --ignoredepsThe --ignoredeps option has been deprecated. Dependencies are resolved automatically every time now. --ignoremissingIgnore the missing packages and groups instead of halting the installation to ask if the installation should be aborted or continued. For example: %packages --ignoremissing
32.6. Pre-installation ScriptYou can add commands to run on the system immediately after the ks.cfg has been parsed. This section must be placed towards the end of the kickstart file, after the kickstart commands described in Section 32.4, "Kickstart Options", and must start with the %pre command. If your kickstart file also includes a %post section, the order of the %pre and %post sections does not matter. You can access the network in the %pre section; however, name service has not been configured at this point, so only IP addresses work. Note that the pre-install script is not run in the change root environment. --interpreter /usr/bin/pythonAllows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice.
Here is an example %pre section: %pre #!/bin/sh hds="" mymedia="" for file in /proc/ide/h* do mymedia=`cat $file/media` if [ $mymedia == "disk" ] ; then hds="$hds `basename $file`" fi done set $hds numhd=`echo $#` drive1=`echo $hds | cut -d' ' -f1` drive2=`echo $hds | cut -d' ' -f2` #Write out partition scheme based on whether there are 1 or 2 hard drives if [ $numhd == "2" ] ; then #2 drives echo "#partitioning scheme generated in %pre for 2 drives" > /tmp/part-include echo "clearpart --all" >> /tmp/part-include echo "part /boot --fstype ext3 --size 75 --ondisk hda" >> /tmp/part-include echo "part / --fstype ext3 --size 1 --grow --ondisk hda" >> /tmp/part-include echo "part swap --recommended --ondisk $drive1" >> /tmp/part-include echo "part /home --fstype ext3 --size 1 --grow --ondisk hdb" >> /tmp/part-include else #1 drive echo "#partitioning scheme generated in %pre for 1 drive" > /tmp/part-include echo "clearpart --all" >> /tmp/part-include echo "part /boot --fstype ext3 --size 75" >> /tmp/part-includeecho "part swap --recommended" >> /tmp/part-include echo "part / --fstype ext3 --size 2048" >> /tmp/part-include echo "part /home --fstype ext3 --size 2048 --grow" >> /tmp/part-include fi This script determines the number of hard drives in the system and writes a text file with a different partitioning scheme depending on whether it has one or two drives. Instead of having a set of partitioning commands in the kickstart file, include the line: %include /tmp/part-include The partitioning commands selected in the script are used. The pre-installation script section of kickstart cannot manage multiple install trees or source media. This information must be included for each created ks.cfg file, as the pre-installation script occurs during the second stage of the installation process. 32.7. Post-installation ScriptYou have the option of adding commands to run on the system once the installation is complete. This section must be placed towards the end of the kickstart file, after the kickstart commands described in Section 32.4, "Kickstart Options", and must start with the %post command. If your kickstart file also includes a %pre section, the order of the %pre and %post sections does not matter. This section is useful for functions such as installing additional software and configuring an additional nameserver. 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. The post-install script is run in a chroot environment; therefore, performing tasks such as copying scripts or RPMs from the installation media do not work. --nochrootAllows 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 file system that was just installed. %post --nochroot cp /etc/resolv.conf /mnt/sysimage/etc/resolv.conf --interpreter /usr/bin/pythonAllows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice. --log /path/to/logfileLogs the output of the post-install script. Note that the path of the log file must take into account whether or not you use the --nochroot option. For example, without --nochroot: %post --log=/root/ks-post.log with --nochroot: %post --nochroot --log=/mnt/sysimage/root/ks-post.log
Example 32.1. Registering and Then Mounting an NFS Share Register the system to a Red Hat Subscription Management server (in this example, a local Subscription Asset Manager server): %post --log=/root/ks-post.log/usr/sbin/subscription-manager register [email protected] --password=secret --serverurl=sam-server.example.com --org="Admin Group" --environment="Dev" Run a script named runme from an NFS share: mkdir /mnt/temp mount -o nolock 10.10.0.2:/usr/new-machines /mnt/temp openvt -s -w -- /mnt/temp/runme umount /mnt/temp NFS file locking is not supported while in kickstart mode, therefore -o nolock is required when mounting an NFS mount. 32.7.2. Running subscription-manager as a Post-Install ScriptThe subscription-manager command-line script registers a system to a Red Hat Subscription Management server (Customer Portal Subscription Management, Subscription Asset Manager, or CloudForms System Engine). This script can also be used to assign or attach subscriptions automatically to the system that best-match that system. When registering to the Customer Portal, use the Red Hat network login credentials. When registering to Subscription Asset Manager or CloudForms System Engine, use whatever user account was created by the local administrator. Additional options can be used with the registration command to set a preferred service level for the system and to restrict updates and errata to a specific operating system version. %post --log=/root/ks-post.log/usr/sbin/subscription-manager register [email protected] --password=secret --serverurl=sam-server.example.com --org="Admin Group" --environment="Dev" --servicelevel=standard --release="6.4" 32.8. Making the Kickstart File AvailableA kickstart file must be placed in one of the following locations: Normally a kickstart file is copied to the removable media or hard drive, 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. 32.8.1. Creating Kickstart Boot MediaTo perform a kickstart installation using removable media, the kickstart file must be named ks.cfg and must be located in the top-level directory of the disc. Diskette-based booting is no longer supported in Red Hat Enterprise Linux. Installations must use CD-ROM or flash memory products for booting. However, the kickstart file may still reside on a diskette's top-level directory, and must be named ks.cfg. Separate boot media will be required. To perform a pen-based flash memory kickstart installation, the kickstart file must be named ks.cfg and must be located in the flash memory's top-level directory. The kickstart file should be on a separate flash memory drive to the boot media. Refer to Section 2.2, "Making Minimal Boot Media" for instructions on creating live USB media using the rhel-variant-version-architecture-boot.iso image file that you can download from the Software & Download Center of the Red Hat customer portal. Creation of USB flashdrives for booting is possible, but is heavily dependent on system hardware BIOS settings. Refer to your hardware manufacturer to see if your system supports booting to alternate devices. 32.8.2. Making the Kickstart File Available on the NetworkNetwork installations using kickstart are quite common, because system administrators can quickly and easily automate the installation on many networked computers. 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. If the dhcpd.conf file on the DHCP server is configured to point to /var/lib/tftpboot/pxelinux.0 on the BOOTP server (whether on the same physical machine or not), systems configured to boot over the network can load the kickstart file and commence installation. Example 32.2. Using the ks option in the pxelinux.cfg/default file For example, if foo.ks is a kickstart file available on an NFS share at 192.168.0.200:/export/kickstart/, part of your pxelinux.cfg/default file might include: label 1 kernel RHEL6/vmlinuz append initrd=RHEL6/initrd.img ramdisk_size=10000 ks=nfs:192.168.0.200:/export/kickstart/foo.ks 32.9. Making the Installation Tree AvailableThe kickstart installation must access an installation tree. An installation tree is a copy of the binary Red Hat Enterprise Linux DVD with the same directory structure. If you are performing a DVD-based installation, insert the Red Hat Enterprise Linux installation DVD 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 DVD are on a hard drive in the computer. 32.10. Starting a Kickstart InstallationFirstboot does not run after a system is installed from a Kickstart file unless a desktop and the X Window System were included in the installation and graphical login was enabled. Either specify a user with the user option in the Kickstart file before installing additional systems from it (refer to Section 32.4, "Kickstart Options" for details) or log into the installed system with a virtual console as root and add users with the adduser command. To begin a kickstart installation, you must boot the system from boot media you have made or the Red Hat Enterprise Linux DVD, 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. - DVD and local storage
The linux ks= command also works if the ks.cfg file is located on a vfat or ext2 file system on local storage and you boot from the Red Hat Enterprise Linux DVD.
- With Driver Disk
If you need to use a driver disk with kickstart, specify the dd option as well. For example, if installation requires a kickstart file on a local hard drive and also requires a driver disk, boot the system with: linux ks=hd:partition:/path/ks.cfg dd - Boot CD-ROM
If the kickstart file is on a boot CD-ROM as described in Section 32.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: askmethodPrompt the user to select an installation source, even if a Red Hat Enterprise Linux installation DVD is detected on the system. asknetworkPrompt for network configuration in the first stage of installation regardless of installation method. autostepMake kickstart non-interactive. debugStart up pdb immediately. ddUse a driver disk. dhcpclass=<class>Sends a custom DHCP vendor class identifier. ISC's dhcpcd can inspect this value using "option vendor-class-identifier". dns=<dns>Comma separated list of nameservers to use for a network installation. driverdiskSame as 'dd'. expertTurns on special features: gateway=<gw>Gateway to use for a network installation. graphicalForce graphical install. Required to have ftp/http use GUI. isaPrompt user for ISA devices configuration. ip=<ip>IP to use for a network installation, use 'dhcp' for DHCP. ipv6=auto, ipv6=dhcpIPv6 configuration for the device. Use auto for automatic configuration (SLAAC, SLAAC with DHCPv6), or dhcp for DHCPv6 only configuration (no router advertisements). keymap=<keymap>Keyboard layout to use. Valid layouts include: be-latin1 - Belgian
bg_bds-utf8 - Bulgarian
bg_pho-utf8 - Bulgarian (Phonetic)
br-abnt2 - Brazilian (ABNT2)
cf - French Canadian
croat - Croatian
cz-us-qwertz - Czech
cz-lat2 - Czech (qwerty)
de - German
de-latin1 - German (latin1)
de-latin1-nodeadkeys - German (latin1 without dead keys)
dvorak - Dvorak
dk - Danish
dk-latin1 - Danish (latin1)
es - Spanish
et - Estonian
fi - Finnish
fi-latin1 - Finnish (latin1)
fr - French
fr-latin9 - French (latin9)
fr-latin1 - French (latin1)
fr-pc - French (pc)
fr_CH - Swiss French
fr_CH-latin1 - Swiss French (latin1)
gr - Greek
hu - Hungarian
hu101 - Hungarian (101 key)
is-latin1 - Icelandic
it - Italian
it-ibm - Italian (IBM)
it2 - Italian (it2)
jp106 - Japanese
ko - Korean
la-latin1 - Latin American
mk-utf - Macedonian
nl - Dutch
no - Norwegian
pl2 - Polish
pt-latin1 - Portuguese
ro - Romanian
ru - Russian
sr-cy - Serbian
sr-latin - Serbian (latin)
sv-latin1 - Swedish
sg - Swiss German
sg-latin1 - Swiss German (latin1)
sk-qwerty - Slovak (qwerty)
slovene - Slovenian
trq - Turkish
uk - United Kingdom
ua-utf - Ukrainian
us-acentos - U.S. International
us - U.S. English
The file /usr/lib/python2.6/site-packages/system_config_keyboard/keyboard_models.py on 32-bit systems or /usr/lib64/python2.6/site-packages/system_config_keyboard/keyboard_models.py on 64-bit systems also contains this list and is part of the system-config-keyboard package. ks=nfs:<server>:/<path>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. ks={http|https}://<server>/<path>The installation program looks for the kickstart file on the HTTP or HTTPS 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. ks=hd:<device>:/<file>The installation program mounts the file system on <device> (which must be vfat or ext2), and looks 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 mounts the file system on the specified partition on the specified BIOS device <biosdev>, and looks for the kickstart configuration file specified in <path> (for example, ks=bd:80p3:/mydir/ks.cfg). Note this does not work for BIOS RAID sets. ks=file:/<file>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. ks=cdrom:/<path>The installation program looks for the kickstart file on CD-ROM, as file <path>. ksIf ks is used alone, the installation program configures the Ethernet card to use DHCP. The kickstart file is read from NFS server specified by DHCP option server-name. 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.
ksdevice=<device>The installation program uses this network device to connect to the network. You can specify the device in one of five ways: the device name of the interface, for example, eth0 the MAC address of the interface, for example, 00:12:34:56:78:9a the keyword link, which specifies the first interface with its link in the up state the keyword bootif, which uses the MAC address that pxelinux set in the BOOTIF variable. Set IPAPPEND 2 in your pxelinux.cfg file to have pxelinux set the BOOTIF variable. the keyword ibft, which uses the MAC address of the interface specified by iBFT
For example, consider a system connected to an NFS server through the eth1 device. To perform a kickstart installation on this system using a kickstart file from the NFS server, you would use the command ks=nfs:<server>:/<path> ksdevice=eth1 at the boot: prompt. kssendmacAdds 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". lang=<lang>Language to use for the installation. This should be a language which is valid to be used with the 'lang' kickstart command. loglevel=<level>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. mediacheckActivates loader code to give user option of testing integrity of install source (if an ISO-based method). netmask=<nm>Netmask to use for a network installation. nofallbackIf GUI fails exit. nofbDo not load the VGA16 framebuffer required for doing text-mode installation in some languages. nofirewireDo not load support for firewire devices. noipv6Disable IPv6 networking during installation. During installations from a PXE server, IPv6 networking might become active before anaconda processes the Kickstart file. If so, this option will have no effect during installation. nomountDon't automatically mount any installed Linux partitions in rescue mode. nonetDo not auto-probe network devices. noparportDo not attempt to load support for parallel ports. nopassDo not pass information about the keyboard and mouse from anaconda stage 1 (the loader) to stage 2 (the installer). nopcmciaIgnore PCMCIA controller in system. noprobeDo not automatically probe for hardware; prompt the user to allow anaconda to probe for particular categories of hardware. noshellDo not put a shell on tty2 during install. repo=cdromDo a DVD based installation. repo=ftp://<path>Use <path> for an FTP installation. repo=hd:<dev>:<path>Use <path> on <dev> for a hard drive installation. repo=http://<path>Use <path> for an HTTP installation. repo=https://<path>Use <path> for an HTTPS installation. repo=nfs:<path>Use <path> for an NFS installation. rescueRun rescue environment. resolution=<mode>Run installer in mode specified, '1024x768' for example. serialTurns on serial console support. skipddcDo not probe the Data Display Channel (DDC) of the monitor. This option provides a workaround if the DDC probe causes the system to stop responding. syslog=<host>[:<port>]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). textForce text mode install. If you select text mode for a kickstart installation, make sure that you specify choices for the partitioning, bootloader, and package selection options. These steps are automated in text mode, and anaconda cannot prompt you for missing information. If you do not provide choices for these options, anaconda will stop the installation process. updatesPrompt for storage device containing updates (bug fixes). updates=ftp://<path>Image containing updates over FTP. updates=http://<path>Image containing updates over HTTP. updates=https://<path>Image containing updates over HTTPS. upgradeanyOffer to upgrade any Linux installation detected on the system, regardless of the contents or the existence of the /etc/redhat-release file. vncEnable vnc-based installation. You will need to connect to the machine using a vnc client application. vncconnect=<host>[:<port>]Connect to the vnc client named <host>, and optionally use port <port>. Requires 'vnc' option to be specified as well. vncpassword=<password>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.
|
| |
