[dm-crypt] Filesystem unreadabe after resizing LUKS
sven at whgl.uni-frankfurt.de
Fri Jan 31 03:26:31 CET 2014
On Thu, January 30, 2014 22:01, 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
>> 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
>> 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.
> I also have to say that this is one of the reasons I think that
> lvm has no place in a normal installation: It just complicates
Actually mount complains that the crypto target holds an lvm which can not
be mounted (for obvious reasons). The question here is if there was a LVM
before taking any action and if not how the LVM signatures showed up.
I think the very first important information we need is: Setup before
anything was done, which steps were taken and were there any errors durign
LVM makes it more complicated, esp if one is not familiar with the steps
>> Testdisk recognizes the filesystems as FAT32/FAT12/NTFS and can't do
>> Photorec on the other hand can seamlessly recover all data as long as
>> told that the filesystem is ext4.
> Is the data good? If so, this stronglyindicates that this is not
> a nencryption problem.
True. maybe the OP just forgot to activate the LVs. Hard to tell without
knowing anything about the system ;-).
>> From what I understand, the first step in the resizing process -
>> -p /dev/mapper/neuro-root 9G - has gone wrong - even though all the
>> done in the meantime worked.
>> I have a backup from 3 days ago, yet it's a question of honor for me to
>> understand what has gone wrong and how to repair it. I will owe a beer
>> whoever helps me.
> Ok, so at least you did not kill all data. The mystery. however seems
> to be in some other place than the encryption. You can try doing this
> again and looking after each step what is on disk.
> Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
> GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D
> A good decision is based on knowledge and not on numbers. - Plato
> dm-crypt mailing list
> dm-crypt at saout.de
@Pawel, you might want to do a blkid before opening the crypto container
and afterwards. Blkid is non-destructive and the output might help to
understand your layout (or whatever is left of it). Of course a blkid
output etc. of the before state would have been good.
More information about the dm-crypt