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) ** Attachment added: "test-luks-blkid.sh" http://launchpadlibrarian.net/34094423/test-luks-blkid.sh -- luks encrypted partition not detected https://bugs.launchpad.net/bugs/428435 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
