Ubuntu
udev package

Duplicate UUIDs after Edgy update

Bug #64909 reported by David Planella on 2006-10-09

Affects		Status	Importance	Assigned to	Milestone
	udev (Ubuntu)	Fix Released	High	Scott James Remnant (Canonical)	Ubuntu ubuntu-6.10

Bug Description

After updating to Edgy, I realised I was not booting onto the right partition, which lead to an unbootable system, until I noticed that /etc/fstab had the same UUID for 2 different partitions. The solution I've adopted so far is to remove the UUIDs and go back to the good ole /dev/hd* descriptions.

Just a little background: the partitions affected by this are /dev/hda5 (where I did the upgrade to Edgy) and /dev/hda9 (where I had a copy of my previous Dapper system). Before the upgrade, both partitions where identical, since /dev/hda9 was simply a copy of /dev/hda5 I made with gparted in case the upgrade went wrong. In this way I would still have my old Dapper.

Anyway, here's the /etc/fstab generated after the upgrade to Edgy (notice /dev/hda5 and /dev/hda9 have got the same UUIDs).

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/hda5 -- converted during upgrade to edgy
UUID=f0bfe866-2449-4d75-8222-b444ff564876 / ext3 defaults,errors=remount-ro,user_xattr 0 1
# /dev/hda9 -- converted during upgrade to edgy
UUID=f0bfe866-2449-4d75-8222-b444ff564876 /media/ubuntu/dapper ext3 defaults 0 0
# /dev/hda1 -- converted during upgrade to edgy
UUID=1E4F-1A0D /media/windows/C vfat shortname=winnt,codepage=850,umask=000,user,exec 0 0
# /dev/hda7 -- converted during upgrade to edgy
UUID=b7ffa27f-4c89-4b7f-82cc-e18afa7f6552 none swap sw 0 0
# /dev/hda8 -- converted during upgrade to edgy
UUID=4401-99ED /media/windows/Y vfat shortname=winnt,codepage=850,umask=000,user 0 0

# /dev/hdb1 -- converted during upgrade to edgy
UUID=1AF1-4021 /media/windows/D vfat shortname=winnt,codepage=850,umask=000,user 0 0

# /dev/hdc1 -- converted during upgrade to edgy
UUID=908ce3ae-1ac8-450e-b6b6-9dfdb71aef2c /media/debian/etch ext3 defaults 0 0
# /dev/hdc6 -- converted during upgrade to edgy
UUID=7b19bf37-516b-47c9-beea-108abf1582e3 /media/lfs ext3 defaults 0 0

/dev/hdd /media/cdrom0 udf,iso9660 user,noauto 0 0

Revision history for this message

Kevin Kubasik (kkubasik) wrote on 2006-10-10:

Assigning this bug to a package.

Please note, this is just my best guess at the package this bug should be assigned to, if it is incorrect, please feel free to correct, and if I am consistently assigning bugs incorrectly, please contact me through my launchpad page. I am just a member of BugSquad triaging as best I can!

Revision history for this message

David Planella (dpm) wrote on 2006-10-10:

menu.lst with unbootable UUIDs Edit (4.7 KiB, text/plain)

I just wanted to notice that I also had to remove the UUIDS from /boot/grub/menu.lst, otherwise the wrong partition is mounted as root.

I attached my menu.lst as reference.

The only bootable entry is the first one (title Ubuntu, kernel 2.6.17-10-generic), the next two, which I left unmodified with the original UUID, try to mount / onto the wrong partition (/dev/hda9), which leads to an unusable system.

Revision history for this message

Scott James Remnant (Canonical) (canonical-scott) wrote on 2006-10-11:

The update script should probably ignore UUIDs for which their are multiple resolutions

Changed in udev:
assignee:	nobody → keybuk
importance:	Undecided → High
status:	Unconfirmed → Confirmed

Revision history for this message

Scott James Remnant (Canonical) (canonical-scott) wrote on 2006-10-16:

Migration script fixed to abort on discovering a duplicate UUID

Changed in udev:
status:	Confirmed → Fix Released

Revision history for this message

David Planella (dpm) wrote on 2006-10-18:

Now that the fix has been released, the update process should not create duplicate UUIDs, but how can people already affected by this bug get rid of the duplicate UUIDs?

Is there a way to generate new UUIDs for each affected partition or should we remove all UUIDs from menu.lst and fstab and use e.g. /dev/hd* instead?

Revision history for this message

Scott James Remnant (Canonical) (canonical-scott) wrote on 2006-10-18:

Just edit /etc/fstab - the original device names are in the comment above the UUID

Revision history for this message

David Planella (dpm) wrote on 2006-10-18:

> Just edit /etc/fstab - the original device names are in the comment above the UUID

I had done this from the start (see the original post), otherwise I could have not booted up. Not only I had to edit /etc/fstab but also /boot/grub/menu.lst, otherwise the wrong kernel would be loaded.

So from what I understand, once the UUID generation goes wrong, there is no way to "regenerate" proper UUIDs and the only option is to forget the UUIDs altogether and use /dev/hdXY. Is that right?

Revision history for this message

Scott James Remnant (Canonical) (canonical-scott) wrote on 2006-10-19:

We don't generate UUIDs at all! That's a common misconception.

We just use the UUIDs already present in the filesystem, in cases where you have a clash, there's no way you can mount-by-UUID for that device, so yes, you have to fall back to /dev/hd*

(You could use LABEL=... but the chances are that if you've got a duplicate UUID, the LABEL is probably the same too)

This will break in feisty when the /dev/hd* names go away.

Revision history for this message

David Planella (dpm) wrote on 2006-10-19:

May thanks for the explanation, now I'm starting to get it.

Is there any particular package then to blame (and to file a bug against) for the UUID clashes?

Revision history for this message

Scott James Remnant (Canonical) (canonical-scott) wrote on 2006-10-19:

#10

It depends what's caused your clash.

If they are NTFS filesystems, then that's a bug in the NTFS filesystem ... not sure what Microsoft's bug tracker is for that. It appears that it only tries to avoid duplicate IDs in the same install, and doesn't use the UUID standard for it -- we need to investigate this more.

If it's caused by you making a duplicate of a disk (with dd), and leaving both disks in the system, then that's entirely your own fault :) You can alter the UUID for the other partition with:

tune2fs -U random /dev/hda9

The trouble with doing this ourselves is that we don't know there's no other O/S on the system also relying on UUID mounting.

Revision history for this message

David Planella (dpm) wrote on 2006-10-19:

#11

> If it's caused by you making a duplicate of a disk (with dd), and leaving both disks in the system, then that's entirely your own fault :)

Err... that sounds somehow familiar... I guess I'll have to fill a bug against myself ;).

Many thanks for your help.

Revision history for this message

Philippe Vanhaesendonck (philippe-vanhaesendonck) wrote on 2006-10-31:

#12

I ran into the same problem and I have to say it cost me a major headache.

So, right, it is entirely my fault since I had an old copy of my root partition somewhere else...
... but since there is a change in behavior between Dapper & Edgy, it would be nice to issue a warning when we have 2 partitions with the same UUIDs on the system.

Revision history for this message

David Planella (dpm) wrote on 2006-11-01:

#13

Philippe,

when did you do the upgrade?

As far as I understand from Scott's comment #4:

>Migration script fixed to abort on discovering a duplicate UUID

this should not happen anymore. So if I understood it correctly, you should not get a warning, but the migration script would detect that there are duplicate UUIDs and leave /etc/fstab untouched (i.e. leave the original /dev/hd* descriptors). Therefore you shouldn't run into problems.