I finally have enough time to write up the resolution to my difficulties with the 2.6.20-16 kernel upgrade:
First of all, there is a bug, or at least an inconsistency, in the way the kernel is handling SATA disks. (Warning: Blogger is about to dive into areas he knows almost nothing about. Please keep your various appendages inside the vehicle while he attempts this dangerous maneuver.)
Apparently, disks (or, at least, SATA disks) can be mounted using one of two drivers: piix (Pci Ide/Isa Accelerator), which treats the disks as IDE drives, and ata_piix, which treats them as SCSI drives. In the former case, drives are mapped to /dev/hda, /dev/hdb, /dev/hdc, etc. In the latter, the drives are mapped to /dev/sda, /dev/sdb, /dev/sdc, and so on.
In the Dapper release, my drives were mapped to /dev/hda and /dev/hdd, meaning that we were using piix. In the initial install of Feisty, however, the drives were mapped to /dev/sda and /dev/sdb. (Drives “d” and “b” are the same drive, IDE worries about which controller the drive is connected to, SCSI doesn't.)
It doesn't matter, so long as we're consistent. So long as we can construct a proper /etc/fstab file, all will be well.
My problem began with the aforementioned update. From what I learned reading bug report, sometimes the piix driver gets control of the disks, and sometimes the ata_piix driver does. The kernel should choose one or the other consistently, but different kernels choose different drivers — that's the bug. (I think.)
Now, as to what was happening to me. Let's look at my pre-20-16 /etc/fstab file:
# /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 # /dev/sda1 UUID=38afc33a-e732-45eb-8271-cd23555ce5bc / ext3 defaults,errors=remount-ro 0 1 /dev/sdb1 /home ext3 defaults 0 2 # /dev/sda6 UUID=efc49726-51d6-411e-9745-a05edad31c21 /opt ext3 defaults 0 2 # /dev/sda2 UUID=a955cf3a-b1bc-4998-92e1-0073aba94c4c /scratch ext3 defaults 0 2 # /dev/sda5 UUID=79a7a282-c5b8-416b-a738-89ed35013381 /usr/local ext3 defaults 0 2 # /dev/sda3 UUID=080af2c2-1bd6-4b4a-bceb-2e7c6c2a8fa2 none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0 /media/floppy0 auto rw,user,noauto 0 0
One of these lines is not like the others, one of these lines just doesn't belong. Spot it? It's the line that starts /dev/sdb1. There is no UUID for this drive, which just happens to be the partition holding all my data. Apparently (Danger! He's thinking again), the piix and ata_piix drivers can locate disk partitions by their Universal Unique IDs, and the initial Feisty install determined the UUIDs for all of the drives in my system, and entered them into /etc/fstab, helpfully putting up a # /dev/sda? comment for each drive, so we know how to refer to it in the traditional way.
Except that I didn't have my data disk hooked up when I installed Feisty — if something went wrong, I didn't want to accidentally erase all my files. I installed the drive later, and manually added the /dev/sdb1 line to /etc/fstab.
Which works fine, so long as the kernel keeps using the ata_piix driver! With the update to 20-16, the kernel started referring to my data drive as /dev/hdd1, which wasn't in the /etc/fstab file.
OK, I could just change /dev/sdb1 to /dev/hdd1 and all would work, but suppose the next kernel starts using ata_piix again? A more elegant solution is needed, and that is to refer to my data disk by its UUID.
$ ls -l /dev/disk/by-uuid/ total 0 lrwxrwxrwx 1 root root 10 2007-06-06 13:06 080af2c2-1bd6-4b4a-bceb-2e7c6c2a8fa2 -> ../../hda3 lrwxrwxrwx 1 root root 10 2007-06-06 13:06 38afc33a-e732-45eb-8271-cd23555ce5bc -> ../../hda1 lrwxrwxrwx 1 root root 10 2007-06-06 13:06 79a7a282-c5b8-416b-a738-89ed35013381 -> ../../hda5 lrwxrwxrwx 1 root root 10 2007-06-06 13:06 a955cf3a-b1bc-4998-92e1-0073aba94c4c -> ../../hda2 lrwxrwxrwx 1 root root 10 2007-06-06 13:06 bdad36ce-b67a-4c39-988e-94f40df90f67 -> ../../hdd1
Which tells me that /dev/hdd1 has the UUID bdad36ce-b67a-4c39-988e-94f40df90f67.
So now the resolution of the problem (for me, anyway) is simple. I just replace the offending line in my /etc/fstab file by
# /dev/sdb1 UUID=bdad36ce-b67a-4c39-988e-94f40df90f67 /home ext3 defaults 0 2
Problem solved. I can now use the new kernel, and, hopefully, will be immune from this type of problem.