Next Saturday, March 22, a mere 11 days from now, the Intel Pentium processor will turn a grand 15 years of age. The Pentium marked a pretty dramatic increase in x86-based processor optimization capabilities, namely the introduction of multiple instruction pipelines. The optimization gains were so much so, that many software packages don’t usually enable CPU code optimization beyond the standard 386-level 32 bit code until you get to the Pentium/i586 architecture.

The age of the Pentium CPU was quite astonishing for me to realize. I remember our family purchasing our first Intel-based PC in 1993 with a 486 CPU. At the time, the Pentium was brand new. Those who were involved in the computer industry during this transition to brave new CPU-worlds will remember that the original Pentium chips, running at a blazing 60 and 66 MHz, had numerous heat issues. The 486 and earlier CPUs of the time did not have the heat dissipation issues that the Pentium chips had, so the older CPUs could usually get by with merely a heat sink attached to the chip. The Pentium was the first real introduction to computer enthusiasts of the requirement for not only a heat sink for the CPU, but a fan for active cooling of that heat sink as well.

Continuing in our early-to-mid-nineties throwbacks, the Pentium Pro will turn 13 in November of this year, reaching CPU adolescence. The Pentium Pro itself may not have seen wide adoption among computer enthusiasts, who instead opted to upgrade to the more consumer-friendly Pentium IIs, but the Pentium Pro left us quite a legacy of its own. The Pentium Pro ushered in the i686 instruction set, the prevailing 32 bit x86 instruction set to this day. The x86 instruction set would not see another serious upgrade until the release of the first x86_64 instruction set-based CPU, the AMD Opteron, in 2003. It would be approximately a year later before the first Intel CPUs sporting the new 64 bit architecture began shipping. It’s still amazing to me that the i686 instruction set, still the most widely used instruction set for x86 machines, is almost 13 years old. Around the time that Pentium Pro arrived on the scene, RISC architecture was becoming more and more prevalent, and the industry buzz was that RISC would become the architecture of choice, even for desktop CPUs. With the increasing optimization of the x86 architecture, including the inclusion of several RISC principles in the CPU, the i686 instruction set has lived on, and pure RISC has all but become a thing of the past, relegated to niche sectors of the computing world. Of course, the most recent, and high profile, casualty of this is the switch Apple, Inc. made during the 2006 year from its previous PowerPC based machines to its current Intel-based machines.

The first real usage of a brand for CPUs by Intel, the Pentium name is still with us to this day. With the introduction of the newer Core branding from Intel, the Pentium name has taken its place as the new moniker for lower-end processors from the silicon giant. Still, its been a great 15 years. Here’s lookin’ at you, kid.

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.