Boot fails after installing updates, error: “cryptsetup: evms_activate is not available"

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1003309

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

Please note: I ran the apport collector, however, as I cannot boot the problematic kernel, I am running this on the WORKING kernel. This probably means, that the collected data is not useful.

So, I guess that it is not possible to use apport to collect data in this bug.

Confirmed as data has been added.

This may be a duplicate of bug #1000655 which seems to be fixed after an upgrade to kernel 3.2.0-24.38. Could you please test this kernel to see if it solves the problem? A simple 'apt-get update ; apt-get dist-upgrade' should do the job.

I have already 3.2.0-24.38 installed. I think this was the update that broke it actually.

ii linux-image-3.2.0-24-generic 3.2.0-24.38 Linux kernel image for version 3.2.0 on 64 bit x86 SMP

Ok, sorry. It was not clear which version was failing (there were more than on 3.2.0-24.XX kernels).

Anyway, you refer you have tried to run 'update-initramfs -u', but I believe this will only update the initramfs for the currently running kernel (i.e., the 3.2.0-23.36). Could you try 'update-initramfs -u -k all', which will update for all the installed kernels?

Yeah, I just did update-initramfs -u -k all followed by update-grub.
That did not solve the problem. In fact, now I cannot even boot the previous kernel.

I really hope you will help me get my system back in a working state.

When I try to boot either kernel, it gives the missing evms error. After a while, I get a BusyBox prompt. Is there anything I can do from here?

Right, so something *very* wrong is going on. The first thing you should try is to make sure you can still access your encrypted partitions. You can do this by booting through a live CD/USB and manually mount your encrypted partitions. Take a look at https://help.ubuntu.com/community/EncryptedFilesystemLVMHowto if you don't know how to do that.

From there, you can also take a look at the last packages you have updated (/var/log/apt/history.log in your encrypted filesystem). This should give us an hint of the last packages that have been updated in your system, as this doesn't look like a kernel issue (initramfs, cryptsetup, etc).

Although your previous kernel works that may be related to the initramfs contents which for encrypted root contains a lot of additional packages. It is possible that if you rebuilt your working kernels initrd with the current packages it would also stop working; of course if this is your only kernel trying this would be dangerous.

Luis, the page you link to seems to be for 7.04. That is 5 years old. Is this still valid?

I used the following procedure to access the encrypted data:
1: Boot Ubuntu Desktop amd64 12.04 LiveCD.
2: Try Ubuntu
3: Start Terminal and run
sudo su -
apt-get update
apt-get install cryptsetup initramfs-tools lvm2
modprobe aes-x86_64
modprobe dm-crypt
modprobe dm-mod
cryptsetup luksOpen /dev/sda5 pvcrypt
vgscan
vgchange -a y barbera
mount /dev/mapper/barbera-root /mnt

Then I could cd into /mnt and access the data.
So, what to do from here? How do I fix the system?

I use aptitude, here is the log:
http://p.adora.dk/P2405.html

It was after this upgrade, it failed:

===============================================================================

Log complete.
Aptitude 0.6.6: log report
Mon, May 21 2012 20:39:46 +0200

IMPORTANT: this log only lists intended actions; actions which fail due to
dpkg problems may not be completed.

Will install 4 packages, and remove 0 packages.
116 kB of disk space will be used
===============================================================================
[UPGRADE] linux-headers-3.2.0-24:amd64 3.2.0-24.37 -> 3.2.0-24.38
[UPGRADE] linux-headers-3.2.0-24-generic:amd64 3.2.0-24.37 -> 3.2.0-24.38
[UPGRADE] linux-image-3.2.0-24-generic:amd64 3.2.0-24.37 -> 3.2.0-24.38
[UPGRADE] linux-libc-dev:amd64 3.2.0-24.37 -> 3.2.0-24.38
===============================================================================

Log complete.
Aptitude 0.6.6: log report
Tue, May 22 2012 15:29:59 +0200

IMPORTANT: this log only lists intended actions; actions which fail due to
dpkg problems may not be completed.

Will install 0 packages, and remove 0 packages.
===============================================================================

More info. Here is the dpkg.log:

http://p.adora.dk/P2406.html

/var/log/apt/history.log is here:
http://p.adora.dk/P2407.html

Andy Whitcroft, right now my previous kernel does *not* work. It stopped working when I ran update-initramfs -u -k all
:(

That's great you're able to access your encrypted filesystem. From your apt history, there's nothing really obvious there that could break the system on upgrade (but I may be wrong, will investigate that further).

For the moment, one thing you could try is to rebuild once again your initramfs. This should be easy to do, but it will depend on how you have your disk partitioned. Basically, you could mount your encrypted rootfs (say, in /mnt) and then mount your boot partition on /mnt/boot. Once you have this setup, you can chroot into it (sudo chroot /mnt) and rebuild the initramfs from there.

The easiest way to rebuild it should be dpkg-reconfigure linux-image-3.2.0-23-generic (I would start with the last kernel that was working). Since you're on a chroot, you could also try to apt-get update ; apt-get dist-upgrade.

Let me know if you were able to rebuild your initramfs (pay attention to any possible errors while doing this!) and if it made any difference.

Luis, I would like to do as you suggest. My partition table is seen here:
http://paste.adora.dk/P2408.html

/dev/sda1 is /boot
/dev/sda5 is the LUKS encrypted partition containing LVM with swap and rootfs.

So, what is the procedure?
Will the following work?

apt-get update
apt-get install cryptsetup initramfs-tools lvm2
modprobe aes-x86_64
modprobe dm-crypt
modprobe dm-mod
cryptsetup luksOpen /dev/sda5 pvcrypt
vgscan
vgchange -a y barbera
mount /dev/mapper/barbera-root /mnt
mount /dev/sda1 /mnt/boot
chroot /mnt
apt-get update && apt-get dist-upgrade
dpkg-reconfigure linux-image-3.2.0-23-generic
reboot

?

Do I have to mount /proc, /sys or other inside the chroot? Anything else I should be aware of?

I tried mounting rootfs in /mnt and boot in /mnt/boot
Then I mounted proc, sys, and so on as described on:
https://wiki.archlinux.org/index.php/Change_Root

Then I ran:
apt-get update
apt-get dist-upgrade

This is the complete output:
http://p.adora.dk/P2409.html

Highligted output:
Found linux image: /boot/vmlinuz-3.2.0-24-generic
Found initrd image: /boot/initrd.img-3.2.0-24-generic
Found linux image: /boot/vmlinuz-3.2.0-23-generic
Found initrd image: /boot/initrd.img-3.2.0-23-generic
Found memtest86+ image: /memtest86+.bin
  /var/lock/lvm: mkdir failed: No such file or directory
  File-based locking initialisation failed.
done
[...]
Not updating initrd symbolic links since we are being updated/reinstalled
(3.2.0-24.38 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled
(3.2.0-24.38 was configured last, according to dpkg)
[...]
Found initrd image: /boot/initrd.img-3.2.0-23-generic
Found memtest86+ image: /memtest86+.bin
  /var/lock/lvm: mkdir failed: No such file or directory
  File-based locking initialisation failed.
done
[...]
Found memtest86+ image: /memtest86+.bin
  /var/lock/lvm: mkdir failed: No such file or directory
  File-based locking initialisation failed.
done
[...]

What now?

Oh. Forgot to mention that this did not solve the problem.

Rebooting to the previous kernel (23) still gives me "evms_activate is not available", however, booting the current kernel (24) gives no error, but nothing happens. No error is printed and no passphrase prompt is shown. If I press Esc to see what happens behind the boot splash, it is just black. No lines of text.

Just to add some more info: If I boot the previous kernel in Recovery Mode, the screen says:
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /script/local-top ... Reading all physical volumes. This may take a while...
  No volume groups found
  No volume groups found
cryptsetup: evms_activate is not available
Begin: Waiting for encrypted source device... ...

This is the output from dpkg-reconfigure linux-image-3.2.0-23-generic :
http://p.adora.dk/P2411.html

/ # dpkg-reconfigure linux-image-3.2.0-23-generic
Running depmod.
update-initramfs: deferring update (hook will be called later)
Not updating initrd symbolic links since we are being updated/reinstalled
(3.2.0-23.36 was configured last, according to dpkg)
Not updating image symbolic links since we are being updated/reinstalled
(3.2.0-23.36 was configured last, according to dpkg)
Running postinst hook script /usr/sbin/update-grub.
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-24-generic
Found initrd image: /boot/initrd.img-3.2.0-24-generic
Found linux image: /boot/vmlinuz-3.2.0-23-generic
Found initrd image: /boot/initrd.img-3.2.0-23-generic
Found memtest86+ image: /memtest86+.bin
  /var/lock/lvm: mkdir failed: No such file or directory
  File-based locking initialisation failed.
done
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/dkms 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic
update-initramfs: Generating /boot/initrd.img-3.2.0-23-generic
hostname: Name or service not known
run-parts: executing /etc/kernel/postinst.d/pm-utils 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.2.0-23-generic /boot/vmlinuz-3.2.0-23-generic
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.2.0-24-generic
Found initrd image: /boot/initrd.img-3.2.0-24-generic
Found linux image: /boot/vmlinuz-3.2.0-23-generic
Found initrd image: /boot/initrd.img-3.2.0-23-generic
Found memtest86+ image: /memtest86+.bin
  /var/lock/lvm: mkdir failed: No such file or directory
  File-based locking initialisation failed.
done

This did not work either.
Get this error on boot:
http://i.imgur.com/RapUA.png

I get the same error tdn posted here:
http://i.imgur.com/RapUA.png

Have a similar setup.
After modifying my crypttab and /etc/initramfs-tools/modules with correct values, I did notice when I run
update-initramfs -k all -c
It finishes WAY faster than it has on all past distributions. I don't think its working correctly....

Is there any progress on this bug?

Is there anything I can do to help?

Do you need any additional info?

I am pretty sure I just reproduced this again in these steps:

1: Create a new virtualbox guest machine
2: Set Ubuntu Desktop 12.04 amd64 Alternate installer as virtual cdrom
3: Boot up the system and install Ubuntu Desktop selecting "Use entire disk, encrypted with LVM" during disk options
4: When the installer has finished, reboot
5: Run: apt-get update && apt-get dist-upgrade -y && reboot
6: It fails to come up :(

This time, I do not see the evms error, however, it seems to fail the same place : before prompting for LUKS passphrase.

Thank you for reporting. I'll try to reproduce this issue following the steps you just described.

Unfortunately, I wasn't able to reproduce the issue. I tried with the alternate CD and also the Kubuntu alternate CD (as I noticed you were using it in you initial report). Could you please post the output of the command:

 $ sudo update-initramfs -v -c -k 3.2.0-24-generic

I guess that its easier to run these commands in your virtualbox environment.

Also, could you check that if inside the initramfs you've just created there is a file <RAMFS-ROOTDIR>/conf/conf.d/cryptroot ? It should contain two lines if you've installed using the default partitioning scheme for LVM+encryption:

target=sda5_crypt,source=UUID=<SOME_UUID>key=none,rootdev,lvm=ubuntu-root
target=sda5_crypt,source=UUID=<SOME_UUID>key=none,lvm=ubuntu-swap_1

(<SOME_UUID> should be the same in both lines).

I am sorry, but I had to give up on this as I was forced to reinstall a new VM and recover from backup. I just needed my system in order to get some work done.

I have taken a snapshot of the old VM and I will try to boot it up again as soon as it is possible, however, I do not currently have enough free space on my working system (laptop) that i can have two VM images at the same time. Thus, I will have to wait a bit before I can do it....

It seems Ryan has the same problem. Maybe Ryan can provide more info?

Hi, I have the same problem.

I found a temporary workaround:

at the initramfs prompt i type:

cryptsetup luksOpen /dev/sda5 <VG Name>

Then I'm asked for the key. After entering the corrct key I type "exit"
After that I ame asked for key three times again (*) before boot continues into a fully working system with all encrypted partions mounted.

I would however like to fix this as it is annoying and takes several minutes extra to boot every time. I suspect that somewhere there is a missing or wrong configuration which result in the initramfs is not buildt with correct modules.

My problem actually started when upgrading from 10.04 to 11.04. Several upgrades later the problem is still the same. Now running on latest build of 12.04 (LTS).

(*) just pressing enter each time works just fine as I get errors even if i type the correct key. I have no idea why it asks for keys at this stage as the encrypted partitions already are mounted... I think...:)

This also seems to occur when installing a stock 12.10 32 bit desktop using LVM and encryption, then upgrading from 3.5.0-17 to 3.5.0-18.

I can't even guess what could cause it, but after reboot i ended up with "cryptsetup: evms_activate is not available" on luks-encrypted instance of 12.10 x86_64

The situation is weird. This is not raid, without lvm. blkid from-under initramfs console shows nothing related to the drive as well as in live environment.

FYI: I never solved this problem. I had to reinstall.

Hard to find this long-term bug report now.
I have this problem too, since a few minutes.

Today, I did a dist-upgrade on my laptop with lubuntu 12.04, including new kernel 3.2.0-38-generic, and found myself unable to decrypt the LVM partition that contains root-fs and home.

kernel 3.2.0-35 which operates well before update, has the same error now. For me, this indicates a problem in the upgrade procedure but not in the new kernel.

I am able to reach the data via the rescue mode of the lubuntu alternate CD. Also, the workaround described above by jorn-g (#48) works for me.

Maybe a new(?) helpfull fact: After using the workaround, I did

update-initramfs -v -k all -u

and collected the sterr and stdout for analysis.
And, stderr tells exactly two lines (one for each of the two installed kernel versions):

cryptsetup: WARNING: invalid line in /etc/crypttab for lda -

'lda' is the name of the LVM volume group that resides on the encryptet partition!

/etc/crypttab contains one single line as this:

sda2_crypt UUID=... none luks

The UUID is the same as given by blkid

/dev/sda2: UUID="..." TYPE="crypto_LUKS"

And, after collecting all messages in one file, I see the WARNING is thrown after

Calling hook cryptroot
cryptsetup: WARNING: invalid line in /etc/crypttab for lda -
Adding module...

Iirc when I had this problem I solved it by first 1)booting to a live cd
2) chrooting to the new system
3) installing crypt-setup AND lvm
4) doing the update ramfs thing
5) rebooting

The main problem I had was upgrading did not detect the need for the lvm and encryption packages and update the boot kernel modules accordingly. Instead it treated it as a regular install/upgrade without encrypted hard drives.

hm, lvm and cryptsetup reside in initrd, since I can use them at initramfs-prompt:

initramfs> cryptsetup luksOpen /dev/sda2 lda
...enter password...
initramfs> exit
...boot cont'd...

So, theres no missing software. It's a logical problem.

Actually, after another

update-initramfs -v -k all -c
update-grub

I see my lubuntu boot screen with blinking points but with NO input line for the crypt password. That remains for some more seconds as usual.

Then it falls down to initramfs prompt.

After manually cryptsetup and exit (see above), the boot continues and the boot screen flickers WITH the input line for the crypt password, but only for a second or less.

Then the lightdm screen appears and I can login.

This seems to me as if the sequence of steps is wrong, anyway: no input line first, but some timeout for decrypt? Input line thereafter when decrypt has been manually done.

I have this problem, dropping to the initramfs prompt just like post #40. It started for me 3.5.0-23, so i boot into 3.5.0-22 to get a working system. I am running 12.10. I do not have lvm, so that's probably not the problem. I have an encrypted /home. I was hoping the kernel update today would fix this(it didn't). It said this in the description:

"includes the corresponding System.map file, the modules built by the
packager, and scripts that try to ensure that the system is not left in an
unbootable state after an update."

I am thinking this is the solution--
http://askubuntu.com/questions/4950/how-to-stop-using-built-in-home-directory-encryption
Remove disk encryption! With all the stuff in booting and the mess of uefi there is just too much going on. Too many very difficult problems being caused. If you need encryption use the application cryptkeeper. This is a fantastically simple and elegant program.

Ubuntu needs to put a strong warning on disk encryption, like it is a pack or cigarettes or something.

I had similar problem. I was unable to boot with new kernel and update-initrams -u -k all caused that I couldn't also boot with old kernel. At the end I tried to completly reinstall grub and all kernels through a live cd - that did a trick. All works now. Here's short list of steps I did. http://ubuntuforums.org/showthread.php?t=2147608&p=12661995#post12661995 Doesn't matter there's nothing about luks there. I have luks + lvm and all that worked. I didn't write that in that thread to simplify procedure.

I have also one notice. Having luks it's very important to check /etc/crypttab. First parameter should be single name (and not device path), second should be UUID of *encrypted* partition. Next two usually have null and luks. Once I had problems having in /etc/crypttab UUID of decrypted partition instead of encrypted.

Notice also that first parameter must match all other stuff like ones in /etc/fstab.

More over I found on some debian forum that restarting luks/lvm from live cd, by chrooting to your unbooting system and performing update-initrams and some other magic things, before chroot you should mount whole your system just like it's expected in /etc/crypttab and /etc/fstab. So all names should be same as ones in that file - i.e. if you luksOpen your partition then it should look like: sudo cryptsetup luksOpen /dev/sdXY <FIRST PARAMETER FROM /etc/crypttab>.

This thread helped me once: http://forums.debian.net/viewtopic.php?f=5&t=74232

My problem (encrypted RAID1 drive refusing to boot when degraded) was fixed by adding a new initramfs boot script to start the RAID array before cryptsetup runs:

http://feeding.cloud.geek.nz/posts/the-perils-of-raid-and-full-disk-encryption-on-ubuntu/

i had the same problem as the_nipper (robert-wirth-gmx) #58.
i migrated a previous "root in lvm in luks" to "root in lvm in luks in raid1" (by creating new block devices incl. a degraded raid1, copying all data over and changing the configuration of crypttab, fstab etc. and updating the initramfs).

the solution mentioned in http://forums.debian.net/viewtopic.php?f=5&t=74232#p506229 (as linked by #61) did not work for me, probably because of plymouth...? the stdin of cryptsetup was not connected so typing the password had no effect whatsoever, yey... but hey canoncial could get a fancy and completely useless boot screen, that's important!

anyway, I resorted to copying lots of the ui logic from /usr/share/initramfs-tools/scripts/local-top/cryptroot into the attached script, which has to be put in /etc/initramfs-tools/scripts/local-top/cryptraid (and made executable!).
it is tailored to open /dev/md1, change cryptsource if needed.
then run update-initramfs -k all -u

it works for me, but it is not much tested, ymmv.

tdn, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please just make a comment to this.

If reproducible, could you also please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc6

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

i'm also affected.
i had ugraded to 14.04, but sadly i don't know anymore if that fixed it. then i reinstalled 13.10 again,
details here:

http://askubuntu.com/questions/398406/encrypted-13-10-will-not-reliably-boot
http://www.reddit.com/r/Ubuntu/comments/1u55fo/encrypted_1310_will_not_reliably_boot/

i guess you would like me to test 14.04 daily again? would gnubuntu (ubuntu gnome) 14.04 daily work too, or do you need ubuntu vanilla?

this bug is really driving me insane, not being able to reliably boot and waste sometimes 10 minutes to restart until it works. recovery mode usually works just fine, but takes even longer.

btw, any idea why booting an encrypted install takes over one minute?
i have a 800MB/s read speed pcie samsung ssd in my vaio pro 13. osx boots in 15 seconds on a slow sata3 ssd.

vaioproneedsubuntu, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu (ubuntu-gnome is fine) by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://help.ubuntu.com/community/ReportingBugs

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

I have had this problem occur when upgrading from Kubuntu 13.10 to 14.04.

On rebooting after the upgrade completed successfully I am unable to log in, I receive the error at the encryption password screen: "evms_activate not available" and my encryption pass phase is not accepted.

Managed to boot into an older kernel via grub, but not sure where to go with this now.

Was there any resolution? If I can help with any logs etc please advise how, I'm new to submitting bugs here but happy to help if I can! :)

Ruth

Ruth Cheesley, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

I was struggling on the same problem (Ubuntu 14.04 + software raid1 + dm-crypt) for a while.
The computer started ok with two disks but failed with the "waiting for encrypted source device" message with just one disk.
Note : I have to point that the system is able to start with mdadm, one disk but no encryption.

I finally found the solution here :
http://serverfault.com/questions/209379/what-tells-initramfs-or-the-ubuntu-server-boot-process-how-to-assemble-raid-arra

It was for a problem with mdadm, but it works beautifully with mdadm + dm-crypt in 14.04 version (And probably until 12.10 version)

In summary, and if you have two software raid partitions (Say /dev/md0 and /dev/md1) :
Create a new file /etc/initramfs-tools/scripts/local-top/workaround_mdadm :
--------
#!/bin/sh
sleep 6
mdadm --stop /dev/md1
mdadm --stop /dev/md0
sleep 6
mdadm --assemble --scan
--------

Make the file executable :
chmod 755 /etc/initramfs-tools/scripts/local-top/workaround_mdadm

Create new initrd files in /boot :
update-initramfs -k all -c

Reboot with just one disk and enjoy.

The problem seems related to the fact that /etc/initramfs-tools/conf.d/mdadm with BOOT_DEGRADED=true doesn't exist anymore for the 14.04 version. If you create it, the problem still exists.
With this workaround, you will be able to obtain the passphrase asking and boot with no problem.

Cheers.

Phi-Phong Nguyen: I tried your solution but got error "cannot get exclusive access to /dev/md0" ... and I can't see why. I am beginning to think Ubuntu is a total mess if you want to use RAID with encryption.

re #71 - I should have said that the "access" arror occurs when I run update-initramfs

This bug report goes back to 2012, it is now 2016 and this bug is STILL happening in kernel 4.2.0-35??? Pleas fix this, I had this happen when upgrading kernel in Ubuntu 14.04lts and had to load 15.10 on my external to even use my computer, still cannot get into by internal drive. I figured a very cumbersome workaround out for the 15.10 external but cannot even get to that place on the internal...there I just get a blinking cursor and it goes nowhere. This is ridiculously lame for this to be continuing for more than 4 years....

This change was made by a bot.

This is a somewhat old LP bug, but for completeness it worth mentioning here that recently some patches were merged on initramfs-tools and cryptsetup, that allow a good experience booting with LUKS-encrypted rootfs on top of a degraded RAID1 array; for details, please check: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980
(this is specially in response to comment #70, from phi-phong-nguyen).
Cheers,

Guilherme