Re: [dm-crypt] cryptsetup versions: cryptsetup 2.3.4 vs. cryptsetup 2.1.0 - thought I had data corruption!?!

[Milan Broz <gmazyland@gmail.com>]

On 25/11/2020 19:01, Michael Kjörling wrote:
> On 25 Nov 2020 18:30 +0100, from mjoerg@gmail.com (Martin Jørgensen):
>> I tried to look in version history but am not into the details of the
>> difference in crypt-setup versions. Can anyone please tell why I got/get
>> this error using 2.1.0 and not with 2.3.4?
>>
>> "mount: wrong fs type, bad option, bad superblock on /dev/mapper/....,
>> missing codepage or helper program, or other error
> 
> _If_ you're able to unlock the container using both versions, _but_
> with one you are able to mount the file system within the container
> and with the other you are unable to do so, then I would suggest
> comparing the output of `file -s /dev/mapper/whatever` for the two
> cases after unlocking. You could also try `cryptsetup luksDump
> --dump-master-key` for each version of cryptsetup and comparing the
> output, but be sure that you understand the consequences of the master
> key being potentially compromised before you do so.

Yes, but the key is validated through LUKS key digest, if the validation fails,
it is never used for the mapping. I do not believe it is a wrong key problem.

Also compare "dmsetup table <device>" on both systems for LUKS active device.
It should produce exactly the same parameters (mainly offset, size, crypt options).

All this looks as a kernel issue unrelated to cryptsetup (note that you have different
kernels if you have different distros and the data decryption and fs handling is the kernel).

> I'm sure someone will correct me if I'm wrong about this, but I am
> _fairly_ certain that there is nothing in the luksOpen/luksClose code
> that will change anything in the LUKS header, so something else must
> be going on in your case.

For LUKS1 is it always true, LUKS2 have two metadata areas, there is autocorrection
in place if one area checksum is wrong (happens on the header load) but this is IMO
unrelated to this case.

(If I understand the mail correctly, the LUKS device can be still activated but
the filesystem is corrupted now? If not, we need --debug output from luksOpen command
to check what is wrong.)

m.