Comment 13 for bug 577239

Well, I had to "fix" this for myself today because I did an update and some linux-image stuff was removed ("no longer used") and I couldn't boot any kernel afterwards. Previously, only the 2.6.32-23 kernel gave me the error and the 2.6.32-22 kernel was OK. I set GRUB to default to .22 because I was hoping it would get fixed and I was worried about breaking things worse (encrypted LVM, UUID's, boot, GRUB etc. scare me).

I managed to boot "recovery mode" - but before this I had an "initramfs" shell and :

1) cryptsetup luksOpen /dev/sda5 sda5_crypt
2) mount /dev/mapper/vgthera--n-root /mnt/root
3) backup the /etc/crypttab file (.bak) ([1] below)
4) create a new /etc/crypttab file ([2] below)

This above might have been what allowed me to boot "recovery mode", single user and see a correct "passphrase" prompt.

[1] /etc/crypttab - From :

sda5_crypt UUID=fb...d92 none luks

[2] /etc/crypttab - To :

sda5_crypt /dev/sda5 none luks

Booted single-user "recovery mode" - and recreated the initrd for each kernel I had i.e.

mkinitramfs -u -k 2.6.32-21-generic
mkinitramfs -u -k 2.6.32-22-generic
mkinitramfs -u -k 2.6.32-23-generic

On a reboot, I get prompted for the passphrase correctly :

Unlocking the disk /dev/sda5 (sda5_crypt)
Enter passphrase :

I am happy I am back running properly - but a bit of a disaster really. Something broke 10:04 seriously for me, some update soon after the release. The average user (let alone my Mum, who I have using Ubuntu) would have been dead in the water. Even here, I was seriously considering a complete reinstall.