What's the easiest way to decrypt a disk partition?

Question

I made a mistake of encrypting the entire LVM physical volume (contains both home, root, and swap) when installing a CentOS 6.4 (2.6.32-358.6.1.el6.x86_64) box. I soon came to realize that moving files takes a horrendous amount of time due to kcryptd running at 90% of CPU and that encryption was not really necessary as it's just a home server containing no crucial data. However, I already configured it and installed loads of packages, tuned it as far as power management goes, and set up all the services.

Is there any way to remove the encryption without having to re-install the whole thing and go through the configuration all over again? I'd love an option that would take less than 30 mins but I'm not sure one exists.

Also, if anyone has any recommendations on how to make kcryptd more easy to use, let me know.

Edit 1

~]# fdisk -l /dev/sda

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000078c9

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          64      512000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2              64       19458   155777024   83  Linux

~]# dmsetup ls
vg_centos-lv_home       (253:3)
vg_centos-lv_swap       (253:2)
vg_centos-lv_root       (253:1)
luks-2ffcc00c-6d6e-401c-a32c-9c82995ad372       (253:0)

~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/mapper/luks-2ffcc00c-6d6e-401c-a32c-9c82995ad372
  VG Name               vg_centos
  PV Size               148.56 GiB / not usable 4.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              38030
  Free PE               0
  Allocated PE          38030
  PV UUID               euUB66-TP3M-ffKp-WhF5-vKI5-obqK-0qKoyZ

Edit 2

~]# df -h / /home /boot
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_centos-lv_root
                       50G  2.3G   45G   5% /
/dev/mapper/vg_centos-lv_home
                       94G  1.3G   88G   2% /home
/dev/sda1             485M   53M  408M  12% /boot

Solution

That is possible. It requires

1. another Linux to boot (CD/DVD is OK)
2. some spare space outside the PV (100M would be good)
3. a certain amount of fearlessness...

Then you copy a block from the encrypted volume to the area outside the PV and (after success) to the unencrypted base device. After that you increase a counter in the safe area so that you can continue the transformation in case of a crash. Depending on the kind of encryption it may be necessary (or at least useful) to copy from the end of the block device to the beginning.

If this is an option for you then I can offer some code.

Edit 1

Deactivate the swap partition (comment it out in etc/fstab). Then boot another Linux (from CD/DVD) and open the LUKS volume (cryptsetup luksOpen /dev/sda2 lukspv) but don't mount the LVs. Maybe you need run pvscan afterwards to that the decrypted device is recogniced. Then vgchange -ay vg_centos may be necessary to activate the volumes. As soon as they are you can reduce the file systems in them:

e2fsck -f /dev/mapper/vg_centos-lv_root
resize2fs -p /dev/mapper/vg_centos-lv_root 3000M
e2fsck -f /dev/mapper/vg_centos-lv_home
resize2fs -p /dev/mapper/vg_centos-lv_home 2000M

After that you can reduce the size of the LVs (and delete the swap LV):

# with some panic reserve... shouldn't be necessary
lvresize --size 3100M /dev/mapper/vg_centos-lv_root
lvresize --size 2100M /dev/mapper/vg_centos-lv_home
lvremove /dev/mapper/vg_centos-lv_swap

# vgdisplay should show now that most of the VG is free space
vgdisplay

Now the PV can be reduced (exciting, I have never done this myself ;-) ):

vgchange -an vg_centos
pvresize --setphysicalvolumesize 5500M /dev/mapper/lukspv

Edit: Maybe pvmove is needed before pvresize can be called. In case of an error see this question.

Before you reduce the partition size you should make a backup of the partition table and store it on external storage.

sfdisk -d /dev/sda >sfdisk_dump_sda.txt

You can use this file for reducing the size of the LUKS partition. Adapt the size (in sectors) to about 6 GiB (panic reserve again...): 12582912. Then load the adapted file:

sfdisk /dev/sda <sfdisk_dump_sda.mod.txt

If everything looks good after rebooting you can create a new partition in the free space (at best not consuming all the space, you probably know why meanwhile...) and make it an LVM partition. Then make the partition a LVM PV (pvcreate), create a new volume group (vgcreate) and logical volumes for root, home and swap (lvcreate) and format them (mke2fs -t ext4, mkswap). Then you can copy the contents of the opened crypto volumes. Finally you have to reconfigure your boot loader so that it uses the new rootfs.

The block copying I mentioned in the beginning is not necessary due to the large amount of free space.

Comments

[Admin]

How is the PV encrypted? What is the output of fdisk -l /dev/sda, dmsetup ls and pvdisplay?

[Admin]

@HaukeLaging, here are the specs: fpaste.org/10427

[Admin]

/dev/sda1 is /boot with several hundred MiB free space? How much space is currently consumed? df -h / /home, please. I think it probably makes sense to reduce the size of (a) the file systems, (b) the LVs, (c) the PV, (d) the LUKS volume, and (e) the LUKS partition (/dev/sda2) first. The free space can easily be added after the transformation.

[Admin]

@HaukeLaging, see Edit 2.

[Abhinav Jayaram]

So if I understand this correctly, it would basically copy a block of e.g. 100M to a separate drive (will a USB drive suffice?), format that block on the PV, and copy it back unencrypted? Definitely interested in the code :) Thanks!

[Hauke Laging]

@mart1n See the edit

[Abhinav Jayaram]

When you say "Then you can copy the contents of the opened crypto volumes.", is that literaly just a cp /dev/mapper/vg_centos-lv_root /dev/mapper/vg_new-newlv_root (similarly with lv-home)?

[Hauke Laging]

@mart1n No, using dd doesn't make sense. "opened crypto volumes" is misleading. You have to mount those volumes (whereever) and copy the file system contents: cp -a. Of course, you have to mount the new, unencrypted volumes somewhere before, too. E.g. cp -a /mnt/root-old/. /mnt/root-new

[Abhinav Jayaram]

So the pvresize --setphysicalvolumesize 5500M /dev/mapper/lukspv command fails with: /dev/mapper/lukspv: cannot resize to 1374 extents as later ones as allocated.. Any ideas how to get pass this?

[Abhinav Jayaram]

Ok, I solved the above by moving the extents into one pile. Basically, the answer was similar to: unix.stackexchange.com/questions/67702/…