Pixie Chronicles: Part 2 Bootable Linux

By Henry Grebler

The Story So Far

In Part 1, I said that my project was to build a server. However I glossed over many details. In this part, I propose to examine those details more closely. I also raised a problem, which I left hanging. I'll get back to it a bit later.

By the end of this set of articles, you should have enough information to perform your own PXE network install.

Now Read On ...

Gathering Information

Before I install anything, I like to get some idea of what is on the machine. Does it have enough memory? How big is the hard drive? Will Linux recognise all the hardware? For this task, nothing could be better than a Linux which can run off a CD. I have a couple of versions of Knoppix, a couple of versions of Ubuntu and a Fedora which fit this bill quite nicely. I'm sure there are others.

My preference is for Knoppix. It has one nice capability that does not seem to be available on Ubuntu: once the machine has booted from the CD, it is a simple task to configure networking and then start sshd (the SSH daemon). I can then return to my desktop, ssh into the target machine and do everything from the comfort of "home". "Home" has my favourite keyboard, mouse and screen. When the target machine is rolled out, I will probably choose to run it headless, keyboardless and mouseless. However while it is being built, I connect the smallest, oldest screen, keyboard and mouse I have lying around They work, but they are not comfortable.

I had been given a machine with a single NIC. I inserted a second, a spare which I'd bought at a swap meet and which was lying around waiting to be useful.

For the network install, I would need the MAC address (aka Ethernet address) of at least one NIC, preferably both. This is exactly the sort of information that one can easily get if one first boots a standalone system from CD.

There are other uses for bootable Linux (or Live Linux CD). Some friends and I have developed a very powerful mechanism for cleaning viruses from Windows machines. When a machine is infected so badly that the viruses take control before Windows, a bootable Linux CD and a USB drive can save the day.

Investigation

And now for the use which is the point of this part. Part 1 ended with the discovery that I had installed Fedora 10, the target machine had then rebooted and restarted the install. It had stopped waiting for clarification about partitioning.

Ok, so what state was my target machine in?

I booted off the Knoppix CD to look around. What was on the hard drive? Hmm, nothing. That's a bit disappointing. What about all the software that I had seen it install? Actually, it was less nothing than that. The partitioning information had disappeared!

I remembered something that had been in the kickstart file. Or thought I remembered. I decided to check.

Here is a huge advantage of using kickstart as opposed to interactive install. If there is doubt about what responses were given at install time, with an interactive install one can only rely on one's memory. And in some cases, only on someone else's memory. I have oodles of proof that my memory is fallible; and also that many people have merely human memory. Even if one is assiduous, as I often am, and one writes down one's responses, that only makes the situation better; it's still not perfect. But the kickstart file can always be examined to confirm or disprove a suspicion.

I looked at the kickstart file. There was an interesting line:

	clearpart --all --initlabel

Clearly, I hadn't been paying enough attention when I was constructing the kickstart file. (I'll have more to say about this at another time.) The line requests that all disks have their partition tables removed and their labels reinitialised.

All?!

[Uneasy feeling.] Surely not ALL?! Surely only real hard drives.

It's Worse Than I Thought

To make my life more comfortable, when I boot off the Knoppix CD, I usually insert my USB stick as well. Apart from the antivirus stuff, the USB stick has my environment - my aliases, functions and scripts. These are my equivalent of a tradesman's tools of trade. With a couple of commands, I can recreate my personal environment. It also helps to shield me from the variations between different Unix and Linux systems: I have created a sort of HAL - Henry Abstraction Layer.

I examined my USB stick. All gone! The install had cleared its partition table. On reflection, that probably occurred on the first cycle through the install process, and was repeated on the second. A subtle but hardly comforting distinction.

In addition to losing the install, I had lost all the information on my USB stick!

If you've been paying attention, you might have guessed that all is not lost. In Part 1 I said, "... it's important to be able to recover from mistakes."

Fortunately I am a wizard of not inconsiderable power and I was able to recreate the partition table on the USB stick.

Analysis

I was also able to restore the install on the hard drive. But that's not where I want to go right now. I want to pick up on the last point of Part 1.

I implied that just changing the kickstart file to not reboot at the end of the install was short-sighted. Here's why.

Making that change certainly stops problems at the end of the install. But what happens if I turn off the machine for whatever reason and then turn it back on again? You might say that if I behaved like that I would be foolish and would deserve what I got. True. But, what if I turned off the machine and someone else turned it on? I need a robust solution.

Ideally, there ought to be a way to perform the PXE boot just once. I'm not aware of such a mechanism on my hardware. When one configures a boot sequence in a BIOS, one usually sets CD before hard drive. If a bootable CD is in the drive, the machine boots from CD. If not, it boots from hard drive. And it's true that if there is no network, the machine will give up on a PXE boot and try the CD and hard drive. But that doesn't help me. I need the network there for the network install. I would then have to remember to remove the network before the next reboot. I have not solved the problem.

For my purposes, it would be nice if the PXE boot mechanism required that the user press a key while the machine was booting. So, when I first turned on the machine, I would hold the key down and the PXE boot would take over. Once the PXE sequence had started, I would stop pressing the key. Now if the machine reboots at the end of the install, or it is switched on in the usual way, the PXE boot is bypassed.

Dream on. I needed to look elsewhere. I talked to a colleague, Ian, who pointed me in the right direction.

During the PXE boot, the machine downloads the installation environment and a PXELINUX config file (which is very similar to a GRUB config file). The PXELINUX config file can be set to simply proceed; alternatively it can be set to offer the user a number of choices for how to boot.

After some judicious editing, my PXELINUX config file now achieves a very serviceable compromise. When invoked it presents a boot: prompt. If the user types b2 (the name of this machine) within 10 seconds, the kickstart install process is invoked. There are some other nice options but I'll defer discussing those.

If the user presses Enter or 10 seconds elapse with no user input, the machine boots from local hard disk. Now it doesn't matter how the machine is turned on: the default condition is to boot from local hard drive. I have to be at the keyboard to start the kickstart process, but I'm there anyway to turn on the machine. I have to wait for perhaps a minute for the PXE boot to finish and the boot: prompt to appear. I then enter b2 to start the kickstart install - and then I can leave. The rest of the install will be automatic. If I've requested a reboot at the end of the install, the machine will perform the PXE boot from the network and after 10 seconds boot off the hard drive. All boxes ticked.

Eventually, when I'm satisfied that the machine is set up how I want it, I can get into the BIOS and turn off the PXE boot.

Lessons

Amongst its many advantages, a kickstart file provides an audit trail and reproducibility. It also allows for convenient change management.

One can always keep track of changes using documentation, but it requires more discipline and is more error-prone.

Look for robust solutions.

Consider many scenarios, not just the one which presented the problem.

Reference

For more on Knoppix see this article: Knoppix gives bootable, one-disk Linux

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.