Thanks, I've applied the blkid LUKS patch to the e2fsprogs SCM (modulo a minor whitespace breakage which I fixed up). BTW, there appears to be a problem here in udev regarding LUKS identification: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/93921 The problem is that udev sets its magic string in the first 512 bytes of the partition. This is dangerous and error-prone, because other things like boot sectors and BSD disk labels tend to live in the first 512 byte sector. Hence, many programs are very careful before zapping the first 512 byte sector. LUKS was added to the vol_id program very high in the list of filesystems to be probed, ahead of ext2/ext3, so a filesystem previously contained a LUKS setup, but then was later mke2fs'ed to be used as a normal ext2/3 filesyste, may get misidentified by udev's vol_id as still being a LUKS filesystem if other fields in the first 512 byte sector cause mke2fs to mistakenly think there was a BSD disklabel in the sector and thus refuse to zero it out. This won't be a problem with blkid, since LUKS is placed *after* ext3/4. However, it would be a good idea to check and make sure that whever is setting up a LUKS partition clears the first and last 32k of a filesystem, to avoid potential confusion by other in-band filesystem type checkers. It would probably be a good idea to (after you make sure this is done) to submit a patch to the uev folks changing the probing order of vol_id so that it probes for the LUK filesystem after ext2/3. I am currently consider adding specific kludges to mke2fs that checks the first couple of bytes of the 512 byte sector for the problematic filesystem types (NTFS and LUKS), explicitly clearing just those bytes to avoid future confusion. But that won't help the existing filesystems that are out there.... - Ted - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
