LinuxQuestions.org - Problem with crypted LVM after Debian installation

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - Problem with crypted LVM after Debian installation (https://www.linuxquestions.org/questions/linux-newbie-8/problem-with-crypted-lvm-after-debian-installation-692343/)

Problem with crypted LVM after Debian installation

Hello,

I installed Fedora on crypted LVM (I created it using partition manager from installation program). It works fine: ask for passphrase during startup. Then I installed Debian on the other partition (again crypted LVM). At the moment I am not able to run Fedora anymore. My passphrase doesn't work. After the third attempt I see messages that /dev/sda3 (my Fedora crypted LVM) is not a LUKS partition...
pvscan recognise /dev/sda3 as LVM PV partition, but command:

Code:

cryptsetup luksOpen /dev/sda3 lvvm

What should I do?

pvscan shouldn't be able to recognize the partition if its not been opened with luksOpen. It's possible that something got overwritten when you did your debian install, but lets not jump to conclusions.

We could do with seeing the output from the following to better advise you.

Code:



fdisk -l /dev/sda



cryptsetup luksDump /dev/sda3 | grep 'Cipher \| Slot'



pvs

Thank you for your answer! I have thought that nobody would answer to my question.

fdisk -l /dev/sda :

Code:

Disk /dev/sda: 160.0 GB, 160041885696 bytes

255 heads, 63 sectors/track, 19457 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Disk identifier: 0x5c405320



  Device Boot      Start        End      Blocks  Id  System

/dev/sda1  *          1        5471    43945776    7  HPFS/NTFS

/dev/sda2            5472        5496      200812+  83  Linux

/dev/sda3            5497      11870    51199155  8e  Linux LVM

/dev/sda4          11871      19457    60942577+  83  Linux

where sda2 is /boot, sda3 is/was Fedora and sda4 is/was Debian.

cryptsetup luksDump /dev/sda3 :

Code:

/dev/sda3 is not a LUKS partition

Command failed.

pvs:

Code:

 

  PV        VG  Fmt  Attr PSize  PFree 

  /dev/sda3      lvm2 --  48.83G 48.83G

After

Code:

cryptsetup luksOpen /dev/sda4

pvs shows:

Code:

  PV        VG  Fmt  Attr PSize  PFree

  /dev/dm-0      lvm2 --  58.12G 58.12G

  /dev/sda3      lvm2 --  48.83G 48.83G

hmmm...

The fdisk -l shows that you only have one lvm partition (type 8e) sda3. sda4 is a standard linux partition. Normally a pvcreate won't let you create on a non lvm type partition, but as we're dealing with a luks mapping that may explain why pvcreate managed to create a pv on it.

Worryingly, the pvs command shows that its finding a lvm physical volume, on sda3 which it shouldn't as that is the encrypted device and it should only find it on the /dev/mapper device associated with it when you open it. Your psize/pfree show it as being empty and its not allocated to a volume group. Here's mine for comparison purposes.

Code:

root@jupiter:~# pvs

  PV                VG    Fmt  Attr PSize  PFree 

  /dev/mapper/pvhda2 sysvg  lvm2 a-    18.91G  6.91G

  /dev/mapper/pvhdb1 datavg lvm2 a-  149.05G 97.05G

stranger still is that once unlocked, the sda4/dm-0 device doesn't show any information either.

Are these commands being run from your running debian system or a live/recovery cd?

If you're running from a live cd, try a

Code:

vgscan --mknodes

vgchange -ay

and see if that changes the output of pvs.

If they're from your debian system I'd be interested to see the output of commands.

Code:

mount



vgs



lvs

My gut feeling is that somehow during the debian install a new physical volume has been created over the sda3 partition wiping out the existing luks metadata. The unopened sda3 would have just looked like random data to the installer so there's no way it could have known it was already in use. Your sda4 appears to have a pv header on it, but at this stage its not clear whether its actually being used as such.

Quote:

Originally Posted by GazL (Post 3385939)

If you're running from a live cd, try a

Code:

vgscan --mknodes

vgchange -ay

and see if that changes the output of pvs.

I use SystemRescueCd. Unfortunately there are no changes in output of pvs.

Quote:

Originally Posted by GazL (Post 3385939)

That is what I was being afraid of. Hopefully these two installation were only for a test purpose. But anyway, now I am wondering what would have happened if I had done it on my desktop computer - ufff :). So there are no possibilities to recover data from sda3?

Could you advise me how to prevent a situation like this? Is it better to create two PV manually and than to install these two system on it?

Quote:

Originally Posted by setkos (Post 3387557)

Could you advise me how to prevent a situation like this? Is it better to create two PV manually and than to install these two system on it?

To be honest, I don't think it matters. My distro of choice is Slackware, and in order to do a lvm/luks install with Slackware you have to do all the partitioning, luks formatting/opening and lvm object creation manually from the command line prior to running the setup process. I personally prefer this approach over the more automated installs, but really there's just as much scope for error as with a more automated install process.

The only thing you can do to mitigate this sort of stuff is to develop a healthy case of paranoia and take a few extra seconds before you hit that final <enter>. Double and triple check any confirmation dialogs or command line you've just typed when installing to sense-check what it's going to do, rather than what you think you've told it to do. Doing this has saved me on more than one occasion.

As for recovering sda3, if as it appears, lvm has written its pv metadata over the top of your luks encrypted partition then I'd be very surprised if there's any way to recover it.

Somehow I have destroyed again pv on sda3 (with new Fedora installation) after Debian installation on sdb4. So I have installed Fedora again on sda3 and now everyting works fine.

Thank you for your explanations!

You're welcome Setkos. Glad you got there in the end.