2

I have a Debian 8 VPS with an encrypted root partition. After a kernel update a few months ago (package version 3.2.73-2+deb7u3), it stopped being able to decrypt properly on boot. As far as I can tell, the initramfs wasn't loading the crypt libraries, and so didn't know what to do.

I found this answer, but that didn't solve the issues, no matter what UUID we tried. https://unix.stackexchange.com/questions/107810/why-my-encrypted-lvm-volume-luks-device-wont-mount-at-boot-time

Our current kludge that enables us to boot with errors is creating a cryptroot file in /etc/initramfs-tools/conf.d/cryptroot with contents

CRYPTOPTS=target=root,source=/dev/vda5,lvm=cloud--vg-root

and an /etc/crypttab with contents

# <target name> <source device>     <key file>  <option>
crypt-vda5  /dev/vda5   none    luks

During boot it asks for the password and mounts vg-root, and then it asks us for the password again and complains that the partition is already mounted, and throws a bunch of errors that I have to hit esc repeatedly to get past. If we remove either one of those files or change them, it doesn't prompt for password on boot, and thus mounting root fails.

Any ideas how to remove the kludge and fix this for good?

thanks!

Community
  • 1
mxroo
  • 41
  • 5

1 Answers1

1

It may just work if you add the following to /etc/initramfs-tools/initramfs.conf and move /etc/initramfs-tools/conf.d/cryptroot out of the way.

CRYPTSETUP=Y

Then rebuild initramfs, run it with the -k and -v options which will show you what it is doing and whether it adds crypt support. The -k option will keep around the temporary directory mkinitramfs used, which can help in investigating what is going on. Of course keep a copy of the old initramfs around so you can boot that if necessary.

Also /etc/crypttab should contain the logical volume name, if that is vg-root instead of crypt-vda5 make sure to replace it. That name is the string example-name used in the following:

cryptsetup -v luksOpen /dev/vda5 example-name

Which should be accessible under:

/dev/mapper/example-name
aseq
  • 4,610
  • 1
  • 24
  • 48
  • I'm afraid that didn't work. I edited /etc/crypttab to `crypt-vda5 /dev/cloud--vg-root none luks` and then got the error: Volume group "cloud-vg" not found Skipping volume group cloud-vg Unable to find LVM volume cloud-vg/root – mxroo Jul 13 '16 at 01:52
  • I'm pretty sure the thing I didn't have clear to myself earlier is that there is a device /dev/vda5 which is encrypted. The LVM, which contains cloud--vg-root, is on that device. – mxroo Jul 13 '16 at 01:54