Mint 17.X and 18.X Full Disk Encryption (directory /boot included)

Write tutorials here
There are more tutorials here http://community.linuxmint.com/tutorial/welcome
Forum rules
Please don't add support questions to tutorials,start your own thread in the appropriate sub-forum instead. Before you post please read this
1ng0
Level 1
Level 1
Posts: 1
Joined: Mon Oct 16, 2017 10:54 am

Re: Mint 17.X and 18.X Full Disk Encryption (directory /boot included)

Postby 1ng0 » Mon Oct 16, 2017 11:40 am

Hello linux22,

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!

Keep up the good work and best wishes!
Ingo

linux22
Level 1
Level 1
Posts: 13
Joined: Mon Jun 08, 2015 2:41 pm

Re: Mint 17.X and 18.X Full Disk Encryption (directory /boot included)

Postby linux22 » Sun Oct 22, 2017 10:50 am

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.

Regards.

linux22

linux22
Level 1
Level 1
Posts: 13
Joined: Mon Jun 08, 2015 2:41 pm

Re: Mint 17.X and 18.X Full Disk Encryption (directory /boot included)

Postby linux22 » Sun Oct 22, 2017 11:48 am

By the way, 1ng0 and Luyseyal, did you committed 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 ?

See the note for BTRFS filesystem inside Step 4 !!!

Please keep me informed about this.

Regards.

linux22

linux22
Level 1
Level 1
Posts: 13
Joined: Mon Jun 08, 2015 2:41 pm

Re: Mint 17.X and 18.X Full Disk Encryption (directory /boot included)

Postby linux22 » Wed Nov 08, 2017 2:19 pm

Hello 1ng0, I have done my tests and the results are:

Test with HDD SATA on hardware PC UEFI: OK
Test with HDD SATA on VirtualBox 5.2.0 machine UEFI: OK
Test with HDD NVMe on hardware PC UEFI: NOT AVAILABLE
Test with HDD NVMe on VirtualBox 5.2.0 machine UEFI: OK

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.

Please keep me informed about your attempts.

Regards.

linux22


Return to “Tutorials”