boot - Full disk encryption with lvm2 fails after kernel update

I am running Ubuntu 12.04 with full disk encryption.

This was implemented as per the guide here:

http://57un.wordpress.com/2013/02/01/full-disk-encryption-using-ubuntu-in-most-secure-mode-with-aes-xts-plain64/

This was working fine until the kernel was upgraded from 3.5.0-32-generic to 3.5.0-34-generic.

Now during boot, the encrypted partition fails to mount and drops into (initramfs) prompt with the following.

Gave up waiting for root device.
...
ALERT! /dev/mapper/crypt does not exist. Dropping to a shell!

The system will still boot okay when the previous kernel is selected in GRUB.

I understand that the boot process requires a different step or image to enable lvm2 to mount the encrypted root prior to booting, but am not sure where or how to troubleshoot and correct the problem.

I have tried creating a new initrd

    sudo update-initramfs -u
    update-initramfs: Generating /boot/initrd.img-3.5.0-34-generic

Extract from grub.cfg

Broken:

menuentry 'Ubuntu, with Linux 3.5.0-34-generic' --class ubuntu --class gnu-linux --class gnu --class os {
    recordfail
    gfxmode $linux_gfx_mode
    insmod gzio
    insmod part_msdos
    insmod ext2
    set root='(hd1,msdos1)'
    search --no-floppy --fs-uuid --set=root f4554fcf-eba8-4cb0-96ea-1427fff02328
    linux   /vmlinuz-3.5.0-34-generic root=/dev/mapper/crypt ro   quiet splash $vt_handoff
    initrd  /initrd.img-3.5.0-34-generic

}

Works:

menuentry 'Ubuntu, with Linux 3.5.0-32-generic' --class ubuntu --class gnu-linux --class gnu --class os {
    recordfail
    gfxmode $linux_gfx_mode
    insmod gzio
    insmod part_msdos

    insmod ext2
    set root='(hd1,msdos1)'
    search --no-floppy --fs-uuid --set=root f4554fcf-eba8-4cb0-96ea-1427fff02328
    linux   /vmlinuz-3.5.0-32-generic root=/dev/mapper/crypt ro   quiet splash $vt_handoff
    initrd  /initrd.img-3.5.0-32-generic
}

Any suggestions?

Cheers

I have discovered that spaces in my /etc/crypttab were causing the newly created initrd to fail. Even though the crypttab file appeared okay.

This was discovered after I rolled back to the working kernel and also broke it when I created a new initrd using:

sudo update-initramfs -u

I removed the unnecessary spaces from /etc/crypttab and updated the initramfs again.

All good.