Eventually having connected my amd64 desktop upto a decent internet connection, I decided to wipe the FC3 install on the box and replace it with ubuntu. I left my i686 gentoo install alive and started out on an Ubuntu 6.06 LTS (aka Dapper Drake) install, sometime around 11 PM.
My hardware setup is not what I would call conventional. Inside my monster tower I have four SATA ports - two of them on the motherboard and a couple more on my RAID controller. The first port is occupied by my 10k RPM 80gig drive which is basically my boot drive. The other onboard port has a 120 gig drive, which is my secure (AES256) storage and is hardly ever mounted. There are two 200 gig SATA drives connected to the RAID controller (Promise), which after a couple of abortive attempts with dmaraid, have ended up as discrete SATA disks instead of in RAID-0.
Now, as soon as the Dapper liveCD boots, the disks on the RAID subsystem show up as sda and sdb. The onboard SATA controller gets relegated to sdc and sdd. I thought it was strange, but I picked the renamed partitions and went through a complete install with this setup. The first reboot just froze the machine with a pretty GRUB on the left corner. Modifications of device.map, replacing the hd1 entries in the boot menu did nothing either. Whatever I tried, the machine just threw up a blank GRUB stage1.
As it turns out the BIOS and grub still recognize the onboard SATA channels as the first pair of hard disks, but half-way through stage2 of the boot the kernel takes a flip and then it all goes south for the summer. Faced with the renaming, I tried to connect the boot drive to the RAID controller, just to bring it back to sda. But as it turns out my BIOS can only boot off onboard primaries. Which all left me up shit creek without a paddle.
Now, dapper is not without its advantages. The live CD installer meant that I could do more than just watch the lines scroll while the installer did its magic (anyone remember the caldera tetris games ?). So I still had a functional internet browser even though my machine wasn't booting (grub ensured that I couldn't boot gentoo).
Thanks to the internet, I came to know that I wasn't alone (*play x-files music*). Turns out somebody had run into this Grub of Death before. Also there lay open a launchpad bug in the helpful status called CONFIRMED, which basically meant I had run into something real (like an iceberg). As luck would have it, someone had already sent a patch to work-around the problem in kernel land - and it had been rejected. All this was no help at all, till I discovered magic beyond mere device names.
UUID mounts: /etc/fstab could use other identifiers than raw device names to uniquely identify drives. And the first patch I discovered dates from 2001 - this must've been the *best kept secret* in linux kernel land. As it turns out, both grub and /etc/fstab will accept volume UUIDs, completely transparently. But still the installer couldn't figure out where to put grub or what to put in it. At around 3 AM, I managed to pry open my machine, pull out the off-board SATA and attempt a reinstall.
The system reinstall went almost perfectly. All that was left to do was to replace the device names in the relevant sections with the correct UUID volume names. The unique identifiers can be read easily using the blkid command. A couple of reboots later, I plugged the RAID controller back in and added those partitions similarly.
It all worked out, eventually. But the amount of effort it took to get it working reminded me of those nights in 1999, spent struggling with an X configuration, with some magazine's help section open.
--"First things first -- but not necessarily in that order."
-- Doctor Who