As far as IT work goes, this was one of the simplest tasks you can face: install an OS. Yet it took nearly all day due to a series of unfortunate turns. It was the kind of day that makes you question your sanity.
The task was extremely low profile. In order to support legacy SPARC-based code, an older Sun T2000 needed a fresh install of Solaris 10. This server would likely do next to nothing. It might service a log-in or two each month, as developers may want to check older code or test this and that. Otherwise, it's nowhere near a critical system. Still, it would serve a purpose, and despite its age, it would easily handle the minor load. I figured it might take 15 minutes of actual effort to kick off a clean install from DVD and voilà -- I could move on to more important duties. I mean, I've installed Solaris a million times. How long could it take? Little did I know.
[ Revealed! Paul Venezia shares the secrets behind IT magic tricks. | Also on InfoWorld: Teach your router new tricks with DD-WRT. | Get expert networking how-to advice from InfoWorld's Networking Deep Dive PDF special report and Technology: Networking newsletter. ]
For those not familiar with this vintage of SPARC systems, the T2000 does have an ALOM (Advanced Lights Out Manager). This ALOM may have been advanced several years ago, but it's quite rudimentary compared to modern units. Essentially it allows for server power control, device component and sensor readings, and a text console. There are no facilities for virtual media or anything fancy. Also, there's no frame buffer on these systems. Everything is done via serial console or a telnet log-in to the network management processor.
That's not a problem because there's a DVD-ROM drive, so off we go. I kill the default boot sequence and boot from the DVD. Eventually the Solaris 10 installer pops up, and I enter the requisite configuration information, ho hum. The installer heads off to start the actual package install -- then promptly kicks out to an emergency shell, displaying a variety of errors. This is followed by 30 minutes of digging around, looking for why the package install failed to start. Next up comes another attempt, but this time paying slightly more attention. Nope, it bails out again.
After much more digging through various document searches and the system itself, I determine that due to a bug in the kernel used by the installer (and possibly a problem with the firmware on this particular DVD-ROM model), the installer cannot mount the DVD's file system to access the packages, though it is able to boot from the DVD. It's not exactly a common problem, but there we are. Time to punt on the DVD install -- I'll just JumpStart it.
There are no other Solaris systems handy, so I'd have to do this with a Linux server. I didn't really need a full JumpStart configuration server; I just needed the system to be able to boot the installer from the network and access the packages via NFS -- easy peasy. I install rarpd and bootparamd on an available Linux server, toss the MAC address into /etc/ethers, add a hostname and IP to /etc/hosts, toss the appropriate inetboot file into /tftpboot, and configure a bare-bones bootparam entry for the box. After that, I mount the DVD ISO across a loop and export that via NFS.
Aside from the ISO export, this is how most Solaris JumpStart scenarios work. If I had a Solaris box to work with, most of the process would be more or less automated. But hey, this was quick enough even when done manually.