-   Ubuntu (
-   -   UUID: wrong values in Ubuntu /etc/fstab files (

grautu 05-02-2007 05:39 AM

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:

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.
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 10: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 08: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 06: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:

** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to, **
** 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 **

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

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

# /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.


jschiwal 05-05-2007 07:42 AM

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


> udevinfo -q env -n /dev/sdc1

binary_y2k2 05-05-2007 09: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 02: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.


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


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.


jschiwal 05-05-2007 05: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:
Here is the UUID number for a fat32 SanDisk pendrive:

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:

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.

All times are GMT -5. The time now is 03:39 PM.