[dm-crypt] Filesystem unreadabe after resizing LUKS
rnicholsNOSPAM at comcast.net
Fri Jan 31 02:36:33 CET 2014
On 01/30/2014 03:01 PM, Arno Wagner wrote:
> On Thu, Jan 30, 2014 at 16:24:27 CET, Pawel Chojnacki wrote:
>> 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_.
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
More information about the dm-crypt