Pixie Chronicles: Part 4 Kickstart
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:
boot:
We have not yet set up enough to proceed to the next stage, for which I used NFS.
Planning
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.
Components
PXE client (see previous article) PXE server (see previous article) tftp dhcp pxelinux kickstart NFS (see below)
NFS
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 192.168.0.0/24(ro,no_subtree_check,root_squash) /NFS/CD_images 192.168.0.0/24(ro,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 192.168.0.3:/NFS /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 graphical # 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=192.168.0.3 --dir=/NFS/CD_images # Network information network --bootproto=static --device=eth0 --gateway=192.168.99.1 --ip=192.168.99.25 --nameserver=127.0.0.1 --netmask=255.255.255.0 --onboot=on network --bootproto=static --device=eth1 --gateway=192.168.25.1 --ip=192.168.25.25 --nameserver=198.142.0.51,203.2.75.132 --netmask=255.255.255.0 --onboot=on --hostname b2 # Reboot after installation reboot #Root password rootpw --iscrypted $1$D.xoGzjz$kMojNQR7KFddumcLlQPEs0 # SELinux configuration selinux --enforcing # System timezone timezone --isUtc Australia/Melbourne # Install OS instead of upgrade install # X Window System configuration information xconfig --defaultdesktop=GNOME --depth=8 --resolution=640x480 # Clear the Master Boot Record #zerombr %packages @development-tools @development-libs @base @base-x @gnome-desktop @web-server @dns-server @text-internet @mail-server @network-server @server-cfg @editors emacs gdm lynx -mutt -slrn %end
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.
References:
https://docs.fedoraproject.org/install-guide/f10/en_US/sn-automating-installation.html https://fedoranews.org/dowen/nfsinstall/ https://www.instalinux.com/howto.php https://ostoolbox.blogspot.com/2006/01/review-automated-network-install-of.html open source toolbox Tuesday, January 31, 2006 Review: automated network install of suse, debian and fedora with LinuxCOE https://nfs.sourceforge.net/ Linux NFS Overview, FAQ and HOWTO Documents https://docs.fedoraproject.org/mirror/en/sn-server-config.html https://docs.fedoraproject.org/mirror/en/sn-planning-and-setup.html https://nfs.sourceforge.net/
| Share |
|
Talkback: Discuss this article with The Answer Gang
![[BIO]](../gx/authors/grebler.jpg)
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.
