Upgrading Ubuntu 12.04 to 14.04 breaks encrypted LVM

My laptop runs Ubuntu and is fully encrypted (since version 10.04). Upgrade from 10.04 to 12.04 was smooth in the sense that my system booted fine, asking for the passphrase to unlock the LVM. However, when I upgraded from 12.04 to 14.04, things broke and my laptop no longer booted properly as the LVM never got encrypted. I had to do the following to get my laptop working again (after many rounds of trial and error):

  • Boot a live usb Ubuntu session, de-crypted the LVM, and chroot’ed to run as the original OS
  • Finish the upgrade session via apt-get update && apt-get upgrade
  • It appears Ubuntu 14.04 installed some new package (did not write name down) that manages LVM or disks somehow (based on googling the error message). I removed this package.
  • Saw lvm issues, so installed the package lvm2
  • I made sure both dm-crypt and lvm2 were installed, and were accessible in initramfs, as cryptsetup was removed from initramfs since version 13.10. Had to do something with the following CRYPTSETUP issue.
  • Based on this post, I modified various files, but things still did not boot properly. I believe what finally fixed it was explicitly pointing to the LVM by /dev/sda5 in the GRUB_CMDLINE_LINUX line in /etc/default/grub.

The following is summary of these files for me. /etc/crypttab:

# <target name> <source device>         <key file>      <options>
# sdb5_crypt UUID=731a44c4-4655-4f2b-ae1a-2e3e6a14f2ef none luks
sdb5_crypt UUID=731a44c4-4655-4f2b-ae1a-2e3e6a14f2ef none luks,retry=1,lvm=vg01


## vinh created http://www.joh.fi/posts/2014/03/18/install-ubuntu-1310-on-top-of-encrypted-lvm/
# CRYPTROOT=target=sdb5_crypt,source=/dev/disk/by-uuid/f1ba5a54-ac7e-419d-8762-43da3274aba4

Then run update-initramfs -k all -c in order to update the initramfs images.

Have this line in /etc/default/grub:


Run update-grub.

Again, I think the key is the source definition in the previous line. I kept trying to refer to it by uuid but that did not work.

About Vinh Nguyen



  1. When I updated Trisquel recently I forgot to run “apt-get dist-upgrade” as well as “apt-get update” and “apt-get upgrade”. Maybe this led to my machine not booting anymore (LVM password couldn’t be entered because the logitech keyboard froze; after fixing this the LVM wasn’t recognized properly). After 2 days of struggling, your blog helped me out. Thank you so much, man! For all you other guys, here’s what I did: Using a Live-CD (or USB stick), run these commands:

    sudo apt-get install lvm2 vim sudo cryptsetup luksOpen /dev/sdb5 sda5_crypt #it’s crucial that you mount it under the name that will be used later on, so sda5_crypt, in this case; might be sda5_crypt on your machine etc! sudo vgscan –mknode sudo vgchange -ay sudo mkdir /volume sudo mount /dev/mapper/volumes-root /volume #volumes-root is the root partition of my LVM sudo mount /dev/sda5 /volume/boot #mounting the regular boot partition (unencrypted)

    sudo mount –bind /dev /volume/dev sudo mount –bind /proc /volume/proc sudo mount –bind /sys /volume/sys

    now Chroot into your system

    sudo chroot /volume export HOME=/root export LC_ALL=C

    Add suport to Logitech USB bluetooth wireless keyboad and encryption

    vim /etc/initramfs-tools/modules

    Add these lines:

    hid usbhid hid_logitech_dj dm-crypt

    Good luck to anyone having similar issues!

  2. You don’t need to have both the grub option and the cryptroot file.

    Take a look at /usr/share/initramfs-tools/scripts/local-top/cryptroot in the end of the file: if [ -n “$cmdline_cryptopts” ]; then # Call setup_mapping separately for each possible cryptopts= setting for cryptopt in $cmdline_cryptopts; do setup_mapping “$cryptopt” done exit 0 fi

    Do we have any settings from the /conf/conf.d/cryptroot file?

    if [ -r /conf/conf.d/cryptroot ]; then while read mapping <&3; do setup_mapping “$mapping” 3<&- done 3< /conf/conf.d/cryptroot fi

    Basically it tries to setup your mapping twice now. Which isn’t a problem, since there is a if for it in setup_mapping:

    if [ -e "/dev/mapper/$crypttarget" ]; then
        return 0

    But never the less, it’s not correct.

    Further more, the reason it stopped working is probably update-initramfs wasn’t able to generate the cryptroot file in /conf/conf.d (from initramfs perspective, same file as in /etc/initramfs-tools/conf.d

    One way you could’ve tested this is to generate the initramfs, then unpack it somewhere with zcat /boot/initrd.img-$(uname -r) | cpio -iv and take a look if there is any cryptroot in /conf/conf.d

    If that’s the case and you’ve used the installer from the start then a bug report would’ve been advised.

    At the moment, if you do change any of your devices, luks or lvm, and forget to update cryptroot file in /etc/initramfs-tools/conf then cryptsetup won’t be able to decrypt your drive in initramfs.

    In other words this ‘workaround’ is not wished in the long run when you’ve forgotten all about the cryptroot file.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>