Comment 57 for bug 428435

As a first step, I created a script which exercises all combinations of luks with ext2/ext3/ext4/swap/vfat.

This runs fine on current karmic, which shows that all the mkfs.* are fixed now and we don't create further breakage with the karmic versions. The script needs to run as root, and uses /dev/ram0 for testing, so please make sure that you don't use this! (or change it in the script, it's a variable at the top). Expected output:

$ sudo ./test-luks-blkid.sh
*** test pair: luks/ext2 ***
ext2 luks ext2
*** test pair: luks/ext3 ***
ext3 luks ext3
*** test pair: luks/ext4 ***
ext4 luks ext4
*** test pair: luks/swap ***
swap luks swap
*** test pair: luks/vfat ***
vfat luks vfat

On Jaunty, this demonstrates that cryptsetup doesn't properly clean traces of ext:

$ ./test-luks-blkid.sh

*** test pair: luks/ext2 ***
ext2 luks
FAIL: Expected fs type: crypto_LUKS; blkid result
/dev/ram0: LABEL="MyExt2" UUID="a359cbd4-d406-4aa8-a0a2-807697a50710" TYPE="ext2"

Since most things in Jaunty use vol_id, I also added a vol_id mode to the script, which gets a little further due to the different preference order of vol_id. It still stumbles over luks-after-swap:

[jaunty] # ./test-luks-blkid.sh vol_id
*** test pair: luks/ext2 ***
ext2 luks ext2
*** test pair: luks/ext3 ***
ext3 luks ext3
*** test pair: luks/ext4 ***
ext4 luks ext4
*** test pair: luks/swap ***
swap luks unknown or non-unique volume type (--probe-all lists possibly conflicting types)
[jaunty] # vol_id --probe-all /dev/ram0
swap
crypto_LUKS

On hardy, blkid behaves exactly the same. vol_id did not yet prefer luks over swap at that time (and the script can't test ext4, sinced that wasn't available yet):

[hardy] # ./test-luks-blkid.sh vol_id
*** test pair: luks/ext2 ***
ext2 luks ext2
*** test pair: luks/ext3 ***
ext3 luks ext3
*** test pair: luks/swap ***
swap luks
FAIL: Expected fs type: crypto_LUKS; vol_id result
ID_FS_USAGE=other
ID_FS_TYPE=swap
ID_FS_VERSION=2
ID_FS_UUID=fa48b160-08fb-44a5-9db5-1be7440912e5
ID_FS_UUID_ENC=fa48b160-08fb-44a5-9db5-1be7440912e5
ID_FS_LABEL=
ID_FS_LABEL_ENC=
ID_FS_LABEL_SAFE=

[hardy] # vol_id --probe-all /dev/ram0
swap
crypto_LUKS

Another real-world test case is the ext3-luks.img which is attached here, which can be used to verify a proposed karmic fix for blkid:

$ BLKID_DEBUG=0xffff blkid -p /tmp/ext3-luks.img
[...]
ERROR: ambivalent result detected (2 filesystems)!
/tmp/ext3-luks.img: ambivalent result (probably more filesystems on the device)