Apparently from Linux 4.10 onwards, the ecb module became a dependency of xts[1]. I am running a custom kernel in which both XTS and ECB are built as modules (kernel config attached for 4.14.3). However, ECB does not appear in the initrd, causing the system to be unable to mount the encrypted root. It's unclear to me how this dependency should be picked up. The only mention of ecb in lsmod (output attached for 4.14.3 kernel) is as follows: ecb 16384 2 Attempting to boot a locally built kernel from 4.10 sources onwards (most recently tried 4.14.3) will fail to be able to mount encrypted root unless I add ecb to /etc/initramfs-tool/modules. I am using make-kpkg for all kernel builds. This issue does not appear to occur with Debian's own kernels, perhaps because something else is pulling in the ecb dependency when building the initrd. [1] https://www.spinics.net/lists/stable/msg160678.html
Control: retitle -1 xts module should depend on ecb
Control: reassign -1 src:linux 4.10.1-1
Control: affects -1 cryptsetup
The issue was reported against cryptsetup's upstream BTS earlier this
year: https://gitlab.com/cryptsetup/cryptsetup/issues/319 .
The xts module needs to explicitly depend on ecb. AFAICT Milan's patch
[0] has been applied to 4.14.0-1-amd64, but modinfo(8) still doesn't
list ecb in its dependencies, so the initramfs hook file doesn't pull it
automatically.
In the meantime, a workaround is to manually add ‘ecb’ to
/etc/initramfs-tools/modules. Doesn't seem needed on systems with
AES-NI support, though; there I don't have ecb in the initrd, and
$ grep '^driver\s*:\s*xts' /proc/crypto
driver : xts-aes-aesni
while on a system without AES-NI support:
$ grep '^driver\s*:\s*xts' /proc/crypto
driver : xts(ecb(aes-asm))
Version: 4.11-1~exp1 In commit 12cb3a1c4184f891d965d1f39f8cfcc9ef617647 that dependency was added to the upstream kernel and part of 4.11-rc1 and the first upload to the Debian archive was with kernel version 4.11-1~exp1, so close it with that version.