UUID: wrong values in Ubuntu /etc/fstab files

grautu · 05-02-2007, 04:39 AM

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:

Code:

Unable to resolve 'UUID=XXXX...'
fsck died with exit status 8

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

Patrick K · 05-02-2007, 09:36 AM

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.

binary_y2k2 · 05-03-2007, 07:54 AM

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.

amos · 05-05-2007, 05:37 AM

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

fsck error:

Code:

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible --  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will read-only check consistency of the filesystem on UUID=23f148cb-bdfb-4d1f-ae09-abf593709556
Will put log info to 'stdout'

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Failed to open the device 'UUID=23f148cb-bdfb-4d1f-ae09-abf593709556': No such file or directory

Output of running ls -l /dev/disk/by-uuid

Code:

lrwxrwxrwx 1 root root 17 2007-05-05 11:06 23f148cb-bdfb-4d1f-ae09-abf593709556 -> ../../mapper/sdb6
lrwxrwxrwx 1 root root 17 2007-05-05 11:06 62257cce-21bc-4954-ac23-c970a48c3f58 -> ../../mapper/sdb1
lrwxrwxrwx 1 root root 17 2007-05-05 11:06 b02783aa-37ba-4513-9cfc-89b5ce1111b0 -> ../../mapper/sdb5
lrwxrwxrwx 1 root root 17 2007-05-05 11:06 B2881DB6881D79D5 -> ../../mapper/sda1
lrwxrwxrwx 1 root root 17 2007-05-05 11:06 b8d5cb77-d623-4271-a919-db72f161c627 -> ../../mapper/sda2

Contents of fstab

Code:

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/hdb1 -- converted during upgrade to edgy
UUID=62257cce-21bc-4954-ac23-c970a48c3f58 / reiserfs notail 0 1
# /dev/hda2 -- converted during upgrade to edgy
UUID=b8d5cb77-d623-4271-a919-db72f161c627 /home reiserfs defaults 0 2
# /dev/hda1 -- converted during upgrade to edgy
UUID=B2881DB6881D79D5 /media/hda1 ntfs defaults,nls=utf8,umask=007,gid=46 0 1
# /dev/hdb6 -- converted during upgrade to edgy
UUID=23f148cb-bdfb-4d1f-ae09-abf593709556 /usr reiserfs defaults 0 2
# /dev/hdb5 -- converted during upgrade to edgy
UUID=b02783aa-37ba-4513-9cfc-89b5ce1111b0 none swap sw 0 0
/dev/cdrom        /media/cdrom0   udf,iso9660 user,noauto     0       0

Any ideas? Plus I've not installed any other versions of Linux in the meantime.

Cheers
Amos

jschiwal · 05-05-2007, 06:42 AM

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

example:

Code:

> udevinfo -q env -n /dev/sdc1
ID_VENDOR=SanDisk
ID_MODEL=Cruzer_Mini
ID_REVISION=0.1
ID_SERIAL=SanDisk_Cruzer_Mini_SNDK41A4B41C47300502
ID_TYPE=disk
ID_BUS=usb
ID_PATH=pci-0000:00:02.2-usb-0:2:1.0-scsi-0:0:0:0
ID_FS_USAGE=filesystem
ID_FS_TYPE=vfat
ID_FS_VERSION=FAT16
ID_FS_UUID=3B69-1AFD
ID_FS_LABEL=
ID_FS_LABEL_SAFE=

binary_y2k2 · 05-05-2007, 08:41 AM

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

amos · 05-05-2007, 01:11 PM

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:

Quote:

Originally Posted by binary_y2k2

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

In the fsck man page it says

Quote:

If no filesystems are specified on the command line, and the -A option is not specified, fsck will default to checking filesystems in /etc/fstab serially. This is equivalent to the -As options.

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

Cheers
Amos

jschiwal · 05-05-2007, 04:28 PM

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:

Code:

grep 'disk/by-uuid' *
60-persistent-storage.rules:ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}"
64-device-mapper.rules:ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}"
hpamd64:/etc/udev/rules.d # ls /dev/disk/by-uuid/ -l
total 0
lrwxrwxrwx 1 root root 10 May  4 16:07 3B69-1AFD -> ../../sdb1
lrwxrwxrwx 1 root root 10 May  4 03:45 4B1135F8699960E7 -> ../../hda1
lrwxrwxrwx 1 root root 10 May  4 03:45 93f3e07d-9286-454a-928d-d341bae8960c -> ../../hda6
lrwxrwxrwx 1 root root 10 May  4 03:45 b545812a-57af-43e8-bbd8-f9b43dd25fc8 -> ../../sda1
lrwxrwxrwx 1 root root 10 May  4 03:45 c521eb35-c7f9-4976-a75a-a2bf36cc8e1a -> ../../hda5

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.