UUID: wrong values in Ubuntu /etc/fstab files
 

Here is a nuissance, a solution and some unanswered questions

The problem
Each device, say a partition /dev/hdaN, has a UUID label which might be retrieved as the name of the associated file in /dev/disk/bu-uuid directory. On the other hand, Ubuntu&Kubuntu identify the same device /dev/hdaN, by its UUID label, inside the /etc/fstab file. Now, assuming the abnormal situation when the two UUID strings differ, the boot process of Ubuntu&Kubuntu will hang when checking the file system: where 'XXXX...' is the associated UUID value in /etc/fstab.
The solution
Just edit /etc/fstab to correct the UUID value 'XXXX...' from there; one might retrieve the right value from the directory /dev/disk/by-uuid or by running the command sudo vol_id -u /dev/hdaN. That's all.
Do such errors occur in Ubuntu&Kubuntu?
Yes they do. In my computer, such accidents produce whenever another Linux system installs after Kubuntu, even in case the new installation process does not modify either the partition table or the file systems inside.
Who is responsive?
It might be either Kubuntu or the "intruder" (i.e. the new Linux distribution) but I can not say who. The complete answer could be obtained by comparing the same Ubuntu/Kubuntu information, at three different moments. The information would consist of:
A. The content of /etc/fstab file;
B. The content of /dev/disk/by-uuid directory.

The three moments I have in mind would be the following:
1. Just before installing/reinstalling another Linux system, after Ubuntu/Kubuntu;
2. Immediately after the new installation process but before any rebooting of Ubuntu/Kubuntu. Such a 'forensic' reading may be obtained by running a live distribution such as Knoppix;
3. Immediately after the first reboot of Ubuntu/Kubuntu.

This way one could say at which moment /etc/fstab and /dev/disk/by-uuid begin to disagree and who is responsive for that. If somebody knows the answer I think it would be great to post it here.
Thanks!
P.S. By installation, my Linux distributions do share the same swap partition but nothing else (I never tell the installers to use partitions which belong to other distributions).

I don't really understand what you're doing but you can find UUID numbers in /dev/.udev/db. Open the file ending in the partition name you're interested in.

The reason you'll get a new UUID assigned to a partition after another install is that it's generated when a partition is formatted. E.G: in the case of a shared swap partition, the new install formats the swap partition and generates a new UUID. In that case you'll need to edit the fstab of the old install to reflect the new UUID.

Hi I seem to be having related problem but the UUIDs seem to correspond and yet fsck still exits with error 8.

fsck error:
Output of running ls -l /dev/disk/by-uuid
Contents of fstab
Any ideas? Plus I've not installed any other versions of Linux in the meantime.

Cheers
Amos:scratch:

Try using udevinfo to obtain the UUID number to use:
I'll use "UUID=" for fstab entries of removable devices.

example:

When running fsck manually you need to either give the actual device name, or give the /dev/disk/by-uuid/(UUID) location.

jschiwal: Do you mean take the value returned after the ID_FS UUID = bit and paste it into fstab?
This gives me the same value.

binary_y2k2:
In the fsck man page it says

Plus I'm experiencing this problem at boot, I merely included the manual fsck to show the output at boot time.

Cheers
Amos

Yes, I do. That should be the correct file system UUID. It should also be identical to what is used by udev to construct the by-uuid devices on the fly. If they are off, then you might try restarting the dbus, udev, and hal daemons. The /etc/fstab entry is static, and if you have changed the filesystem, it may be wrong, so update the /etc/fstab file to match the other dynamic values. About the length, different file systems have uuid numbers of different lengths. A pendrive will have a short one, while an xfs partition will be longer.

Here is a the UUID number of a usb drive with the xfs filesystem:
b545812a-57af-43e8-bbd8-f9b43dd25fc8
Here is the UUID number for a fat32 SanDisk pendrive:
3B69-1AFD

If the fstab entry is wrong, it is probably due to reformatting the partition, in which case, you probably are using it for something else and need to edit the fstab entry anyway.

Also, if the UUID number changes, since this is what is being used to reference where to find the filesystem, you couldn't reliably automate a correction reliable because that would involve a guess. If you had installed one distro, but with several, looking for a /boot partition by performing trial mount of partitions and looking for certain files could come up with the wrong answer. A rescue disk could offer choices however. When I used Mandrake Linux, it would examine the devices and mount them under /mnt. The SuSE install program has a repair program that might repair a bad fstab entry as well. However, I don't think that anything that involves educated guesses should be performed automatically behind the users back. Because if the wrong guess is made, the user would really have a hard time understanding how or why the system changed after a reboot. Imagine dual booting and booting up Ubuntu to have the /home partition of Mandriva come up instead.

If the information from hal & udev doesn't match the number used in /dev/disk/by-uuid, then you may have a problem with your system. It is the udev rules that activate the creation of the /dev/disk/by-uuid symlinks.
On my SuSE laptop:
The udevinfo's ID_FS_UUID should match the number found in /dev/disk/by-uuid, because ID_FS_UUID is what is used to create the link with the "SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}" rule.