/usr/share/initramfs-toos/hooks/cryptroot does not honour the CRYPTSETUP variable

> The problem is that update-initramfs does not put /sbin/cryptsetup
> into initramfs. My root filesystem is unencrypted but I mount an
> encrypted partition during boot, so I need cryptsetup in initramfs.

Why do you think you need cryptsetup in the initramfs for mounting an encrypted filesystem that isn't the root filesystem? This is meant to be handled via /etc/init/cryptdisks-udev.conf, with no involvement of the initramfs.

On 12/02/2013 04:04 AM, Steve Langasek wrote:
>> The problem is that update-initramfs does not put /sbin/cryptsetup
>> into initramfs. My root filesystem is unencrypted but I mount an
>> encrypted partition during boot, so I need cryptsetup in initramfs.

> Why do you think you need cryptsetup in the initramfs for mounting an
> encrypted filesystem that isn't the root filesystem? This is meant to
> be handled via /etc/init/cryptdisks-udev.conf, with no involvement of
> the initramfs.

Admitted. I might be doing something wrong. To be more clear,
My /etc/fstab looks like this and all is on an USB stick.

UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / ext4
noatime,errors=remount-ro 0
    1
/dev/mapper/vg-lvdata /lvdata ext4 noatime,errors=remount-ro 0 2
/dev/mapper/vg-lvswap none swap sw 0 0
tmpfs /tmp tmpfs rw 0 0
tmpfs /media tmpfs rw 0 0
tmpfs /mnt tmpfs rw 0 0
/lvdata/var /var bind defaults,bind 0 0
/lvdata/root /root bind defaults,bind 0 0
/lvdata/home /home bind defaults,bind 0 0
/lvdata/opt /opt bind defaults,bind 0 0
/lvdata/etc/cups /etc/cups bind defaults,bind 0 0
/lvdata/zvol /zvol bind defaults,bind 0 0

Of course, I'd like to setup my system so that nothing is written to the
usb stick at boot time. I have the impression, that works with Raring. I
don't even have /etc/crypttab there.

But apart from my (perhaps wrong) configuration, the problem remains:
/usr/share/initramfs-toos/hooks/cryptroot in Saucy does not honour the
CRYPTSETUP=y setting in /etc/initramfs-tools/initramfs.conf. It should
force putting /sbin/cryptsetup into initramfs (as far as I understand
the meaning of that variable). That's the bug. My setup is actually
irrelevant. I only added it as a hint.

Ralf

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

Indeed we recently found out that putting CRYPTSETUP=y in the /etc/initramfs-tools/initramfs.conf is not sufficient to include cryptsetup into the initramfs.

However e.g.:
$ cat ./usr/share/initramfs-tools/conf-hooks.d/forcecryptsetup
export CRYPTSETUP=y

Does include cryptsetup into the initramfs. I'll work on resolving this issue.

I can confirm the fix in comment #4 worked for me as well.

I had a 12.04.5 system running with Full Disk Encryption (from initial install). After upgrading to 14.04.1 and rebooting, the luks encrypted root file system could not be unlocked. The system would prompt for the password, but then throw a bunch of errors, with the most notable "/sbin/cryptsetup not found".

I then booted off the 12.05.5 install media (14.04.1 would could not properly unlock the luks encrypted file systems) and created the /usr/share/initramfs-tools/conf-hooks.d/forcecryptsetup as described in comment #4, updated the initrd, and rebooted. I was then prompted for the password, which was accepted and opened the root file system.

All is good again after upgrading!

I upgraded from 14.04 LTS to 16.04 LTS, and _after_ installing the next new kernel (4.4.0-22) the new kernel's initrd.img did not have cryptsetup anymore. 4.4.0-21 still had so I have continued to boot to it for a week now.

I tried a lot of things before finding this bug, but it seems comment #4 finally adds a megabyte or so to the 22's initrd. I still don't get a password prompt when booting to 22, and the 22 initrd.gz is still 400kB smaller than 21's.

For possible interest, I'm attaching two diffs:
- Diff from 21 to 22+forcecryptsetup - note that I've removed btrfs package meanwhile since I was getting "Scanning for btrfs filesystems" messages on boot which I thought might be a problem
- Diff from 22 to 22+forcecryptsetup

The diffs are from ls -1R outputs of the initrd contents, with manual sedding get cleaner diffs, but including (don't let it confuse) all version numbers were changed to say "4.4.0-21".

Notably while the forcecryptsetup included all the needed kernel modules and the cryptsetup tool, I'm still missing conf/conf.d/cryptroot on 22 which I guess is the remaining blocker for working. Maybe text.so too?

Ok I have booting working now. I can almost describe the steps...

I followed http://blog.nguyenvq.com/blog/2014/07/25/upgrading-ubuntu-12-04-to-14-04-breaks-encrypted-lvm/ and created /etc/initramfs-tools/conf.d/cryptroot (did not exist before creating). That solved the issue. However, I finally noticed my /etc/fstab's / entry pointed to the UUID of /dev/sda4, not the UUID of /dev/mapper/xyz. After changing the UUID to /dev/mapper/xyz, neither /etc/initramfs-tools/conf.d/cryptroot or the forcecryptsetup were needed anymore.

To make the story complete, right after I had really upgraded from 14.04 to 16.04, my system did not boot with any kernel, new or old, and I needed to boot from USB and install cryptsetup + mount manually. I tinkered around /etc/default/grub and /etc/fstab until I got it booting... I was not using UUIDs in 14.04, that much I remember, and I think I did not have the cryptdevice option in grub.

It's so complex topic I really have no good ideas what should be made more robust. Obviously something broke (for me) during upgrade, and my fix to that broke further initrd creations.

I'm not sure why changing the entry in /etc/fstab would resolve the issue of the missing passphrase query in the first place. /etc/fstab is only read after successfully decrypting your encrypted file system and any change in there will not be reflected at boot.

AFAICS this bug is still relevant as the check is still in place and putting CRYPTSETUP=y in
/etc/initramfs-tools/initramfs.conf is still not enough.

I try to boot a btrfs on a RAID1 (dm) inside an encrypted partition. For some reason, update-initramfs is not able to determine the "canonical device of /dev/md0" which in turn probably makes it not include the cryptsetup binary.

The hack mentioned in comment #4 seems to work.

for me, hack from comment #4 works only partially.
i indeed got cryptsetup binary included to initramfs, but the damn thing still does not ask me LUKS password, so everytime i have to do type cryptsetup & vgchange commands in initramfs shell to be able to resume normal boot.

If you run into this make sure when you are mounting and repairing in a chroot via `cryptsetup open /dev/whatever mapper-name` that the `mapper-name` matches what you have in your `/etc/crypttab`. You can get this by booting from the LiveCD and manually mounting the encrypted partition.

Or try something like the script below which was tested on 18.04, but may work for earlier versions as hopefully the APIs haven't changed much for things like critical boot path.

https://gist.github.com/dragon788/e777ba64d373210e4f6306ad40ee0e80