Sorry for the noobish question, but the thing that confuses me, is how to mount the efi partition to /boot.
When I set up the system, I need to mount the efi partition to /boot/efi, since when I use /boot here, I can’t boot the system.
You’re welcome.
I wouldn’t know how similar it is to the graphical installer, since I haven’t used it before. 
I just picked Manjaro Architect because of the extra control, and not having to burn new images for future OS installs.
What exactly do you mean with slow unlock? When I enter my password, it takes 2 seconds or so. Is that slow to you?
I believe everything I did, is right there in the tutorial. Check all options again where you did something different to make sure that wasn’t the cause. Or maybe the VMs are just slower than on-metal installs. But I’m probably the wrong person to ask for more detailed advice, since this is literally my first Manjaro install.
Good luck though! Really hope it works out for you.
2s would be fine and more in line with what I see on my old laptop using Linux Mint + FDE (which didn’t even have a CPU with AES instructions).
On my new one with Manjaro it’s more like 5s+ until the message “Slot 0 opened” appears and then again 5-10s until the splash screen comes up.
So in total I seem to lose about 15s on unlocking alone, maybe a bit more (haven’t measured it yet).
But of course it’s possible that the VM is contributing here, I guess?
No it’s not overkill 
Completely normal for me 
That doesn’t sound unreasonably slow to me, especially on a laptop and in a VM (I’m on desktop without VM). But of course, you should decide what you are comfortable with.
Also, it might be a good idea to go with @Chrysostomus advice of not using LVM. I didn’t even consider it because I’ve never used a swap file before, and was set on a large swap partition for hibernation. But I understand that these days, hibernation might as well be done with a swap file, so it would be possible to ditch LVM altogether. Ah well, might do that next time! 
Dunno about the suggestion to mount efi partition to /boot instead of /boot/efi, would like some clarification about that too.
The benefit is that then the encrypted volume needs to be decrypted only once per boot, and it is done by initramfs, not grub. Grub sucks at decryption.
The downside is that it is very bad for multibooting linux distros, because you don’t want to share /boot directory between distros. But if you single boot or only dual boot with windows, it is fine.
And is that literally everything it involves? Simply changing the UEFI boot partition mountpoint to /boot instead of /boot/efi, no further tweaks necessary to make it bootable?
The 15+ s unlock time is unfortunately on my laptop directly, not in a VM.
But not with your tutorial, I used the graphic installer. The end result seems to be relatively close, however, with the big difference that you used a swap partition.
I did try to mount the bootloader to /boot in the VM (by choosing that as the mountpoint instead of /boot/efi during installation), but the result was a non-booting system.So obviously I was being too naive there.
That would probably still be ok to me. But then again, I generally just suspend, and reboot like twice a year.
I do hope this part gets clarified.
@Chrysostomus Are we missing something here?
This is only if you are just installing a new system. On already installed system, migrating the /boot partition requires much more steps.
But, on new installation in manjaro-architect:
- automatic partitioning
- create LUKS container in the bigger volume
- mount the luks container to /. Choose ext4 or xfs if you want to use a swapfile.
- for swap, choose swap file
- for extra mounts, don’t choose anything.
- for efi mount point, choose /boot and the smaller automatically created partition
Then just install normally. This setup is also compatible with bootloaders other than grub.
2 Likes
Ok, thanks, I can try that in Manajro archtitect again tonight.
But as I said, using /boot instead of /boot/efi in the graphical installer didn’t result in a booting system.
Actually the installer will even give a warning that this might happen.
Gotcha. I’ll be trying that on next install!
Just for completeness sake; is there any reason this would not work with LVM? Or does that have no impact whatsoever?
It does work with lvm, no problem. But why would you want to use lvm in this case? It carries a performance penalty, so what are you getting in exchange to it?
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.