Tips and tricks for anaconda and kickstart
For full documentations, please see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/ch-kickstart2.html (CentOS 5), https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-kickstart2.html (CentOS 6) or https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Installation_Guide/chap-kickstart-installations.html (CentOS 7)
Tuning the %packages section
When using %packages to define the set of packages that should be installed there are a number of more or less documented options that can be set:
- --resolvedeps
- Dependencies between packages will be automatically resolved. This option has been deprecated in Centos 5, dependencies are resolved automatically every time now.
- --excludedocs
Skips the installation of files that are marked as documentation (all files that are listed when you do rpm -qld <packagename>)
- --nobase
- Skips installation of @Base. This won't work unless you know what you're doing as it might leave out packages required by post installation scripts
- --ignoremissing
- Ignore missing packages and groups instead of asking what to do. This option has been deprecated in Centos 5, dependencies are resolved automatically every time now.
Example of minimal package selection for CentOS 4:
%packages --resolvedeps --excludedocs --nobase kudzu
please note that essential stuff will be missing. There will be no rpm, no yum, no vim, no dhcp-client and no keyboard layouts. Kudzu is required, because the installer fails if it is missing.
Example of minimal package selection for CentOS 5:
%packages --excludedocs --nobase @Core
Again, this will leave you with a *very* basic system that will be missing almost every feature you might expect.
The --resolvedeps used with CentOS 4 is not required for CentOS 5 and newer releases as the newer installer always resolves dependencies.
Partitioning
If you start out with a unpartitioned disk, or a virtual machine on a unpartitioned image, use the --initlabel parameter to clearpart to make sure that the disklabel is initialized, or Anaconda will ask you to confirm creation of a disklabel interactively. For instance, to clean all partitions on xvda, and initialize the disklabel if it does not exist yet, you could use:
clearpart --all --initlabel --drives=xvda
Running anaconda in real text-mode
You probably already know that you can make anaconda run with a ncurses interface instead of the X11 interface by adding the line "text" to your kickstart file. But there's another option: install in real shell-like textmode. Replace the "text"-line with a "cmdline"-line in your kickstart file and anaconda will do the whole installation in textmode. Especially when you use %packages --nobase or run complex %post scripts this will probably save hours of debugging, because you can actually see the output of all scripts that run during the installation.
Enable/disable firstboot
You all know firstboot, the druid that helps you to set up the system after install. It can be enabled and disabled by adding either "firstboot --enable" or "firstboot --disable" to the command section of your kickstart file.
What the different terminals display
- Alt-F1
- The installation dialog when using text or cmdline
- Alt-F2
- A shell prompt
- Alt-F3
- The install log displaying messages from install program
- Alt-F4
- The system log displaying messages from kernel, etc.
- Alt-F5
- All other messages
- Alt-F7
- The installation dialog when using the graphical installer
Logging %pre and %post
When using a %pre or %post script you can simply log the output to a file by using --log=/path/to/file
%post --log=/root/my-post-log echo 'Hello, World!'
Another way of logging and displaying the results on the screen would be the following:
%post exec < /dev/tty3 > /dev/tty3 chvt 3 echo echo "################################" echo "# Running Post Configuration #" echo "################################" ( echo 'Hello, World!' ) 2>&1 | /usr/bin/tee /var/log/post_install.log chvt 1
Trusted interfaces for firewall configuration
You can use the --trust option to the firewall option multiple times to trust multiple interfaces:
# Enable firewall, open port for ssh and make eth1 and eth2 trusted firewall --enable --ssh --trust=eth1 --trust=eth2
Use a specific network interface for kickstart
When your system has more than one network interface anaconda asks you which one you'd like to use for the kickstart process. This decision can be made at boot time by adding the ksdevice paramter and setting it accordingly. To run kickstart via eth0 simply add ksdevice=eth0 to the kernel command line.
A second method is using ksdevice=link. In this case anaconda will use the first interface it finds that has a active link.
A third method works if you are doing PXE based installations. Then you add IPAPPEND 2 to the PXE configuration file and use ksdevice=bootif. In this case anaconda will use the interface that did the PXE boot (this does not necessarily needs to be the first one with a active link).
Within the kickstart config itself you need to define the network interfaces using the network statement. If you are using method 2 or 3 then you don't know which device actually will be used. If you don't specify a device for the network statement anaconda will configure the device used for the kickstart process and set it up according to your network statement.
Forcing kickstart to ask for network configuration
Starting at CentOS 5, there a undocumented option that enable a prompt asking for network configuration during the installation. At the network statement, put the query keyword at the --bootproto= networking configuration, as we see below:
network --device=eth0 --bootproto=query
And a dialog box will appear asking for IP addressing, as well the hostname configuration.
Useful collection of ready-made kickstart files
At https://github.com/CentOS/Community-Kickstarts you can find a collection of ready-made kickstart files. Their primary goal is to provide functional sample kickstarts and snippets for the various types of deployments used in the community.