encrypted block devices unavailable with linux-virtual

$ cat /etc/crypttab
vg--root-lv--root_crypt UUID=9bdcff58-de6d-40e4-8f3e-d214da46ddf2 none luks

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid -o value -s UUID' to print the universally unique identifier
# for a device; this may be used with UUID= as a more robust way to name
# devices that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
/dev/mapper/vg--root-lv--root_crypt / ext4 relatime,nodiratime,data=journal,errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=bfc4552d-4dc0-485d-b1fe-bf27357a027e /boot ext2 noatime,nodiratime,nodev,nosuid 0 2
tmpfs /tmp tmpfs rw,noatime,nodiratime,nodev,nosuid 0
        0

I can confirm this is a problem. My system was installed with the alternate Gutsy installer with whole disk encryption. I've dist-upgraded all the way to Lucid with no problem and after doing an upgrade to Maverick I receive the cyptsetup: evms_activate is not available error message.

Set to confirmed per Eric Frost's comments.

I'm getting the "cryptsetup: evms_activate is not available" on boot too, but I don't think this has anything to do with linux-virtual, since I don't use it. I have just installed 4 laptops without problems using the 10.10beta image (i386) in last two weeks, and now with the fifth I used the final 10.10 image and got this after updating the initramfs (needed to tweak the encryption to use a a file in a usb flash drive to decrypt the drive).

If I wait log enough, I get also "-r ALERT! /dev/disk/by-uuid/[id] does not exist. Dropping to a shell!"

If I try to boot with recovery mode, I get this:

"Begin: Mounting root file system ... Begin: Running /scripts/local-top ... cryptsetup: lvm device name (/dev/disk/by-uuid/[id]) does not begin with /dev/mapper/
cryptsetup: evms_activate is not available
Begin: Waiting for encrypted source device... ..."

My guess is that there is some regression in making of the initramfs. This is kind of major bug since it totally stops the booting of a system with encrypted root partition.

Ehm... Actually my "bug" seems to be a copy&paste mistake made by myself in crypttab. I didn't remember to change the UUID to match this laptop when I copied it from a previous install.

That was really the reason, wrong UUID and therefore cryptsetup failed since it didn't find the correct partition. The first visible error message "cryptsetup: evms_activate is not available" was kinda misleading.

So toobuntu and Eric, check that you have correct UUID.

You can check and fix it by booting from a live CD, mount your /boot partition and then extract the initramfs (after first copying it to a temporary directory):

gunzip -c -9 initrd.img-2.6.35-22-generic | cpio -i -d -H newc --no-absolute-filenames

Check and fix conf/conf.d/cryptroot (the source parameter, I corrected the UUID by replacing it with correct /dev/sdaX).

Then pack the initramfs again:

find . -print0 | cpio --null -ov --format=newc | gzip -9 > your-new-initramfs.cpio.gz

Then backup your old initramfs and copy the new to the correct location. Reboot, and hope this fixes things also for you. :)

TuxFan: If I wait log enough, I get also "-r ALERT! /dev/disk/by-uuid/[id] does
not exist. Dropping to a shell!"

The timeout is four minutes, IIRC.

I'm glad you solved your problem. I suppose it is possible that the affected package is initramfs-tools, but it seems like it's linux-virtual to me. For me, it's not a UUID issue, because I can boot normally by using linux-generic.

For me it is not a UUID issue. I checked /dev/disk/by-uuid and cross checked that with /etc/crypttab and also unpacked the initrd and checked conf/conf.d/cryptroot

It was the same UUID in all cases. I don't have linux-virtual installed like toobuntu does. My case is a system that has whole disk encryption and was upgraded to Maverick. I now experience this problem. I think something in the initramfs is the problem...it's looking for evms to be installed which naturally isn't.

Toobuntu: different kernel versions have different initramfs files. Check if your working and non-working have the same conf/conf.d/cryptroot in them.

I find using UUIDs a bit too hard (or at least I'm not used to deal with them so much), that's why I did my initial fix with /dev/sdaX so that I was absolutely sure what partition was the encrypted one.

Eric: If you did dist-upgrade, do you have any old working kernels/initramfs left on your system?

The initrd's have the same cryptroot!

$ cat initrd-virtual/initrd/conf/conf.d/cryptroot
target=sda5_crypt,source=UUID=e8bd3ebc-0510-4df6-b734-826ea47050b6,key=none,rootdev,lvm=maverick-root

$ cat initrd-generic/initrd/conf/conf.d/cryptroot
target=sda5_crypt,source=UUID=e8bd3ebc-0510-4df6-b734-826ea47050b6,key=none,rootdev,lvm=maverick-root

I think this might be a regression of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544487 (which is a bug in cryptsetup and its interaction with lvm2), but cryptsetup and lvm2 have reportedly been fixed since then.

From the debian bug: "the problem is that my root filesystem /dev/mapper/yoom-root is a symlink to /dev/dm-1,
(see fstab and mtab below). With this setup, the canonical_device function in /usr/share/initramfs-tools/hooks/cryptroot returns 1 since the target of the symlink is not in /dev/mapper, (without having checked that the symlink itself *is* in /dev/mapper)."

$ ls -lh /dev/mapper/
total 0
crw------- 1 root root 10, 59 2010-10-30 13:36 control
lrwxrwxrwx 1 root root 7 2010-10-30 13:36 maverick-root -> ../dm-1
lrwxrwxrwx 1 root root 7 2010-10-30 13:36 sda5_crypt -> ../dm-0

$ cat /etc/mtab | grep /dev
/dev/mapper/maverick-root / ext4 rw,nodiratime,relatime,errors=remount-ro,commit=0 0 0
none /dev devtmpfs rw,mode=0755 0 0
none /dev/pts devpts rw,noexec,nosuid,gid=5,mode=0620 0 0
none /dev/shm tmpfs rw,nosuid,nodev 0 0
/dev/sda1 /boot ext2 rw,nosuid,nodev,noatime,nodiratime 0 0

$ apt-cache policy cryptsetup
cryptsetup:
  Installed: 2:1.1.2-1ubuntu1
  Candidate: 2:1.1.2-1ubuntu1
  Version table:
 *** 2:1.1.2-1ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages
        100 /var/lib/dpkg/status

$ apt-cache policy lvm2
lvm2:
  Installed: 2.02.54-1ubuntu6
  Candidate: 2.02.54-1ubuntu6
  Version table:
 *** 2.02.54-1ubuntu6 0
        500 http://us.archive.ubuntu.com/ubuntu/ maverick/main amd64 Packages
        100 /var/lib/dpkg/status

Perhaps, though, this is a regression introduced in lvm2:

lvm2 (2.02.54-1ubuntu5) maverick; urgency=low

  * Backport from Debian:
    - Don't overwrite names of dm devices; use symlinks instead
      (LP: #621951).

 -- Colin Watson <email address hidden> Wed, 08 Sep 2010 22:50:26 +0100

What's still perplexing (and disturbing) me is why this works with -generic but not with -virtual. Perhaps something to do with upstart/udev?

Regarding lvm2, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544487:

Message #41 received at <email address hidden> (full text, mbox):

From: Jonas Meurer <email address hidden>
To: Carl Worth <email address hidden>
Cc: 544487 <email address hidden>
Subject: Re: [pkg-cryptsetup-devel] Bug#544487: please try to reproduce
 with old cryptsetup
Date: Mon, 21 Sep 2009 00:33:33 +0200

the reason for both appearance and disappearance of the bug where last
but one and last upload of the lvm2 packages. see the buglog of bug
#544773 for more information: http://bugs.debian.org/544773

greetings,
 jonas

Message #46 received at <email address hidden> (full text, mbox):

From: Bastian Blank <email address hidden>
To: <email address hidden>
Subject: Workaround to be removed
Date: Mon, 12 Oct 2009 12:56:04 +0200

I intend to remove the workaround in the lvm2 package in 2 weeks.
I will make this bug RC because of that in 1 week.

Bastian

toobuntu, would you mind regenerating your initrd for both -generic and -virtual to verify that the bug you are seeing is definitely between kernel types rather than the cryptsetup package available during initrd generation? (keep a backup of your working -generic, just in case.)

I am also having a very similar sounding bug, but it is between two -generic kernels (following a dist-upgrade, like Eric). If you find that regenerating both initrds breaks both, then I'll add my details here. Otherwise, I probably have a different bug. I'll run through the same test by generating a new initrd to replace my working one.

Ok, so I came here because of the following error:

cryptsetup: lvm device name (/dev/disk/by-uuid/...) does not begin with /dev/mapper/
cryptsetup: evms_activate is not available

You may only see the last three characters of your uuid followed by ") does not begin with /dev/mapper/" depending on how many characters fit on your screen.

But it turns out, this error is presented for any number of issues resulting in the crypted volume not being available. In my case, it was that modprobe ahci was producing an Oops. Subsequently, scripts/init-premount/mdadm and scripts/init-premount/lvm2 failed, leaving no crypted volume to identify by UUID. To make sure the disks you are expecting are there, wait for the timeout and:

ls -l /dev/disk/by-*

Also, take a look at /tmp/mountroot-fail-hooks.d/ for clues.

Good luck to all who stumble here.

Recently dist-upgraded my netbook to 10.10 and it started exhibiting the same problem. Interestingly enough, both my laptop and my netbook will occasionally boot up and present the screen properly, but statistically it gives me the above mentioned issue (cryptsetup: evms_activate is not available).

Note: laptop was started out with a fresh 7.10 install and dist-upgraded over time to 10.10.
The netbook was started out with a fresh install 8.10 install and dist-upgraded to 10.10.

Only after a dist-upgrade to 10.10 does the problem start presenting itself and every great once in a while when I reboot does it behave "normally".

I just received the same error message:

"evms_activate is not available"

After a short time, I'm dropped to a prompt (initramfs), with the initial error indicating the following:

"-r ALERT /dev/disk/by-uuid/<UUID> does not exist. Dropping to shell"

I just installed ubuntu-10.10-alternate-amd64.iso. Partitioned my disks, setup raid and crypto from the manual disk installer during the setup process. Everything was running great. I decided I wanted to modify one of the three encrypted partitions, I wanted to utilize a key file versus a passphrase so I entered in the following:

sudo cryptsetup luksFormat /dev/sda6 /root/keyfile (the keyfile is owned by root, read only).

Upon reboot, the error above. I'm just not starting the investigative process and stumbled upon this thread, I will continue to investigate.

I booted into the CD installer again and went into the manual partition disks section. Looks like by entire partition table and mounts points are all screwed up, in addition to not having anything show up as encrypted.

One thing I didn't notice before that I just saw now is that there are multiple kernel options available during the boot process:

2.6.35-25 (generic and recovery)
2.6.35-22 (generic and recovery)

Neither of the generics work. I tried the 2.6.35-22 recovery, prompted me for my passphrase for the first encrypted disk. Stated that it was successful, then the following:

cryptsetup: lvm is not available
cryptsetup: evms_activate is not available
Begin: waiting for encrypted source drive

Same thing happens on 2.6.35-25 recovery.

I'm pretty much at a loss.

Status changed to 'Confirmed' because the bug affects multiple users.