You’re totally right, I’m not planning to use it with LVM.
I was just curious whether this could be the reason it didn’t work for @Dino-Fossil.
So, results!
I followed the tutorial by @davidde and the advice by @Chrysostomus to make a fresh installation on my laptop. That seems to have helped now, boot time is improved since the long unlock time is gone.
Maybe that could be added as an alternative configuration to the tutorial?
Anyway, many thanks to both of you!
I only wrote an LVM on LUKS tutorial because (mostly clueless) people were always asking for it. On my current machine I only encrypted the home partition with simple LUKS (LUKS2 actually). I could have encrypted the whole disk with simple LUKS as well.
You’re right, it would be best to add that to the tutorial.
If I had thought of using a swapfile instead of a partition, I probably wouldn’t have bothered with LVM.
But as it stands, I probably won’t reinstall my entire system for a minor boot time speedup either. So for now, I’ll just make a small edit to the start of my tutorial add a comment with Chrysostomus’s instructions. (Can’t seem to find the edit button for my own tutorial).
I’m probably still gonna do some research on rEFInd, and maybe on grub 2.06 and /boot encryption. Maybe I’ll get a sudden drive to reinstall anyway and update the tutorial accordingly. 
Your tutorial was excellent, and appreciated either way!
But will probably go plain LUKS too on next install. 
There are several excellent Guides by @linux-aarhus how to install an encrypted system with CLI only:
I followed it but used weaker but lighter encryption options from here: dm-crypt/Device encryption - ArchWiki I mean 256 instead of 512 and 2000 instead of 5000.
But I used --type luks2 option even though I didn’t need the additional feature, but maybe it is more future proof regarding support and compatibility.
Great info, thanks a lot. Will definitely be checking those out.
However, in manjaro-architect there is also an option to modify the parameters of the cypher.
Well, whether the total speedup is worth a reinstall is definitely debatable, I guess… 
One thing to note is that I didn’t use the automatic hibernation option. If I’m not mistaken, it works slightly differently with a swapfile and I was too lazy to bother with finding out how to fix it. I’ve not used it recently and there’s always the possibility to activate it later, isn’t there?
I would expect so. I did use the option, but it did not work anyway.
I documented how I fixed it in my tutorial.
Yes, and it works better if you use it in installed system.
Caveat emptor, it is years since I wrote it and haven’t tested it a long while. If have valuable data on the system, have some backups before trying hibernator.
Hey all. I recently added a secondary encrypted drive with a keyfile to automatically decrypt/mount at boot, and have some more questions:
-
The
fsckfield in/etc/fstab: Archwiki says it should be 1 for root, and either 2 or 0 for other partitions. But it is 0 for all partitions on my system, including root, meaning it will also be skipped by fsck. Is there a reason for that, or should I change it back to 1 for root? -
If I open Gnome Disks, go to the secondary encrypted device, and click
Edit Encryption Options, I get a window that by default contains an encryption passphrase, for which I can simply check an option toShow passphrase. Note this is not my chosen passphrase, but a really long excerpt from the keyfile. Still, isn’t this a security flaw in Gnome Disks? After all, anyone could just copy that while the running system is left unattended. I agree that is not ‘supposed’ to happen, but it still doesn’t feel right; it just shouldn’t show it in the first place.
Yes, fsck is done by a separate systemd service instead of the initramfs hook.
Good to know.
Any idea about that Gnome Disks thing?
A keyfile should reside in an encrypted partition, otherwise it is insecure.
The correct way is to enter the passphrase for an encrypted root, then it gets decrypted and the user doesn’t need to enter the password for an encrypted home or other because it is done by a keyfile.
Exactly, that is how things are set up. The keyfile is in the encrypted root partition. But obviously when I run Gnome Disks, the root is decrypted already …
Seems more like a bug in Gnome Disks to me.
Edit: Apparently, I’m not the only one who noticed this:
Hard to imagine a bug like that. Could also be a confusing feature.
See the reddit post above. I’m not sure this is actually exploitable though. I don’t know much about this Gnome keyring.
But if you’re curious, it should be easy to reproduce by just adding a secondary encrypted drive (e.g. flash drive), and adding a keyfile to it. Then you could judge for yourselves if Gnome Disks is exposing anything it shouldn’t.
I think I wasn’t very clear. I’m not doubting that what you say is happening. I just think that this behavior might have been intended by gnome-disks designers instead of it being accident.
Gnome keyring is encrypted storage for passwords and secrets. It is usually decrypted when you log in.
Yeah, that’s what I figured, and I hear you; probably nothing to worry about.
But I still feel it’s a strange choice to have the passphrase there by default, without any involvement of the user.
Thanks for the replies btw.