Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto_keyfile.bin is always listed in crypttab even if it does not exist #1096

Closed
refi64 opened this issue Feb 23, 2019 · 5 comments
Closed

crypto_keyfile.bin is always listed in crypttab even if it does not exist #1096

refi64 opened this issue Feb 23, 2019 · 5 comments

Comments

@refi64
Copy link

@refi64 refi64 commented Feb 23, 2019

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 systemd/systemd#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.

@FrogMcRibbit
Copy link

@FrogMcRibbit FrogMcRibbit commented Feb 23, 2019

Thanks for your collaboration and reporting the issue. 👍

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

@philmmanjaro
Copy link
Member

@philmmanjaro philmmanjaro commented Feb 23, 2019

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.

@abucodonosor
Copy link
Contributor

@abucodonosor abucodonosor commented Feb 24, 2019

@philmmanjaro @kirbyfan64

The /boot luks problems should be fixed now by reverting one commit e50c2bc

cryptsetup v2.1.0 should be build with --with-default-luks-format=LUKS1 to work on compat setups.
( See #1099 )

The other part is systemd issue which we cannot fix.

@philmmanjaro
Copy link
Member

@philmmanjaro philmmanjaro commented Mar 3, 2019

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
@adriaandegroot
Copy link
Contributor

@adriaandegroot adriaandegroot commented Apr 25, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants