hda -> sda transition not handled during upgrade

[Hilario J. Montoliu (hjmf)]

Binary package hint: linux-source-2.6.20

Just upgraded to new kernel in feisty (linux-image-2.6.20-12-generic_2.6.20-12.19_i386.deb) and boot process hangs when trying to mount my reiserfs partitions.

Here is the error output:
...
Log of fsck -C -R -A -a
Mon Mar 19 11:30:34 2007

fsck 1.40-WIP (14-Nov-2006)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
/dev/mapper/sda5: 396 files, 8820243/9002901 clusters
Failed to open the device '/dev/hda6': No such file or directory

Failed to open the device '/dev/hda7': No such file or directory

Failed to open the device '/dev/hda8': No such file or directory

Failed to open the device '/dev/hda9': No such file or directory

fsck died with exit status 8
...

From my /etc/fstab file:

...
~$ egrep "hda6|hda7|hda8|hda9" /etc/fstab
/dev/hda6 /home2 reiserfs defaults 0 2
/dev/hda7 /usr/local reiserfs defaults 0 2
/dev/hda8 /chroot reiserfs defaults 0 2
/dev/hda9 /home/hjmf reiserfs defaults 0 2
...

I'll attach the full fstab file

[Paul Sladen (sladen)]

Hello Hilario; could you provide some information about which kernel or version of Ubuntu you have upgraded from?

IDE disks now appear under the SCSI layer (just as USB and Firewire disks do aswell); as such the hard-disk is now accessed as '/dev/sdX' instead of '/dev/hdY'.

During an upgrade, one of the methods that is used to ensuring smooth transfer from the old method of referring disks, to the new method is by referring to the disk using a unique UUID identifier.

The upgrade process should have taken care of converting these; have you done a normal upgrade, or just installed the 'linux-image' package?

Entries within a new '/etc/fstab' will probably look something like:

UUID=b1d95d5f-8bd6-3e7a-af2e-a8f3624ccfaf / ext3 defaults,errors=remount-ro 0 1

[Hilario J. Montoliu (hjmf) (hmontoliu)]

El mar, 20-03-2007 a las 00:54 +0000, Paul Sladen escribió:
> Hello Hilario; could you provide some information about which kernel or
> version of Ubuntu you have upgraded from?

I was upgrading from 2.6.20-11-generic which was the one that got
installed on Thu Mar 15 08:03:07 when I did a dist-upgrade from edgy to
feisty. On that upgrade I didn't notice any error related to the kernel.

> IDE disks now appear under the SCSI layer (just as USB and Firewire
> disks do aswell); as such the hard-disk is now accessed as '/dev/sdX'
> instead of '/dev/hdY'.
>
> During an upgrade, one of the methods that is used to ensuring smooth
> transfer from the old method of referring disks, to the new method is by
> referring to the disk using a unique UUID identifier.
>
> The upgrade process should have taken care of converting these; have
> you done a normal upgrade, or just installed the 'linux-image' package?

Was a normal upgrade ussing the command:
apt-get update && apt-get -y dist-upgrade

> Entries within a new '/etc/fstab' will probably look something like:
>
> UUID=b1d95d5f-8bd6-3e7a-af2e-a8f3624ccfaf / ext3 defaults,errors
> =remount-ro 0 1

That UUID stuff doesn't appear in the reiserfs partitions and in the
chroot mounts; but *does* appear in the rest of my fstab entries (you
can check it in the fstab file I submitted yesterday as attachment).

Thank you for your feedback

[Dirk Schramm (no-comment)]

Time for a friendly "me too". Just tried to access a NTFS-Partition (yeah, well...erm, it's useful :D) just to notice it's "gone" (yeah, i fixed the fstab entry manually and, whoops, there it was), so no big problem, still the update-process should just handle this somehow.

fstab:

# /etc/fstab: static file system information.
#
# -- This file has been automaticly generated by ntfs-config --
#
# <file system> <mount point> <type> <options> <dump> <pass>

proc /proc proc defaults 0 0
# Entry for /dev/sda3 :
UUID=514cea97-b751-4950-b02f-d88cf6f94ca7 / ext3 defaults,errors=remount-ro 0 1
# Entry for /dev/sda6 :
UUID=6e5a7a50-3db3-4e75-89ae-64db627cad9c none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/hda5 /media/windows ntfs-3g defaults,locale=de_DE.UTF-8 0 0

[Dirk Schramm (no-comment)]

forgot to notice that i upgraded from 2.6.20-11-generic to 2.6.20-12-generic, too.

[Miguel Gaspar (ghaspias)]

I had a similar problem, my swap partition wouldn't mount, resulting in an barely usable system. I had to manually edit fstab, and now my swap partiton is used twice:
xxx@xxx:~$ swapon -s
Filename Type Size Used Priority
/dev/sda6 partition 433684 92932 -1
/dev/mapper/sda6 partition 433684 0 -2

Also, smartmontools couldn't be configured and smartd stopped working.

[Michael Vogt (mvo)]

Unduplicated, from #79327, this bug is only about cdrom entries in the sources.list.

[Erdal Ronahi (erdalronahi)]

I can confirm this. I upgraded yesterday and now I have troubles because fstab has still the "hdc1, hdc2" etc disks. No transition has been made. My fstab after the upgrade:

proc /proc proc defaults 0 0
/dev/hdc2 / ext3 defaults,errors=remount-ro 0 1
/dev/hdc1 /media/hdc1 ntfs umask=222 0 0
/dev/hdc5 none swap sw 0 0
/dev/hda /media/cdrom0 udf,iso9660 user,noauto 0 0
/dev/cdrom /media/cdrom1 udf,iso9660 user,noauto 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

[glenstewart (glen-stewart)]

Isn't this bug report similar to https://bugs.launchpad.net/ubuntu/+source/grub/+bug/8497 ?

[Hilario J. Montoliu (hjmf) (hmontoliu)]

Hello, and thanks to you for following this issue; sadly, I have to say that this behavior is still present.

As far as from today in the last kernel update (linux-image-2.6.20-16-generic) I had, when re-boot hanged, to manually change fstab as:
/dev/hda6 /home2 reiserfs defaults 0 2 -> /dev/sda6 /home2 reiserfs defaults 0 2
/dev/hda7 /usr/local reiserfs defaults 0 2 -> /dev/sda7 /usr/local reiserfs defaults 0 2
/dev/hda8 /chroot reiserfs defaults 0 2 -> /dev/sda8 /chroot reiserfs defaults 0 2
/dev/hda9 /home/hjmf reiserfs defaults 0 2 -> /dev/sda9 /home/hjmf reiserfs defaults 0 2

This is been a constant on every upgrade of the kernel since I first reported this issue. Notice how curious is that I had to change from sda# to hda# and from sda# to hda# alternatively on each kernel upgrade, e.g.

* in linux-image-2.6.20-15-generic update, I had to change: /dev/sda# -> /dev/hda# (YES, the inverse operation I did today)
* in linux-image-2.6.20-14-generic update, I had to do as I did today: /dev/hda# -> /dev/sda#
* ... happens always since 2.6.20-12 kernel.

This affects only my reiserfs partitions (the fstab file is the same I attached in my first post). The reiserfs partitions incidentally were present before I migrated to ubuntu one year ago (are partitions created some years ago and that have survived several distros w/o problems). This issue also happens in the computer of a familiar of me since he upgraded to feisty (as me he has old reiserfs partitions).

Though it is not a big problem for me as I know how to fix it every time it happens (it just take few seconds to edit fstab and mount -a), it can be a huge problem for people not used to deal with system files (as happens with that familiar -- I had to go to his home every time there's a kernel upgrade ;-) -- )

Feedback would be greatly appreciated.

[Hilario J. Montoliu (hjmf) (hmontoliu)]

Just in case this might help:

root@paleo:/home/hjmf# for id in 6 7 8 9; do /sbin/vol_id -u /dev/sda${id}; echo $?; done
4
4
4
4
root@paleo:/home/hjmf# for id in 6 7 8 9; do echo -n "sda${id}: "; udevinfo --name=sda${id} --query=symlink; done
sda6: disk/by-id/scsi-1ATA_WDC_WD2500JB-00EVA0_WD-WMAEH1589653-part6 disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part6
sda7: disk/by-id/scsi-1ATA_WDC_WD2500JB-00EVA0_WD-WMAEH1589653-part7 disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part7
sda8: disk/by-id/scsi-1ATA_WDC_WD2500JB-00EVA0_WD-WMAEH1589653-part8 disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part8
sda9: disk/by-id/scsi-1ATA_WDC_WD2500JB-00EVA0_WD-WMAEH1589653-part9 disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0-part9

I haven't found what /sbin/vol_id "return code" 4 means

[Scott James Remnant (Canonical) (canonical-scott)]

We handled the transition during an earlier upgrade cycle, and have always written UUID= form since then. If you don't have UUIDs in your fstab, it's likely that you removed them yourself. We preserve this for you, since it's your choice.

Gutsy's volumeid (113-0ubuntu15) package contains the migration script separately, you can run /usr/lib/udev/migrate-fstab-to-uuid.sh at any time.

[Hilario J. Montoliu (hjmf) (hmontoliu)]

El mié, 03-10-2007 a las 14:36 +0000, Scott James Remnant escribió:
> We handled the transition during an earlier upgrade cycle, and have
> always written UUID= form since then. If you don't have UUIDs in your
> fstab, it's likely that you removed them yourself. We preserve this for
> you, since it's your choice.

hmm, AFAIK I didn't touch the fstab. The only particular thing about
those partitions was that they were quite old and were inherited from my
previous system (mandrake) when I migrated the desktop computer to
ubuntu Dapper Drake. The problem arose only when I upgraded from Edgy to
Feisty.

The fact was that the other partitions do have UUIDs as you can see in
the fstab I posted in my first post. i.e.:
...
# /dev/hda11 -- converted during upgrade to edgy
UUID=f65fc6e0-f00f-46ef-8cfb-c60ca09cdd37 / ext3 defaults,errors=remount-ro 0 1
...

So it seems that during the upgrade from dapper to edgy only the ext3
partitions were converted.

>
> Gutsy's volumeid (113-0ubuntu15) package contains the migration script
> separately, you can run /usr/lib/udev/migrate-fstab-to-uuid.sh at any
> time.

OK, cool! I'll run the migration script when I'll upgrade to Gutsy.

Thank you for your interest :)

[Recon69 (m-carpenter)]

well, I did a upgrade from 6.06 to 8.04 yesterday and my fstab was not updated with the new sh* or uuid locations of my drives. and since one of those drives was my home directory took quite a while to unravel what the problem was as i only had command line. Find it a bit strange that this does not warrant a fix. cause a lot of 6.06 users going to get a upgrade prompt when 8.04 is released and their hard drives are going to disappear. other than that the upgrade went very well.