ROCKS Installer

This page is a description of how the ROCKS installer boots, how it requests the kickstart file for the node, how the server generates the kickstart file, etc.

Table goes top to bottom in time.

Node	Frontend
Power Up
Ethernet firmware starts NIC and broadcasts DHCPDISCOVER. The request will be tagged with some info including "client-architecture 00:00" (for x86)
	Replies with DHCPOFFER with IP, and additional info including "next-server" and "filename"
Makes DHCPREQUEST for IP	Registers lease and replies with DHCPACK
Now fetches via tftp filename from above at location next-server. For ROCKS, this file will be the pxelinux.0 image	tftpserver sends requested file
Switch to running downloaded image
pxelinux.0 starts through a list of config files to fetch from server, first is pxelinux.cfg/01-00-21-9b-92-1d-33 (use MAC address), then starts with full IP expressed in HEX pxelinux.cfg/0A0A0287, if no file found yet, starts dropping digits from filename. E.g. 0A0A02F 0A0A02 etc. If none of these were found, tries to get file named "default".	send first file found
This file will be a boot script similar to a grub.conf file, except the images will be fetched via tftp. Can include kernel command line options
Fetch kernel and initrd (if specified) via tftp	send requested files
Down Ethernet in preparation for kernel control (not sure exactly when this step happens?)
load initrd and kernel with kernel options specified, note that these options get passed to init as well

How the ROCKS installer goes after the above.

Node	Frontend
Start init (/bin/init is default)
Loads drivers, including Ethernet ones (Ethernet will have been down)
Runs pump dhcp client, this involves a couple quick cycles of Ethernet ports --- this is confused by spanning tree delays on switches...
PXE boot on Eth0, repeats DHCP requests as done above by firmware, however the "client-architecture" is not sent in request	Replies with IP, next-server and filename. These are the IP for frontend and "/install/sbin/kickstart.cgi" --- see /etc/dhcpd.conf on ROCKS frontend.
Starts network using settings received
ROCKS has modified anaconda so that it always does an http request to get the kickstart file. Server to go to is DHCP "next-server" and URL is constructed using DHCP "filename" (strange but true). ROCKS doesn't simply use the ks= option (it wouldn't be possible to specify cgi options in normal syntax).	Replies to http request, this involves generation of kickstart file. "rocks list host xml"
Saves kickstart file, and restarts anaconda with it
Starts mini_httpd with special behavior for requests received from 127.0.0.1. These are forwarded via rocks-bt.py to the frontend. (location of frontend is "next-server"). The rocks-bt.py script changes these requests from whatever to whatever.torrent --- so torrent seeds are fetched instead of actual files. The mini_httpd can respond to requests from peer nodes that are also in the process of installing. Clever.	Sends files as requested
Runs through install
Near end of install, accesses URL ??? to change boot state	Changes boot type of node

-- TomRockwell - 06 Feb 2009