I used cryptsetup + dropbear in initramfs often. The integration in Debian was sometimes “strange”, but reading the doc was enough. With stretch I found some problems; I found the solutions, too, so hope this would be useful
dropbear in initramfs will only allow login from root. The keys used to be read from /etc/initramfs-tools/root/.ssh/authorized_keys
The path was weird, and it changed to /etc/dropbear-initramfs/authorized_keys. This is great and more logical, but AFAIK undocumented and without retrocompatibility.
UUID for root partition in fstab is not supported
Yep. You’d better use /dev/mapper/cryptoroot as device path. It’s just as reliable as the UUID.
use the same mapper name on the install system and the installed system
That’s hard to explain. I was installing debian from a rescue system using debootstrap, then manually editing relevant files, then running
chroot /mnt/ update-initramfs -u -k all
Unforunately, I mounted /mnt/ using cryptsetup open /dev/sda1 root, but /mnt/etc/crypttab mentioned the same device as cryptoroot. update-initramfs doesn’t like this discrepancy.
ethernet persistent naming
I know, that’s not a bug, and that’s widely known. However, I find some edges confusing. For example, the initramfs called my interface “eth0” but on the main system it was “enp3s0”. I would have also liked to have an easy way to know what name my ethernet interface would have had with persistent naming enabled
I’m not totally sure about it because I was testing, and maybe my conclusions are wrong. However, at first boot it did not log anything. When I created /var/log/journal, log finally appeared. I think this doesn’t match the documentation, which states that creating /var/log/journal is only needed to log in journald format, not to log to /var/log/syslog or /var/log/messages