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_.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
