DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arno Wagner <arno@wagner.name>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] Filesystem unreadabe after resizing LUKS
Date: Fri, 31 Jan 2014 04:17:05 +0100	[thread overview]
Message-ID: <20140131031705.GA30616@tansi.org> (raw)
In-Reply-To: <lceuml$9qd$1@ger.gmane.org>

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

  reply	other threads:[~2014-01-31  3:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-30 15:24 [dm-crypt] Filesystem unreadabe after resizing LUKS Pawel Chojnacki
2014-01-30 16:22 ` Matthias Schniedermeyer
2014-01-30 21:01 ` Arno Wagner
2014-01-31  1:36   ` Robert Nichols
2014-01-31  3:17     ` Arno Wagner [this message]
2014-01-31  9:04       ` Pawel Chojnacki
2014-01-31  2:26   ` Sven Eschenberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140131031705.GA30616@tansi.org \
    --to=arno@wagner.name \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox