April 27, 2011, 10:10 p.m.
posted by jack
Testing your kickstart boot media is fairly simple. Pop in the bootdisk.img floppy or boot.iso CD, verify that the machine BIOS is set to boot off that media, that your networking hardware is all connected, and that you're on a DHCP LAN (if you're doing nonstatic IP network loads), and power up.
Remember, if you're using the bootdisk.img and the network, you're going to have the driver disk in hand.
If you're using a stock bootdisk.img-based floppy, before you get any drivers loaded up you will still need to tell the program from where to get its ks.cfg file. In this example, we manually point it to the web share that we've created when it gives up the boot prompt:
You will then have to manually feed it the drvnet driver floppy so it can see the network and go to the ks.cfg file that you pointed it to.
If you're running a custom build (automated) floppy and configured your boot floppy correctly, it should default to the proper URL for the ks.cfg (even though you may not see it), load the syslinux boot environment, and then prompt you for your driver disk(s). At this time you'll need to start feeding it floppies for whatever hardware you need access to during the install (usually just the drvnet disk).
Regardless of the type of floppy install you're going with (manual or automatic), you will need to insert the pcmcia.img disk (if you have a PCMCIA-based network card) and/or your drvnet.img disk for network drivers. Also, if you are installing any block device or mass storage devices such as SCSI drives or RAID controllers or the like, you'll also want the dvrblock.img floppy handy.
After these drivers are all loaded and if you're running a customized/automated bootdisk.img floppy, the Anaconda installer should take off and start following your kickstart config file and scripts. No more intervention should be required.
If the automation aspect of the installer stops somewhere and it starts prompting you for questions that are supposed to be automated (such as the keyboard, mouse, partition layout, and so on), this indicates that there is a problem in your kickstart config file. It's probably a typo, or maybe you left something commented out that shouldn't be (the clearpart or part lines are common mistakes). Go back and check your install script line by line.
CD installs are a bit nicer if you ask me. If you've set up your own custom boot.iso CD with the preconfigured ks.cfg network pointers, then this is really a fire-and-forget operation. Just be sure not to walk away and forget about it if you have configured the kickstart to reboot when it's done. Doing so would put the machine into a perpetual install-reboot-install-reboot loop that will most likely get you a visit from your NOC (network operation center) wanting to know who's been DoSing the network and eating up the network bandwidth all day. This type of event usually lands one a colorful nickname with your cohorts as well.
If you are using a stock boot.iso-based CD image, you will still have to give only one piece of information at the initial boot: prompt:
boot: linux ks=http://example.com/installs/ks-server.cfg ksdevice=eth0
You are now armed with all the information that you need to kickstart your own desktop, workstation, server, or customized systems automatically and from any network enabled PC.