On Thu, January 30, 2014 22:01, 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. > > 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 > things. > > [...] 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 transformation. LVM makes it more complicated, esp if one is not familiar with the steps to take. > >> Testdisk recognizes the filesystems as FAT32/FAT12/NTFS and can't do >> much. >> Photorec on the other hand can seamlessly recover all data as long as >> it's >> 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 - >> resize2fs >> -p /dev/mapper/neuro-root 9G - has gone wrong - even though all the >> tests >> 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 >> to >> 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 > -- > Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx > 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 > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > @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. Regards -Sven _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
