I just want to say thanks for your great tutorials! They helped me a lot when setting up my new PC.

In my setup I use BTRFS inside the LVM inside the LUKS volume on an NVMe SSD and I ran into the issue reported by user Luyseyal in the comments section of the tutorial (when /boot/grub is stored on the cryptroot as well, only /boot/efi remains unencrypted). Despite of mounting individual BTRFS subvolumes within the chroot environment, GRUB paths always relate to the BTRFS filesystem root and the prefix path contains the @ somewhere, for example.

I'd like to share my solution, I came up with after some research on the issue: A script which parses the main grub.cfg (created by update-grub) and builds an EFI bootable image for crypt-mounting of the encrypted root volume to get access to the kernel and the main grub.cfg. It is similar to the one created by the grub-install command but adds the cryptmount command, an appropriate keyboard layout and fixes the prefix and root paths regarding BTRFS. Moreover, I don't know how this relates to the grub-mkstandalone command you refer to in the text. However, my script creates a single 'grubx64.efi' file as well, which can then be signed with the Secure Boot key. As Luyseyal wrote, 'GRUB_ENABLE_CRYPTODISK=y' in /etc/defaults/grub is not required with this script because the disk is opened at a very early stage during boot.

The dash-compatible shell script can be run by update-grub after the main grub.cfg was populated, it just needs to be appended to the scripts in /etc/grub.d/ with a small delay. It can be found as github gist.

Your guide on configuring UEFI Secure Boot in custom mode with my own keys together with the original M$ keys worked perfectly!

Hello 1ng0, I have read your message. I have installed my FDE solution with BTRFS filesystem a few times only, without any particular issues. So I think I will test these solutions again, trying to reproduce the error reported from you and Luyseyal. I think I will end the test within 30/11/2017. We will talk again after the test.

So, the installation seems working smoothly for me, without any particular issue.

Anyway I do not have an hardware PC with NVMe and therefore I can not test FDE+BTRFS for this configuration.

I can say that if you use a Linux distribution that adopt BTRFS with subvolumes (like Ubuntu, Mint, ecc.)
you MUST commit the command 'sudo mount -o subvol=@ /dev/mapper/mint-root /mnt' instead of
'sudo mount /dev/mapper/mint-root /mnt' as the first command of Step 4 of my tutorial.

Instead, if you use a Linux distribution that adopt BTRFS without subvolumes (like Debian) you MUST
commit the common command 'sudo mount /dev/mapper/mint-root /mnt' as the first command of Step 4
of my tutorial.

If you get the same error again my advice is updating your NVMe and/or your MOTHERBOARD firmwares and
try again.

Hello RobertoR, I have read your message. If your PC has UEFI firmware you can easily boot via USB copying your bootx64.efi (or grubx64.efi) in your USB drive under a directory named /EFI/BOOT and renaming it as bootx64.efi. At boot-up you must enter your PC UEFI firmware boot menu and select the boot-up from your /EFI/BOOT/bootx64.efi file inside your USB drive. You can find this tip as the 3rd advice in Appendix A of my tutorial at https://community.linuxmint.com/tutorial/view/2061

I have UEFI but never used the EFI/GPT setup.
But so far I can see is the EFI System Partition un-encrypted and there is a lot of space to put something there!
And me being paranoid about computer security... and not without a reason.

I don't know noting about EFI and how secure it is, but I stay with MBR so long I can.
From MBR I know that the size is only 512 bytes, and that looks for me not so much space for to put some kind of virus.
But I don't really know much about this subject, but for me MBR looks more secure.