You are not logged in.

#1 2017-05-20 22:36:10

coderiferous
Member
Registered: 2017-05-20
Posts: 2

"Lost" LUKS LVM encryption?

A bit of background: I installed Arch a few months ago using the LVM on LUKS from here.  Everything worked fine until yesterday when I was trying to install Kali onto a USB stick into an LVM.  The Kali installation media was on one stick and being installed onto another, so my harddrive shouldn't have been involved at all.  However, afterwards, when I try to boot into Arch, I get the following:

Waiting 10 seconds for device /dev/disk/by-uuid/XXXXXXXX ...
Waiting 10 seconds for device /dev/mapper/arches-root ...
ERROR: device '/dev/mapper/arches-root' not found. Skipping fsck.
:: mounting '/dev/mapper/arches-root' on real root
mount: you must specify the filesystem type

And dumped into a recovery shell.  The timing with this Kali LVM stuff and my Arch LVM acting up (which had been fine up to this point) seems too much to be coincidence, but I have no idea what could have actually happened.

My kernel parameters in rEFInd (normally has rw and quiet but I took them out for this testing):

options  "cryptdevice=UUID=XXXXXXXX:arches root=/dev/mapper/arches-root pcie_port_pm=off"

I searched the forums for similar issues and found a few (1,2,3) which involve getting into the encrypted root partition and poking around in it.  I booted into my Live USB and tried:

root@archiso ~ # cryptsetup luksOpen /dev/sda2 lvm
Device /dev/sda2 is not a valid LUKS device.

I'm not really sure what to make of it.  I've tried things that I think should tell me what's in the LVM if it were open, but there's never any output and I suspect that's because there is no open LVM since it's still (or should be) encrypted, yet LUKS apparently can't recognize it.  But when I'm trying to boot, I think Linux does still know it's LUKS-encrypted.  I wondered about the UUID (which worked fine before, but I was short on ideas) so I checked with lsblk and lo and behold, that gave a different UUID for the LVM than what I have in the kernel parameters.  When I changed the parameters and tried to boot:

ERROR: Failed to open encryption mapping: The device UUID=YYYYYYYY is not a LUKS volume and the crypto= parameter was not specified.

Since I don't get this error normally, it must know that the original UUID is LUKS encrypted, and is just failing to prompt me for the password which is why it can't access the root partition.  But then on the Live USB it says it's not a LUKS device, so I don't know what to do.  All I can really look into right now is my /boot partition but that seems unchanged from how it normally is and it seems the problem is more related to the LVM/LUKS itself than the booting.

I don't have any super important files on here so it's not the end of the world if I can't recover them, but I really don't feel like having to restart Arch and redo all my customization and everything.  Any help, please?

Last edited by coderiferous (2017-05-20 22:37:11)

Offline

#2 2017-05-20 23:00:11

frostschutz
Member
Registered: 2013-11-15
Posts: 1,418

Re: "Lost" LUKS LVM encryption?

Are you simply using the wrong device name?

# file -sL /dev/sd* /dev/md* /dev/dm* /dev/hd* /dev/vd*
/dev/sdc3: LUKS encrypted file, ver 1 [aes, xts-plain64, sha512] UUID: 9b42751b-b0e5-4a0c-8d59-da9c0a75d0dc

If there is no LUKS header anywhere, that's the end of the story (unless you can somehow find it again somewhere, wholly undamaged...). LUKS header is about 128K of random data (more if using more than one keyslot), the slightest damage to this data renders it unuseable.

Last edited by frostschutz (2017-05-20 23:00:44)

Offline

#3 2017-05-20 23:30:00

coderiferous
Member
Registered: 2017-05-20
Posts: 2

Re: "Lost" LUKS LVM encryption?

By "using the wrong device name" do you mean am I sure that /dev/sda2 is the LVM partition?  If so, yes, that's how it shows up on fdisk and lsblk, it says that's an LVM.  I'll check your suggestion and edit this with the output.

Edit: Using all the arguments in the command doesn't work because it can't find them, but using /dev/sda*:

/dev/sda:  DOS/MBR boot sector; partition 1 : ID=0xee, start-CHS (0x0,0,1), end-CHS (0x3ff,254,63), startsector 1, 937703087 sectors, extended partition table (last)
/dev/sda1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "MSDOS5.0", sectors/cluster 4, reserved sectors 6174, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 40, sectors 524288 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 1009, reserved 0x1, serial number 0x303f208c, unlabeled
/dev/sda2: LVM2 PV (Linux Logical Volume Manager), UUID: Fzocbf-DTpx-J20W-Qt1G-LEi6-YInN-WD6sol, size: 338228674560
/dev/sda3: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS    ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 661127208, dos < 4.0 BootSector (0x80), FAT (1Y bit by descriptor); NTFS, sectors/track 63, sectors 276575846, $MFT start cluster 786432, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 0ecb03d09b03cdbb0
/dev/sdb:  DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 164, 131072 sectors
/dev/sdb1: DOS/MBR boot sector; partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 164, 131072 sectors
/dev/sdb2: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, reserved sectors 4, root entries 512, Media descriptor 0xf8, sectors/FAT 128, sectors/track 32, heads 64, sectors 131072 (volumes > 32 MB) , serial number 0xe1493759, label: "ARCHISO_EFI", FAT (16 bit)

So yeah, no LUKS sad  What could have happened to it, why is it a different UUID?  I thought the point was that those didn't change.  I suppose it could have been overwritten, though I haven't the foggiest idea how.  More importantly, shouldn't it be yelling at me at boot that the UUID doesn't exist or something?

Edit edit: My understanding of the way this works is that /dev/sda2 is the physical volume which contains the (previously encrypted) LVM, my volume group (arches) contains the physical LVM volume which itself has the logical volumes (root, home).  Is that right?  And since "vgdisplay" and "lvdisplay" (and other vg* commands in the LVM page) yield no output, that means I have no volume groups or logical volumes, meaning I can't get to my data?

Last edited by coderiferous (2017-05-21 00:44:28)

Offline

Board footer

Powered by FluxBB