Mint 17.X, 18.X and 19 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)

Post by 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: 16
Joined: Mon Jun 08, 2015 2:41 pm

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

Post by 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: 16
Joined: Mon Jun 08, 2015 2:41 pm

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

Post by 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: 16
Joined: Mon Jun 08, 2015 2:41 pm

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

Post by 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

RobertoR
Level 1
Level 1
Posts: 16
Joined: Tue Jul 17, 2018 12:35 pm

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

Post by RobertoR » Tue Jul 17, 2018 2:35 pm

I have been using this setup for 2 years now, and the only thing I regret about it that I did not used it before!

I there also a way to setup the keyfile on a usb disk and that you need to have a password and the usb stick for to boot?

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

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

Post by linux22 » Thu Jul 19, 2018 12:45 pm

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


Regards.

linux22

RobertoR
Level 1
Level 1
Posts: 16
Joined: Tue Jul 17, 2018 12:35 pm

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

Post by RobertoR » Fri Jul 27, 2018 6:26 pm

Thanks linux22

I did not see this reply until now.

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.

User avatar
MikZ
Level 2
Level 2
Posts: 61
Joined: Sun Mar 17, 2013 7:08 pm
Contact:

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

Post by MikZ » Fri Sep 21, 2018 7:14 am

Hi @linux22! I do appreciate these guides, but I still haven't managed to get what I want, which is a multi-drive Mint 19 system (/home on its own drive) with FDE on each drive. It'd be really great if hibernate to worked in such a setup, too, since i'm tired of having to reboot everything from scratch when I swap a battery on an airliner. So I don't think _all_ of 'our concerns for an easy, standard and reliable FDE solution' are over quite yet. :wink:

I posted for help with this a few weeks ago. Perhaps you can offer me some advice? Cheers.

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

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

Post by linux22 » Tue Oct 02, 2018 1:29 pm

Hello MikZ, I have read your message. I do not see great difficulties to achieve your wishes.
You can easily configure a LUKS encrypted drive and mount it under '/home' directory at boot time, simply configuring your '/etc/crypttab' file.

Then if you really want to enable the 'hibernate' function you must correctly configure the parameters 'root' and 'resume' inside the GRUB_CMDLINE_LINUX_DEFAULT directive in your '/etc/default/grub' file and then re-enable the option in the 'power menu'.

Remember that the 'hibernate' function is disabled by default in Ubuntu (and many based/derived), probably because of the data losses occurred in the past versions.

Regards.

linux22

User avatar
MikZ
Level 2
Level 2
Posts: 61
Joined: Sun Mar 17, 2013 7:08 pm
Contact:

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

Post by MikZ » Sun Oct 07, 2018 7:06 am

Thanks, @linux22! I seem to have muddled along far enough so far; /etc/fstab and /etc/crypttab weren't as complicated as they initially looked. ☺

Thanks for the tops about hibernating; I'll give those a go soon. We're starting to drift off topic, but were the data losses you talked about anything more than sessions failing to fully restore after hibernation?

john523
Level 1
Level 1
Posts: 2
Joined: Fri Nov 30, 2018 10:45 am

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

Post by john523 » Fri Nov 30, 2018 11:08 am

Hello,

I have used BIOS and PC with GPT method and everything went fine except renaming initctl because it was not present in the /mnt/sbin/ folder. I eventually skipped that step, committed the last comand (sudo umount ...) and finished with tutorial.
What consequences will skipping renaming initctl (because I couldn't find it) have and can any future adjustments be made after completing tutorial, or will I need to start it over from scratch?

Although I was installing linux mint 19 this time (using method for Mint 17.x & 18.x), but if I remember correctly, last time that I was installing linux mint 18.x I also couldn't find initctl in its supposed folder.

(I also used Appendix A 1st recommendation if it matters)

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

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

Post by linux22 » Sat Dec 01, 2018 6:03 am

Hello john523, I have read your message. Do not worry about initctl.

This issue was present in Linux Mint 17.X only. If your installation works fine let initctl as it is.

Regards.

linux22

john523
Level 1
Level 1
Posts: 2
Joined: Fri Nov 30, 2018 10:45 am

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

Post by john523 » Sun Dec 02, 2018 3:56 pm

Thank you for your reply! It's a relief to hear everything is working as it supposed to and thank you for the tutorial.

Post Reply

Return to “Tutorials”