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 :)
If you use full disk encryption for your root filesystem then you will have to solve the problem that the Python interpreter is normally not available early at boot. You will need several megabytes of additional unencrypted disk space to store for example /usr/bin/python2.7 and a bunch of essential stuff from /usr/lib/python2.7 and you will have to develop several modifications to your /boot/initrd in order to make this work.
The boot process invokes /scripts/local-top/cryptroot from the initrd root.
This normally calls the tool plymouth ask-for-password --prompt. This is used to ask the user for the passphrase before the graphical user interface is started. This passphrase is in turn piped into cryptsetup.
If you still really want to continue with this approach you can/should use a configuration file in the configuration directory /etc/initramfs-tools/ to configure a new value for your own cryptkeyscript instead of hacking the script /usr/share/initramfs-tools/scripts/local-top/cryptroot directly. This will make the installation of OS distribution updates less cumbersome later.
For more information refer to the documentation of the packages initramfs-tools, cryptsetup and plymouth and have a look into the shell script cryptroot I mentioned above.
Best Answer
Did you regenerate the initramfs ?
The initramfs is a small file system called before your rootfs to ask for your password and decrypt the LUKS container and handle stuff. It contains the /etc/cryptab file to be able to know what it should uncrypt / mount.
If you haven't regenerate it, the initramfs don't have you modified file and can't handle your new configuration.
So try to update the initramfs. Here some help for Red Hat : http://advancelinux.blogspot.ch/2013/06/how-to-rebuild-initrd-or-initramfs-in.html
Keep in mind that your key file have not to be on the encrypted partition, and so the encryption become useless because it easy to find the key.