Entering the LUKS password once on startup

General system EndeavourOS installation
1

Hey all,

I’m quite a newbie with arch Linux and EndeavourOS, but not new to Linux. So, I installed EndeavourOS about a week ago, and I turned on encryption during the installation. I used the normal online installer to pick KDE as the DE.
It surely works fine, but I have a problem with how the encryption is configured, currently, there are three partitions: an unencrypted efi partition with systemd-boot, an encrypted root partition (LUKS, password-protected) and a separate swap partition, also encrypted with LUKS, but they share the password.
Every time I boot into the system, I get prompted for a disk password twice (once for each partition).

On my last setup, I used LVM to put the root and swapfile into one LVM setup, so I only had to put the password in once.

How can I do that with my current setup? Is there a way to decrypt the swapfile automatically after decrypting the root partiton? Why is it not using lvm?

Thanks in advance,
Moon

// I don’t think they help in this case, because it’s about the installer //
Hardware information:
https://0x0.st/oRLM.bin

Boot log:
https://0x0.st/oRLj.txt

2

Even though they share the same password they are still separately encrypted and have to be decrypted separately.

That is a good solution to the problem.

I have not tested it, but I think the installer supports lvm via manual partitioning.

If you use grub instead of systemd-boot it will encrypt the additional datasets with a keyfile and then use a keyfile to unlock them. We have not yet tested this approach with systemd-boot yet.(The option to use systemd-boot was only recently added)

3

Well, the crypttab config shows that the both use the same keyfile crypto_keyfile.bin in the root dir. Shouldn’t that be on the boot partition?

4

Does that file exist?

5

yeah it does

6

If you look at the luks volumes, are they encrypted with that keyfile?

7

What do you mean by that? /etc/crypttab is configured to decrypt them (the root and the swapfile) with the specified keyfile:

# <name>               <device>                         <password> <options>
luks-51cc7362-a970-4d47-966f-7fe31e0c6f8c UUID=51cc7362-a970-4d47-966f-7fe31e0c6f8c     /crypto_keyfile.bin luks
luks-e2fca0e7-4d1c-40fc-8226-4dd8216ba095 UUID=e2fca0e7-4d1c-40fc-8226-4dd8216ba095     /crypto_keyfile.bin luks

The kernel also gets the args passed down in the systemd-boot boot entry

8

Use cryptsetup luksDump on the volume to see how many keyslots you have on those volumes.

That is probably for the root volume.

9

It’s for both, root and resume. Excerpt of the kernel args:

rw rd.luks.uuid=51cc7362-a970-4d47-966f-7fe31e0c6f8c root=/dev/mapper/luks-51cc7362-a970-4d47-966f-7fe31e0c6f8c rd.luks.uuid=e2fca0e7-4d1c-40fc-8226-4dd8216ba095 resume=/dev/mapper/luks-e2fca0e7-4d1c-40fc-8226-4dd8216ba095

Well, I got the output from cryptsetup, but I don’t know how to see that they are linked to the file. They both have two keyslots occupied.

LUKS header information for /dev/nvme1n1p2 (root partition, but the one from the swapfile basically looks the same)

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512
MK digest:      digest
MK salt:        salt
MK iterations:  320861
UUID:           51cc7362-a970-4d47-966f-7fe31e0c6f8c

Key Slot 0: ENABLED
        Iterations:             5127510
        Salt:                  salt
        Key material offset:    8
        AF stripes:             4000
Key Slot 1: ENABLED
        Iterations:             5203850
        Salt:                   salt
        Key material offset:    512
        AF stripes:             4000
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED
10

Did you convert to systemd-boot or did you choose systemd-boot in the installer?

11

I choose it as the recommended option in the installer. The old system I was talking about used grub2. I’m sure that you could repeat my experience if you would download the latest installer and choose systemd-boot + LUKS encryption.

12

If that is the case, you may have found a bug in the installer.

Those shouldn’t be created for systemd-boot. I will take a look at that.

However, fixing that won’t solve your problem, it will just remove the keyfiles and modify crypttab.

13

But how does systemd-boot decrypt LUKS partitions? I mean as far as I can see from the boot entry, I just passes the partitions down to the kernel

14

It doesn’t. The initrd decrypts them.

The issue is that the initrd doesn’t have access to the keyfile. If you add the keyfile to the keyfile to the initrd, it will work exactly like you want. However, since the initrd lives in an unencrypted space, that would basically defeat the encryption. I am not sure if there is a way around that. It would need more testing and experimentation.

I can think of two ways to deal with your situation, use lvm or switch to grub.

15

I really like systemd-boot, so I will probably keep to that. I think I understand the situation now, and I think there is no good way with dealing with it, but I really don’t want to reinstall because I set everything up so neatly. I guess there goes an evening of backing up my config files, installed packages list, etc. Thanks for the help anyway.

1 Like
16

Before you do that you might want to test it out in a VM and make sure everything works the way you want.

1 Like
17

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.