Restore your encrypted Ubuntu 18.04 drive
It sucks when your PC dies. Especially so when you’re somewhat security aware. I remember, back in the day, when i haven’t really cared about security. Moving the data from my old hard drive to a new computer was just as simple as plugging it in to a SATA-to-USB connector, let ubuntu automount that thing and copy my files to the new machine.
Having to do this on a machine that was installed with ubuntus default disk encryption proved to be somewhat of a challenge. So in order to save you some hassle, here’s a short guide on how to get your data off of a LUKS encrypted LVM volume.
So, here’s the situation:
You have rescued your encrypted SATA SSD (or HDD) from your old laptop whose mainboard ( or graphics card, or screen, or whatever ) just died. You’ve got yourself a handy little SATA-to-USB adapter (a real lifesaver if you ask me) and you want to copy the data on it to a new computer. Your new PC is running ubuntu or any other ubuntu distribution.
So, how do you now get it to recognize your drive? Let’s start with a bit of theory.
LUKS and LVM
LUKS is shorthand for “Linux Unified Key Setup”. Its the standard method for encrypting partitions with linux. This means, that In order to get “full disk encryption” (not really, but close enough), you will need to create only one partition on your disk, encrypt it with LUKS and then create your additional partitions ( like /home /swap or / ) inside the encrypted container.
“But thats not how partitions work!”, i hear someone scream… Yes, correct. This is where LVM comes into play.
LVM is linux’s “Logical Volume Manager”. It allows you to create logical volumes inside physical partitions. These are grouped into so called “Logical Volume Groups”. You can imagine the volume groups to be virtual hard drives and the contained “Logical Volumes” as virtual partitions if you want.
So, putting things together: When you’re creating a fully encrypted ubuntu installation, the installer first creates a new partition on your hard drive, sets up an encrypted LUKS container on that partition, installs a Logical Volume Group into that container and then adds one logical volume per partition you want to create to that volume group. On my ubuntu installation, this looks somewhat like the following:
“Partition 1” And “Partition 2” are my other OSes. “Partition 3” Contains the Ubuntu installation. “Logical Volume 1” and “Logical Volume 2” contain my root and swap-partitions.
Decrypting and mounting your drive
Now, let’s get back to topic. How do you now mount a logical volume from a logical volume group that’s in a LUKS encrypted container on a USB device?
The Following Steps were tested under Ubuntu 18.04, but i’m rather certain they’ll also work under different OSes.
First, open up a terminal window and make sure you’re root by running:
user:~/ $ sudo su -
[sudo] password for user:
root#Next, we will need to gather some information about the encrypted disk so we don’t start messing around with your other partitions. Run the following to get an overview of all block devices (or volumes) connected to your machine:
root# lsblk --allNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 9,1M 1 loop /snap/kubectl/655
...
loop15 7:15 0 0 loop
sda 8:0 0 465,8G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
├─sda2 8:2 0 732M 0 part /boot
└─sda3 8:3 0 464,6G 0 part
└─sda3_crypt 253:0 0 464,6G 0 crypt
├─neon--vg-root 253:1 0 463,6G 0 lvm /
└─neon--vg-swap_1 253:2 0 980M 0 lvm [SWAP]
sdb 8:16 0 238,5G 0 disk
├─sdb1 8:17 0 512M 0 part
├─sdb2 8:18 0 732M 0 part
└─sdb3 8:19 0 237,3G 0 part
As you can see, we have a couple of “loop” devices attached. You can ignore all of these. We’re mainly interested in the ones named sd* . In my case, we have two physical drives, sda and sdb with 3 partitions each. The drive I've attached via USB is sdb . You can identify it by looking at the MOUNTPOINT ( your USB drive should not have been automounted ) as well as the SIZE .
When you know, which drive the one attached via USB is, run the following command to inspect the partitions on the drive: (substitute sdb for the drive name you got)
root# lsblk -f /dev/sdb
NAME FSTYPE LABEL UUID MOUNTPOINT
sdb
├─sdb1 vfat 9BCC-475E
├─sdb2 ext4 ad2fcd47-3725-4a8a-8ea6-90943b5914d2
└─sdb3 crypto_LUKS a740ff78-58b7-4ccd-87a1-92ba8715edcfThere’s out encrypted LUKS container. Make note of the partition name ( sdb3 in my case) and run the following to open the container.
root# cryptsetup open /dev/sdb3 olddisk
Enter passphrase for /dev/sdb3:
root#You will be prompted for the password for the encrypted container. olddisk is just a name reference for the container. You can name is whatever you want.
Next, run lsblk again to verify that the container has been properly opened:
root# lsblk -f /dev/sdb
NAME FSTYPE LABEL UUID MOUNTPOINT
sdb
├─sdb1 vfat 9BCC-475E
├─sdb2 ext4 ad2fcd47-3725-4a8a-8ea6-90943b5914d2
└─sdb3 crypto_LUKS a740ff78-58b7-4ccd-87a1-92ba8715edcf
└─olddisk LVM2_member sucIx2-pWqP-XfWA-j9Fs-lnhr-Xsbc-GfD0PM
root#You’ll notice, that a new Volume of the type LVM2_member appeared. This is the logical volume group that holds our logical volumes. Now we will just need to open that container using the lvm tools.
First, we’ll need to get the ID of the volume group. If your setup is like mine, this will be a little bit difficult. Run vgdisplay to list all currently connected logical volume groups:
mrGizmo# vgdisplay
--- Volume group ---
VG Name neon-vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 0 # <== LOOK HERE
Max PV 0
Cur PV 1
Act PV 1
VG Size 237,25 GiB
PE Size 4,00 MiB
Total PE 60737
Alloc PE / Size 60725 / <237,21 GiB
Free PE / Size 12 / 48,00 MiB
VG UUID fsCVYY-xUXi-3GXN-XxgP-9sel-g11U-AC2o4Y--- Volume group ---
VG Name neon-vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size <464,54 GiB
PE Size 4,00 MiB
Total PE 118922
Alloc PE / Size 118922 / <464,54 GiB
Free PE / Size 0 / 0
VG UUID 8eWmhy-fpQC-xT6G-MWVU-8GP6-4RFx-ViG67v
On my machine there were two volume groups with the same name. You will need to identify the one on the USB drive by either the size or (if they have the same size) the OPEN LV property. This shows the number of currently open logical volumes. If your system is like mine, you will have two logical volumes opened from one volume group. This is the one where your current OS is installed.
Copy the ID of the other volume group and rename it with the following command:
root# vgrename fsCVYY-xUXi-3GXN-XxgP-9sel-g11U-AC2o4Y olddata Processing VG neon-vg because of matching UUID fsCVYY-xUXi-3GXN-XxgP-9sel-g11U-AC2o4Y
Volume group "fsCVYY-xUXi-3GXN-XxgP-9sel-g11U-AC2o4Y" successfully renamed to "olddata"
This way, there’s no confusion with the names. Run vgdisplay again to verify your changes:
root# vgdisplay
--- Volume group ---
VG Name olddata
System ID
Format lvm2
...Now that we know the unique name of the volume group where our precious data is located, run lvs to inspect the logical volumes in that volume group:
root# lvs olddata
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root olddata -wi------- 236,25g
swap_1 olddata -wi------- 976,00mThere is our old root partition! In order to mount it, we will need to activate it first. To do so, run the following (substitute olddata with the name of your volume group and root with the name of the logical volume you want to get the data off of):
root# lvchange -ay olddata/rootYou can use lvscan to check whether or not your partition is now activated:
root# lvscan
ACTIVE '/dev/olddata/root' [236,25 GiB] inherit # <<<<
inactive '/dev/olddata/swap_1' [976,00 MiB] inherit
ACTIVE '/dev/neon-vg/root' [463,58 GiB] inherit
ACTIVE '/dev/neon-vg/swap_1' [980,00 MiB] inheritNow we are able to mount the logical volume in our file system. To do so, create a new folder in /media (or anywhere else) and mount the volume:
root# mkdir /media/user/olddata
root# mount /dev/olddata/root /media/user/olddataAdjust /dev/olddata/root so that it fits your volumes. It should read /dev/<volume_group_name>/<volume_name> .
Finally we’re able to access our data:
user:~/ $ ls -l /media/user/olddata
total 124
drwxr-xr-x 2 root root 4096 Dez 10 21:26 bin
drwxr-xr-x 2 root root 4096 Okt 3 20:13 boot
drwxr-xr-x 2 root root 4096 Okt 3 20:14 cdrom
drwxr-xr-x 4 root root 4096 Sep 27 07:30 dev
drwxr-xr-x 135 root root 12288 Dez 17 23:30 etc
drwxr-xr-x 3 root root 4096 Okt 3 20:15 home
lrwxrwxrwx 1 root root 33 Dez 10 21:30 initrd.img -> boot/initrd.img-4.15.0-42-generic
lrwxrwxrwx 1 root root 33 Dez 10 21:30 initrd.img.old -> boot/initrd.img-4.15.0-38-generic
drwxr-xr-x 21 root root 4096 Okt 3 20:17 lib
drwxr-xr-x 2 root root 4096 Sep 27 07:30 lib64
drwx------ 2 root root 16384 Okt 3 20:13 lost+found
drwxr-xr-x 3 root root 4096 Okt 3 20:21 media
drwxr-xr-x 2 root root 4096 Sep 27 07:30 mnt
drwxr-xr-x 5 root root 4096 Nov 10 12:54 opt
drwxr-xr-x 2 root root 4096 Apr 24 2018 proc
drwx------ 3 root root 4096 Okt 11 20:29 root
drwxr-xr-x 13 root root 4096 Sep 27 07:39 run
drwxr-xr-x 2 root root 12288 Dez 10 21:26 sbin
drwxr-xr-x 9 root root 4096 Dez 13 16:05 snap
drwxr-xr-x 2 root root 4096 Sep 27 07:30 srv
drwxr-xr-x 2 root root 4096 Apr 24 2018 sys
drwxrwxrwt 9 root root 12288 Dez 18 01:07 tmp
drwxr-xr-x 10 root root 4096 Sep 27 07:30 usr
drwxr-xr-x 12 root root 4096 Sep 27 07:40 var
lrwxrwxrwx 1 root root 30 Dez 10 21:30 vmlinuz -> boot/vmlinuz-4.15.0-42-generic
lrwxrwxrwx 1 root root 30 Dez 10 21:30 vmlinuz.old -> boot/vmlinuz-4.15.0-38-genericThanks for staying till the bitter end. I hope i could deliver some value to you, my dearest reader. Feel free to share your thoughts with me. I may have an article on medium, but i also may be wrong :)
