From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fQg8BQXj07o for ; Fri, 31 Jan 2014 04:17:07 +0100 (CET) Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.saout.de (Postfix) with ESMTP for ; Fri, 31 Jan 2014 04:17:06 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-44-24.dclient.hispeed.ch [77.57.44.24]) by v6.tansi.org (Postfix) with ESMTPA id 0913620DC239 for ; Fri, 31 Jan 2014 04:17:06 +0100 (CET) Date: Fri, 31 Jan 2014 04:17:05 +0100 From: Arno Wagner Message-ID: <20140131031705.GA30616@tansi.org> References: <20140130210159.GA27307@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dm-crypt] Filesystem unreadabe after resizing LUKS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Fri, Jan 31, 2014 at 02:36:33 CET, Robert Nichols wrote: > On 01/30/2014 03:01 PM, Arno Wagner wrote: > >On Thu, Jan 30, 2014 at 16:24:27 CET, Pawel Chojnacki wrote: > >>Hello, > >> > >>Two days ago I tried to shrink my LUKS-encrypted /dev/sdb5 partition from > >>119 to 110 GB according to > >>http://ubuntuforums.org/showthread.php?t=726724. Each step worked > >>properly, but in the end I'm not able to mount the > >>partition. I wanted to ask if you have any idea what may have caused that > >>and how to fix it: > >> > >># cryptsetup luksOpen /dev/sdb5 neuro > >> > >>accepts the proper password, doesn't recognize any other, and fails to > >>mount the partition inside: > >> > >># mount /dev/mapper/neuro /mnt/ > >>mount: unknown filesystem type 'LVM2_member' > > > >This means LUKS is fine, just the resize failed. > >I should pount out the clear "It should go without > >saying, resizing your crypt may result in data loss > >Be sure to BACK UP your data first." given in that posting. > > The thing that bugs me about the procedure in that thread is that it > includes a totally unnecessary and complex ("I had to do this by trial > and error") step of "cryptsetup ... resize". Nowhere in the LUKS header > is there any field that holds the size of the container. Each time the > LUKS container is opened it takes on the size of whatever is holding it > (physical partition, LVM logical volume, dmsetup mapping, ... whatever). > > The "resize" operation in cryptsetup is useful only in the fairly rare > circumstance that you actually want to _use_ an encrypted area _while_ > it is smaller than whatever is holding it. That is similar to having > a filesystem that is smaller than its partition, except that the > filesystem _does_ have persistent knowledge of its size whereas a LUKS > container does _not_. Indeed. I missed that. In fact, I was unaware that cryptsetup even had a resize operation (well, I must have been aware at some time, because I revised the man-page, but apparently forgot about it immediately), possibly because I know that there is no size-field anywhere in the header and that it is completely unnecessary to have one. I guess there is some massive misunderstanding somewhere in that set of instructions.... 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