vol_id: detects crypto_LUKS instead of ext3 UUID

[jens_acamedia]

Binary package hint: e2fsprogs

on my updated feisty i do

root@bigboy:~# vol_id -u /dev/hda2
18942279-eaf5-4e86-a174-8b04b5d3127e
root@bigboy:~# findfs UUID=18942279-eaf5-4e86-a174-8b04b5d3127e
findfs: Unable to resolve 'UUID=18942279-eaf5-4e86-a174-8b04b5d3127e'
root@bigboy:~#

this seems strange to me. could this be connected with the reason why i cannot see hda2 as mounted when i do "mount" or "df"

i know hda2 is mounted since its my root fs and it is referenced by UUID in fstab. this is confusig me but perhaps im missing something...

[mc^2 (mkoren)]

very much the same on my machine.
"ls -l ... " gives correct output but findfs and df have a problem

[jens_acamedia (commercial-acamedia)]

the latest vol_id gives more verbose output...this is probably where the problem lies:

root@bigboy:~# vol_id /dev/sda2
ID_FS_USAGE=crypto
ID_FS_TYPE=crypto_LUKS
ID_FS_VERSION=
ID_FS_UUID=18942279-eaf5-4e86-a174-8b04b5d3127e
ID_FS_LABEL=
ID_FS_LABEL_SAFE=
root@bigboy:~#

it seems that luks has left some traces on this partition.

BUT

root@bigboy:~# dumpe2fs /dev/sda2 | head -n 5
dumpe2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name: root
Last mounted on: <not available>
Filesystem UUID: caa107c2-d2ba-11db-a205-0013cea46521
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
root@bigboy:~#

NB the UUIDs are different. how does that work? i dont really know what this means but i hope its useful to somebody...

[Daniel Hahler (blueyed)]

I can confirm this (see bug 110138), except that "dumpe2fs /dev/sda1 | head -n 5" displays the same/correct UUID in my case.

[Theodore Ts'o (tytso)]

What does the "blkid" command report?

[jens_acamedia (commercial-acamedia)]

i had to do a mkfs to the partition to fix the problem so i can no
longer help with this...

[Theodore Ts'o (tytso)]

This is very likely a duplicate of bug #110138. Can you tell me something about the partition? Was there originally an NTFS partition on it, by any chance (or some other filesystem located at that location)?

Also, when was the filesystem (with the problem) originally mke2fs'ed? There was bug in very old versions of mke2fs where it didn't zap the boot sector of the filesystem, which meant that an old NTFS filesystem signature could end up confusing the blkid/findfs programs. This would explain the symptoms that you reported.

[jens_acamedia (commercial-acamedia)]

theo,

this was a while back so i dont have the details. it def. wasnt an ntfs
partition though. it had been a luks partition before and i think that
was related...maybe it will happen again and we'll get more
information...or hopefully it wont!

[Theodore Ts'o (tytso)]

Ah, OK. So this looks like it was really a bug with vol_id where it was giving you the UUID for the old LUKS partition, so when you searched for the UUID of the old LUKS partition, findfs didn't find it because it correctly identified it as an ext3 partition.

I've received a patch to identify a crypto_LUKS into e2fsprogs, so I'm going to want to make sure we don't misidentify a previously old LUKS partition. I also want to make sure that mke2fs is zapping the location where the LUKS partition was located so we don't have this problem in the future.

[Theodore Ts'o (tytso)]

This specific issue has already been raised upstream, who has said it's not their problem. They don't consider trying to improve in-band type detection of fillesystems to be a priority. :-(

My recommendation is to move the LUKS detection farther down in the list of filesystem types in vol_id, but it's not clear upstream will be willing to do that.

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

Kay: your opinion on this bug?

[Kay Sievers (kaysievers)]

As pointed out several times, just reordering the probing without adding additional checks to the probers, just moves the problems from one user the other. We've been there several times, and stopped doing this.

If "/lib/udev/vol_id --probe-all <device>" returns more than one filesystem, the disk was formatted with a broken tool. Sane formatting applications wipe out all known signatures before applying a new filesystem. That's what we should fix, and possibly add more checks if the actual filesystem really exists and is still valid.

[Theodore Ts'o (tytso)]

Well, some formats allow for more complicated checks, and others don't. LUKS is really bad, in that it only uses 4 bytes at the beginning of the disk, and nothing else. And the formatter in question, NTFS, isn't under our control. So with blkid, I make a policy that probers that are more sophisticated should try first, and probers which are really stupid (and in the case of LUKS, the probe routine can only be stupid, because everything after the magic number is apparently random encrypted garbage :-).

I agree that in general, it's better to make the probing routines more sophisticated, and to fix the broken tool if we can. But short of telling the whole world not to use Windows NT (I am King Canute! I can command the tide from coming in! :-), we can't really do the latter, and in this case, the format prevents us from doing the former. So changing the order to hide the LUKS prober behind more sophisticated probing routines does make sense.

[Theodore Ts'o (tytso)]

Oops, I'm confusing this with another bug report where a NTFS partition was getting misidentified as LUKS.

In this case, I suspect what happen is the user got very unlucky. Mke2fs always zaps the first 8k, *except* on sparc platforms (where the default is to use an inline partition table) and if it detects a BSD boot label. So if the LUKS encrypted superblock has 4 bytes that match the two possible values of the BSD boot label, mke2fs will skip zero'ing the boot sector.

I could remove that check, but on platforms that are dual-booting with BSD, this could run into problems.

In any case, I still think that moving the LUKS check makes sense in this case, since there's no way to improve the probing function, given the LUKS format.