And Then They Fix the Kernel

Bug, feature, whatever, the latest kernel upgrade, delivered tonight, uses the ata_piix driver, and all my disks once again pretend they are SCSI.

Of course, now that I switched all the entries in /etc/fstab to use UUIDs, so it doesn't matter.

I hope.

Fixing My Bug

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.

And how to I do that you ask? Well, I sure didn't know, so I looked around the Ubuntu Forums and general Googling®. There, I discovered the command

$ 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.

Hopefully.

Things I Don't Know About SATA

Sometimes, I astound myself with my technological dweebishness. I mean, here I am, knowing more about computers than 95% of the people on the planet,^† and I still get confused about things.

I think I know what happened to me yesterday. The “bug” probably doesn't affect every user of Ubuntu, only those who added extra disks and labeled them as /dev/sdb in /etc/fstab.

It might even be a feature, not a bug.

Unfortunately, I don't have time to track it down now. When I do, I'll write it up for posterity. I just wanted to post add a post here so that those who actually have a clue won't think I've completely lost my geek status.

^†That's not particularly arrogant. I also know more physics than 99.9% of the people on the planet. That would be arrogant, but I've got all sorts of pieces of paper to prove it.

The Ubuntu SATA Bug

If you recently did the Ubuntu Feisty Fawn maintenance upgrade of the kernel from 2.6.20-15 to 2.6.20-16, your system probably doesn't work: in previous versions of the kernel, all your SATA disk drives were considered to be SCSI drives, and so the partitions were mapped to /dev/sda1, /dev/sdb2, etc. 20-16 breaks this, considers the disks to be IDE drives, and tries to map them to /dev/hda1, /dev/hdb17, and so on.

Fortunately, there's a quick, if temporary, fix: when you boot up your computer, hit the ESC key as soon as you see the message about “grub”. Then use the arrow keys to select the 2.6.20-15-generic kernel. Proceed with boot and all will be well.

You can edit the /boot/grub/menu.1st file to make the 20-15 kernel the default. I'd advise that if you have non-geeks using the computer.

Presumably a fix will be along in a few days, version 20-17 of the kernel. When this is installed you may have to edit your menu.1st file to make the new kernel the default.

Sigh. Things like this happened occasionally with Fedora as well. I hope there aren't too many newbies scared away because they think Ubuntu broke their computers.