From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v1.tansi.org (mail.tansi.org [84.19.178.47]) by mail.server123.net (Postfix) with ESMTP for ; Fri, 15 Jul 2016 15:13:35 +0200 (CEST) Received: from gatewagner.dyndns.org (77-56-144-126.dclient.hispeed.ch [77.56.144.126]) by v1.tansi.org (Postfix) with ESMTPA id 34A7414004A for ; Fri, 15 Jul 2016 15:13:33 +0200 (CEST) Date: Fri, 15 Jul 2016 15:13:33 +0200 From: Arno Wagner Message-ID: <20160715131333.GA30326@tansi.org> References: <20160715091351.GA28512@tansi.org> <3bf87426-e4fe-3032-a649-779a510b29d2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bf87426-e4fe-3032-a649-779a510b29d2@gmail.com> Subject: Re: [dm-crypt] Offset/size issue during LUKS recovery. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Fri, Jul 15, 2016 at 13:12:30 CEST, Milan Broz wrote: > On 07/15/2016 11:13 AM, Arno Wagner wrote: > > On Fri, Jul 15, 2016 at 02:52:35 CEST, Julio Cesar Faracco wrote: > >> Hi, > >> > >> Since I moved to the version 1.6.7 of cryptsetup, I started to have some problems to recovery a LUKS partition > >> using a LUKS header file and a valid passphrase. > >> > >> # cryptsetup luksDump my_header_file --debug > >> # Detected kernel Linux 3.10.0-327.13.1.el7.x86_64 x86_64. > >> # Reading LUKS header of size 1024 from device /tmp/my_header_file > >> # Key length 64, device size 8192 sectors, header size 4036 sectors. > > [...] > >> # # cryptsetup luksOpen /dev/loop0 my_enc_partition < >> $(PASSWORD) > >> EOF > >> # Detected kernel Linux 3.10.0-327.13.1.el7.x86_64 x86_64. > >> # Reading LUKS header of size 1024 from device /tmp/my_header_file > >> # Key length 64, device size 4060 sectors, header size 4036 sectors. > > > > I take it, the device is 8192 sectors, i.e. 4MB? > > > > If so, there seem to be a bug in device-size detection > > as used by luksOpen. > > libcryptsetup uses BLKGETSIZE64 ioctl as all other tools, so more likely is that > device-size is really 4MB :) > > But if separate header is used then the debug output above mean device > (or file image) size for the header image, > not the data device > > I should probably change wording in this message... > > Milan Hmm, makes sense, from the file-names this is a detached header. But the data-offset should then be 0, should it not? It was > Payload offset: 4096 from luksDump. @Julio: Did you manually split the header off from a file that was originally 8MB and is now 4MB header and 4MB data? If so, you probably need to adjust the data-offset field manually. Regards, Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier