Does LUKS also encrypt free space

• 1 - When using encrypted LVM on Debian/Ubuntu a partition is created. DM-CRYPT is setup on that partition, and then a LVM volume is created within the encrypted DM-CRYPT volume. If you use it for all your partitions, then it basically is full disk encryption.

• 2 - Using the encrypted LVM, once the system is booted and the volumes are mounted everything after that is transparent. This does mean that if someone is able to remotely compromise your system while it is turned on and the drives are mounted, then they simply don't know or care about the encryption.

• 3 - Using software RAID with DM-CRYPT and LVM is easy. I have it setup on half a dozen boxes. Setup the RAID, then Setup an Encrypted volume on the RAID, then Setup LVM on the Encrypted Volume.

• 4 - I haven't found a good solution to this. I guess one thing you could do is come up with a IP-based KVM. That early SSH tool does look like it should work.

• 5

  • Yes you can add them, it is pretty easy.
  • Setup the RAID, run cryptsetup, create the LVM volume group. Update crypttab/fstab if you want things automatically mounted
  • Moving a volume to another system is Linux system should be as easy as moving the physical drives and mounting them.

Just take some time to read the following docs. It is all pretty easy.

• http://linux.die.net/man/8/cryptsetup
• http://tldp.org/HOWTO/LVM-HOWTO/
• http://www.saout.de/misc/dm-crypt/

I had the same problem and finally solved

The problem seems to be in update-initramfs that doesn't generate the initrd properly.

"evms_activate not found" means that the /sbin/evms_activate file is not created inside the initrd file by update-initramfs

So, my workaround consists in unpacking the not working initrd, and copy the evms_activate executable into /sbin/ from a working initrd file (probably getting one from a deb file of debian/ubuntu repositories), and packing initrd again.

In my case, I made the following steps.

We create two folders:

mkdir NOT_WORKING
mkdir WORKING

We copy the corrupted initrd to NOT_WORKING folder (in my case "initrd.img-3.4.94") and the working to WORKING (in my case "initrd.img-3.8.0-31-generic").

cp /boot/initrd.img-3.4.94 NOT_WORKING
cp initrd.img-3.8.0-31-generic WORKING

Unpack both initrd:

cd NOT_WORKING
mv initrd.img-3.4.94 initrd.img-3.4.94.gz
gzip -d initrd.img-3.4.94.gz
cpio -id < initrd.img-3.4.94
cd ..
cd WORKING
mv initrd.img-3.8.0-29-generic initrd.img-3.8.0-29-generic.gz
gzip -d initrd.img-3.8.0-29-generic.gz
cpio -id < initrd.img-3.8.0-29-generic
cd ..

We copy evms_activate

cp WORKING/sbin/evms_activate NOT_WORKING/sbin/evms_activate 

And we pack initrd again

cd NOT_WORKING
mv initrd.img-3.4.94 .. #We don't want to pack an older initrd into the newer :p
find . | cpio --quiet -H newc -o | gzip -9 -n > /boot/initrd.img-3.4.94

Now the evms_active error should dissappear :)