I had reason recently to purchase a copy of Steve Gibson’s SpinRite utility to try to recover some data on a backup drive that went kaput. Since all of our workstations in the house are Macs, and I wanted to be able to let SpinRite perform its sometimes lengthy drive analysis without tying up any currently-running machines in the house, I decided to use a spare x86 server that had been sitting idle in our rack for some time. The machine itself was basically nothing more than the case, power supply, and motherboard (with on-board video and LAN). I didn’t have a spare CD drive at the time, and I didn’t really want to go buy one for this application, so I set out to run SpinRite the same way I install my server operating systems - via PXE. The one thing I did install in the system was a removable IDE drive tray, which allows me to easily install drives that I want to run through SpinRite (the “SpinCycle”? :)). I actually started calling this setup my SpinStation, since it turned out to be a very easy way to just pop a drive in and let it run. But I digress. It dawned on my while I was setting this up that organizations, including the ones Nearband Networks supports, may have good use for being able to boot SpinRite via the network. Imagine desktop support technicians responding to the call of a non-booting workstation due to a hard drive failure. Instead of having to carry a CD with SpinRite on it, they can simply set the machine to boot off the network, and let SpinRite run its course. Imagine the case of a server in amongst a rack of servers who’s hard drive has failed. Instead of having to remove that drive for testing, simply boot up SpinRite on the server from the network and let it do its magic. Finally, imagine performing maintenance (yes, as Steve Gibson is fond of pointing out, SpinRite is a drive maintenance tool just as much as it is a recovery tool) on a lab of machines. You could burn a CD for each system, run each system sequentially, or you could boot all of the systems from the network into SpinRite simultaneously and let them perform their maintenance overnight. These are some of the useful examples I was able to dream up while thinking about using SpinRite in this fashion. So, without further ado, on to how I set up SpinRite to boot via PXE.

PXE, or the Pre-boot eXecution Environment is an Intel standard on how to boot x86-based machines via the network. Many different system architectures through the years have had ways to boot from the network (Sun, Apple, etc). PXE is basically network booting for Intel-and-like-based machines. As I mentioned before, I use PXE to perform my server installs, usually Linux. If you’re familiar with the Windows way of doing things, then you may have used Remote Installation Services to install Windows over a network, a technology based on PXE. Most x86 systems built within the last 5+ years come with client-side PXE capabilities built in, especially if they have on-board ethernet, so chances are the systems you’re using now already support it.

Since my home network is Linux-server based, I already have the capability to boot via PXE. The basic requirements are DHCP and TFTP. I use the standard ISC DHCP server that is freely available and comes with most Linux distributions and the TFTP server that is included as well. In order to boot a PXE image off of the network, you’ll need to update your DHCP configuration to tell the client where your TFTP server is and what PXE image file to retrieve and boot from. Most DHCP servers are capable of sending clients the appropriate DHCP options to perform PXE booting with the appropriate configuration, but the specifics that follow will focus on the ISC DHCP server. For ISC DHCP to pass clients the necessary options, you’ll need to add two options to your configuration:

• next-server
• filename

The next-server option is followed by the IP address of your TFTP server, and the filename option is followed by the path to the file on the TFTP server. I use pxelinux to PXE boot my clients, and my TFTP server IP address is 172.16.24.1, so my lines look like this:

# For network OS installs
next-server 172.16.24.1;
filename "pxelinux.0";

Once you have DHCP set up to pass the appropriate bootstrap information, you need to configure pxelinux. Here’s where things get interesting. SpinRite comes with two image options: It can write out an ISO image or a floppy image for you. Normally, you’d use the images to create the necessary disks to run SpinRite from. With pxelinux, however, comes a very handy feature called memdisk, which allows you to boot a floppy image from the network, allowing you to take the floppy image written out by SpinRite, and use it directly with your PXE clients with no doctoring necessary. You’ll need to take the memdisk image and SpinRite images, and place them in the root of your TFTP directory alongside pxelinux.0. Next, edit the pxelinux.cfg/default file in your TFTP directory. If you have other network booting options, be sure to set prompt to 1 so that a prompt is displayed where you can type your booting option. You can also set up a boot message, which can display a menu of choices. Once you have that configured, add the following lines to the file:

label spinrite
kernel memdisk
append initrd=spinrite.img

When the spinrite option is invoked from the pxelinux boot command line, the client will retrieve the memdisk image and use it to then boot the spinrite.img file, which is the floppy image containing SpinRite’s FreeDOS and the SpinRite application.

That’s pretty much it. There may be some details left out, but most of those can be found from other PXE booting tutorials or the pxelinux documentation. If you’re feeling adventurous, you can even open up the SpinRite floppy image, using your image tool of choice, and make changes to the image, such as setting the auto option when invoking SpinRite from the autoexec.bat. This will basically make SpinRite a mostly hands-off operation (other than choosing to boot from the network and, optionally, choosing the spinrite boot option), as the machine will boot from the network and immediately begin checking all available drives in the system. Using this setup, I actually ended up testing every old and unused hard drive I had around the house, so that I could begin using them in my new Icy Dock external USB enclosure.

Finally, one last note. If you’re thinking about using this in a large organization, be sure that you pay attention to Steve’s modest site and enterprise licensing requirements.