m (→network: syntax highlight --activate option)
(Update supported keyboard list for F16 and F17)
|Line 492:||Line 492:|
be-latin1, , br-abnt2, cf, cz-lat2, cz-us-qwertz, de, de-latin1, de-latin1-nodeadkeys, dk, dk-latin1, dvorak, es, et, fi, fi-latin1, fr, fr-, fr-, fr-pc, fr_CH, fr_CH-latin1, gr, hu, hu101, is-latin1, it, it-ibm, it2, jp106, la-latin1, mk-utf, , no, , pt-latin1, , , -, -, , sg, sg-latin1, sk-qwerty, slovene, , -, sv-latin1, , -, -, trq, ua, uk, us, us-acentos
== lang ==
== lang ==
Revision as of 23:46, 8 May 2012
- 1 Chapter 1. Introduction
- 2 Chapter 2. Kickstart Options
Chapter 1. Introduction
What are Kickstart Installations?
Many system administrators would prefer to use an automated installation method to install Fedora or Red Hat Enterprise 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 installation.
Kickstart files can be kept on a server system and read by individual computers during the installation. This installation method can support the use of a single kickstart file to install Fedora or Red Hat Enterprise Linux on multiple machines, making it ideal for network and system administrators.
The Fedora installation guide at http://docs.fedoraproject.org/en-US/index.html has a detailed section on kickstart.
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 diskette with the kickstart file or make the kickstart file available on the network.
- Make the installation tree available.
- Start the kickstart installation.
This chapter explains these steps in detail.
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 using the Kickstart Configurator application or by writing it from scratch. The Fedora or Red Hat Enterprise 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:
- While not strictly required, there is a natural order for sections that should be followed. Items within the sections do not have to be in a specific order unless otherwise noted. The section order is:
- Command section -- Refer to Chapter 2 for a list of kickstart options. You must include the required options.
- The %packages section -- Refer to Chapter 3 for details.
- The %pre, %post, and %traceback sections -- These sections can be in any order and are not required. Refer to Chapter 4 and Chapter 5 for details.
- The %packages, %pre, %post and %traceback sections are all required to be closed with %end
- 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.
- If deprecated commands, options, or syntax are used during a kickstart installation, a warning message will be logged to the anaconda log. Since deprecated items are usually removed within a release or two, it makes sense to check the installation log to make sure you haven't used any of them. When using ksvalidator, deprecated items will cause an error.
- For kickstart upgrades, the following items are required:
- Installation method
- Device specification (if device is needed to perform installation)
- Keyboard setup
- The upgrade keyword
- Boot loader configuration
If any other items are specified for an upgrade, those items will be ignored - this includes package selection.
Special Notes for Referring to Disks
Traditionally, disks have been referred to throughout Kickstart by a device node name (such as
sda). The Linux kernel has moved to a more dynamic method where device names are not guaranteed to be consistent across reboots, so this can complicate usage in Kickstart scripts. To accommodate stable device naming, you can use any item from
/dev/disk in place of a device node name. For example, instead of:
part / --fstype=ext4 --onpart=sda1
You could use an entry similar to one of the following:
part / --fstype=ext4 --onpart=/dev/disk/by-path/pci-0000:00:05.0-scsi-0:0:0:0-part1 part / --fstype=ext4 --onpart=/dev/disk/by-id/ata-ST3160815AS_6RA0C882-part1
This provides a consistent way to refer to disks that is more meaningful than just
sda. This is especially useful in large storage environments.
You can also use shell-like entries to refer to disks. This is primarily intended to make it easier to use the
ignoredisk commands in large storage environments. For example, instead of:
You could use an entry similar to the following:
Finally, anywhere you want to refer to an existing partition or filesystem (say, in the
part --ondisk=) option, you may also refer to the device by its filesystem label or UUID. This is done as follows:
part /data --ondisk=LABEL=data part /misc --ondisk=UUID=819ff6de-0bd6-4bf4-8b72-dbe41033a85b
Chapter 2. 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.
auth or authconfig
This required command sets up the authentication options for the system. This is just a wrapper around the authconfig program, so all options recognized by that program are valid for this command. See the manual page for authconfig for a complete list.
By default, passwords are normally encrypted and are not shadowed.
Automatically create partitions -- 1 GB or more root (/) partition, a swap partition, and an appropriate boot partition for the architecture. One or more of the default partition sizes can be redefined with the part directive.
- Select automatic partitioning scheme. Must be one of the following: lvm, btrfs, plain. Plain means regular partitions with no btrfs or lvm. (Added in anaconda-17.3)
- Should all devices with support be encrypted by default? This is equivalent to checking the "Encrypt" checkbox on the initial partitioning screen.
- Provide a default system-wide passphrase for all encrypted devices.
- Load an X.509 certificate from
<url>. Store the data encryption keys of all encrypted volumes created during installation, encrypted using the certificate, as files in
/root. Only relevant if
- Only relevant if
--escrowcertis specified. In addition to storing the data encryption keys, generate a random passphrase and add it to all encrypted volumes created during installation. Then store the passphrase, encrypted using the certificate specified by
--escrowcert, as files in
/root(one file for each encrypted volume).
Kickstart installs normally skip unnecessary screens. This makes the installer step through every screen, displaying each briefly.
This is mostly used for debugging.
- Take a screenshot at every step during installation and copy the images over to /root/anaconda-screenshots after installation is complete. This is most useful for documentation.
This required command specifies how the boot loader should be installed. This option is required for both installations and upgrades.
- Specifies kernel parameters. The default set of bootloader arguments is "rhgb quiet". You will get this set of arguments regardless of what parameters you pass to --append, or if you leave out --append entirely. For example:
bootloader --location=mbr --append="hdd=ide-scsi ide=nodma"
- Specify which drive is first in the BIOS boot order. For example:
- 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).
- If using GRUB, sets the GRUB boot loader password. This should be used to restrict access to the GRUB shell, where arbitrary kernel options can be passed.
- If using GRUB, similar to
--password=except the password should already be encrypted.
- Upgrade the existing boot loader configuration, preserving the old entries. This option is only available for upgrades.
- Specify the number of seconds before the bootloader times out and boots the default option.
(Added in anaconda-17.3)
Defines a BTRFS volume or subvolume. This command is of the form:
btrfs <mntpoint> --data=<level> --metadata=<level> --label=<label> <partitions*>
for volumes and of the form:
btrfs <mntpoint> --subvol --name=<path> <parent>
<partitions*> (which denotes that multiple partitions can be listed) lists the BTRFS identifiers to add to the BTRFS volume. For subvolumes, <parent> should be the identifier of the subvolume's parent volume.
- Location where the file system is mounted.
- RAID level to use (0, 1, 10) for filesystem data. Optional. This option has no meaning for subvolumes.
- RAID level to use (0, 1, 10) for filesystem/volume metadata. Optional. This option has no meaning for subvolumes.
- Specify the label to give to the filesystem to be made. If the given label is already in use by another filesystem, a new label will be created. This option has no meaning for subvolumes.
- Use an existing BTRFS volume and do not reformat the filesystem. This option has no meaning for subvolumes.
- Same as --noformat, above. This option has no meaning for subvolumes.
The following example shows how to create a BTRFS volume from member partitions on three disks with subvolumes for root and home. The main volume is not mounted or used directly in this example -- only the root and home subvolumes.
part btrfs.01 --size=6000 --ondisk=sda part btrfs.02 --size=6000 --ondisk=sdb part btrfs.03 --size=6000 --ondisk=sdc btrfs none --data=0 --metadata=1 --label=f17 btrfs.01 btrfs.02 btrfs.03 btrfs / --subvol --name=root LABEL=f17 btrfs /home --subvol --name=home f17
Removes partitions from the system, prior to creation of new partitions. By default, no partitions are removed.
- Erases all partitions from the system.
- Specifies which drives to clear partitions from. For example, the following clears the partitions on the first two drives on the primary IDE controller:
clearpart --all --drives=hda,hdb
- Initializes the disk label to the default for your architecture (for example msdos for x86 and gpt for Itanium). This is only meaningful in combination with the '--all' option.
- Erases all Linux partitions.
- Do not remove any partitions.
Perform the installation in a completely non-interactive command line mode. Any prompts for interaction will halt the install. This mode is useful on S/390 systems with the x3270 console.
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 the installation program to install extra modules, is in this format:
device <moduleName> --opts=<options>
- Replace with the name of the kernel module which should be installed.
- Options to pass to the kernel module. For example:
dmraid --name= --dev=
Driver diskettes can be used during kickstart installations. You need to copy the driver disk's contents to the root directory of a partition on the system's hard drive. Then you need to use the driverdisk command to tell the installation program where to look for the driver disk.
- Partition containing the driver disk.
- Specify a URL for the driver disk. NFS locations can be given with
- BIOS partition containing the driver disk (such as 82p2).
This option corresponds to the Firewall Configuration screen in the installation program:
firewall --enabled|--disabled <device> [options]
- Reject incoming connections that are not in response to outbound requests, such as DNS replies or DHCP requests. If access to services running on this machine is needed, you can choose to allow specific services through the firewall.
- Do not configure any iptables rules.
- 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.
- Replace with none or more of the following to allow the specified services through the firewall.
--ssh- The ssh option is enabled by default, regardless of the presence of this flag.
- You can specify that ports be allowed through the firewall using the port:protocol format. You can also specify ports numerically. Multiple ports can be combined into one option as long as they are separeted by commas. For example:
- This option provides a higher-level way to allow services through the firewall. Some services (like cups, avahi, etc.) require multiple ports to be open in order for the service to work. You could specify each individual service with the
--portoption, or specify
--service=and open them all at once. Valid options are anything recognized by the lokkit program in the system-config-firewall-base package.
Determine whether the Setup Agent starts the first time the system is booted. If enabled, the firstboot package must be installed. If not specified, firstboot is disabled by default.
- The Setup Agent is started the first time the system boots.
- The Setup Agent is not started the first time the system boots.
- Enable the Setup Agent to start at boot time in reconfiguration mode. This mode enables the language, mouse, keyboard, root password, security level, time zone, and networking configuration options in addition to the default ones.
Creates a new user group on the system.
group --name=<name> [--gid=<gid>]
- Provides the name of the new group.
- The group's GID. If not provided, this defaults to the next available non-system GID.
Perform the kickstart installation in graphical mode. This is the default.
At the end of installation, display a message and wait for the user to press a key before rebooting. This is the default action.
Controls anaconda's access to disks attached to the system. Only one of the following two options may be used.
- Specifies those disks that anaconda should not touch when partitioning, formatting, and clearing.
- Specifies the opposite - only disks listed here will be used during installation.
- Allow the user manually navigate the advanced storage screen.
Tells the system to install a fresh system rather than upgrade an existing system. This is the default mode. For installation, you must specify the type of installation from one of cdrom, harddrive, nfs, or url (for ftp or http installations). The install command and the installation method command must be on separate lines.
- Install from the first CD-ROM/DVD drive on the system.
- Install from a directory of ISO images on a local drive, which must be either vfat or ext2. In addition to this directory, you must also provide the install.img in some way. You can either do this by booting off the boot.iso or by creating an images/ directory in the same directory as the ISO images and placing install.img in there.
- BIOS partition to install from (such as 82p2).
- Partition to install from (such as, sdb2).
- Directory containing both the ISO images and the images/install.img. For example:
harddrive --partition=hdb2 --dir=/tmp/install-tree
- Install from the NFS server specified. This can either be an exploded installation tree or a directory of ISO images. In the latter case, the install.img must also be provided subject to the same rules as with the harddrive installation method described above.
- Server from which to install (hostname or IP).
- Directory containing the Packages/ directory of the installation tree. If doing an ISO install, this directory must also contain images/install.img.
- Mount options to use for mounting the NFS export. Any options that can be specified in /etc/fstab for an NFS mount are allowed. The options are listed in the nfs(5) man page. Multiple options are separated with a comma.
- For example:
nfs --server=nfsserver.example.com --dir=/tmp/install-tree
- Install from an installation tree on a remote server via FTP or HTTP.
- The URL to install from.
- Specify an HTTP/HTTPS/FTP proxy to use while performing the install. The various parts of the argument act like you would expect.
- For a tree on a HTTPS server do not check the server's certificate with what well-known CA validate and do not check the server's hostname matches the certificate's domain name.
Specifies additional iSCSI storage to be attached during installation. If you use the iscsi parameter, you must also assign a name to the iSCSI node, using the iscsiname parameter. The iscsiname parameter must appear before the iscsi parameter in the kickstart file.
iscsi --ipaddr= [options]
We recommend that wherever possible you configure iSCSI storage in the system BIOS or firmware (iBFT for Intel systems) rather than use the iscsi parameter. *Anaconda* automatically detects and uses disks configured in BIOS or firmware and no special configuration is necessary in the kickstart file.
If you must use the iscsi parameter, ensure that networking is activated at the beginning of the installation, and that the iscsi parameter appears in the kickstart file before you refer to iSCSI disks with parameters such as clearpart or ignoredisk.
- The IP address of the target to connect to.
- The port number to connect to (default, --port=3260).
- The target iqn.
- Bind connection to specific network interface instead of using the default one determined by network layer. Once used, it must be specified for all iscsi commands.
- The username required to authenticate with the target.
- The password that corresponds with the username specified for the target.
- The username required to authenticate with the initiator from a target that uses reverse CHAP authentication.
- The password that corresponds with the username specified for the initiator.
Assigns an initiator name to the computer. If you use the iscsi parameter in your kickstart file, this parameter is mandatory, and you must specify iscsiname in the kickstart file before you specify iscsi.
This required command sets system keyboard type. Here is the list of available keyboards on i386, Itanium, and Alpha machines:
ar-azerty, ar-azerty-digits, ar-digits, ar-qwerty, ar-qwerty-digits, be-latin1, ben, ben-probhat, bg_bds-utf8, bg_pho-utf8, br-abnt2, cf, croat, cz-lat2, cz-us-qwertz, de, de-latin1, de-latin1-nodeadkeys, dev, dk, dk-latin1, dvorak, es, et, fi, fi-latin1, fr, fr-latin1, fr-latin9, fr-pc, fr_CH, fr_CH-latin1, gr, guj, gur, hu, hu101, ie, is-latin1, it, it-ibm, it2, jp106, ko, la-latin1, mk-utf, nl, no, pl2, pt-latin1, ro, ro-cedilla, ro-std, ro-std-cedilla, ru, sg, sg-latin1, sk-qwerty, slovene, sr-cy, sr-latin, sv-latin1, tj, tml-inscript, tml-uni, trq, ua-utf, uk, us, us-acentos