Karel Zak schrieb:
On Sat, Aug 29, 2009 at 07:36:08PM +0200, Thomas Bächler wrote:ERROR: ambivalent result detected (2 filesystems)!What is the best solution here?Use the latest version of cryptsetup. cryptsetup 1.0.7 changelog:- Wipe start of device (possible fs signature) before LUKS-formatting.
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.
Is there a tool that wipes out the old magic numbers from ext2/3/4?(I'd like to add SBMAGIC, SBMAGIC_LEN, SBMAGIC_OFFSET values to libblkid, then should be pretty simple to wipe all signatures in mkfs programs or create a new wipefs(8) tool or so.)Now, if you really hate your data you can try to use with dd(1) ...extN magic number is \x53\xef at offset 1080:$ blkid -p ~/ext2.img /home/kzak/ext2.img: LABEL="COOL" UUID="ed409e8e-44cc-4c2e-a31a-cd98f54eff36" VERSION="1.0" TYPE="ext2" USAGE="filesystem"$ hexdump -C -s 1080 -n 2 ~/ext2.img 00000438 53 ef |S.| $ dd if=/dev/zero of=~/ext2.img bs=1 seek=1080 count=2 conv=notrunc 2+0 records in 2+0 records out 2 bytes (2 B) copied, 0.000123413 s, 16.2 kB/s $ hexdump -C -s 1080 -n 2 ~/ext2.img 00000438 00 00 |..| 0000043a ... but think twice. Really.
I know that such a solution is dirty, but it is the only way unless blkid handles LUKS volumes like udev's vol_id used to (my guess is that you don't want to do this, which is understandable).
I just don't know if I can advise users to use this hack. Doesn't this offset overlap with one of the LUKS key slots? Activating that particular key slot would then overwrite the magic.
Anyway, thanks again for your insight, I will find out how to deal with this - it seems there are only a very small number of people that have this particular problem.
Thomas
Attachment:
signature.asc
Description: OpenPGP digital signature
