You are not logged in.
Hi, obligatory "this is my first post so sorry if I'm an idiot!" I'm familiar with Arch, I've been using it for about 6 years, but Linux at the low level is still mostly voodoo magic to me.
I got a new laptop, and I've been working on setting up encryption with suspend-to-disk (hibernate) support. I feel like I'm about 70% of the way there, but I'm pretty unclear how the sd-encrypt mkinitcpio hook interacts with /etc/crypttab.
My understanding so far is based on primarily these three sections from the dm-crypt wiki pages: (1) (2) (3)
I was inclined to avoid LVM, because I'm not concerned with flexible partition management, so it just seemed like a superfluous step. My thinking was, I should just be able to (A) encrypt my root partition with a password, (B) encrypt my swap partition with a key file stored in the decrypted root filesystem, e.g. a file called /etc/swapkey containing an arbitrary string, then (C) set up my kernel boot parameters and/or /etc/crypttab to automatically decrypt the swap partition after decrypting and mounting the root partition.
I got (A) and (B) working fine, but now I'm questioning whether (C) is actually possible the way I'm imagining.
I went with using the sd-encrypt hook because my ultimate goal is to decrypt two separate partitions at boot, which according to the wiki (I can't seem to find the paragraph that mentioned this) is better suited to sd-encrypt than encrypt
So I modified my /etc/mkinitcpio.conf as per wiki (without sd-vconsole because I just use US keymap):
HOOKS=(base systemd autodetect keyboard modconf block sd-encrypt filesystems fsck)I'm unclear whether I need to add the resume hook too, but I haven't even gotten to the hibernation part so I'll figure that out later.
Let's call the encrypted root partition UUID "ROOT-UUIID" and the encrypted swap partition "SWAP-UUID". I made this systemd-boot entry:
title "Arch Linux"
linux /vmlinuz-linux
initrd /amd-ucode.img
initrd /initramfs-linux.img
options rd.luks.name=ROOT-UUID=cryptroot root=/dev/mapper/cryptroot rd.luks.name=SWAP-UUID=cryptswap rd.luks.key=SWAP-UUID=/etc/swapkey rd.luks.options=SWAP-UUID=swap,cipher=aes-cbc-essiv:sha256,size=256 resume=/dev/mapper/cryptswap rwI didn't put anything in /etc/crypttab because of this sentence in (3):
When using the systemd-based initramfs with the sd-encrypt mkinitcpio hook, simply specify additional rd.luks kernel parameters to unlock the swap partition.
With this, the root part seems to work fine and I'm even able to get all the way into my desktop environment, but the swap partition doesn't get decrypted and never mounts, I get the "A start job is running for /dev/disk/by-uuid/<UUID corresponding to /dev/mapper/cryptswap> for 90 seconds before systemd gives up and starts the display manager anyway.
My suspicion for why this might be happening is that maybe the /etc/swapkey isn't available yet when it's time to decrypt the swap partition. But I dunno, this is a bit over my head.
So in conclusion:
1) Is it possible to use a key file in this way to auto-decrypt a swap partition at boot when the key file is itself stored in my root partition, which must be decrypted with a password, and the two partitions are both physical volumes?
2) If this is possible, do you have any examples or can you see obvious places I goofed?
3) Again if it is possible, what info should I pull for troubleshooting?
4) If it's not possible, is my only option then to set up LVM with the root and swap? I know swapfiles are a thing but my understanding is you can't hibernate to them. (You can, I think I was mis-remembering a detail about certain filesystems not playing nicely with swapfiles)
The laptop is a Swift 3 (SF314-42) which has the AMD Ryzen 4700U (integrated graphics) and a Samsung NVMe SSD. I'm sure y'all will want more information than that, so just say the word!
Last edited by ThirteenPeeps (2020-08-17 01:30:56)
Offline
I was inclined to avoid LVM, because I'm not concerned with flexible partition management, so it just seemed like a superfluous step.
I had similar thoughts but soon realised that doing this manually is much harder, and also much more esoteric, less documented.
In other words, there's a reason for having LVM.
This is what I used.
Last edited by ondoho (2020-08-16 11:42:35)
Offline
Fair enough, I'll just rework what I have to use LVM then. Thanks for the reply!
Offline
UPDATE: Instead of using LVM I actually looked deeper into the use of swapfiles, and I went with that instead.
Since my root filesystem is ext4, which supports swapfiles, I was able to follow this guide to setup a swapfile and use it to hibernate. The method still worked even though I'm just using systemd-boot and not GRUB. I was even able to successfully resize my encrypted root partition to encompass the now-deleted swap partition, so as to not waste that space.
So, the swapfile ended up being the much easier solution for me than either LVM (which would require me to clone whole disk to re-make the partitions) or the separate physical volumes. I think the reason I didn't try it from the start was that, on my first install on this laptop I tried the F2FS filesystem and ran into issues with its still-young support for swapfiles. So in my head that was just not an option. Silly me!
Interestingly, even though hibernate now works perfectly fine, normal suspend is still busted. The system never actually enters the S3 state. This is apparently a known problem with these new Swift 3's, so I do look forward to someone finding a solution for that. Anyway, that's not related to this topic.
Offline