Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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

share|improve this question
add comment

1 Answer 1

up vote 1 down vote accepted

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.