From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ste-pvt-msa2.bahnhof.se (ste-pvt-msa2.bahnhof.se [213.80.101.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Wed, 25 Nov 2020 19:06:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTP id 2A0103F470 for ; Wed, 25 Nov 2020 19:00:53 +0100 (CET) Received: from ste-pvt-msa2.bahnhof.se ([127.0.0.1]) by localhost (ste-ftg-msa2.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgI_SzxIsFdY for ; Wed, 25 Nov 2020 19:00:52 +0100 (CET) Received: by ste-pvt-msa2.bahnhof.se (Postfix) with ESMTPA id 1C40F3F6C4 for ; Wed, 25 Nov 2020 19:00:51 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTPS id 6ADFB2E0014 for ; Wed, 25 Nov 2020 19:01:21 +0100 (CET) Date: Wed, 25 Nov 2020 18:01:20 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [dm-crypt] cryptsetup versions: cryptsetup 2.3.4 vs. cryptsetup 2.1.0 - thought I had data corruption!?! List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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. 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. Are you able to reproduce the behavior with a brand new container? (You can use a plain file to hold a LUKS container.) If so, please list the exact commands, in order, and the exact software versions (kernel, cryptsetup, libcryptsetup) involved. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”