Theodore Tso schrieb:
On Sun, Aug 30, 2009 at 02:48:50AM +0200, Thomas Bächler wrote:We already use 1.0.7, the problem only occurs with old volumes, created by 1.0.6 and older (which probably not everyone wants to wipe out). It's a legacy we are now carrying around.Could you add a hack to your userspace to determine which of the 64k at the front of the disk is in use by LUKS, and zap the sectors that aren't (and then set a flag in the LUKS superblock so you only have to do this once)?
I think I'll post that to the dm-crypt list, probably Milan Broz is the most competent to solve this problem. A "cryptsetup luksFixHeader" action that has to be run once is the best thing here. I could even live with forcing everyone to run it manually.
It could be possible to reorder the detection algorithms to put LUKS ahead of the tests ext2/3/4 (and in the past when I was the sole maintainer of blkid I've done that sort of thing before), but really, depending on that kind of ordering is really a bad idea; it's better to fix a filesystem's utilities to do the right thing at mkfs time andif necessary to do any fixups in the filesystem's fsck utility.
The order is still that way. However, blkid doesn't stop once it finds a match: It does all probes, and when it finds more than one match, it says nothing - only in debug mode it will inform you about the ambiguity.
Btw, here is a nice note for Karel: http://www.archlinux.org/pipermail/arch-general/2009-August/007244.html So I guess big thanks are in order.
Attachment:
signature.asc
Description: OpenPGP digital signature
