HOWTO - GPT/UEFI install with full disk encryption: BTRFSonLUKS with separate root, home and pkg subvolumes; hibernation with a swapfile; auto-snapshots with easy system rollback (GUI); boot into snapshots

Thank you for the quick reply, I haven’t had chance to try it out but I’m about to. What if sda is for my root partition and I want to use sdb for /home? should I mount it as /home or @home? I don’t mind if I use EXT4 or BTRFS on my home partition to be honest.

Try to get it running “as-is” first. Once you’ve set it up that way you can always replace and/or delete the btrfs @home subvolume by changing the /home mount in your fstab later on.
But unless you really need to re-use/mount a existing home partition or device I’d advise against doing this.

Thanks, I already mounted it as /home in order to avoid confusion and I have to say that, after following your guide, my system is running beautifully and I don’t even notice the slower read/write speeds that I had previously.

Thank you so much for all of your help :+1: :+1: :+1: :+1: :+1: :+1: :+1:

p.s. I’m another Manjaro user that has been looking to jump ship for a while, the latest issues with the team was the last straw. I love the EOS community and now that I can get it running properly (thanks to you), I wouldn’t look back.


Currently i have used the copy and paste version of your set up on 2 nvme drives and an ssd on the same system. So i have 3 different desktops of EOS booting with Refind and your setup. I had to modify rEFInd to boot from the grubx64.efi instead of the vmlinuz image which i would normally do. It’s all working great. One of my other computers messed up with the grub update and had triple entries in it so i wiped it out and also put this setup on it with dual boot Windows 10 not using rEFInd on that one currently just grub.

I want to also try the BTRFS set up without encryption but i don’t understand completely your instructions.
#5 btrfsonluks=/dev/sda2

What if it is nvme drives? Doesn’t matter? On the setups i did before two were nvme and one an ssd and i just copied and pasted your instructions.

Also #6

I’m not getting that?


fs_uuid=`sudo blkid -o device | grep luks` &&


fs_uuid=`sudo blkid -o device | grep sda2` &&

Okay change what the copy and paste sections has?

.delete (do not run) …  (What does this mean?

Delete these lines?

fs_uuid=`sudo blkid -o device -l -t TYPE=crypto_LUKS` &&
fs_uuid=`sudo blkid -o value -s UUID $fs_uuid` &&
sudo sed -i "s/parent_device_uuid\" : \"/parent_device_uuid\" : \"$fs_uuid/" /etc/timeshift.json &&

You will have to manually enter your root device. Could also be /dev/nvme0n1p2 for instance.

Just what it says…

  • change “grep luks” to “grep sda2” or “grep nvme0n1p2” in the script under step #06
  • do not execute the three mentioned lines

Okay Thanks. So was i supposed to change anything in the copy and paste setup when i installed? Because two drives were nvme and one is ssd but i never changed anything. It all seems to be working?

No, the copy&paste script doesn’t care what type of storage you have.

I was just asked how to setup this without encryption. The proposed quick solution needs you to manually change the root device. Could of course also be automated.

1 Like

Hi guys

Sorry to resurrect this issue but I have installed using the above steps (without the swapfile, hibernation and luks) and noticed something strange when I did a lsblk:

sda      8:0    0 111.8G  0 disk 
├─sda1   8:1    0   500M  0 part /boot/efi
└─sda2   8:2    0 111.3G  0 part /run/timeshift/backup
sdb      8:16   0 894.3G  0 disk 
├─sdb1   8:17   0 892.3G  0 part /var/cache/pacman/pkg
└─sdb2   8:18   0   1.9G  0 part [SWAP]

My root partition is on sda2 and sdb1 is mounted as /home but they show as /run/timeshift/backup and /var/cache/pacman/pkg respectively.

Is this correct, as surely sda2 should show as / or @ and sdb1 should show as /home?

lsblk lists volumes but can only list one mount point per volume, so it shows only one of the subvolumes. What is the output of df?

As @csteinforth stated this is a lsblk limitation. No need to worry, all is good.

Just check the actual mountpoints with
findmnt -nt btrfs

[Edit] If you want to also list non-btrfs filesystems and additional size info, try something like this
findmnt -D -t vfat,btrfs,ext4

1 Like

Thanks guys - it all seems to be fine. I was just confused by the mountpoints


:+1: for findmnt

1 Like

I was using Arch and decided to go to EndeavourOS for a new install on a recent laptop. I had choose to follow your quick tutorial for an encrypted system with BTRFS and automatic snapshots. Very easy ! I am pleased with the results. Thank you !

1 Like

A while back you asked me about dual boot and rEFInd using the BTRFSonLuks. So i have been using it for a while and i actually had triple boot with BTRFSonLUKS on 3 separate drives with rEFInd. I have since installed it without encryption on two drives still using rEFInd. It works well! What i like about it is grub doesn’t add any entries for the other drives so it boots up with rEFInd and then you select the OS or desktop and then it either has to be decrypted or not and then the grub menu comes up and you enter your password to log in. I am using the grubx64.efi to boot instead of the vmlinuz-linux image that i would normally use with rEFInd because of grub being intertwined in the Btrfs setup with snaps and timeshift. I like it.

Edit: So i still have triple boot but only one is encrypted.


Hi guys

Just a quick question - has anyone found the encrypted method to be slower? Just asking because I am intending to do a new install as above but wanted to know if it slows the system down.

It is only slower when it has to decrypt the disc which is why i decided to go with unencrypted as i don’t really need that feature.

Thanks - I’ll just stick to the unencrypted version too I think

Disk encryption will lead to a mostly very small yet measurable performance decrease since the computer needs to perform an additional step during disk access. However, the bottle neck on a system with fairly modern specs will almost always be the disk itself and not the processing power required for encryption or decryption.

With a fairly modern system you most probably will not be able to tell the difference without running some benchmarks!

But you can test this yourself: run …
cryptsetup benchmark

With the default “aes-xts” cipher, you’re usually good even on entry level / mobile systems, as long as the CPU supports AES-NI. That should make the encryption fast enough to be unnoticable, even for SSD storage.

An example:
Let’s assume a standard SSD can read sequential data at a speed of about 550 megabytes per second (MBps) and write it at 520 MBps. In contrast, a fast HDD may carry out sequential reads and writes at just 125MBps.
If cryptsetup benchmark for example now delivers something like 1690 MiB/s for encryption and 1717 MiB/s for decryption the full disk encryption will not slow down the reading or writing of data because your disk is only able to handle about a third or less of that data even when unencrypted.


There are good reasons to do this. Choosing not to encrypt for fear of a notably less performant system is usually not one of them! (Because most of the time it’s simply not true in real life situations)

1 Like

I agree but in fairness most of my data is on a separate internal drive which I have labelled /DATA and create symlinks to so if anything, that’s the drive I should encrypt.

1 Like