8

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

7
  • 1
    I don't know stretch, but under jessie you definitely need a good crypttab in place before initramfs generation.
    – Ferenc Wágner
    Mar 4, 2016 at 10:43
  • 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.
    – Robert Cutajar
    Mar 4, 2016 at 15:16
  • 1
    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.
    – Ferenc Wágner
    Mar 5, 2016 at 21:20
  • @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.
    – Robert Cutajar
    Mar 7, 2016 at 19:49
  • 1
    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.
    – Ferenc Wágner
    Mar 8, 2016 at 10:23

2 Answers 2

Reset to default
8

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.

4
  • Do not forget to install cryptsetup if you are bootstrapping.
    – ceremcem
    Dec 24, 2019 at 3:52
  • 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? :-)
    – atb00ker
    Dec 20, 2020 at 15:15
  • 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."
    – Andrew Gallagher
    Dec 21, 2020 at 16:45
  • 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.
    – Andrew Gallagher
    Dec 21, 2020 at 16:49
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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .