Closed refi64 closed 5 years ago
Thanks for your collaboration and reporting the issue. :+1:
Here's a couple of threads reporting what we have faced on Manjaro development branches. https://forum.manjaro.org/t/testing-update-2019-02-14-kernels-systemd-browsers-calamares-firmware-plasma5-kde-framework/75655/26 https://forum.manjaro.org/t/encrypted-home-inaccessible-with-systemd-241/75711/10
We ended up finding the workaround (removing the reference to /crypto_keyfile.bin) here. https://forum.manjaro.org/t/unstable-update-2019-02-22-systemd-cryptsetup-go-python-might-break-encrypted-systems-with-luks/76767/11
I also noticed the reference to /crypto_keyfile.bin in Namib GNU/Linux, an obscure distro (or more an Arch installer perhaps) which also use Calamares as its installer. https://forum.manjaro.org/t/unstable-update-2019-02-22-systemd-cryptsetup-go-python-might-break-encrypted-systems-with-luks/76767/17
Also I noticed some timeout issues when we use cryptsetup v2.1.0 in Manjaro. Therefore I had to revert to v2.0.6 for now to get it working, plus I've to revert a commit. Also we have to find a solution to fix running systems on our end, as adding that commit will break existing installations of Manjaro.
@philmmanjaro @kirbyfan64
The /boot luks problems should be fixed now by reverting one commit https://github.com/calamares/calamares/commit/e50c2bcb44b57a77751326a6f598621ac3055311
cryptsetup v2.1.0 should be build with --with-default-luks-format=LUKS1 to work on compat setups. ( See https://github.com/calamares/calamares/issues/1099 )
The other part is systemd issue which we cannot fix.
Based on Arch Wiki, these steps are needed to create it:
# dd bs=512 count=4 if=/dev/random of=/crypto_keyfile.bin iflag=fullblock
# chmod 000 /crypto_keyfile.bin
# chmod 600 /boot/initramfs-linux*
# cryptsetup luksAddKey /dev/sdX# /crypto_keyfile.bin
This was "fixed" by the commit mentioned by @abucodonosor (which reverts something else). The other issues are outside of Calamares, so I'm going to close this one. I do remain interested in the encryption things in general: PRs welcome.
crypto_keyfile.bin is always used for the crypttab password field, but it is only generated if the root device uses LUKS.
This has led to https://github.com/systemd/systemd/issues/11723, where a change in systemd 241 has unintentionally caused an invalid key file to cause a boot error rather than being ignored and treated as a single failed password attempt. Regardless of that issue, writing a non-existent file to the crypttab isn't a good thing!
The fix would be to either use
-
as the password field of a key file is not generated or to always generate a key file.