The Art of Tech

I've had that Duron processor for over 6 years, but the original motherboard died in April of 2004. That's why I built my dual Opteron workstation (in May, 2004). I let the Duron chip sit for about a year before I bought the new motherboard, which required me to get new RAM as the old one was too specific to the memory controller on the old, now dead, board. I decided the newly resurrected Duron system should be my file server and the old file server hardware now serves as a firewall/router. I was able to just move the 3 hard drives (and a couple of NICs) to the new system and everything came up just fine; no OS reinstall. Man, I love Linux.

Anyway, when I went to install the new SATA hard drive that I had picked up, I decided that I should rearrange the other drives so that when I pull the 120GB & 45GB drives from the box, that there will still be really good airflow around the new drive. As I shuffled the 4 hard drives around in the 6 drive hanging cage (this case has room for another 5 5-1/4 inch and 1 3.5 inch drives), I realized that I was just going to have to do it again, so I arranged things such that I should be able to get the most air over the 4 drives. I'll just move the new one when I pull the old drives out.

But when I hooked everything back up, the system (by which I mean the BIOS) could not see the new SATA controller. To make matters worse, it could no longer see the 4GB system drive either. At that point, however, I had to leave for a few business trips and didn't get around to working on the box again until this past weekend. It turns out that I merely had to reverse the IDE ribbon cable going to the 4GB drive and all is well, with it.

Then, when I booted the system up with the 4GB drive back in view, I got a kernel panic. Looks like the latest kernel which I have installed for RHEL4 (2.4.22-37.0.1) can't find the root partition at all. That was quickly fixed by editing /boot/grub/menu.lst in a rescue environment; it turned out that there was no value for the root= parameter on the kernel line. After rebooting I get a little different kernel panic. It seems there is misconfiguration in this kernel' initrd so that it can't do the pivot_root(8) properly (seems like the old_dir it's trying to use doesn't exist. So, I boot into the next previous (2.4.22-37) kernel, which also fails since it can't find anything in the /etc/fstab file.

OK, another trip into the rescue environment and, sure enough, there are zero bytes of content in the /etc/fstab file (/me shakes head). so, I reconstruct the basic lines needed to get the OS up and running, reboot again, and viola; I finally have a running system. I still had to add a few more lines to /etc/fstab before everything was ready for normal operation, but that only took about 3 minutes.

Still, the BIOS doesn't see the new SATA controller. Perhaps a BIOS update will get things going. I'm thinking that perhaps the BIOS just doesn't have the first clue what kind of card it is, so it doesn't initialize it into the PCI bus. To test this theory, I booted from a handy SUSE Linux 10.1 CD and checked some things out in the installer's partitioning tools and with the command line. No dice, there just is no /dev/sda device appearing at all.

All right, then, let's update the BIOS. Of course, it's a DOS program, so I decided to burn a CD as I don't even have a floppy drive installed on this box and didn't really want to dig one out. My first attempt at creating a bootable CD from a DOS floppy I have used for about a decade failed to boot. I did a little digging to find out what I needed to do to properly create a bootable CD with mkisofs. I came up with this command line:

mkisofs -r -b workdos95.img -c boot.cat -o SV266AD.iso SV266AD-BIOS/

The trick is that the workdos95.img file (created by running dd if=/dev/fd0 of=workdos95.img bs=512 with the working boot floppy in the drive) has to be placed in the SV266AD-BIOS (in my case, since that's what I named it on my hard drive while I was building the CD) directory. That isn't exactly clear from the mkisofs(8) man page.

Burning the resulting ISO9660 image to a blank CD-R produced a working, bootable DOS CD. The oakcdrom.sys DOS driver even works with my Pioneer slot loading DVD drive. I was able to change to the G:\ drive (the CD) and run the BIOS update utility. Sadly, rebooting showed that the newest BIOS still didn't bring up the PCI SATA controller. Nuts.

To satisfy those scratching their heads over the workdos95.img file, WorkDOS is a name I have used for utility boot disks that I have built. They are simply a DOS boot floppy with almost all of the main C:\DOS\ files, a couple of other tools and some CD-ROM & NIC drivers included on a 1.44MB floppy. They have been quite useful over the years, though I haven't used one in a long time.

The next test is to pull out the card and drive, plug them into my dual Opteron box (which has 4 SATA ports on board) and make sure the drive is good and see if the card is visible. I'm working on that now.

Perhaps I have a bad card. Maybe this BIOS will never be able to see it. Either way, the next iteration of my home file server will make use of a way cool SATA controller; the 3ware 9590SE-16ML. Oh, yeah :) !