>> root@road:/dev/disk/by-uuid# grep -ob --binary-files=text LUKS /tmp/sdm >> 32256:LUKS >> >> or grep directly on /dev/sdm >> >> [ 32256 ] should be offset. >> >> What should I do with this? > > This confirms that you did create the LUKS container at the > right place, namely the LUKS header is at 64 x 512 B offset. 64x512 =32768 32768 != 32256 512 bytes is partition table? should it be 32780? I am probably missing something. I just tested it on other LUKS disks and every disk gives 32256 which means that this offset is OK. > This seems to be some bizzarre issue with your system not detecting the > partitions right and LUKS is actually working as expected. grep -ob --binary-files=text LUKS /dev/sdm1 /dev/sdm1 does not return anything although it should return "0:LUKS". but grep on /dev/sdm returns "32256:LUKS" > > Ok, lets do some triage. > > - What Linux, what kernel version? 2.6.29.4, vanilla I have a few other HDDs in this machine, some of them with LUKS, raid5 with LUKS etc. This is the only disk with LUKS on USB (others are intern/SATA) but that should not be the reason. > - Any special set-up like virtuzlization? > - Any special partition management system? No to both. I think it has something to do with 4Kb sector size and some kind partition table incompatibilty with the kernel. or maybe mkfs.xfs did something because I did not use "-b 4096" (block size in XFS is 4kB by default). LUKS header starts obviously where it should if I look at /dev/sdm. I don't know enough about partition tables and headers but it looks like /dev/sdm1 is starting little bit too far and LUKS header stays before the beginning of /dev/sdm1 (first partition). Only obvious reason (at lease for me) for this could be in this 4Kb sector size. Thanks M. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
