[ENCRYPTION] Full Disk Encryption with BTRFS

[Chopstick]

Hi All,
I just installed the pre-release version of Focal on a 2014 T540 Thinkpad with SSD drive. As with my previous install, I wanted to have full disk encryption (using Luks LVM). I did a clean install and opted to do the partition and Luks setup manually, with an encrypted main/root partition and a encrypted /boot partition as well, and using BTRFS for both.
Essentially I followed this guide but had to improvise a little:
https://help.ubuntu.com/community/Fu...ion_Howto_2019
The steps described worked perfectly until I got to the "Post-Installation Steps", where things did not go smoothly and I had to fix the chroot environment myself (see below). One other thing: for some reason in this guide all /dev/sda partitions have a 'p' before the number , as in /dev/sdap5 --- I omitted that, since mine don't have that and I have never seen that.
The result is a mostly working system, but unfortunately the decryption of the main Luks volume at the initial stage does not work automatically. Here the system drops into the Busy Box (initramfs) shell and I have to manually decrypt and mount the root partition. This only requires two commands:
[#] cryptsetup luksOpen /dev/sda5 sda5_crypt [/#]
[#] vgchange -ay [/#]
(and Ctrl-D to exit the shell)
However, I find this a bit unsatisfying and I would like to get this fixed.

Deviation from guide during post-installation setup:
Essentially the chroot environment did not work after the commands listed, because several essential system utilities were missing (including bash...). So I actually had to 'mount --rbind' all system folders in the original root, not only the ones listed; in addition, /etc required special treatment, since we need to write to that folder: therefore we need to mount--rbind the /etc/apt/ folder and the /etc/resolv.conf file separately (inside a newly created /etc folder in the new chroot environment). Also keep in mind that you need to create all the folders (and one file) that serve as mount points for mount --rbind. But other than fixing the chroot environment in this manner, I followed the instructions and all commands execute successfully.

I don't really understand why the main Luks partition does not decrypt automatically; however, I don't really understand how that is supposed to work in the first place... it appears that the (also encrypted) boot partition does decrypt and mount automatically: I get a password prompt for that, enter it, then a KDE splash screen, but then the initramfs shell, so the second (main) partition does not decrypt. I did check that all of the permissions and file contents in the /etc/luks folder and friends are correct (as per the commands shown in the guide).

I'm not sure if having BTRFS on both, the /boot and the main/root partition would have any impact; the guide suggests to use ext4. (In fact, the initial motivation to do this myself, and the reason I searched for this guide, was that the default full disk encryption offered by the installer will use ext4 and you can't change that.)

Any ideas would be greatly appreciated! I am afraid I don't understand this boot loader and crypt-setup stuff well enough to really see what is going on here.
Thanks!

[oshunluvr]

There might be a hint in here:

https://flypenguin.de/2018/01/20/arc...n-efi-systems/

[Chopstick]

Somehow my initial response got lost... here it is again.

This post deals with a setup where the boot partition is not encrypted. In my setup it is, so that the only non-encrypted is /boot/efi, so I am not sure how this would apply. There are also some steps creating subvolumens, where I don't really follow. I guess this has something to do with BTRFS and maybe this is where I went wrong, but I am not sure.

One thing I have noticed when I was looking around within the initramfs shell is that running cat on crypttab and fstab does not return anything, suggesting that the files are empty. I guess that would result in this kind of behaviour (requiring manual decrypt).

[Don B. Cilly]

But you should not use btrfs for the /boot/efi partition. It should be a very small one, some 100MB - or less, mine uses 6.4 MB, but nowadays... and it should be formatted to FAT32.
Also, I can't possibly think of a reason to encrypt it. It only has the boot loader stuff in it. Not exactly "sensitive information".
In the link above: "NOTE: Do not follow the above link down to “prepare the boot partition”, cause they use ext2 and we need FAT32 for EFI boot partitions. Just don’t.

Now, your /boot directory - which only has kernels in it anyway, is not a partition, it will be in the "/" filesystem, and therefore encrypted... I guess.
I also guess the boot loader will take care of decrypting it. I don't know anything about encrypted partitions. What I know is that boot/efi should be FAT32, and it can't be encrypted.

[Chopstick]

Apologies, if this was not clear. I have four partitions as described by the guide above:
* /dev/sda1 BTRFS (encrypted) 768MB
This is the boot partition and should be mounted at /boot, although for some reason GParted does not show this partition mounted anywhere...
* /dev/sda2 2MB, this is a a bios_grub partition
I am not sure where/how it is mounted or what the filesystem is...
* /dev/sda3 FAT16 128MB
This is the /boot/efi partition Don B. Cilly is referring to, and it is *not* encrypted; GParted does not show a mount point...
* /dev/sda5 BTRFS 232GB
This is the main partition, which contains an encrypted LVM with the root and swap partition (16GB)

My understanding is that the regular installation process only encrypts the root file system, but leaves /boot *and* /boot/efi unencrypted; however, /boot can be encrypted, whereas /boot/efi will never be encrypted (and needs a FAT file system). It was also my assumption that having the /boot partition decrypted at startup would be the difficult part, and the main/root filesystem should be no issue... however, it seems that in my case decrypting the /boot partition works, while decrypting the main filesystem requires manual intervention... obviously there is something I am missing...

[Don B. Cilly]

It's still rather confusing (to me).
What does
df -h
say?

[Chopstick]

Here is the df -h output... I do not understand this fully myself...

udev 7.8G 0 7.8G 0% /dev
tmpfs 1.6G 3.3M 1.6G 1% /run
/dev/mapper/vgkubuntu-root 217G 132G 85G 61% /
tmpfs 7.8G 297M 7.5G 4% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup
/dev/loop0 153M 153M 0 100% /snap/chromium/1077
/dev/loop1 28M 28M 0 100% /snap/snapd/6953
/dev/loop2 49M 49M 0 100% /snap/gtk-common-themes/1474
/dev/loop3 261M 261M 0 100% /snap/kde-frameworks-5-core18/32
/dev/loop4 55M 55M 0 100% /snap/core18/1705
/dev/loop5 155M 155M 0 100% /snap/chromium/1089
/dev/loop6 3.3M 3.3M 0 100% /snap/krdc/33
/dev/mapper/vgkubuntu-root 217G 132G 85G 61% /home
tmpfs 1.6G 20K 1.6G 1% /run/user/1000

I have no idea what these loop/snap things are... I guess they have something to do with Chromium... (probably not relevant...)

[Don B. Cilly]

Yes, discard udev, tmpfs and - (especially ;·) /dev/loop stuff, which (last) are snaps.
Just for comparison, my df -h is

~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            3.9G     0  3.9G   0% /dev
tmpfs           793M  1.3M  792M   1% /run
/dev/sdc2        96G   33G   58G  37% /
tmpfs           3.9G   75M  3.8G   2% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/sdc4      1008M  6.8M 1001M   1% /boot/efi
tmpfs           793M   20K  793M   1% /run/user/1000

So, after that you have
/dev/mapper/vgkubuntu-root 217G 132G 85G 61% /
and
/dev/mapper/vgkubuntu-root 217G 132G 85G 61% /home

What's missing? The equivalent of my /dev/sdc4 1008M 6.8M 1001M 1% /boot/efi
and you don't seem to have anything mounted at /boot.

So... I would... check with
sudo fdisk -l
See if you do have a small partition, and it has EFI System as "Type".
If you do, try to set its mount point to /boot/efi with a partition manager - from another system - live USB or installed OS.

[EDIT] I don't have any /dev/loops because I purged snap.
--------- I notice - now - that your / and /home partitions have the same size, used space and everything. That's a bit strange, isn't it?

[Don B. Cilly]

Actually... cilly me... maybe you could try and set it to mount there with /etc/fstab. Just
sudo blkid
find the UUID of the partition...

[Chopstick]

This is my /etc/fstab:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/vgkubuntu-root /               btrfs   defaults,subvol=@ 0       1
/dev/mapper/LUKS_BOOT /boot           btrfs   defaults        0       2
# /boot/efi was on /dev/sda3 during installation
UUID=43CA-BB66  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/vgkubuntu-root /home           btrfs   defaults,subvol=@home 0       2
/dev/mapper/vgkubuntu-swap none            swap    sw              0       0

The UUID=43CA-BB66 device at /boot/efi is in fact /dev/sda3, which is the EFS partition (set with this property in the KDE Partition Manager); LUKS_BOOT is /dev/sda1.
So, I think that is essentially what you are suggesting, right?

I should add though, that I have absolutely no idea what all these flags after the filesystem mean...

[Don B. Cilly]

I really feel like "Dylan's Mr. Jones" here.*
So you tell your fstab to mount /dev/mapper/LUKS_BOOT on /boot
and you tell your fstab to mount /dev/sda3 on /boot/efi
and your df says they ain't mounted nowhere in the neighborhood.
(in a Tennessee accent ;·)

Not only that, but your / and /home partitions have the same size, used space and everything. (in an East London accent :·).

I hope someone who actually understands disks, partitions, encryption and boots will shed some light on this :·/

*And you know something is happening here
But ya' don't know what it is
Do you, Mister Jones?
--- Bob Dylan - "Ballad of a Thin Man"

[EDIT] Sorry, can't resist... "boots" in East London would be "daisies" (for daisy roots :·)

[Chopstick]

I hope someone who actually understands disks, partitions, encryption and boots will shed some light on this :·/

Yes, indeed! Thanks for your effort, though!
To put this into a bit of context, I have had full disk encryption on my old system as well, and I have never been able to make sense of the output of df and some other programs when it came to encrypted partitions.