8.04 upgrade re-arranged drive designations, broke my system

[bsmith1051]

Before the upgrade I had 3 hard-drives described as sda, sdb, and hda. Now, after the upgrade I have sda, sdb, and sdc. If this were merely cosmetic I wouldn't care but the upgrade failed to update my 'fstab' configuration file so my system failed to boot! It's taken me nearly an hour to figure-out what was wrong.

Isn't this kind of an obvious bug in the updater?

I suspect the problem is that my sda and sdb are setup as a RAID-1 mirror, md0, and that must've confused the updater. Still, there's no excuse for this. I'm about to try editing my fstab, and I suspect I'll also need to update (or maybe recreate) my 'md0' partition, too.

[Vivaldi Gloria]

Before the upgrade I had 3 hard-drives described as sda, sdb, and hda. Now, after the upgrade I have sda, sdb, and sdc. If this were merely cosmetic I wouldn't care but the upgrade failed to update my 'fstab' configuration file so my system failed to boot! It's taken me nearly an hour to figure-out what was wrong.

Isn't this kind of an obvious bug in the updater?

I suspect the problem is that my sda and sdb are setup as a RAID-1 mirror, md0, and that must've confused the updater. Still, there's no excuse for this. I'm about to try editing my fstab, and I suspect I'll also need to update (or maybe recreate) my 'md0' partition, too.

I agree with you. There is no justification for an update that brakes a working system. It sucks.

Unfortunately, it happens once in a while. Last year an ubuntu update broke my cups. A couple of years ago a windows update broke my net connection.

I suggest that you report a bug. Also backup fstab and remember howto fix your update error incase it happens again.

[logos34]

Before the upgrade I had 3 hard-drives described as sda, sdb, and hda. Now, after the upgrade I have sda, sdb, and sdc. If this were merely cosmetic I wouldn't care but the upgrade failed to update my 'fstab' configuration file so my system failed to boot!

Ubuntu swtiched to the libata scsi storage driver some time back, though it's actual implementation on individual machines seems to vary. (It didn't change my ide's to 'sda', etc. until Hardy, apparently due to the existing ata driver being recognized and used at boot before the libata one).

More here:
https://blueprints.launchpad.net/ubuntu/+spec/libata-for-all-ata-disks

If you were using UUIDs in fstab it shouldn't have affected mount. (although for all I know you're upgrading from dapper LTS)

[twolaw]

thankyouthankyouthankyou!!!!

I just upgraded from Gutsy to Hardy, and I've been scouring the 'net for the last two hours to try to find out why my partitions wouldn't mount anymore under Hardy. This totally fixed it.

I thought I was going insane... but why would Ubuntu suddenly flip my /dev/hda1 to /dev/sda1 (a FAT32 partition that contains some data), fstab is still just fine with my root linux partition /dev/hda4 and not /dev/sda4?!

[logos34]

but why would Ubuntu suddenly flip my /dev/hda1 to /dev/sda1 (a FAT32 partition that contains some data), fstab is still just fine with my root linux partition /dev/hda4 and not /dev/sda4?!

One scenario for what you describe would be where you manually added the fat32 line, without the uuid:

e.g.:


# /dev/hda4
UUID=184481b8-116c-40f3-b4d7-f1e5aef53547 / ext3 errors=remount-ro 0 1

/dev/hda1 /dev/hda1 vfat user,auto,fmask=0111,dmask=0000 0 0

Notice the # mark in the default entry--it's not scanning that line, but the next one with uuid. The drive may have switched to 'sda4', but it's being identified by the uuid.

But in the case of the next entry the system IS looking for '/dev/hda1', but can't mount it because it's now 'sda1.'