|
|
| (202 intermediate revisions by 34 users not shown) |
| Line 1: |
Line 1: |
| = Chapter 1. Introduction = | | {{autolang|base=yes}} |
|
| |
|
| == What are Kickstart Installations? ==
| | The kickstart documentation is now on Read the Docs: |
|
| |
|
| 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.
| | [http://pykickstart.readthedocs.io/en/latest/ http://pykickstart.readthedocs.io/en/latest/] |
|
| |
|
| 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 Fedora or Red Hat Enterprise Linux on multiple machines, making it ideal for network and system administrators.
| | It should be automatically kept up to date and links pointing to it and its parts should remain reasonably stable. |
| | |
| Kickstart provides a way for users to automate a Fedora or Red Hat Enterprise Linux installation.
| |
| | |
| == 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 editing a copy of the sample.ks file found in the RH-DOCS directory of the Fedora or Red Hat Enterprise Linux Documentation CD, using the Kickstart Configurator application, or 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. Old-style kickstart syntax does not specify for any end token after the %packages section or scripts. In this case, the following section order is required. New-style kickstart syntax requires using %end following these sections, which means that ordering is not required. 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.
| |
| * 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 while doing 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:
| |
| *# Language
| |
| *# 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 (note that this includes package selection).
| |
| | |
| = 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.
| |
| | |
| {{Admon/caution | If the option is followed by an equals mark (=), a value must be specified after it.
| |
| | |
| In the example commands, options in '''[square brackets]''' are optional arguments for the command.}}
| |
| | |
| {{Admon/caution | pykickstart processes arguments to commands just like the shell does.
| |
| | |
| If a list of arguments can be passed in, the arguments must be separated by commas and not include any extra spaces. If extra spaces are required in the list of arguments, the entire argument must be surrounded by double quotes. If quotes, spaces, or other special characters need to be added to the argument list, they must be escaped.}}
| |
| | |
| == 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.
| |
| | |
| == autopart ==
| |
| | |
| 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.
| |
| | |
| <code>--encrypted</code>
| |
| | |
| : Should all devices with support be encrypted by default? This is equivalent to checking the "Encrypt" checkbox on the initial partitioning screen.
| |
| | |
| <code>--passphrase=</code>
| |
| | |
| : Provide a default system-wide passphrase for all encrypted devices.
| |
| | |
| <code>--escrowcert=<url></code>
| |
| | |
| : Load an X.509 certificate from <code><url></code>. Store the data encryption keys of all encrypted volumes created during installation, encrypted using the certificate, as files in <code>/root</code>. Only relevant if <code>--encrypted</code> is specified as well.
| |
| | |
| <code>--backuppassphrase</code>
| |
| | |
| : Only relevant if <code>--escrowcert</code> is specified as well. 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 <code>--escrowcert</code>, as files in <code>/root</code> (one file for each encrypted volume).
| |
| | |
| == autostep ==
| |
| | |
| Similar to interactive except it goes to the next screen for you. It is used mostly for debugging.
| |
| | |
| <code>--autoscreenshot</code>
| |
| | |
| : 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.
| |
| | |
| == bootloader ==
| |
| | |
| This required command specifies how the boot loader should be installed. This option is required for both installations and upgrades.
| |
| | |
| <code>--append=</code>
| |
| | |
| : 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:
| |
| | |
| : <code>bootloader --location=mbr --append="hdd=ide-scsi ide=nodma"</code>
| |
| | |
| <code>--driveorder</code>
| |
| | |
| : Specify which drive is first in the BIOS boot order. For example:
| |
| | |
| : <code>bootloader --driveorder=sda,hda</code>
| |
| | |
| <code>--location=</code>
| |
| | |
| : 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).
| |
| | |
| <code>--password=</code>
| |
| | |
| : If using GRUB, sets the GRUB boot loader password the one specified with this option. This should be used to restrict access to the GRUB shell, where arbitrary kernel options can be passed.
| |
| | |
| <code>--md5pass=</code>
| |
| | |
| : If using GRUB, similar to <code>--password=</code> except the password should already be encrypted.
| |
| | |
| <code>--lba32</code>
| |
| | |
| : Force use of lba32 mode instead of auto-detecting.
| |
| | |
| <code>--upgrade</code>
| |
| | |
| : Upgrade the existing boot loader configuration, preserving the old entries. This option is only available for upgrades.
| |
| | |
| <code>--timeout=<secs></code>
| |
| | |
| : Specify the number of seconds before the bootloader times out and boots the default option.
| |
| | |
| == clearpart ==
| |
| | |
| Removes partitions from the system, prior to creation of new partitions. By default, no partitions are removed.
| |
| | |
| {{Admon/caution | If the clearpart command is used, then the <code>--onpart</code> command cannot be used on a logical partition.}}
| |
| | |
| <code>--all</code>
| |
| | |
| : Erases all partitions from the system.
| |
| | |
| <code>--drives=</code>
| |
| | |
| : Specifies which drives to clear partitions from. For example, the following clears the partitions on the first two drives on the primary IDE controller:
| |
| | |
| : <code>clearpart --all --drives=hda,hdb</code>
| |
| | |
| <code>--initlabel</code>
| |
| | |
| : Initializes the disk label to the default for your architecture (for example 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.
| |
| | |
| <code>--linux</code>
| |
| | |
| : Erases all Linux partitions.
| |
| | |
| <code>--none</code> (default)
| |
| | |
| : Do not remove any partitions.
| |
| | |
| == cmdline ==
| |
| | |
| 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.
| |
| | |
| == device ==
| |
| | |
| 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:
| |
| | |
| <code>device <moduleName> --opts=<options></code>
| |
| | |
| <code><moduleName></code>
| |
| | |
| : Replace with the name of the kernel module which should be installed.
| |
| | |
| <code>--opts=</code>
| |
| | |
| : Options to pass to the kernel module. For example:
| |
| | |
| : <code>--opts="aic152x=0x340 io=11"</code>
| |
| | |
| == dmraid ==
| |
| | |
| <code>dmraid --name= --dev=</code>
| |
| | |
| == driverdisk ==
| |
| | |
| 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.
| |
| | |
| <code>driverdisk <partition>|--source=<url>|--biospart=<part> [--type=<fstype>] </code>
| |
| | |
| <code><partition></code>
| |
| | |
| : Partition containing the driver disk.
| |
| | |
| <code>--source=<url></code>
| |
| | |
| : Specify a URL for the driver disk. NFS locations can be given with <code>nfs:host:/path/to/img</code>.
| |
| | |
| <code>--type=</code>
| |
| | |
| : File system type (for example, vfat or ext2).
| |
| | |
| <code>--biospart=<part></code>
| |
| | |
| : BIOS partition containing the driver disk (such as 82p2).
| |
| | |
| == firewall ==
| |
| | |
| This option corresponds to the Firewall Configuration screen in the installation program:
| |
| | |
| <code>firewall --enabled|--disabled <device> [options] </code>
| |
| | |
| <code>--enabled</code> or <code>--enable</code>
| |
| | |
| : 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.
| |
| | |
| <code>--disabled</code> or <code>--disable</code>
| |
| | |
| : Do not configure any iptables rules.
| |
| | |
| <code>--trust=</code>
| |
| | |
| : 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.
| |
| | |
| <code><incoming></code>
| |
| | |
| : Replace with none or more of the following to allow the specified services through the firewall.
| |
| | |
| :: <code>--ssh</code> - The ssh option is enabled by default, regardless of the presence of this flag.
| |
| | |
| :: <code>--telnet</code>
| |
| | |
| :: <code>--smtp</code>
| |
| | |
| :: <code>--http</code>
| |
| | |
| :: <code>--ftp</code>
| |
| | |
| <code>--port=</code>
| |
| | |
| : 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:
| |
| | |
| : <code>firewall --port=imap:tcp,1234:ucp,47</code>
| |
| | |
| <code>--service=</code>
| |
| | |
| : 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 <code>--port</code> option, or specify <code>--service=</code> and open them all at once. Valid options are anything recognized by the lokkit program in the system-config-firewall-base package.
| |
| | |
| == firstboot ==
| |
| | |
| Determine whether the Setup Agent starts the first time the system is booted. If enabled, the firstboot package must be installed. If not specified, this option is disabled by default.
| |
| | |
| <code>--enable</code> or <code>--enabled</code>
| |
| | |
| : The Setup Agent is started the first time the system boots.
| |
| | |
| <code>--disable</code> or <code>--disabled</code>
| |
| | |
| : The Setup Agent is not started the first time the system boots.
| |
| | |
| <code>--reconfig</code>
| |
| | |
| : 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.
| |
| | |
| == group ==
| |
| | |
| Creates a new user group on the system.
| |
| | |
| <code>group --name=<name> [--gid=<gid>]</code>
| |
| | |
| <code>--name=</code>
| |
| | |
| : Provides the name of the new group.
| |
| | |
| <code>--gid=</code>
| |
| | |
| : The group's GID. If not provided, this defaults to the next available non-system GID.
| |
| | |
| == graphical ==
| |
| | |
| Perform the kickstart installation in graphical mode. This is the default.
| |
| | |
| == install ==
| |
| | |
| : 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.
| |
| | |
| :: <code>cdrom</code>
| |
| | |
| ::: Install from the first CD-ROM/DVD drive on the system.
| |
| | |
| :: <code>harddrive</code>
| |
| | |
| ::: 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.
| |
| | |
| :::: <code>--biospart=</code>
| |
| | |
| ::::: BIOS partition to install from (such as 82p2).
| |
| | |
| :::: <code>--partition=</code>
| |
| | |
| ::::: Partition to install from (such as, sdb2).
| |
| | |
| :::: <code>--dir=</code>
| |
| | |
| ::::: Directory containing both the ISO images and the images/install.img. For example:
| |
| | |
| ::::: <code>harddrive --partition=hdb2 --dir=/tmp/install-tree </code>
| |
| | |
| :: <code>nfs</code>
| |
| | |
| ::: 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.
| |
| | |
| :::: <code>--server=</code>
| |
| | |
| ::::: Server from which to install (hostname or IP).
| |
| | |
| :::: <code>--dir=</code>
| |
| | |
| ::::: Directory containing the Packages/ directory of the installation tree. If doing an ISO install, this directory must also contain images/install.img.
| |
| | |
| :::: <code>--opts=</code>
| |
| | |
| ::::: 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:
| |
| | |
| ::::: <code>nfs --server=nfsserver.example.com --dir=/tmp/install-tree</code>
| |
| | |
| :: <code>url</code>
| |
| | |
| ::: Install from an installation tree on a remote server via FTP or HTTP.
| |
| | |
| ::: <code>--url=</code>
| |
| | |
| :::: The URL to install from.
| |
| | |
| ::: <code>--proxy=[protocol://][username[:password]@]host[:port]</code>
| |
| | |
| :::: Specify an HTTP/HTTPS/FTP proxy to use while performing the install. The various parts of the argument act like you would expect.
| |
| | |
| == ignoredisk ==
| |
| | |
| : Controls anaconda's access to disks attached to the system. Only one of the following two options may be used.
| |
| | |
| : <code>ignoredisk --drives=[disk1,disk2,...]</code>
| |
| | |
| :: Specifies those disks that anaconda should not touch when partitioning, formatting, and clearing.
| |
| | |
| : <code>ignoredisk --only-use=[disk1,disk2,...]</code>
| |
| | |
| :: Specifies the opposite - only disks listed here will be used during installation.
| |
| | |
| == interactive ==
| |
| | |
| : 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 autostep.
| |
| | |
| == iscsi ==
| |
| | |
| :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.
| |
| | |
| : <code>iscsi --ipaddr= [options] </code>
| |
| | |
| :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.
| |
| | |
| :: <code>--ipaddr=</code> (mandatory)
| |
| :::The IP address of the target to connect to.
| |
| | |
| :: <code>--port=</code>
| |
| :::The port number to connect to (default, --port=3260).
| |
| | |
| :: <code>--user=</code>
| |
| :::The username required to authenticate with the target.
| |
| | |
| :: <code>--password=</code>
| |
| :::The password that corresponds with the username specified for the target.
| |
| | |
| :: <code>--reverse-user=</code>
| |
| :::The username required to authenticate with the initiator from a target that uses reverse CHAP authentication.
| |
| | |
| :: <code>--reverse-password=</code>
| |
| :::The password that corresponds with the username specified for the initiator.
| |
| | |
| <code>iscsiname</code> (optional)
| |
| :Assigns a name to an iSCSI node specified by the iscsi parameter. 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.
| |
| | |
| : <code>iscsiname <iqn></code>
| |
| | |
| == keyboard ==
| |
| | |
| : This required command sets system keyboard type. Here is the list of available keyboards on i386, Itanium, and Alpha machines:
| |
| | |
| <pre>
| |
| be-latin1, bg, 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-latin0, fr-latin1, fr-pc, fr_CH, fr_CH-latin1, gr, hu,
| |
| hu101, is-latin1, it, it-ibm, it2, jp106, la-latin1, mk-utf, no,
| |
| no-latin1, pl, pt-latin1, ro_win, ru, ru-cp1251, ru-ms, ru1, ru2,
| |
| ru_win, se-latin1, sg, sg-latin1, sk-qwerty, slovene, speakup,
| |
| speakup-lt, sv-latin1, sg, sg-latin1, sk-querty, slovene, trq, ua,
| |
| uk, us, us-acentos
| |
| </pre>
| |
| | |
| : The file /usr/lib/python?.?/site-packages/rhpl/keyboard_models.py also contains this list and is part of the rhpl package.
| |
| | |
| == lang ==
| |
| | |
| : <code>lang <id></code>
| |
| | |
| : This required command sets the language to use during installation and the default language to use on the installed system to <code><id></code>. This can be the same as any recognized setting for the $LANG environment variable, though not all languages are supported during installation.
| |
| | |
| : Certain languages (mainly Chinese, Japanese, Korean, and Indic languages) are not supported during text mode installation. If one of these languages is specified using the lang command, installation will continue in English though the running system will have the specified langauge by default.
| |
| | |
| : The file /usr/share/system-config-language/locale-list provides a list the valid language codes in the first column of each line and is part of the system-config-languages package.
| |
| | |
| == logvol ==
| |
| | |
| : Create a logical volume for Logical Volume Management (LVM).
| |
| | |
| : <code>logvol <mntpoint> --vgname=<name> --size=<size> --name=<name> <options></code>
| |
| | |
| :: <code>--noformat</code>
| |
| | |
| ::: Use an existing logical volume and do not format it.
| |
| | |
| :: <code>--useexisting</code>
| |
| | |
| ::: Use an existing logical volume and reformat it.
| |
| | |
| :: <code>--fstype=</code>
| |
| | |
| ::: Sets the file system type for the logical volume. Valid values include ext4, ext3, ext2, btrfs, swap, and vfat. Other filesystems may be valid depending on command line arguments passed to anaconda to enable other filesystems.
| |
| | |
| :: <code>--fsoptions=</code>
| |
| | |
| ::: Specifies a free form string of options to be used when mounting the filesystem. This string will be copied into the /etc/fstab file of the installed system and should be enclosed in quotes.
| |
| | |
| :: <code>--grow</code>
| |
| | |
| ::: Tells the logical volume to grow to fill available space (if any), or up to the maximum size setting.
| |
| | |
| :: <code>--maxsize=</code>
| |
| | |
| ::: The maximum size in megabytes when the logical volume is set to grow. Specify an integer value here, and do not append the number with MB.
| |
| | |
| :: <code>--recommended</code>
| |
| | |
| ::: Determine the size of the logical volume automatically.
| |
| | |
| :: <code>--percent</code>
| |
| | |
| ::: Specify the size of the logical volume as a percentage of available space in the volume group.
| |
| | |
| :: <code>--encrypted</code>
| |
| | |
| ::: Specify that this logical volume should be encrypted.
| |
| | |
| :: <code>--passphrase=</code>
| |
| | |
| ::: Specify the passphrase to use when encrypting this logical volume. Without the above --encrypted option, this option does nothing. If no passphrase is specified, the default system-wide one is used, or the installer will stop and prompt if there is no default.
| |
| | |
| :: <code>--escrowcert=<url></code>
| |
| | |
| ::: Load an X.509 certificate from <code><url></code>. Store the data encryption key of this logical volume, encrypted using the certificate, as a file in <code>/root</code>. Only relevant if <code>--encrypted</code> is specified as well.
| |
| | |
| :: <code>--backuppassphrase</code>
| |
| | |
| ::: Only relevant if <code>--escrowcert</code> is specified as well. In addition to storing the data encryption key, generate a random passphrase and add it to this logical volume. Then store the passphrase, encrypted using the certificate specified by <code>--escrowcert</code>, as a file in <code>/root</code>. If more than one LUKS volume uses <code>--backuppassphrase</code>, the same passphrase will be used for all such volumes.
| |
| | |
| : Create the partition first, create the logical volume group, and then create the logical volume. For example:
| |
| | |
| <pre>
| |
| part pv.01 --size 3000
| |
| volgroup myvg pv.01
| |
| logvol / --vgname=myvg --size=2000 --name=rootvol
| |
| </pre>
| |
| | |
| == logging ==
| |
| | |
| : This command controls the error logging of anaconda during installation. It has no effect on the installed system.
| |
| | |
| :: <code>--host=</code>
| |
| | |
| ::: Send logging information to the given remote host, which must be running a syslogd process configured to accept remote logging.
| |
| | |
| :: <code>--port=</code>
| |
| | |
| ::: If the remote syslogd process uses a port other than the default, it may be specified with this option.
| |
| | |
| :: <code>--level=</code>
| |
| | |
| ::: One of debug, info, warning, error, or critical.
| |
| | |
| ::: Specify the minimum level of messages that appear on tty3. All messages will still be sent to the log file regardless of this level, however.
| |
| | |
| == mediacheck ==
| |
| | |
| : If given, this will force anaconda to run mediacheck on the installation media. This command requires that installs be attended, so it is disabled by default.
| |
| | |
| == monitor ==
| |
| | |
| : If the monitor command is not given, anaconda will use X to automatically detect your monitor settings. Please try this before manually configuring your monitor.
| |
| | |
| :: <code>--hsync=</code>
| |
| | |
| ::: Specifies the horizontal sync frequency of the monitor.
| |
| | |
| :: <code>--monitor=</code>
| |
| | |
| ::: Use specified monitor; monitor name should be from the list of monitors in /usr/share/hwdata/MonitorsDB from the hwdata package. The list of monitors can also be found on the X Configuration screen of the Kickstart Configurator. This is ignored if --hsync or --vsync is provided. If no monitor information is provided, the installation program tries to probe for it automatically.
| |
| | |
| :: <code>--noprobe</code>
| |
| | |
| ::: Do not probe the monitor.
| |
| | |
| :: <code>--vsync=</code>
| |
| | |
| ::: Specifies the vertical sync frequency of the monitor.
| |
| | |
| == multipath ==
| |
| | |
| : <code>multipath --name= --device= --rule=</code>
| |
| | |
| == network ==
| |
| | |
| : 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 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.
| |
| | |
| :: <code>--bootproto=[dhcp|bootp|static] </code>
| |
| | |
| ::: The default setting is dhcp. bootp and dhcp are treated the same.
| |
| | |
| ::: 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 and after the installation. The line for static networking is more complex, as you must include all network configuration information on one line. You must specify the IP address, netmask, gateway, and nameserver. For example: (the \ indicates that it is all one line):
| |
| | |
| <pre>
| |
| network --bootproto=static --ip=10.0.2.15 \
| |
| --netmask=255.255.255.0 --gateway=10.0.2.254 \
| |
| --nameserver=10.0.2.1
| |
| </pre>
| |
| | |
| ::: 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 Chapter 5) to add more name servers, if needed.
| |
| | |
| :: <code>--device=</code>
| |
| | |
| ::: Used to select a specific Ethernet device for installation. The device can be specified by either a device name (e.g., <code>--device=eth0</code>) or by MAC address (e.g. <code>--device=aa:bb:cc:dd:ee:ff</code>). Note that using <code>--device=</code> 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. For example:
| |
| | |
| ::: <code>network --bootproto=dhcp --device=eth0</code>
| |
| | |
| :: <code>--ip=</code>
| |
| | |
| ::: IP address for the interface.
| |
| | |
| :: <code>--ipv6=</code>
| |
| | |
| ::: IPv6 address for the interface. This can be the static address, "auto" for address assignment based on automatic neighbor discovery, or "dhcp" to use the DHCPv6 protocol.
| |
| | |
| :: <code>--gateway=</code>
| |
| | |
| ::: Default gateway as an IP address.
| |
| | |
| :: <code>--nameserver=</code>
| |
| | |
| ::: Primary nameserver, as an IP address.
| |
| | |
| :: <code>--nodns</code>
| |
| | |
| ::: Do not configure any DNS server.
| |
| | |
| :: <code>--netmask=</code>
| |
| | |
| ::: Netmask for the installed system.
| |
| | |
| :: <code>--hostname=</code>
| |
| | |
| ::: Hostname for the installed system.
| |
| | |
| :: <code>--ethtool=</code>
| |
| | |
| ::: Specifies additional low-level settings for the network device which will be passed to the ethtool program.
| |
| | |
| :: <code>--essid=</code>
| |
| | |
| ::: The network ID for wireless networks.
| |
| | |
| :: <code>--wepkey=</code>
| |
| | |
| ::: The encryption key for wireless networks.
| |
| | |
| :: <code>--onboot=</code>
| |
| | |
| ::: Whether or not to enable the device a boot time.
| |
| | |
| :: <code>--dhcpclass=</code>
| |
| | |
| ::: The DHCP class.
| |
| | |
| :: <code>--mtu=</code>
| |
| | |
| ::: The MTU of the device.
| |
| | |
| :: <code>--noipv4</code>
| |
| | |
| ::: Disable IPv4 on this device.
| |
| | |
| :: <code>--noipv6</code>
| |
| | |
| ::: Disable IPv6 on this device.
| |
| | |
| == part or partition ==
| |
| | |
| : Creates a partition on the system. This command is required for installs, and is ignored on upgrades.
| |
| | |
| : If more than one Red Hat Enterprise Linux installation exists on the system on different partitions, the installation program prompts the user and asks which installation to upgrade.
| |
| | |
| {{Admon/caution | All partitions created will be formatted as part of the installation process unless <code>--noformat</code> and <code>--onpart</code> are used.}}
| |
| | |
| : <code>part <mntpoint></code>
| |
| | |
| :: The <code><mntpoint></code> is where the partition will be mounted and must be of one of the following forms:
| |
| | |
| ::: <code>/<path></code>
| |
| | |
| :::: For example, /, /usr, /home
| |
| | |
| ::: <code>swap</code>
| |
| | |
| :::: The partition will be used as swap space.
| |
| | |
| :::: To determine the size of the swap partition automatically, use the <code>--recommended</code> option.
| |
| | |
| :::: The recommended maximum swap size for machines with less than 2GB of RAM is twice the amount of RAM. For machines with 2GB or more, this recommendation changes to 2GB plus the amount of RAM.
| |
| | |
| ::: <code>raid.<id></code>
| |
| | |
| :::: The partition will be used for software RAID (refer to raid).
| |
| | |
| ::: <code>pv.<id></code>
| |
| | |
| :::: The partition will be used for LVM (refer to logvol).
| |
| | |
| :: <code>--size=</code>
| |
| | |
| ::: The minimum partition size in megabytes. Specify an integer value here such as 500. Do not append the number with MB.
| |
| | |
| :: <code>--grow</code>
| |
| | |
| ::: Tells the partition to grow to fill available space (if any), or up to the maximum size setting.
| |
| | |
| :: <code>--maxsize=</code>
| |
| | |
| ::: 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.
| |
| | |
| :: <code>--noformat</code>
| |
| | |
| ::: Tells the installation program not to format the partition, for use with the <code>--onpart</code> command.
| |
| | |
| :: <code>--onpart=</code> or <code>--usepart=</code>
| |
| | |
| ::: Put the partition on an already existing device. Do not prefix the partition name with /dev.
| |
| | |
| :: <code>--ondisk=</code> or <code>--ondrive=</code>
| |
| | |
| ::: Forces the partition to be created on a particular disk. Do not prefix the disk name with /dev.
| |
| | |
| :: <code>--asprimary</code>
| |
| | |
| ::: Forces automatic allocation of the partition as a primary partition or the partitioning will fail.
| |
| | |
| :: <code>--fsprofile=</code>
| |
| | |
| ::: Specifies a usage type to be passed to the program that makes a filesystem on this partition. A usage type defines a variety of tuning parameters to be used when making a filesystem. For this option to work, the filesystem must support the concept of usage types and there must be a configuration file that lists valid types. For ext2/3/4, this configuration file is <code>/etc/mke2fs.conf</code>.
| |
| | |
| :: <code>--fstype=</code>
| |
| | |
| ::: Sets the file system type for the partition. Valid values include ext4, ext3, ext2, btrfs, swap, and vfat. Other filesystems may be valid depending on command line arguments passed to anaconda to enable other filesystems.
| |
| | |
| :: <code>--fsoptions=</code>
| |
| | |
| ::: Specifies a free form string of options to be used when mounting the filesystem. This string will be copied into the /etc/fstab file of the installed system and should be enclosed in quotes.
| |
| | |
| :: <code>--label=</code>
| |
| | |
| ::: Specify the label to give to the filesystem to be made on the partition. If the given label is already in use by another filesystem, a new label will be created for this partition.
| |
| | |
| :: <code>--recommended</code>
| |
| | |
| ::: Determine the size of the partition automatically.
| |
| | |
| :: <code>--onbiosdisk=</code>
| |
| | |
| ::: Forces the partition to be created on a particular disk as discovered by the BIOS.
| |
| | |
| :: <code>--encrypted</code>
| |
| | |
| ::: Specify that this partition should be encrypted.
| |
| | |
| :: <code>--passphrase=</code>
| |
| | |
| ::: Specify the passphrase to use when encrypting this partition. Without the above --encrypted option, this option does nothing. If no passphrase is specified, the default system-wide one is used, or the installer will stop and prompt if there is no default.
| |
| | |
| :: <code>--escrowcert=<url></code>
| |
| | |
| ::: Load an X.509 certificate from <code><url></code>. Store the data encryption key of this partition, encrypted using the certificate, as a file in <code>/root</code>. Only relevant if <code>--encrypted</code> is specified as well.
| |
| | |
| :: <code>--backuppassphrase</code>
| |
| | |
| ::: Only relevant if <code>--escrowcert</code> is specified as well. In addition to storing the data encryption key, generate a random passphrase and add it to this partition. Then store the passphrase, encrypted using the certificate specified by <code>--escrowcert</code>, as a file in <code>/root</code>. If more than one LUKS volume uses <code>--backuppassphrase</code>, the same passphrase will be used for all such volumes.
| |
| | |
| {{Admon/caution | If partitioning fails for any reason, diagnostic messages will appear on virtual console 3.}}
| |
| | |
| == raid ==
| |
| | |
| : Assembles a software RAID device. This command is of the form:
| |
| | |
| : <code>raid <mntpoint> --level=<level> --device=<mddevice> <partitions*></code>
| |
| | |
| :: <code><mntpoint></code>
| |
| | |
| ::: Location where the RAID file system 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 <code><partitions*></code> (which denotes that multiple partitions can be listed) lists the RAID identifiers to add to the RAID array.
| |
| | |
| :: <code>--level=</code>
| |
| | |
| ::: RAID level to use (0, 1, 4, 5, 6, or 10).
| |
| | |
| :: <code>--device=</code>
| |
| | |
| ::: 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.
| |
| | |
| :: <code>--spares=</code>
| |
| | |
| ::: Specifies the number of spare drives allocated for the RAID array. Spare drives are used to rebuild the array in case of drive failure.
| |
| | |
| :: <code>--fstype=</code>
| |
| | |
| ::: Sets the file system type for the RAID array. Valid values include ext4, ext3, ext2, btrfs, swap, and vfat. Other filesystems may be valid depending on command line arguments passed to anaconda to enable other filesystems.
| |
| | |
| :: <code>--fsoptions=</code>
| |
| | |
| ::: Specifies a free form string of options to be used when mounting the filesystem. This string will be copied into the /etc/fstab file of the installed system and should be enclosed in quotes.
| |
| | |
| :: <code>--noformat</code>
| |
| | |
| ::: Use an existing RAID device and do not format the RAID array.
| |
| | |
| :: <code>--useexisting</code>
| |
| | |
| ::: Use an existing RAID device and reformat it.
| |
| | |
| :: <code>--encrypted</code>
| |
| | |
| ::: Specify that this RAID device should be encrypted.
| |
| | |
| :: <code>--passphrase=</code>
| |
| | |
| ::: Specify the passphrase to use when encrypting this RAID device. Without the above --encrypted option, this option does nothing. If no passphrase is specified, the default system-wide one is used, or the installer will stop and prompt if there is no default.
| |
| | |
| :: <code>--escrowcert=<url></code>
| |
| | |
| ::: Load an X.509 certificate from <code><url></code>. Store the data encryption key of this RAID device, encrypted using the certificate, as a file in <code>/root</code>. Only relevant if <code>--encrypted</code> is specified as well.
| |
| | |
| :: <code>--backuppassphrase</code>
| |
| | |
| ::: Only relevant if <code>--escrowcert</code> is specified as well. In addition to storing the data encryption key, generate a random passphrase and add it to this RAID device. Then store the passphrase, encrypted using the certificate specified by <code>--escrowcert</code>, as a file in <code>/root</code>. If more than one LUKS volume uses <code>--backuppassphrase</code>, the same passphrase will be used for all such volumes.
| |
| | |
| : 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.
| |
| | |
| <pre>
| |
| 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
| |
| </pre>
| |
| | |
| == reboot ==
| |
| | |
| : Reboot after the installation is complete (no arguments). Normally, kickstart displays a message and waits for the user to press a key before rebooting.
| |
| | |
| :: <code>--eject</code>
| |
| | |
| ::: Attempt to eject CD or DVD media before rebooting.
| |
| | |
| == repo ==
| |
| | |
| : Configures additional yum repositories that may be used as sources for package installation. Multiple repo lines may be specified. By default, anaconda has a configured set of repos taken from /etc/yum.repos.d plus a special Installation Repo in the case of a media install. The exact set of repos in this directory changes from release to release and cannot be listed here. There will likely always be a repo named "updates".
| |
| | |
| : <code>repo --name=<name> [--baseurl=<url>|--mirrorlist=<url>] [options] </code>
| |
| | |
| :: <code>--name=</code>
| |
| | |
| ::: The repo id. This option is required. If a repo has a name that conflicts with a previously added one, the new repo will be ignored. Because anaconda has a populated list of repos when it starts, this means that users cannot create new repos that override these names. Please check /etc/yum.repos.d from the operating system you wish to install to see what names are not available.
| |
| | |
| :: <code>--baseurl=</code>
| |
| | |
| ::: The URL for the repository. The variables that may be used in yum repo config files are not supported here. You may use one of either this option or <code>--mirrorlist</code>, not both. If an NFS repository is specified, it should be of the form <code>nfs://host:/path/to/repo</code>. Note that there is a colon after the host--Anaconda passes everything after "nfs://" directly to the mount command instead of parsing URLs according to RFC 2224.
| |
| | |
| :: <code>--mirrorlist=</code>
| |
| | |
| ::: The URL pointing at a list of mirrors for the repository. The variables that may be used in yum repo config files are not supported here. You may use one of either this option or <code>--baseurl</code>, not both.
| |
| | |
| :: <code>--cost=</code>
| |
| | |
| ::: An integer value to assign a cost to this repository. If multiple repositories provide the same packages, this number will be used to prioritize which repository will be used before another. Repositories with a lower cost take priority over repositories with higher cost.
| |
| | |
| :: <code>--excludepkgs=</code>
| |
| | |
| ::: A comma-separated list of package names and globs that must not be pulled from this repository. This is useful if multiple repositories provide the same package and you want to make sure it comes from a particular repository.
| |
| | |
| :: <code>--includepkgs=</code>
| |
| | |
| ::: A comma-separated list of package names and globs that must be pulled from this repository. This is useful if multiple repositories provide the same package and you want to make sure it comes from this repository.
| |
| | |
| :: <code>--proxy=[protocol://][username[:password]@]host[:port]</code>
| |
| | |
| ::: Specify an HTTP/HTTPS/FTP proxy to use just for this repository. This setting does not affect any other repositories, nor how the install.img is fetched on HTTP installs. The various parts of the argument act like you would expect.
| |
| | |
| :: <code>--ignoregroups</code>
| |
| | |
| ::: This option is used when composing installation trees and has no effect on the installation process itself. It tells the compose tools to not look at the package group information when mirroring trees so as to avoid mirroring large amounts of unnecessary data.
| |
| | |
| == rescue ==
| |
| | |
| : Automatically enter the installer's rescue mode. This gives you a chance to repair the system should something catastrophic happen.
| |
| | |
| : <code>rescue [--nomount|--romount]</code>
| |
| | |
| :: <code>--nomount|--romount]</code>
| |
| | |
| ::: Controls how the installed system is mounted in the rescue environment. By default, the installer will find your system and mount it in read-write mode, telling you where it has performed this mount. You may optionally choose to not mount anything or mount in read-only mode. Only one of these two options may be given at any one time.
| |
| | |
| == rootpw ==
| |
| | |
| : This required command sets the system's root password to the <code><password></code> argument.
| |
| | |
| : <code>rootpw [options] <password></code>
| |
| | |
| :: <code>--iscrypted|--plaintext</code>
| |
| | |
| ::: If this is present, the password argument is assumed to already be encrypted. <code>--plaintext</code> has the opposite effect - the password argument is assumed to not be encrypted.
| |
| | |
| :: <code>--lock</code>
| |
| | |
| ::: If this is present, the root account is locked by default. That is, the root user will not be able to login from the console.
| |
| | |
| == selinux ==
| |
| | |
| : Sets the state of SELinux on the installed system. SELinux defaults to enforcing in anaconda.
| |
| | |
| : <code>selinux [--disabled|--enforcing|--permissive] </code>
| |
| | |
| :: <code>--disabled</code>
| |
| | |
| ::: If this is present, SELinux is disabled.
| |
| | |
| :: <code>--enforcing</code>
| |
| | |
| ::: If this is present, SELinux is set to enforcing mode.
| |
| | |
| :: <code>--permissive</code>
| |
| | |
| ::: If this is present, SELinux is enabled, but only logs things that would be denied in enforcing mode.
| |
| | |
| == services ==
| |
| | |
| : Modifies the default set of services that will run under the default runlevel. The services listed in the disabled list will be disabled before the services listed in the enabled list are enabled.
| |
| | |
| : <code>services [--disabled=<list>] [--enabled=<list>] </code>
| |
| | |
| :: <code>--disabled=</code>
| |
| | |
| ::: Disable the services given in the comma separated list.
| |
| | |
| :: <code>--enabled=</code>
| |
| | |
| ::: Enable the services given in the comma separated list.
| |
| | |
| == sshpw ==
| |
| | |
| : The installer can start up ssh to provide for interactivity and inspection, just like it can with telnet. This command is used to control the accounts created in the installation environment that may be remotely logged into. For each instance of this command given, a user will be created. These users will not be created on the final system - they only exist for use while the installer is running.
| |
| | |
| : <code>sshpw --username=<name> <password> [--iscrypted|--plaintext] [--lock]</code>
| |
| | |
| :: <code>--username=</code>
| |
| | |
| ::: Provides the name of the user. This option is required.
| |
| | |
| :: <code>--iscrypted|--plaintext</code>
| |
| | |
| ::: If this is present, the password argument is assumed to already be encrypted. --plaintext has the opposite effect - the password argument is assumed to not be encrypted.
| |
| | |
| :: <code>--lock</code>
| |
| | |
| ::: If this is present, the new user account is locked by default. That is, the user will not be able to login from the console.
| |
| | |
| == skipx ==
| |
| | |
| : If present, X is not configured on the installed system.
| |
| | |
| == text ==
| |
| | |
| : Perform the kickstart installation in text mode. Kickstart installations are performed in graphical mode by default.
| |
| | |
| == timezone ==
| |
| | |
| : This required command sets the system time zone to <timezone> which may be any of the time zones listed by timeconfig.
| |
| | |
| : <code>timezone [--utc] <timezone></code>
| |
| | |
| :: <code>--utc</code>
| |
| | |
| ::: If present, the system assumes the hardware clock is set to UTC (Greenwich Mean) time.
| |
| | |
| == updates ==
| |
| | |
| : Specify the location of an updates.img for use in installation. See anaconda-release-notes.txt for a description of how to make an updates.img.
| |
| | |
| :: <code>updates [URL]</code>
| |
| | |
| ::: If present, the URL for an updates image.
| |
| | |
| ::: If not present, anaconda will attempt to load from a floppy disk.
| |
| | |
| == upgrade ==
| |
| | |
| : Tells the system to upgrade an existing system rather than install a fresh system. You must specify one of cdrom, harddrive, nfs, or url (for ftp and http) as the location of the installation tree. Refer to install for details.
| |
| | |
| :: <code>--root-device=<root></code> (optional)
| |
| | |
| ::: On a system with multiple installs, this option specifies which filesystem holds the installation to be upgraded. This can be specified by device name, UUID=<uuid>, or LABEL=<fslabel> just like the harddrive command may be.
| |
| | |
| == user ==
| |
| | |
| : Creates a new user on the system.
| |
| | |
| : <code>user --name=<username> [--gecos=<string>] [--groups=<list>] [--homedir=<homedir>] [--password=<password>] [--iscrypted|--plaintext] [--lock] [--shell=<shell>] [--uid=<uid>]</code>
| |
| | |
| :: <code>--name=</code>
| |
| | |
| ::: Provides the name of the user. This option is required.
| |
| | |
| :: <code>--gecos=</code>
| |
| | |
| ::: Provides the GECOS information for the user. This is a string of various system-specific fields separated by a comma. It is frequently used to specify the user's full name, office number, and the like. See <code>man 5 passwd</code> for more details.
| |
| | |
| :: <code>--groups=</code>
| |
| | |
| ::: In addition to the default group, a comma separated list of group names the user should belong to.
| |
| | |
| :: <code>--homedir=</code>
| |
| | |
| ::: The home directory for the user. If not provided, this defaults to /home/<username>.
| |
| | |
| :: <code>--lock</code>
| |
| | |
| ::: If this is present, the new user account is locked by default. That is, the user will not be able to login from the console.
| |
| | |
| :: <code>--password=</code>
| |
| | |
| ::: The new user's password. If not provided, the account will be locked by default.
| |
| | |
| :: <code>--iscrypted|--plaintext</code>
| |
| | |
| ::: Is the password provided by <code>--password</code> already encrypted or not? <code>--plaintext</code> has the opposite effect - the password argument is assumed to not be encrypted.
| |
| | |
| :: <code>--shell=</code>
| |
| | |
| ::: The user's login shell. If not provided, this defaults to the system default.
| |
| | |
| :: <code>--uid=</code>
| |
| | |
| ::: The user's UID. If not provided, this defaults to the next available non-system UID.
| |
| | |
| == vnc ==
| |
| | |
| : Allows the graphical installation to be viewed remotely via VNC. This method is usually preferred over text mode, as there are some size and language limitations in text installs. With no options, this command will start a VNC server on the machine with no password and will print out the command that needs to be run to connect a remote machine.
| |
| | |
| : <code>vnc [--host=<hostname>] [--port=<port>] [--password=<password>] </code>
| |
| | |
| :: <code>--host=</code>
| |
| | |
| ::: Instead of starting a VNC server on the install machine, connect to the VNC viewer process listening on the given hostname.
| |
| | |
| :: <code>--port=</code>
| |
| | |
| ::: Provide a port that the remote VNC viewer process is listening on. If not provided, anaconda will use the VNC default.
| |
| | |
| :: <code>--password=</code>
| |
| | |
| ::: Set a password which must be provided to connect to the VNC session. This is optional, but recommended.
| |
| | |
| == volgroup ==
| |
| | |
| : Use to create a Logical Volume Management (LVM) group.
| |
| | |
| : <code>volgroup <name> <partitions*> <options></code>
| |
| | |
| :: <code><name></code>
| |
| | |
| ::: Name given to the volume group. The <partitions*> (which denotes that multiple partitions can be listed) lists the identifiers to add to the volume group.
| |
| | |
| :: <code>--noformat</code>
| |
| | |
| ::: Use an existing volume group and do not format it.
| |
| | |
| :: <code>--useexisting</code>
| |
| | |
| ::: Use an existing volume group and reformat it.
| |
| | |
| :: <code>--pesize=</code>
| |
| | |
| ::: Set the size of the physical extents.
| |
| | |
| : Create the partition first, create the logical volume group, and then create the logical volume. For example:
| |
| | |
| <pre>
| |
| part pv.01 --size 3000
| |
| volgroup myvg pv.01
| |
| logvol / --vgname=myvg --size=2000 --name=rootvol
| |
| </pre>
| |
| | |
| == xconfig ==
| |
| | |
| : Configures the X Window System. If this option is not given, anaconda will use X to attempt to automatically configure. Please try this before manually configuring your system.
| |
| | |
| :: <code>--defaultdesktop=</code>
| |
| | |
| ::: Specify either GNOME or KDE to set the default desktop (assumes that GNOME Desktop Environment and/or KDE Desktop Environment has been installed through %packages).
| |
| | |
| :: <code>--startxonboot</code>
| |
| | |
| ::: Use a graphical login on the installed system.
| |
| | |
| == zerombr ==
| |
| | |
| : If zerombr is specified, any invalid partition tables found on disks are initialized. This will destroy all of the contents of disks with invalid partition tables.
| |
| | |
| == zfcp ==
| |
| | |
| :: <code>--devnum=</code>
| |
| | |
| :: <code>--fcplun=</code>
| |
| | |
| :: <code>--scsiid=</code>
| |
| | |
| :: <code>--scsilun=</code>
| |
| | |
| :: <code>--wwpn=</code>
| |
| | |
| == %include ==
| |
| | |
| : Use the <code>%include /path/to/file</code> 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.
| |
| | |
| == %ksappend ==
| |
| | |
| = Chapter 3. 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).
| |
| | |
| Packages can be specified by group or by individual package name. The installation program defines several groups that contain related packages. Refer to the repodata/*comps.xml file on the first CD-ROM for a list of groups. Each group has an id, user visibility value, name, description, and package list. In the package list, the packages marked as mandatory are always installed if the group is selected, the packages marked default are selected by default if the group is selected, and the packages marked optional must be specifically selected even if the group is selected to be installed.
| |
| | |
| In most cases, it is only necessary to list the desired groups and not individual packages. Note that the Core and Base groups are always selected by default, so it is not necessary to specify them in the %packages section.
| |
| | |
| The %packages section should be closed with %end, though this is not yet required. It will be required in the future, however. Also, multiple %packages sections may be given. This may be handy if the kickstart file is used as a template and pulls in various other files with the %include mechanism.
| |
| | |
| Here is an example %packages selection:
| |
| | |
| <pre>
| |
| %packages
| |
| @X Window System
| |
| @GNOME Desktop Environment
| |
| @Graphical Internet
| |
| @Sound and Video
| |
| dhcp
| |
| %end
| |
| </pre>
| |
| | |
| As you can see, groups are specified, one to a line, starting with an @ symbol followed by the full group name as given in the comps.xml file. Groups can also be specified using the id for the group, such as gnome-desktop. Specify individual packages with no additional characters (the dhcp line in the example above is an individual package).
| |
| | |
| Additionally, individual packages may be specified using globs. For instance:
| |
| | |
| <pre>
| |
| %packages
| |
| vim*
| |
| kde-i18n-*
| |
| %end
| |
| </pre>
| |
| | |
| This would install all packages whose names start with "vim" or "kde-i18n-".
| |
| | |
| You can also specify which packages not to install from the default package list:
| |
| | |
| <pre>
| |
| %packages
| |
| -autofs
| |
| %end
| |
| </pre>
| |
| | |
| The following options are available for the %packages option:
| |
| | |
| : <code>--default</code>
| |
| | |
| :: Install the default package set. This corresponds to the package set that would be installed if no other selections were made on the package customization screen during an interactive install.
| |
| | |
| : <code>--excludedocs</code>
| |
| | |
| :: Do not install any of the documentation from any packages. For the most part, this means files in /usr/share/doc* will not get installed though it could mean other files as well, depending on how the package was built.
| |
| | |
| : <code>--ignoremissing</code>
| |
| | |
| :: Ignore any packages or groups specified in the packages section that are not found in any configured repository. The default behavior is to halt the installation and ask the user if the installation should be aborted or continued. This option allows fully automated installation even in the error case. It is used as follows:
| |
| | |
| :: <code>%packages --ignoremissing</code>
| |
| | |
| : <code>--instLangs=</code>
| |
| | |
| :: Specify the list of languages that should be installed. This is different from the package group level selections, though. This option does not specify what package groups should be installed. Instead, it controls which translation files from individual packages should be installed by setting RPM macros. Note: this option is not supported by anaconda at the moment, but is recognized by pykickstart for use in such tools as livecd-creator.
| |
| | |
| : <code>--nobase</code>
| |
| | |
| :: Don't select the Base group by default. This is useful if you are putting together an extremely minimal system. However with this option, it is very easy to end up with a system that does not fully boot to a login prompt as you will need to list all the packages required to get that much functionality.
| |
| | |
| In addition, group lines in the %packages section can take options as
| |
| well:
| |
| | |
| : <code>--nodefaults</code>
| |
| | |
| :: Only install the group's mandatory packages, not the default selections.
| |
| | |
| {{Admon/note|2=Note that if you specify --nodefaults for a group, all of that group's default packages will be ignored, even if you try to specify them individually.
| |
| | |
| See Bug #[[rhbug:448172|448172]] for more info.}}
| |
| | |
| : <code>--optional</code>
| |
| | |
| :: In addition to the mandatory and default packages, also install the optional packages. This means all packages in the group will be installed.
| |
| | |
| = Chapter 4. Pre-installation Script =
| |
| | |
| 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. 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.
| |
| | |
| Preinstallation scripts should be closed with %end, though this is not yet required. It will be required in the future, however.
| |
| | |
| {{Admon/caution | 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.}}
| |
| | |
| {{Admon/caution | Note that the pre-install script is not run in the chroot environment.}}
| |
| | |
| : <code>--interpreter /usr/bin/python</code>
| |
| | |
| :: Allows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice.
| |
| | |
| : <code>--erroronfail</code>
| |
| | |
| :: If the pre-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.
| |
| | |
| : <code>--log=</code>
| |
| | |
| :: Log all messages from the script to the given log file.
| |
| | |
| == Example ==
| |
| | |
| Here is an example %pre section:
| |
| | |
| <pre>
| |
| %pre
| |
| #!/bin/bash
| |
| 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)
| |
| | |
| | |
| if [ $numhd == "2" ] ; then
| |
| echo "#partitioning scheme generated in %pre for 2 drives" > /tmp/part-include
| |
| echo "clearpart --all" >> /tmp/part-include
| |
| echo "part /boot --fstype ext4 --size 75 --ondisk hda" >> /tmp/part-include
| |
| echo "part / --fstype ext4 --size 1 --grow --ondisk hda" >> /tmp/part-include
| |
| echo "part swap --recommended --ondisk $drive1" >> /tmp/part-include
| |
| echo "part /home --fstype ext4 --size 1 --grow --ondisk hdb" >> /tmp/part-include
| |
| else
| |
| echo "#partitioning scheme generated in %pre for 1 drive" > /tmp/part-include
| |
| echo "clearpart --all" >> /tmp/part-include
| |
| echo "part /boot --fstype ext4 --size 75" >> /tmp/part-include
| |
| echo "part swap --recommended" >> /tmp/part-include
| |
| echo "part / --fstype ext4 --size 2048" >> /tmp/part-include
| |
| echo "part /home --fstype ext4 --size 2048 --grow" >> /tmp/part-include
| |
| fi
| |
| %end
| |
| </pre>
| |
| | |
| 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:
| |
| | |
| <code>%include /tmp/part-include</code>
| |
| | |
| The partitioning commands selected in the script will be used.
| |
| | |
| = 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.
| |
| | |
| {{Admon/caution | 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.}}
| |
| | |
| {{Admon/caution | 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.}}
| |
| | |
| {{Admon/caution | 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.}}
| |
| | |
| : <code>--nochroot</code>
| |
| | |
| :: Allows you to specify commands that you would like to run outside of the chroot environment.
| |
| | |
| : <code>--interpreter /usr/bin/python</code>
| |
| | |
| :: Allows you to specify a different scripting language, such as Python. Replace /usr/bin/python with the scripting language of your choice.
| |
| | |
| : <code>--erroronfail</code>
| |
| | |
| :: 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.
| |
| | |
| : <code>--log=</code>
| |
| | |
| :: Log all messages from the script to the given log file.
| |
| | |
| == Examples ==
| |
| | |
| Run a script named runme from an NFS share:
| |
| | |
| <pre>
| |
| %post
| |
| mkdir /mnt/temp
| |
| mount 10.10.0.2:/usr/new-machines /mnt/temp
| |
| open -s -w -- /mnt/temp/runme
| |
| umount /mnt/temp
| |
| %end
| |
| </pre>
| |
| | |
| Copy the file /etc/resolv.conf to the file system that was just installed:
| |
| | |
| <pre>
| |
| %post --nochroot
| |
| cp /etc/resolv.conf /mnt/sysimage/etc/resolv.conf
| |
| %end
| |
| </pre>
| |
| | |
| = 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:
| |
| | |
| <code>mcopy ks.cfg a:</code>
| |
| | |
| 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:
| |
| | |
| <pre>
| |
| filename "/usr/new-machine/kickstart/";
| |
| next-server blarg.redhat.com;
| |
| </pre>
| |
| | |
| 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:
| |
| | |
| <code><ip-addr>-kickstart</code>
| |
| | |
| 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:
| |
| | |
| <code>linux ks=floppy</code>
| |
| | |
| == 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:
| |
| | |
| <code>linux ks=hd:fd0:/ks.cfg</code>
| |
| | |
| == 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:
| |
| | |
| <code>linux ks=floppy dd</code>
| |
| | |
| == 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):
| |
| | |
| <code>linux ks=cdrom:/ks.cfg</code>
| |
| | |
| == Other kickstart options: ==
| |
| | |
| <code>ks=nfs:<server>:/<path></code>
| |
| | |
| : 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.
| |
| | |
| <code>ks=http://<server>/<path></code>
| |
| | |
| : 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.
| |
| | |
| <code>ks=floppy</code>
| |
| | |
| : The installation program looks for the file ks.cfg on a vfat or ext2 file system on the diskette in /dev/fd0.
| |
| | |
| <code>ks=floppy:/<path></code>
| |
| | |
| : The installation program will look for the kickstart file on the diskette in /dev/fd0, as file <path>.
| |
| | |
| <code>ks=hd:<device>:/<file></code>
| |
| | |
| : 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).
| |
| | |
| <code>ks=bd:<biosdev>:/<path></code>
| |
| : 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.
| |
| | |
| <code>ks=file:/<file></code>
| |
| | |
| : 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.
| |
| | |
| <code>ks=cdrom:/<path></code>
| |
| | |
| : The installation program will look for the kickstart file on CD-ROM, as file <path>.
| |
| | |
| <code>ks</code>
| |
| | |
| : 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.
| |
| | |
| <code>ksdevice=<device></code>
| |
| | |
| : 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 <code>ks=nfs:<server>:/<path> ksdevice=eth1</code> at the boot: prompt. For more information, see [[Anaconda_Boot_Options]].
| |
|
| |
|
| ---- | | ---- |
| [[Category:Anaconda]] | | [[Category:Anaconda]] |
