...making Linux just a little more fun!

Pixie Chronicles: Part 4 Kickstart

By Henry Grebler

Keywords: NFS

The Story So Far

In Part 1 I outlined my plans: to build a server using network install. However, I got sidetracked by problems. In Part 2 I made some progress and dealt with one of the problems. In Part 3 I detailed the first part of the network install -- from start to PXE boot. This part details the rest of the procedure.

If you've been following me so far, you have a target machine which uses the PXE process to boot into the PXE boot Linux kernel. Importantly, you've tried it out and confirmed that this much of the exercise behaves as desired.

The PXE boot process comes to the point where you see the prompt:


We have not yet set up enough to proceed to the next stage, for which I used NFS.


First decide on an install method. My exercise was with Fedora 10. The possible install media are:

	CD or DVD drive
	Hard Drive
	Other Device (presumably USB)
	HTTP Server
	FTP Server
	NFS Server

Only the last 3 are network installs, which is all we are interested in here. I chose NFS Server.

Further, I happened to have a machine which was PXE-capable. So my plan was to turn on the machine and (as near as possible) have it install all the software without my intervention.

If your machine is not PXE-capable in hardware, it may still be possible to perform an unassisted install - but you will need to create a CD or DVD to achieve the PXE part. It might be possible to create a PXE floppy.

You will of course need a server to serve PXE data and other info over the network. I chose my desktop as the PXE server.


	PXE client (see previous article)
	PXE server (see previous article)
	NFS (see below)


Since the network method I chose was NFS, I had to set up NFS. I judged that it would be easier to set up NFS than to set up HTTP; I was probably a wee bit foolish not going for FTP -- at the time I had security reservations, but I think for an internal private network like mine, there is no difference in security between FTP and NFS.

Arguably TFTP would have been even better because it was already in place having been needed at an earlier step. But it was not available as an option.

	mkdir -p /Big/FedoraCore10/NFSroot
	ln -s /Big/FedoraCore10/NFSroot /NFS

Create /etc/exports:

#       exports

/NFS          ,no_subtree_check,root_squash)

All I've done here is allow any machine on my local subnet to access NFS on the server (my desktop -- where I'm typing this).

	NB exports do not "inherit". If you export "/NFS" that won't
	allow clients to mount "/NFS/CD_images".

	mkdir /var/lib/nfs/v4recovery
	/etc/rc.d/init.d/nfs start
	exportfs -a
	exportfs -v

I had all sorts of problems with NFS. I found it useful to test locally using:

	mkdir /mnt/nfs
	mount /mnt/nfs

And if you want to snoop network traffic, you'll need:

	tshark -w /tmp/nfs.tshark -i lo

This should behave in a way akin to what the client PC will see when it tries to NFS-mount directories from the server.

The layout of the NFS directory:

	ls -lA /NFS
lrwxrwxrwx 1 root staff 25 Nov 26 22:12 /NFS -> /Big/FedoraCore10/NFSroot

	ls -lA /NFS/.
total 44
drwxrwxr-x 3 root   staff  4096 Nov 28 17:59 CD_images
lrwxrwxrwx 1 root   staff    13 Nov 27 10:31 b2 -> ks.b2.cfg.sck
-rw-rw-r-- 1 henryg henryg 3407 Dec  7 18:28 ks.b2.cfg.sck

The NFS directory also contains many other files left over from numerous false starts. (Hey, I'm human.)

	ls -lA /NFS/CD_images
total 3713468
-rw-rw-r-- 2 henryg henryg 720508928 Nov 26 07:43 Fedora-10-i386-disc1.iso
-rw-rw-r-- 2 henryg henryg 706545664 Nov 26 08:03 Fedora-10-i386-disc2.iso
-rw-rw-r-- 2 henryg henryg 708554752 Nov 26 08:38 Fedora-10-i386-disc3.iso
-rw-rw-r-- 2 henryg henryg 724043776 Nov 26 09:17 Fedora-10-i386-disc4.iso
-rw-rw-r-- 2 henryg henryg 720308224 Nov 26 09:18 Fedora-10-i386-disc5.iso
-rw-rw-r-- 2 henryg henryg  83990528 Nov 26 10:15 Fedora-10-i386-disc6.iso
-rw-rw-r-- 2 henryg henryg 134868992 Nov 26 10:17 Fedora-10-i386-netinst.iso

It is not necessary to mount the CD images; it seems that anaconda (the program which performs the actual install) knows how to do that. Sharp-eyed readers will have spotted that the iso images are hard-linked in the /NFS/CD_images directory. That's because I first downloaded the images to /Big/downloads thinking I would need to mount them; later when I was setting up the NFS directory I finally discovered that I needed the images as not-mounted files. Rather than copy the files and waste a heap of disk space, or move the files and risk making something else fail, I chose to hard-link them and get "two for the price of one".

The kickstart file

I used system-config-kickstart to generate a first kickstart file. I edited it to get more of the things I wanted and then decided to try it out. After several go-arounds I got to the point which got me into trouble (as described in Part 1).

Here is the final kickstart file:

#	ks.b2.cfg.sck - created by HMG from system-config-kickstart for b2

## - - debugging - - - - - - - - - -
## :: uncomment the following to debug a Kickstart config file
## interactive

#platform=x86, AMD64, or Intel EM64T
# System authorization information
auth  --useshadow  --enablemd5 
# System bootloader configuration
bootloader --location=mbr

# I guess the "sda" will prevent trashing my USB stick

clearpart --all --initlabel --drives=sda

part /boot --asprimary --ondisk=sda --fstype ext3 --size=200
part swap  --asprimary --ondisk=sda --fstype swap --size=512
part /     --asprimary --ondisk=sda --fstype ext3 --size=1   --bytes-per-inode=4096 --grow

# Use graphical install
# Firewall configuration
firewall --enabled --http --ssh --smtp  
# Run the Setup Agent on first boot
firstboot --disable
# System keyboard
keyboard us
# System language
lang en_AU
# Use NFS installation media
nfs --server= --dir=/NFS/CD_images
# Network information
network --bootproto=static --device=eth0 --gateway= --ip= --nameserver= --netmask= --onboot=on
network --bootproto=static --device=eth1 --gateway= --ip= --nameserver=, --netmask= --onboot=on --hostname b2
# Reboot after installation

#Root password
rootpw --iscrypted $1$D.xoGzjz$kMojNQR7KFddumcLlQPEs0
# SELinux configuration
selinux --enforcing
# System timezone
timezone --isUtc Australia/Melbourne
# Install OS instead of upgrade
# X Window System configuration information
xconfig --defaultdesktop=GNOME --depth=8 --resolution=640x480
# Clear the Master Boot Record



Putting it all together

That's it. Here's a walk-through of what happens for an install.

	User connects network cable to target machine and powers up.

	PXE gains control and asks network for an IP address and other
	information server has for this machine (at this stage
	identified by MAC address).

	Server sends the requested info.

	PXE configures the NIC with the received IP address.

	PXE uses tftp to download a Linux kernel.

	The linux kernel announces itself with the prompt "boot: ".

User enters b2. User is no longer needed.

	Still using tftp, the target machine downloads another Linux
	kernel. In accordance with the label b2, it then uses NFS to
	download the kickstart file.

	The kickstart file specifies that the install should also use
	NFS. The installer uses the parameters of the kickstart file
	to govern the installation.

	When the install is complete, the target machine (now a shiny
	new server) reboots.

	PXE gains control as before and the steps above are followed.
	However, at the "boot: " prompt, either the user simply
	presses Enter, or, more likely, because the user is not there,
	the boot loader times out. Either way, the default label lhd
	is taken: the target machine boots off the recently installed
	hard drive.

	Some time later, the user reboots and disables the PXE boot
	which is no longer needed.



open source toolbox

Tuesday, January 31, 2006
Review: automated network install of suse, debian and fedora with LinuxCOE

Linux NFS Overview, FAQ and HOWTO Documents




Talkback: Discuss this article with The Answer Gang


Henry has spent his days working with computers, mostly for computer manufacturers or software developers. His early computer experience includes relics such as punch cards, paper tape and mag tape. It is his darkest secret that he has been paid to do the sorts of things he would have paid money to be allowed to do. Just don't tell any of his employers.

He has used Linux as his personal home desktop since the family got its first PC in 1996. Back then, when the family shared the one PC, it was a dual-boot Windows/Slackware setup. Now that each member has his/her own computer, Henry somehow survives in a purely Linux world.

He lives in a suburb of Melbourne, Australia.

Copyright © 2010, Henry Grebler. Released under the Open Publication License unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 176 of Linux Gazette, July 2010