|
|
| (260 intermediate revisions by 43 users not shown) |
| Line 1: |
Line 1: |
| [[TableOfContents()]
| | {{autolang|base=yes}} |
|
| |
|
| = Chapter 1. Introduction =
| | The kickstart documentation is now on Read the Docs: |
|
| |
|
| == What are Kickstart Installations? ==
| | [http://pykickstart.readthedocs.io/en/latest/ http://pykickstart.readthedocs.io/en/latest/] |
|
| |
|
| Many system administrators would prefer to use an automated installation
| | It should be automatically kept up to date and links pointing to it and its parts should remain reasonably stable. |
| 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 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.
| |
| | |
| 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:
| |
| | |
| 1. Create a kickstart file.
| |
| | |
| 1. Create a boot diskette with the kickstart file or make the kickstart file available on the network.
| |
| | |
| 1. Make the installation tree available.
| |
| | |
| 1. 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.
| |
| | |
| {{Template:Warning}}
| |
| If the option is followed by an equals mark (=), a value must be
| |
| specified after it. In the example commands, options in brackets ([] )
| |
| are optional arguments for the command.
| |
| | |
| <code>auth</code> or <code>authconfig</code> (required)
| |
| | |
| 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.
| |
| | |
| <code>autopart</code> (optional)
| |
| | |
| 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>autostep</code> (optional)
| |
| | |
| 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.
| |
| | |
| <code>bootloader</code> (required)
| |
| | |
| Specifies how the boot loader should be installed. This option is
| |
| required for both installations and upgrades.
| |
| | |
| <code>--append=</code>
| |
| | |
| Specifies kernel parameters. To specify multiple parameters,
| |
| separate them with spaces. 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.
| |
| | |
| <code>clearpart</code> (optional)
| |
| | |
| Removes partitions from the system, prior to creation of new
| |
| partitions. By default, no partitions are removed.
| |
| | |
| {{Template:Warning}}
| |
| 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 --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.
| |
| | |
| <code>cmdline</code> (optional)
| |
| | |
| 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.
| |
| | |
| <code>device</code> (optional)
| |
| | |
| 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. Note that multiple
| |
| options may be passed if they are put in quotes. For example:
| |
| | |
| <code>--opts="aic152x=0x340 io=11"</code>
| |
| | |
| <code>dmraid</code> (optional)
| |
| | |
| <code>dmraid --name= --dev=</code>
| |
| | |
| <code>driverdisk</code> (optional)
| |
| | |
| Driver diskettes can be used during kickstart installations. You
| |
| need to copy the driver diskettes'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> [--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>firewall</code> (optional)
| |
| | |
| This option corresponds to the Firewall Configuration screen in
| |
| the installation program:
| |
| | |
| <code>firewall --enabled|--disabled [--trust=] <device> [--port=] </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>
| |
| | |
| * <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. For example, to allow IMAP
| |
| access through your firewall, specify imap:tcp. Numeric ports
| |
| can also be specified explicitly; for example, to allow UDP
| |
| packets on port 1234 through, specify 1234:udp. To specify
| |
| multiple ports, separate them by commas.
| |
| | |
| <code>firstboot</code> (optional)
| |
| | |
| 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.
| |
| | |
| <code>graphical</code> (optional)
| |
| | |
| Perform the kickstart installation in graphical mode. This is the
| |
| default.
| |
| | |
| <code>install</code> (optional)
| |
| | |
| 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 drive on the system.
| |
| | |
| <code>harddrive</code>
| |
| | |
| Install from a Red Hat installation tree on a local drive,
| |
| which must be either vfat or ext2.
| |
| | |
| * <code>--biospart=</code>
| |
| | |
| BIOS partition to install from (such as 82).
| |
| | |
| * <code>--partition=</code>
| |
| | |
| Partition to install from (such as, sdb2).
| |
| | |
| * <code>--dir=</code>
| |
| | |
| Directory containing the RedHat directory of the
| |
| installation tree.
| |
| | |
| For example:
| |
| | |
| <code>harddrive --partition=hdb2 --dir=/tmp/install-tree </code>
| |
| | |
| <code>nfs</code>
| |
| | |
| Install from the NFS server specified.
| |
| | |
| * <code>--server=</code>
| |
| | |
| Server from which to install (hostname or IP).
| |
| | |
| * <code>--dir=</code>
| |
| | |
| Directory containing the RedHat directory of the installation
| |
| tree.
| |
| | |
| * <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.
| |
| | |
| For example:
| |
| | |
| <code>url --url http://<server>/<dir></code>
| |
| | |
| or:
| |
| | |
| <code>url --url ftp://<username>:<password>@<server>/<dir></code>
| |
| | |
| <code>ignoredisk</code> (optional)
| |
| | |
| Used to specify disks that anaconda should not touch when
| |
| partitioning, formatting, and clearing. This command has a single
| |
| required argument, which takes a comma-separated list of drive
| |
| names to ignore.
| |
| | |
| <code>ignoredisk --drives=[disk1,disk2,...] </code>
| |
| | |
| <code>interactive</code> (optional)
| |
| | |
| 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.
| |
| | |
| <code>iscsi</code> (optional)
| |
| | |
| <code>iscsi --ipaddr= [options] </code>
| |
| | |
| <code>--target=</code>
| |
| | |
| <code>--port=</code>
| |
| | |
| <code>--user=</code>
| |
| | |
| <code>--password=</code>
| |
| | |
| <code>iscsiname</code> (optional)
| |
| | |
| <code>key</code> (optional)
| |
| | |
| Specify a registration key, which is needed to aid in package
| |
| selection and identify your system for support purposes. This
| |
| command is RHEL-specific; it has no meaning for Fedora and will
| |
| be ignored.
| |
| | |
| <code>--skip</code>
| |
| | |
| Skip entering a key. Usually if the key command is not given,
| |
| anaconda will pause at this step to prompt for a key. This
| |
| option allows automated installation to continue if you do not
| |
| have a key or do not want to provide one.
| |
| | |
| <code>keyboard</code> (required)
| |
| | |
| 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.
| |
| | |
| <code>lang</code> (required)
| |
| | |
| <code>lang <id></code>
| |
| | |
| 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.
| |
| | |
| <code>logvol</code> (optional)
| |
| | |
| 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
| |
| are ext2, ext3, swap, and vfat.
| |
| | |
| <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.
| |
| | |
| 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>
| |
| | |
| <code>logging</code> (optional)
| |
| | |
| 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.
| |
| | |
| <code>mediacheck</code> (optional)
| |
| | |
| 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.
| |
| | |
| <code>monitor</code> (optional)
| |
| | |
| 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.
| |
| | |
| <code>multipath</code> (optional)
| |
| | |
| <code>multipath --name= --device= --rule=</code>
| |
| | |
| <code>network</code> (optional)
| |
| | |
| 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|query] </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 query method stops the installer during the first stage for
| |
| you to enter the network settings by hand, and then again during
| |
| the second stage for the same information. Don't use this method
| |
| unless you need your kickstart installation stopped for manual
| |
| intervention.
| |
| | |
| 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.
| |
| 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.
| |
| | |
| <code>part</code> or <code>partition</code> (required for installs, ignored for upgrades)
| |
| | |
| Creates a partition on the system.
| |
| | |
| 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.
| |
| | |
| {{Template:Warning}}
| |
| 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 minimum size of the automatically-generated swap
| |
| partition will be no smaller than the amount of RAM in the
| |
| system and no bigger than twice the amount of RAM in the
| |
| system.
| |
| | |
| * <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>--fstype=</code>
| |
| | |
| Sets the file system type for the partition. Valid values are
| |
| ext2, ext3, swap, and vfat.
| |
| | |
| <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>--start=</code>
| |
| | |
| Specifies the starting cylinder for the partition. It requires
| |
| that a drive be specified with <code>--ondisk=</code> or <code>ondrive=</code>.
| |
| It also requires that the ending cylinder be specified with
| |
| <code>--end=</code> or the partition size be specified with <code>--size=</code>.
| |
| | |
| <code>--end=</code>
| |
| | |
| Specifies the ending cylinder for the partition. It requires
| |
| that the starting cylinder be specified with <code>--start=</code>.
| |
| | |
| <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.
| |
| | |
| {{Template:Warning}}
| |
| If partitioning fails for any reason, diagnostic messages will
| |
| appear on virtual console 3.
| |
| | |
| <code>raid</code> (optional)
| |
| | |
| 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, or 5).
| |
| | |
| <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 are
| |
| ext2, ext3, swap, and vfat.
| |
| | |
| <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.
| |
| | |
| | |
| 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>
| |
| | |
| <code>reboot</code> (optional)
| |
| | |
| 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 and CD or DVD media before rebooting.
| |
| | |
| <code>repo</code> (optional)
| |
| | |
| Configures additional yum repositories that may be used as sources
| |
| for package installation. Multiple repo lines may be specified.
| |
| | |
| <code>repo --name=<name> [--baseurl=<url>|--mirrorlist=<url>] [options] </code>
| |
| | |
| <code>--name=</code>
| |
| | |
| The repo id. This option is required.
| |
| | |
| <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.
| |
| | |
| <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>--priority=</code>
| |
| | |
| An integer value to assign a priority level to this repository.
| |
| If multiple repositories provide the same packages, this number
| |
| will be used to prioritize which repository will be used before
| |
| another.
| |
| | |
| <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>rootpw</code> (required)
| |
| | |
| Sets the system's root password to the <code><password></code> argument.
| |
| | |
| <code>rootpw [--iscrypted] <password></code>
| |
| | |
| <code>--iscrypted</code>
| |
| | |
| If this is present, the password argument is assumed to already
| |
| be encrypted.
| |
| | |
| <code>selinux</code> (optional)
| |
| | |
| 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.
| |
| | |
| <code>services</code> (optional)
| |
| | |
| 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.
| |
| | |
| <code>skipx</code> (optional)
| |
| | |
| If present, X is not configured on the installed system.
| |
| | |
| <code>text</code> (optional)
| |
| | |
| Perform the kickstart installation in text mode. Kickstart
| |
| installations are performed in graphical mode by default.
| |
| | |
| <code>timezone</code> (required)
| |
| | |
| 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.
| |
| | |
| <code>updates</code> (optional)
| |
| | |
| 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>
| |
| | |
| <code>url</code>
| |
| | |
| If present, the URL for an updates image. If not present,
| |
| anaconda will attempt to load from a floppy disk.
| |
| | |
| <code>upgrade</code> (optional)
| |
| | |
| 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>user</code> (optional)
| |
| | |
| Creates a new user on the system.
| |
| | |
| <pre>user --name=<username> [--groups=<list>] [--homedir=<homedir>]
| |
| [--password=<password>] [--iscrypted] [--shell=<shell>]
| |
| [--uid=<uid>] </pre>
| |
| | |
| <code>--name=</code>
| |
| | |
| Provides the name of the user. This option is required.
| |
| | |
| <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>--password=</code>
| |
| | |
| The new user's password. If not provided, the account will be
| |
| locked by default.
| |
| | |
| <code>--iscrypted</code>
| |
| | |
| Is the password provided by <code>--password</code> already encrypted or not?
| |
| | |
| <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.
| |
| | |
| <code>vnc</code> (optional)
| |
| | |
| 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.
| |
| | |
| <code>volgroup</code> (optional)
| |
| | |
| 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>
| |
| | |
| <code>xconfig</code> (optional)
| |
| | |
| 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>--driver=</code>
| |
| | |
| Specify the X driver to use for the video hardware.
| |
| | |
| <code>--videoram=</code>
| |
| | |
| Specify the amount of video RAM the video card has.
| |
| | |
| <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.
| |
| | |
| <code>--resolution=</code>
| |
| | |
| Specify the default resolution for the X Window System on the
| |
| installed system. Valid values are 640x480, 800x600, 1024x768,
| |
| 1152x864, 1280x1024, 1400x1050, 1600x1200. Be sure to specify a
| |
| resolution that is compatible with the video card and monitor.
| |
| | |
| <code>--depth=</code>
| |
| | |
| Specify the default color depth for the X Window System on the
| |
| installed system. Valid values are 8, 16, 24, and 32. Be sure
| |
| to specify a color depth that is compatible with the video card
| |
| and monitor.
| |
| | |
| <code>zerombr</code> (optional)
| |
| | |
| 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.
| |
| | |
| <code>zfcp</code> (optional)
| |
| | |
| <code>--devnum=</code>
| |
| | |
| <code>--fcplun=</code>
| |
| | |
| <code>--scsiid=</code>
| |
| | |
| <code>--scsilun=</code>
| |
| | |
| <code>--wwpn=</code>
| |
| | |
| <code>%include</code>
| |
| | |
| 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.
| |
| | |
| <code>%ksappend</code>
| |
| | |
| = 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>--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.
| |
| | |
| <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.
| |
| | |
| {{Template:Warning}}
| |
| Note that the pre-install script is not run in the change root
| |
| 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/sh
| |
| hds=""
| |
| mymedia=""
| |
| | |
| for file in /proc/ide/h*
| |
| do
| |
| mymedia=<code>cat $file/media</code>
| |
| if [ $mymedia == "disk" ] ; then
| |
| hds="$hds <code>basename $file</code>"
| |
| fi
| |
| done
| |
| | |
| set $hds
| |
| numhd=<code>echo $#</code>
| |
| | |
| drive1=<code>echo $hds | cut -d' ' -f1</code>
| |
| drive2=<code>echo $hds | cut -d' ' -f2</code>
| |
| | |
| | |
| 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 ext3 --size 75 --ondisk hda" >> /tmp/part-include
| |
| echo "part / --fstype ext3 --size 1 --grow --ondisk hda" >> /tmp/part-include
| |
| echo "part swap --recommended --ondisk $drive1" >> /tmp/part-include
| |
| echo "part /home --fstype ext3 --size 1 --grow --ondisk hdb" >> /tmp/part-include
| |
| else
| |
| echo "#partitioning scheme generated in %pre for 1 drive" > /tmp/part-include
| |
| echo "clearpart --all" >> /tmp/part-include
| |
| echo "part /boot --fstype ext3 --size 75" >> /tmp/part-include
| |
| echo "part swap --recommended" >> /tmp/part-include
| |
| echo "part / --fstype ext3 --size 2048" >> /tmp/part-include
| |
| echo "part /home --fstype ext3 --size 2048 --grow" >> /tmp/part-include
| |
| fi
| |
| %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.
| |
| | |
| {{Template:Warning}}
| |
| 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.
| |
| | |
| {{Template:Warning}}
| |
| 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=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 ks=nfs:<server>:/<path>
| |
| ksdevice=eth1 at the boot: prompt.
| |
|
| |
|
| ---- | | ---- |
| [[Category:Anaconda]] | | [[Category:Anaconda]] |
