Our field engineers need a way to update industrial compact-PCI machines that have no floppy and no CD/DVD, and while the BIOS supports PXE, it won’t boot from a USB drive. (Yes, the boxes are *that* old.) After I get all my kickstart kinks ironed out, I plan to create a VM out of my kickstart server and have our field engineers run that on their laptops.

Thanks again - very much! - for gathering all the disparate bits together in one easy-to-read place!

Your understanding does seem correct. We found the terminology quite confusing also in the various documents we found and had hoped that we were able to fix that; apparently we were not completely successful in that.

I played with kickstart briefly under Redhat and see that it is an option still under Ubuntu.
I have done similar to you with pxe-netbooting. However I am using a separate bootp server instead of dhcp to assign the ip address and provide the pxe config adn menu files. (Details are recorded as the first section of this page.).

My main comment on your article:

In the section “Kickstart Sequence of Events” After “The PXE Boot file is loaded from the TFTP server…”, the rest of the section and the next section are confusing to me: I have done similar and still cannot follow you. The pxelinux boot kernel, and the ‘installer’ linux kernel are confused.

The former presents the ‘PXE Boot configuration file’, later referred to as ‘our master file’, and then within it as ‘RHEL5 Kickstart configuration file.’ I believe its best name is the ‘PXE Boot configuration file’, and 3 different terms are confusing.

The latter (the installer kernel and initrd chosen from the menu of the PXE Boot) actually runs the Anaconda installer does it not? So keep the terms clearly and consistently named.

As I understand it:

1. You boot a pxe program via netboot and its pxe extension facility.
2. Pxe uses tftp to get the ‘PXE Boot configuration file’ and its associated menu files and present them to you.
3. You choose an item based on a PXE menu file, and its boots whatever is in the associated relevant stanza of the ‘PXE Boot configuration file’. This is normally a linux kernel and its relevant initrd, which runs in this case Anaconda, the linux installer. The stanza in this case also includes a parameter to Anaconda which is the kickstart file Anaconda will use to automate itself, and thus automate an install.

Hmm… every time I write this stuff its gets written more clearly and concisely (I hope).

Other comments:

I also used ftp for a while, but dropped it and just stick with http now. I see no need for ftp at all anymore here. After installation I use mc too, and access remote hosts via its ssh mechanism (’Shell link…’), so even nfs is dropping away for me too.

tftp is limited in its functionality. It seems that it will not access files across symbolic links that traverse mount points. It jails you somewhat, and this is possibly a deliberately-inbuilt security consideration. Like you I found information on some of these aspects difficult or impossible to find. Its a problem in the open-source world: good stuff badly presented or badly worded, or effectively hidden by omission to document at all.

Overall I found the article very good, and got a few good tips. (pxelinux.cfg/C0A80037 is based on the ip address (not the MAC address): good to know)

ps Ubuntu has an alternative to kickstart. It is similar in concept, supposedly more powerful, but its very unfriendly to generate its response file (eg there is no GUI) or make sense of what it produces during an installation run (comparable file to your /root/anaconda-ks.cfg).

The information in this article is very useful. After reading this article, now i am able to implement installation using kickstart.


## Base hard drive partitioning with LVM
part /boot --fstype ext3 --size=128 --asprimary
part swap --fstype swap --size=4096 --asprimary
part pv.1 --size=1 --grow --asprimary

### LVM setup
volgroup vg01 --pesize=16384 pv.1
logvol / --fstype ext3 --vgname=vg01 --size=2048 --name=root
logvol /usr --fstype ext3 --vgname=vg01 --size=8192 --name=usr
logvol /opt --fstype ext3 --vgname=vg01 --size=4096 --name=opt
logvol /var --fstype ext3 --vgname=vg01 --size=4096 --name=var
logvol /tmp --fstype "ext3" --vgname=vg01 --size=4096 --name=tmp
logvol /home --fstype "ext3" --vgname=vg01 --size=1 --grow --name=home