Initramfs in debootstrap chroot of fully encrypted system

Question

I'm working on a script to create a fully encrypted washable system from debootstrap. It's doing some good, but the initramfs image that comes out does not pick up the cryptroot properly. After booting the image with qemu, I'm dropped to a busybox shell and I have to unlock the luks encryption manually with cryptsetup:

cryptsetup luksOpen /dev/sda1 system
/scripts/local-premount/flashback
exit

(flashback does some btrfs snapshoting magic to forget changes made on every boot)

After this, boot in qemu continues normally and I am then able to generate a good initramfs image. I copy this to the btrfs @root.base subvolume and all is well from then on.

I need help with figuring out why the cryptsetup/cryptroot part is not being picked up in the chroot environment by update-initramfs:

echo "CRYPTSETUP=y" >> /usr/share/initramfs-tools/conf-hooks.d/cryptsetup
echo "export CRYPTSETUP=y" >> /usr/share/initramfs-tools/conf-hooks.d/cryptsetup
update-initramfs -ut

I have tried many things, I write a good fstab and crypttab and even tried to explicitly set cryptdevice in grub.cfg. Refer to the specific version of the script.

Here's how I create the fstab and crypttab:

export partuuid=$(blkid $partition | sed -re 's/.*: UUID="([^"]+)".*/\1/')
export decruuid=$(blkid /dev/mapper/$decrypted | sed -re 's/.*: UUID="([^"]+)".*/\1/')
echo "Adding flashback with uuid $partuuid"
echo "system UUID=$partuuid none luks" >> "$rootmount/etc/crypttab"
echo "UUID=$decruuid / btrfs [email protected] 0 0" >> "$rootmount/etc/fstab"
echo "UUID=$decruuid /home btrfs subvol=@home 0 0" >> "$rootmount/etc/fstab"

The question in principle is: How do you generate a functioning initramfs image in an encrypted chroot of a debootstrapped debian?

Thanks a bunch

Solution 1

Using /etc/initramfs-tools/conf.d/cryptsetup is deprecated in stretch.

The new preferred method is to set "CRYPTSETUP=y" in /etc/cryptsetup-initramfs/conf-hook.

In buster and later, this configuration parameter appears to be redundant, as the default behaviour seems to be to configure cryptsetup in initramfs IFF the initramfs-cryptsetup package is installed.

Solution 2

This will always work, even with an empty crypttab:

echo 'export CRYPTSETUP=y' > /etc/initramfs-tools/conf.d/cryptsetup

Alternatively, you can add this to /etc/environment:

CRYPTSETUP=y

Comments

[Admin]

I don't know stretch, but under jessie you definitely need a good crypttab in place before initramfs generation.

[Admin]

Thanks Ferenc, I figured crypttab was important. I've updated the question with the part that generates the file. The confusing thing is that update-initramfs doesn't pick cryptroot up in chroot and yet, without any modification, it works fine once booted. I wonder if debian installer does some more magic.

[Admin]

Your setup seems reasonable, although I don't get the point of modifying /usr/share/initramfs-tools/conf-hooks.d/cryptsetup. However, you could add set -x at the beginning of /usr/share/initramfs-tools/scripts/local-top/cryptroot and get some debug info (actually, lots, so a logged serial console is recommended) after regenerating the initramfs. Appending debug to your kernel command line might also help.

[Admin]

@FerencWágner, re modifying /usr/share/initramfs-tools/conf-hooks.d/cryptsetup - pure desperation :o) or else cryptsetup would not be included in initramfs at all. I'll try your debugging tips and update if I find something curious later.

[Admin]

You'd better echo CRYPTSETUP=y >/etc/initramfs-tools/conf.d/force-cryptsetup, otherwise your modifications will be lost on upgrade. Also, try using the dm-crypt device name (/dev/mapper/system) in your fstab and the kernel root= argument.

[Admin]

Thank you @FerencWágner! I made it work on first run, but it's not fixed, just worked around. I think the cryptroot initramfs scripts do not expect/handle a loop device behind the luks container or at least that much I could guess from the debug. So I eventually found that 'cryptroot' will work better than 'system' and/or the 'cryptopts' instead of 'cryptdevice' in kernel command line params did the trick. changes here. It runs smooth and fast from a tmpfs mount.

[Admin]

@Rbjz Thank you solved my problem i was desperately trying to get my ubuntu to boot past the initramfs . I tried the following : cryptsetup luksOpen /dev/sda6 unencrypted_ubuntu mnt /dev/mapper/unencrypted_ubuntu /mnt/root exec switch_root /mnt/root /sbin/init but this didn't work. Then i saw your commands, tried them and I could finally boot again. I'm talking about the following commands: cryptsetup luksOpen /dev/sda6 system /scripts/local-premount/flashback exit

[ceremcem]

Do not forget to install cryptsetup if you are bootstrapping.

[atb00ker]

As of today, there is note in /etc/cryptsetup-initramfs/conf-hook that this setting will not be honored in the future. Since this is the first post one sees when we google for this problem, can you please update this answer to the latest method? :-)

[Harry Barsegyan]

For the benefit of other readers, this is the new text: "Add cryptsetup and its dependencies to the initramfs image, regardless of this machine configuration. By default, they're only added when a device is detected that needs to be unlocked at initramfs stage (such as root or resume devices or ones with explicit 'initramfs' flag in /etc/crypttab). Note: Honoring this setting will be deprecated in the future. Please uninstall the 'cryptsetup-initramfs' package if you don't want the cryptsetup initramfs integration."

[Harry Barsegyan]

I have no idea what the new default is, although the wording seems to indicate that cryptsetup is now configured automatically if cryptsetup-initramfs is installed. I currently have two machines running buster with encrypted disks, and neither has any configuration in /etc/initramfs-tools/conf-hook, so it certainly looks like the parameter is now redundant. I'll add a note to that effect now.