Manjaro Architect Full Disk Encryption?

Hello everyone, new Manjaro user here. I’m moving over from Debian, where I’ve spent the last 3 years. :wink:

For this new install, I thought I’d go with encryption, which I haven’t done before.
And since I am coming across a lot of contradictory information on how feasible FDE is with Manjaro Architect, I thought I’d ask some clarification here.

I actually already tested a Manjaro Architect install, following this great LVM on LUKS Tutorial. Everything worked out great; M-A is a really wonderful installer.

However, this tutorial leaves the boot partition unencrypted, meaning it is not really Full Disk Encryption. Because everything went so smoothly with M-A, I find myself getting greedier and wanting it all. :laughing:
I wanna ‘fix’ this last flaw in my installation, especially since I’ll be on it for years, and changing it later is only going to be more difficult/risky.

The Archwiki Grub page seems to suggest I can still encrypt the boot partition and reinstall grub on my installed system, or am I misunderstanding this? Maybe it’s easier to just redo the M-A install and put the boot partition inside LVM on LUKS? Or maybe neither of these is a good idea and I should just not bother with Full Disk Encryption at this point? I hear the next GRUB release 2.06 will provide LUKS 2 support, which will likely improve on this tricky situation … Any thoughts?

Manjaro-architect supports fde, but it results in painfully long boot time if you don’t use the special insecure encryption option in manjaro-architect to encrypt the volume.

Usually in fde the boot goes like this: you have the unencrypted efi partition and one big volume mounted to / that contains everything. On boot, grub gives you password dialog where it decrypts the partition so that it can read its own settings file and draw the boot menu. This can take about 45 seconds because grub sucks at this. Then, when you choose a boot entry, it decrypts the / partition again with the keyfile embedded in the initramfs that was stored in the encrypted / volume. This takes about 5 seconds, because kernel actually knows what it is doing.

Fde is overkill and impractical in most situations. Still supported though.

1 Like

Hm ok, thanks for confirming it’s probably overkill, since I’m not really looking forward to doing over all the tweaks and software installs of the last few days. :sweat_smile:

Actually, I already did the install twice since the first time it didn’t work properly because I didn’t boot the UEFI image. :expressionless: There are quite a few gotcha’s that aren’t mentioned in that guide that I had to find out elsewhere, so for the second install I documented everything nicely because I’ll probably want to remember it for my laptop at some point.

I feel my notes have evolved in quite a nice beginner friendly tutorial for an encrypted Manjaro Architect install on a modern (UEFI) system. I’ll probably put it on my blog whenever I get around to creating it (definitely this decade), but is there some place here I could contribute it? I’m thinking with the recent forum migration it would be really nice to have a fully up to date guide on this stuff …

1 Like


Oh yes, please do!
I’m currently struggling with the best encryption options myself (coming from the opposite site of slow FDE) and would appreciate a nice tutorial on how to set it up. Also I’m certainly not the only one, judging from some topics in the old forums.

1 Like

Great, I just put it up:

I hope it’s useful for you!

1 Like

Hey, thanks again for the tutorial.
I did some experimenting yesterday in a virtual machine before I decide to wipe my laptop.
What I noticed is that your approach seems to result in the almost the same setup as using the fully automatic approach from the graphical installer, i.e. we get one /boot/efi partition and an encrypted one for the root directory (and swap).
Speed-wise I didn’t see any difference in the VM between the two approaches when booting.
I think it’s because /boot, which according to various posts in the old forums is the reason for the slow unlock, is still in the encrypted volume.
Did I miss some step there or do anything wrong?

If you want speedier boot with fde, you can use the special less decryption option in manjaro-architect. That can cut about 30 seconds from the boot time, depending on the hardware.

But in general, for easy and fast encrypted system:

  • have 500Mb efi partition mounted to /boot
  • one big / partition in encrypted volume
  • use a swapfile instead of a swap partition
  • don’t use lvm. The only reason to use it is to have encrypted swap partition.

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. :sweat_smile:
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 :blush:
Completely normal for me :innocent:

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! :wink:

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. :sweat_smile:

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:

  1. automatic partitioning
  2. create LUKS container in the bigger volume
  3. mount the luks container to /. Choose ext4 or xfs if you want to use a swapfile.
  4. for swap, choose swap file
  5. for extra mounts, don’t choose anything.
  6. 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.


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.