vol_id: detects vfat instead of ext3 UUID

[Allcolor-g]

Binary package hint: volumeid

My /dev/hda1 partitions can't be automatically mounted in fstab by UUID because vol_id returns wrong result.
What is strange is that blkid returns the correct result. I've also tried to change the UUID with tune2fs, blkid did see the changes but vol_id still gives the old wrong information, restart doesn't change anything. The problem is that udev creates the wrong symlink in /dev/disk/by-uuid/ using the wrong information from vol_id. If I manually creates the symlink with the correct UUID, I can mount the partition.

Here is the output of vol_id /dev/hda1 (wrong):
ID_FS_USAGE=filesystem
ID_FS_TYPE=vfat
ID_FS_VERSION=FAT16
ID_FS_UUID=1645-A1B7
ID_FS_LABEL=
ID_FS_LABEL_SAFE=

Here is the output of blkid /dev/hda1 (correct):
/dev/hda1: LABEL="/boot" UUID="ea8ce475-66f0-4e37-9dc2-4f595896725e" SEC_TYPE="ext2" TYPE="ext3"

Here is the content of my fstab:
UUID=a4657160-a783-43df-ab1a-b6366720a1a6 / ext3 defaults,errors=remount-ro 0 1
UUID=ea8ce475-66f0-4e37-9dc2-4f595896725e /boot ext3 defaults 0 2
UUID=51d2776a-6817-43c3-855f-c39bf92178a1 none swap sw 0 0

Please note that setting the UUID to the output of vol_id (1645-A1B7) does not work even the symlink is created.

But doing a 'ln -s ../../mapper/hda1 ea8ce475-66f0-4e37-9dc2-4f595896725e' in '/dev/disk/by-uuid' permits to do a 'mount /boot' and it works.

Unfortunatelly the symlink disappear at next reboot.

How is it possible to inform udev/vol_id of the correct parameters ?

[Allcolor-g (allcolor)]

I'm on Kubuntu Feisty, kernel 2.6.20-16-generic (but the problem dates back from edgy).

My installation is on an LVM partition which span on two disks (hda5 and hdb5).

[Allcolor-g (allcolor)]

Also when I installed kernel 2.6.20-13-generic my partitions were renamed as /dev/sdxx instead of /dev/hdxx but since 2.6.20-14-generic everything was put back as /dev/hdxx.

My motherboard is an asus A7N8X with nvidia NFORCE2 controller.

an 'fdisk -l' gives:

Disque /dev/hda: 122.9 Go, 122942324736 octets
255 têtes, 63 secteurs/piste, 14946 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets

Périphérique Amorce Début Fin Blocs Id Système
/dev/hda1 * 1 31 248976 83 Linux
/dev/hda2 32 14946 119804737+ 5 Extended
/dev/hda5 32 14946 119804706 8e Linux LVM

Disque /dev/hdb: 122.9 Go, 122942324736 octets
255 têtes, 63 secteurs/piste, 14946 cylindres
Unités = cylindres de 16065 * 512 = 8225280 octets

Périphérique Amorce Début Fin Blocs Id Système
/dev/hdb1 * 1 1305 10482381 7 HPFS/NTFS
/dev/hdb2 1306 14946 109571332+ 5 Extended
/dev/hdb5 1306 14946 109571301 8e Linux LVM

[Allcolor-g (allcolor)]

Has someone read this bug report ?

[flx (flx-proyectoanonimo)]

I have this very same problem, but in debian sid, with both custom 2.6.21 and 2.6.21-k7. Haven't tried with the generic one, but i'll bet the same will happen.
It seems like an udev bug.

--- here the wrong vol_id out ---
vol_id /dev/hda3
ID_FS_USAGE=raid
ID_FS_TYPE=LVM2_member
ID_FS_VERSION=LVM2 001
ID_FS_UUID=
ID_FS_LABEL=
ID_FS_LABEL_SAFE=
------

--- here the blkid correct one ---
blkid /dev/hda3
/dev/hda3: LABEL="/" UUID="ff42ae37-a7bd-41a5-88bc-d674634ddcdc" SEC_TYPE="ext2" TYPE="ext3
------

--- and some relevant parts of initramfs.debug (full file attached) ---
+ /lib/udev/vol_id -t /dev/hda3
+ FSTYPE=LVM2_member
+ RET=0
+ [ -z LVM2_member ]
+ echo LVM2_member
+ return 0
+
[...]
+ modprobe LVM2_member
+ mount -r -t LVM2_member /dev/hda3 /root
mount: Mounting /dev/hda3 on /root failed: No such device
[...]
+ /scripts/init-bottom/udev
mount: Mounting /root/dev on /dev/.static/dev failed: No such file or directory
[...]
-------

[Allcolor-g (allcolor)]

So doing the following (horrible *hack*), resolve my problem and automount correctly my boot partition with the uuid.

1: sudo -s
2: mv /sbin/vol_id /sbin/vol_id.old
3: vi /sbin/vol_id

put the following in the file:
#!/bin/sh
RESULT=`blkid $2`
LABEL=`echo "$RESULT" | cut -d " " -f 2 | cut -d = -f 2 | cut -d \" -f 2`
UUID=`echo "$RESULT" | cut -d " " -f 3 | cut -d = -f 2 | cut -d \" -f 2`
TYPE=`echo "$RESULT" | cut -d " " -f 5 | cut -d = -f 2 | cut -d \" -f 2`

echo "ID_FS_USAGE=filesystem"
echo "ID_FS_TYPE=$TYPE"
echo "ID_FS_VERSION=1.0"
echo "ID_FS_UUID=$UUID"
echo "ID_FS_LABEL=$LABEL"
echo "ID_FS_LABEL_SAFE=$LABEL"

4: chmod u+x /sbin/vol_id

Ensure that you refer to your partition with UUID in /etc/fstab

And that did work o_O ;) I don't know where else vol_id is used so it may breaks something (but at first sight here, nothing is broken and well... it works better now).

Until a patch is done that can help.

[Bill Metzenthen (billm-melbpc)]

I have been bitten by the same bug.

In my case the disk drive started life with the installation of Fedora (although the the computer supplier had used some version of Windows on the disk for testing, which was removed before the computer was supplied to me). I had no problems using the disk with Fedora for several years.

Kubuntu looked interesting, so I decided to try it by installing it on a second drive which I added to the computer.

Kubuntu installed and I have been using it (e.g. now) and working around the inevitable bugs and inconsistencies...

A particularly annoying bug is the fact that udev fails to see my original Fedora partition. This means that I can't use the LABEL or UUID methods for that partition in fstab (udev deletes the entries in /dev/disk and creates new ones each time it is restarted. "mount" appears to use these entries). Ubuntu uses the new-fangled "upstart" init scheme (which is annoying on two counts: how it works on Ubuntu doesn't appear to be well documented, and it seems to be mostly set up to emulate Sysv init anyway!). Having worked my way through this maze (init and udev), I found that script /etc/udev/rules.d/65-persistent-storage.rules appears to be one of the main culprits.

The udev script uses the "vol_id" program to fetch the information about the LABEL and UUID of each disk device. (remark: the man page for vol_id omits several of the options which vol_id accepts, including --help and --probe-all)
`vol_id --probe-all` reveals that it identifies two partition signatures on my old Fedora partition: a vfat one and an ext3 one. For some reason (I haven't yet been able to find an explanation in my googling) it is possible to have both at the same time. The vfat signature is, it appears, always in the first 512 bytes. The ext3 ones start at byte 1024. Thus is would appear that it is possible to have the two valid signatures at the same time by either of the following: format a partition as a vfat drive first and then format it as ext3, or (possibly) format it as vfat and then use it and then by chance have the Windows FAT contain a valid ext3 signature (I don't know whether this is possible but it almost certainly has a very low probability). A key question here is: why didn't the program I used to format the partition as ext3 write nulls over the first 512 bytes?

The solution for me was, as I found on the web, to do "dd if=/dev/zero of=/dev/XXX bs=512 count=1" and hope I didn't mistype it.

However, this took quite a lot of time to track down and I know from my web searching that the bug has troubled a number of people. It certainly didn't make Ubuntu look very "user friendly". I believe that the bug should be squashed (or beaten into submission) and that the importance should be above "low".

Some ways to make the process work better:
1. It would appear to be fairly easy to detect the multiple signatures ("vol_id --probe-all") before udev sets up the /dev/disk entries for a partition and then, if the relevant partition table entry id is not for an MS file system, to offer to wipe the first 512 bytes for the user (with appropriate warnings).
2. Do the same checks during the installation ...

[Sitsofe Wheeler (sitsofe)]

Punting from udev -> volumeid

[Sitsofe Wheeler (sitsofe)]

..which is build from udev. OK.

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

Kay: another vol_id bug for you to look at

[Kay Sievers (kaysievers)]

Same as: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/93921/comments/11

We need to fix the formatting applications to wipe out the first few hundred kilobytes, and the last few hundred kilobytes at the end of the device before applying any new format.

[Thomas R. (pumbaa80)]

> We need to fix the formatting applications to wipe out the first few hundred kilobytes, and the last few hundred kilobytes at the end of the device before applying any new format.

This does not really solve the issue, since other programs might modify the contents of the first sector.
On ubuntuusers.de, someone reported that the FS driver http://www.fs-driver.org/ must have done so; after installing it, the vol_id detection was broken.

http://forum.ubuntuusers.de/topic/177935

Bill Metzenthen's ideas (see above) appear to be good solutions for this.