Someone recently asked in the matrix chat why they had to enter the password twice during boot. They were using systemd-boot, full disk encryption and a swap partition. We came to the conclusion that it’s because of having an encrypted swap partition. I found this article showing me that crypttab might not be needed https://swsnr.de/2021/03/27/arch-linux-with-luks-and-almost-no-configuration.html .
reinstall-kernels and rebooting, the password was only requested once but both partitions were mounted, swap was working and checked with
swapon --show and
free -h. This eliminates the need for
crypto_keyfile.bin (My understanding is that
crypto_keyfile.bin is still needed for grub).
Maybe this improvement can be implemented in a future update.
P.S. I noticed that hibernation was working fine when selecting “Swap (no Hibernate)” during installation.
Yes that works fine I would also be happy if that would be included.
PS: we have discussed
Since the kernel update I have to enter the password again 2 times, seems to be no long term solution.
But the file no longer exists
eos-defaults.conf ostree.conf resume.conf
yes, same here
Would love to have a permanent solution for this.
It seems that
/etc/crypttab still gets added to the initramfs even after
/etc/dracut.conf.d/calamares-luks.conf has been deleted. Not sure why or why a system update has caused this behaviour.
/etc/crypttab and performing
reinstall-kernels reverts the behaviour to only needing the password once.
/etc/crypttab isn’t needed because it only contains instructions to mount our partitions with
crypto_keyfile.bin. This is a remnant of endeavouros using grub with encrypted boot. We are telling the system which partitions to unlock in the kernel commandline which is defined in
Interestingly, I did not have this after the last kernel update, I had to enter the password only once.
Maybe we could create a pacman hook for it? Could this be a good idea?
I don’t think that will be necessary. With deleting
/etc/crypttab this fix should be permanent.
At least I believe so and we should wait and see.
somehow it works now again although /etc/crypttab is still present.
/etc/crypttab gets automatically generated when missing. Then it only contains commented out lines (so it’s effectively empty). You can print the files contents with
# /etc/crypttab: mappings for encrypted partitions.
# Each mapped device will be created in /dev/mapper, so your /etc/fstab
# should use the /dev/mapper/<name> paths for encrypted devices.
# See crypttab(5) for the supported syntax.
# NOTE: You need not list your root (/) partition here, but it must be set up
# beforehand by the initramfs (/etc/mkinitcpio.conf). The same applies
# to encrypted swap, which should be set up with mkinitcpio-openswap
# for resume support.
# <name> <device> <password> <options>
luks-c25f3862-54cc-4289-af20-d4e72ec2d53f UUID=c25f3862-54cc-4289-af20-d4e72ec2d53f /crypto_keyfile.bin luks
luks-cb415483-2790-4fba-839b-41768cd78e0c UUID=cb415483-2790-4fba-839b-41768cd78e0c /crypto_keyfile.bin luks
You’re right. That is confusing. I don’t know why you only had to enter your password once. Probably something else at play that I don’t understand.
Maybe you’ll find a difference in your boot log between a boot when you have to enter it once and when you have to enter it twice.
I also have the crypttab present including 2 luks lines.
Now again in nearly all cases i only needed to enter the password once.
I yet could not find any pattern but i might have a look at the log if i again have to enter it twice.