Fix for having to enter password twice when booting with encrypted swap partition

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 .
After removing /etc/dracut.conf.d/calamares-luks.conf, running 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 /etc/crypttab and 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.

Regards Daniel

P.S. I noticed that hibernation was working fine when selecting “Swap (no Hibernate)” during installation.

4 Likes

Yes that works fine I would also be happy if that would be included.

PS: we have discussed :slight_smile:

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

ls /etc/dracut.conf.d
eos-defaults.conf  ostree.conf  resume.conf
1 Like

yes, same here :frowning:
Would love to have a permanent solution for this.

@Tealk @exp
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.

Deleting /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 /etc/kernel/cmdline.

1 Like

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.

During boot /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 cat /etc/crypttab.

yes but:

cat /etc/crypttab
# /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
1 Like

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.
journalctl -b

1 Like

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.