I've created an encrypted root partition using LUKS which contains a few LVM partitions. I can't boot and get the following output on startup:

Begin mounting root file system ... Begin: Running /scripts/local-top ... /scripts/local-top/cryptroot: line 1: /sbin/cryptsetup: not found

It still prompts me for the password:

Unlocking the disk /dev/sda5 (macbookcrypt)
Enter passphrase: *******************************
cryptsetup: cryptesetup failed, bad password or options?
/scripts/local-top/cryptroot: line 1: /sbin/cryptsetup: not found

Yet it fails every time.

My boot command-line is:

vmlinuz-3.13.0-37 generic ro root=/dev/mapper/macbooklvm-root cryptopts=target=macbookcrypt,source=/dev/sda5,lvm=macbooklvm recovery initrd=\initrd.img-3.13.0-37-generic

I've added "dm_crypt" to /etc/modules and then did update-initramfs to regenerate with dm_crypt included. I'm on Ubuntu 14.04 by the way.

In the initramfs shell, I can't seem to locate cryptsetup anywhere:

(initramfs) cat /proc/modules | grep crypt
dm_crypt 23177 0 - Live 0xffffffffa0006000
(initramfs) find / -iname "cryptsetup"
(initramfs)

It appears that the dm_crypt module is loaded', so that's good, but cryptsetup isn't present here. How do I install it to my Linux boot? Does it need to be included in initrd, vmlinuz, or System files somehow? I'm new to this hackery.

share|improve this question
up vote 3 down vote accepted

Evidently, I didn't create a /etc/crypttab file. Create one, then update-initramfs -u to fix the issue.

share|improve this answer
    
Wow thanks for posting your solution, I didn't know it was that simple and for duplicating usbs with encrypted partitions I was doing it the hard way: extracting initrd manually, editing etc/conf/conf.d/cryptroot, changing the uuid for the right one and recreating againt init with gzip and cpio. – YoMismo Jan 12 '15 at 8:39
    
Read the source, Luke. After isolating the script that either copies cryptsetup (or doesn't), I saw that it checks for the presence of /etc/crypttab as part of its logic. From there, all downhill ☺ – Naftuli Kay Jan 12 '15 at 9:18
    
Now I know why I did it the hard way. If you create an encrypted swap partition and want it to have password so that you can resume from hybernation, update-initramfs doesn't update the swap partition even if it is defined in /etc/crypttab so you have to extract init, create an entry in etc/conf.d/cryptroot with the swap partition and recreate the init. (At least that is my experience in Debian) – YoMismo Jan 13 '15 at 10:06

On Ubuntu 14.04 I was missing the xts kernel module from

/etc/initramfs-tools/modules

Other modules that you might miss could be:

raid1
raid456
aes-x86_64
sha512-ssse3
xts
dm-mod
dm-crypt

I found the root cause out by adding to the grub command line (linux) this option:

break=mount

that forces drop to busybox. After that I was able to copy by USB stick ( from another machine) these files on the ramfs:

mkdir /boot
mount /dev/sdc1 /boot
cp cryptsetup /sbin/cryptsetup
cp libcryptsetup.so.4.0.0 /lib/libcryptsetup.so.4
cp libpopt.so.0.0.0 /lib/libpopt.so.0
cp libgcrypt.so.11.7.0 /lib/libgcrypt.so.11
cp libgpg-error.so.0.8.0 /lib/libgpg-error.so.0
/boot/cryptsetup luksOpen /dev/md10 root

(I have also root on software raid, no LVM) that gave the error of missing module.

A good idea that came in my mind afterwards would be to copy the above cryptsetup files on the /boot partition in advance, so that you don't have to mess around with an USB stick. Another way is to decompress the initramfs image once (in advance) in e.g. /boot/tmp:

gzip -d < ../initrd.img-3.13.0-62-generic | cpio --extract --verbose --make-directories --no-absolute-filenames

so you have all the workings libs and cryptsetup available, even if your update-initramfs -k all -c has failed after some kernel update.

share|improve this answer

Another problem that gave me the above error message, but after investigation (as specified above) I got this more specific error message:

 cryptsetup luksOpen /dev/md10 cryptroot

 device-mapper: table: 252:0: crypt: unknown target type
 ioctl: error adding target to table

Solution: Check that /etc/crypttab root device name (cryptroot) matches /etc/initramfs-tools/conf.d/mdadm settings. I had "cryptroot" in other and "root" in other, after syncing the target device names, boot worked like a dream!

After fixing the settings run

update-initramfs -c -k all
share|improve this answer

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.