Kickstart servers with multiple network interfaces

I attempted to kickstart a server this week with multiple network interfaces, and received an anaconda error stating that it couldn’t find the kickstart configuration file. After a bit of debugging, I noticed that the host kickstarted from one of the interfaces on PCI bus 2, but Anaconda was attempting to use the interface on PCI bus 0. This made sense, since I PXE booted from the one NIC that had link, but anaconda discovered and tried to use all of the installed interfaces. To get around this issue, you can modify the ksdevice= variable a couple of ways:

1. Add the MAC address of the NIC to kickstart from: ksdevice=DE:AD:BE:EF:CA:FE

2. Use the “link” keyword to tell kickstart to use the interface that has a link status of UP: ksdevice=link

3. Use the “bootif” keyword to tell kickstart to use the boot interface: ksdevice=bootif

Due to a bug, option number 3 didn’t work. Since only one of the three NICs connected to the server had link, I ended up using option #2 to install my servers. This worked pretty well, and with a bit of custom logic in my kickstart %post section, unattended installs are now working awesome!

Debugging kickstart issues

Kickstart is used by numerous organizations to automate Redhat, Fedora and CentOS installations, and has numerous options to control the provisioning process. One thing I really dig about kickstart is the logging that occurs to tty2, tty3 and tty4. This information is useful for debugging build issues, since the last messages usually indicate where a problem resides. But like most admins, I multitask and typically kick off installs and come back at a later time expecting to login and configure the new host. Periodically hosts will fail to build, but will be in a state where the debug messages are no longer available. To ensure that I can easily debug issues similar to this, I like to add the syslog and loglevel directives to the list of kickstart options:

kernel /centos53/vmlinuz ip=dhcp syslog=192.168.1.5 loglevel=debug ksdevice=eth0 \
load_ramdisk=1 prompt_ramdisk=0 ramdisk_size=32768 network \
ks=http://192.168.1.5/centos/kickstart.cfg

The syslog directives tells the anaconda installer to send its output to the specified syslog server IP, and the loglevel directive controls how much data is logged. Once both directives are enabled, you will get output similar to the following each time a host builds:

May 20 22:36:15 drfeelgood INFO     trying to mount sda1 on /
May 20 22:36:15 drfeelgood INFO     set SELinux context for mountpoint / to system_u:object_r:root_t:s0
May 20 22:36:17 drfeelgood INFO     trying to mount sys on /sys
May 20 22:36:17 drfeelgood INFO     set SELinux context for mountpoint /sys to None
May 20 22:36:17 drfeelgood INFO     trying to mount proc on /proc
May 20 22:36:17 drfeelgood INFO     set SELinux context for mountpoint /proc to None
May 20 22:36:17 drfeelgood INFO     moving (1) to step migratefilesystems
May 20 22:36:17 drfeelgood INFO     moving (1) to step setuptime
May 20 22:36:17 drfeelgood INFO     moving (1) to step preinstallconfig



To locate errors or warnings, you can run egrep passing the strings WARN and ERROR as input:

$ egrep "drfeelgood.*(WARN|ERROR)" /var/adm/messages
May 20 22:36:17 drfeelgood WARNING  no dev package, going to bind mount /dev
May 20 22:36:38 drfeelgood WARNING  Try 1/10 for http://192.168.1.5/centos/5.3/x86_64/os/CentOS/nspr-devel-4.7.3-2.el5.x86_64.rpm failed
May 20 22:38:47 drfeelgood WARNING  /usr/lib64/python2.4/site-packages/snack.py:250: DeprecationWarning: integer argument expected, got float\n  self.w = _snack.scale(width, total)



Kickstart is pretty sweet, and it is one of those technologies that makes our lives so much easier!