Karel Zak schrieb:
On Sat, Aug 29, 2009 at 03:24:59PM +0200, Thomas Bächler wrote:We may have hit a bug in blkid. I have had reports from at least two people that blkid does not properly detect all their LUKS devices.Running "blkid /dev/sdXY" returns nothing for one LUKS device,Try BLKID_DEBUG=0xffff blkid /dev/sdXYor tryblkid -p blkid /dev/sdXY The important is also return value (echo $?). I guess the problem is that the device contains any other (old) filesystem. The old versions of mkswap and cryptsetup don't zap old superblocks on the device.
It seems your last assumption was right: --> starting probing loop [idx=-1] linux_raid_member: call probefunc() ddf_raid_member: call probefunc() isw_raid_member: call probefunc() lsi_mega_raid_member: call probefunc() via_raid_member: call probefunc() silicon_medley_raid_member: call probefunc() nvidia_raid_member: call probefunc() promise_fasttrack_raid_member: call probefunc() highpoint_raid_member: call probefunc() adaptec_raid_member: call probefunc() jmicron_raid_member: call probefunc() crypto_LUKS: magic sboff=0, kboff=0 crypto_LUKS: call probefunc() assigning UUID assigning TYPE <-- leaving probing loop (type=crypto_LUKS) [idx=15] --> starting probing loop [idx=15] ext4dev: magic sboff=56, kboff=1 ext4dev: call probefunc() ext4: magic sboff=56, kboff=1 ext4: call probefunc() ext3: magic sboff=56, kboff=1 ext3: call probefunc() ext2: magic sboff=56, kboff=1 ext2: call probefunc() ext2_sb.compat = 00000038:00000002:00000003 assigning UUID assigning TYPE <-- leaving probing loop (type=ext2) [idx=23] --> starting probing loop [idx=23] jbd: magic sboff=56, kboff=1 jbd: call probefunc() ufs: call probefunc() sysv: call probefunc() <-- leaving probing loop (failed) [idx=49] ERROR: ambivalent result detected (2 filesystems)!Now this is my situation: Udev switched from its home-grown vol_id to blkid (as you are no doubt aware). I have lots of users who use /dev/disk/by-uuid/ symlinks to identify their LUKS volumes on boot - which udev now fails to create.
vol_id just let LUKS take precedence, knowing that an ambivalent result meant that it was a LUKS volume. blkid seems to be stricter about this - which in principle is nicer, but now causes problems.
What is the best solution here? Is there a tool that wipes out the old magic numbers from ext2/3/4? Is there a workaround that will tell blkid to just assume LUKS if several filesystems have been found and LUKS is one of them? Do you have any other tips on how to proceed here?
Thanks Thomas
Attachment:
signature.asc
Description: OpenPGP digital signature
