You are not logged in.
Hello,
I used the following instructions to install Arch Linux with an encrypted root partition, method "LUKS on a partition" and using the sd-encrypt hooks for configuring mkinitcpio. As indicated in the wiki, I therefore use the following kernel parameters in /etc/default/grub:
rd.luks.name=device-UUID=cryptroot root=/dev/mapper/cryptrootwhere device-UUID is the UUID of the partition containing the luks encrypted system partition. This works.
Now, I would like to have an encrypted swap, that should be on another disk, and that I could use with the suspend-on-disk feature (hibernate). How to do this is explained in this wiki (Section "With suspend-to-disk support"). Unfortunately, the wiki contains detailed instructions only for the case when one uses the "encrypt" hook, but very few details for the "sd-encrypt" hook. The only information available there seem to be
When using the systemd-based initramfs with the sd-encrypt mkinitcpio hook, simply specify additional rd.luks kernel parameters to unlock the swap partition.
So, I guess that I would have to modify the kernel parameters that are indicated in /etc/default/grub as follows:
rd.luks.name=device-UUID=cryptroot root=/dev/mapper/cryptroot rd.luks.name=other-device-UUID=cryptswap resume=/dev/mapper/cryptswapwhere other-device-UUID would be the UUID of the partition containing the luks encrypted swap, and also to add to /etc/fstab the following entry:
/dev/mapper/cryptswap none swap defaults 0 0However, I am not sure if I should also do other modifications, because I do not understand well how the rd.luks parameter work. Specifically, my doubts are:
Do I also have to add the unlocking of /dev/mapper/cryptswap in /etc/crypttab?. This section of the wiki states that "The rd.luks parameters are only honored by the initrd, while the luks parameters are honored by both the main system and initrd." I do not understand what "honored" means here. Does "not being honored by the main system" mean that the luks partition will not stay open if we use rd.luks? Or does this mean that once the main system is started, it will not try to open again the encrypted luks partition? I read "man systemd-cryptsetup-generator" but this did not help me.
Does the order in which I specify the luks partitions to be opened in the kernel parameters matters? Should I put the "resume=" first?
If I use the same passphrase for both partitions, will I be asked to input it twice? "man 8 systemd-cryptsetup", item 4, seems to indicate that the password can be cached.
I could try to do this and see what happens, but I am a bit afraid to break something... Once this is solved, I think it would be a good idea to add the instructions to the wiki, because as I said, currently there are instructions only for the encrypt mkinitcpio hook and very few details for the sd-encrypt one.
Offline
So, I tried what I described, and here's what I found:
1. I did not need to add an entry to /etc/crypttab for the swap, the device is unlocked in initramfs and it is "kept" by the main system. So, I still have no idea what the difference between rd.luks.name and luks.name is. (Seems that I am not the only one)
2 and 3. I first tried to put a different password for the root partition and the swap partition, and, trying different orders for the kernel parameters, it seems that this does not matter: it to always asked me first the password for the root partition, then the password for the resume partition. This is strange because, you might think, once it has unlocked the resume partition, if it is a valid RAM image then it shouldn't need to also unlock the root partition...
I then put the same password for the two partitions and indeed, you can enter the password only once. Sometimes you can see the line where its asks a second password but then it boots anyway.
So hibernate works, but there is still a small something: when I run "systemctl hibernate", the following happens: first my screens go black for about 6 seconds, then they are turned back on but I cannot do anything for about 13 seconds (no keyboard no mouse, I guess during that time it is writing the RAM to swap), then if powers off. Is this normal behavior for hibernate?
I'll leave this one open until I can understand the difference between rd.luks and luks
Offline
i wrote a tutorial some time ago which i'm not sure if others may find useful but it does cover your case i think. have a look and see if it helps. i'm using systemd-boot instead of grub but maybe it's not too hard to adapt
https://gist.github.com/myyc/9595b520a4 … 86582f1ea1
**edit**: sorry, i read your whole thing and it seems like you have figured it out. `luks` and `rd.luks` are the same thing (i think `rd.luks` is the recommended one). my setup doesn't use crypttab so i don't really know whether that makes a big difference but you can compare notes.
Last edited by myyc (2021-05-18 13:21:39)
Offline
It takes a few minutes of time to wrap your head around but the Arch wiki explains the difference between rd.luks.* and luks.* pretty thoroughly:
https://wiki.archlinux.org/title/Dm-cry … crypt_hook
There's also this information (just above it on the same page) for adding a single bootable drive (not using rd.luks or luks):
https://wiki.archlinux.org/title/Dm-cry … crypt_hook
There's also the man entry for systemd-cryptsetup-generator:
https://man.archlinux.org/man/systemd-c … enerator.8
And it's useful reading about how it all ties in together (grub/kernel parameters):
https://wiki.archlinux.org/title/Dm-cry … parameters
Important points:
Compared to the sd-encrypt hook, the encrypt hook does not support: Unlocking multiple encrypted disks (FS#23182). Only one device can be unlocked in the initramfs.
All of the rd.luks parameters can be specified multiple times to unlock multiple LUKS encrypted volumes.
If you are using /etc/crypttab or /etc/crypttab.initramfs together with luks.* or rd.luks.* parameters, only those devices specified on the kernel command line will be activated and you will see Not creating device 'devicename' because it was not specified on the kernel command line.. This is because the luks.* or rd.luks.* parameters control which devices from the crypttab get activated. To activate all devices in /etc/crypttab do not specify any luks.* parameters and use rd.luks.*. To activate all devices in /etc/crypttab.initramfs do not specify any luks.* or rd.luks.* parameters.
Last edited by greywood (2022-06-11 03:46:48)
Offline