Control: reassign -1 cryptsetup-initramfs
X-Debbugs-CC: Pásztor János <pasztor.ja...@it.ppke.hu>
I having doubts that your issue is due to a bug because of this:
> ...
> root@asgard ~ # more /etc/initramfs-tools/hooks/crypttab-fix.sh
> #!/bin/sh
> cp /etc/crypttab "${DESTDIR}/cryptroot/crypttab"
> exit 0
> ...
Why did you add this? Did you notice that during update-initramfs
runs no cryptroot/crypttab file was placed into the initramfs? If yes
then you should have investigated why not because it was indicative
that something in your setup was broken enough for
/usr/share/initramfs-tools/hooks/cryptroot to properly generate its
part of the initramfs. FYI: That script does not simply copy
/etc/crypttab, but parses it and generates a sanitized version because
it relies on /scripts/local-block/lvm2 which does not work with UUIDs
(see #902943). Sure enough your crypttab contains UUID= entries:
> -- /etc/crypttab
> 1Tnvme UUID=1cb8215e-4bb9-479b-ad06-36ae1b3fc957 none luks,discard
> 4Tsolid UUID=2c3dd479-7f24-4aa9-8850-ee5e970e7d32 none luks
Adding some kind of warning in a comment to the generated
cryptroot/crypttab to not manually edit or overwrite it sure would
have been helpful. Or if that's not possible at least a brief README
file in the same directory. One could even lint for this during
initramfs generation and emit a warning, e.g. with:
grep -e '\(etc\|cryptroot\)/crypttab' /etc/initramfs-tools/hooks/*
Regards.
