Mint 17.X, 18.X and 19.X (but also Ubuntu) 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
linux22
Level 1
Level 1
Posts: 30
Joined: Mon Jun 08, 2015 2:41 pm

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

Post by linux22 » Sat Feb 09, 2019 7:37 am

Hello hotwolf, I have read your message. I have a few questions:

- the message you get from NUC appeared after the installation of new hardware (like a USB Hub) ?

- the message you get from NUC appeared prior or after the installation of Linux FDE ?

- is your UEFI Firmware up-to-date (have you installed the last version) or did you recently installed a new firmware version ?

Anyway you can check the following links:

https://superuser.com/questions/904004/ ... t-attempts

http://www.aslab.com/support/kb/191.html

https://www.intel.com/content/www/us/en ... 1549670358


The first one recommend to answer 'Y' entering your UEFI/BIOS firmware and then commit 'Save and Exit'.

The second one recommend to change the kernel boot command line adding the option 'reboot= acpi' or 'reboot=t' and then re-booting many time until the message disappear.

The last one is from Intel and suggest to reload the default UEFI Firmware setting. Doing so you will probably lose you UEFI Firmware Secure Boot settings.

You can test these solution and eventually re-install the Linux FDE system. My first impression is that this warning message is due to hardware and/or firmware issues. So if you don't get rid of this problem with software 'escamotages' (like these explained in the first and second links) my advice is resetting your UEFI Firmware to default setting (as recommended by Intel) and then install the latest UEFI Firmware version. If doing so the warning message remain that is the proof that the problem is most likely due to a hardware and/or firmware problem.

Please keep me informed about your progress.

Regards.

linux22

hotwolf
Level 1
Level 1
Posts: 5
Joined: Sat Feb 02, 2019 12:58 pm

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

Post by hotwolf » Wed Feb 13, 2019 7:18 pm

Hello Linux22,

thanks for all the tips.

First to answer your questions:
- the message you get from NUC appeared after the installation of new hardware (like a USB Hub) ?
I had an external DVD drive connected to my NUC, which I had used for the OS installation. I did remove at it some point later on. So the message may have come at some point after a change of hardware configuration.
- the message you get from NUC appeared prior or after the installation of Linux FDE ?
I don't remember this message showing up after the Linux FDE installation. I think it started to pop up after I tried the secure boot setup.
- is your UEFI Firmware up-to-date (have you installed the last version) or did you recently installed a new firmware version ?
I'm using version 2.2.23 of the Intel Visual BIOS, which my NUC was shipped with.

I followed your links, and the first thing I've tried was to disable the "Failsafe Watchdog" option in the BIOS (as described here https://www.intel.com/content/www/us/en ... 1549670358). And this solved the problem right away. My NUC now boots right to the FDE password entry without any prior BIOS prompt. So I didn't even need to modify the kernel boot options.

Thanks again for your great help.

Regards,
hotwolf

artrieu
Level 1
Level 1
Posts: 6
Joined: Mon Feb 25, 2019 4:50 pm

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

Post by artrieu » Thu Feb 28, 2019 9:12 pm

I'm desperately trying to install Mint 18.3 KDE on a system that already has windows 10 for dual boot.
I'd like to have a full encryption.

I did follow this guide:https://www.youtube.com/watch?v=etzJAG_H5F8 and tried it with Debian first, which worked great. I just would prefer to use Mint.
So I deleted all of that and wanted to repeat it with mint, but the manual partitioning via the wizard crashes or just doesnt let me.


The difference: in Debian you create the encrypted volume and then you manage the volume and create from that root & swap. But with mint i choose the encrypted drive and then im stuck. does someone know how this works?

thanks

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

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

Post by linux22 » Fri Mar 01, 2019 4:57 pm

Hello artrieu, I have read your message. If you are looking for a Dual Boot solution W10+Mint FDE I can suggest my tutorial
at: http://community.linuxmint.com/tutorial/view/2191 but I must warn you that it can be a bit outdated.

Anyway reading it you can learn how to manage LUKS partitions and LVM working with Mint and Ubiquity.
Remember that my solution works on PC with UEFI firmware and HDD with GPT partitioning scheme.

Please keep me informed about your progress.

Regards.

linux22

lofi
Level 1
Level 1
Posts: 4
Joined: Sun Mar 10, 2019 3:10 pm

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

Post by lofi » Sun Mar 10, 2019 4:13 pm

hi Linux22,
I have found and used your tutorial https://community.linuxmint.com/tutorial/view/2438 (EFI, GPT, encrypted /boot, secure boot) and it worked well ! Thanks! I've had no problem at all : I restarted the computer, activated secure boot, and it booted correctly! :wink:
But now I'm stuck after the first apt-get update/upgrade of the system... I read all the thread, searched the web for a solution but didn't find one.
Here are the errors I get :

Code: Select all

~$ sudo apt-get upgrade
(...)
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
5 not fully installed or removed.
(...)
Do you want to continue? [Y/n] Y
Setting up initramfs-tools (0.130ubuntu3.7) ...
update-initramfs: deferring update (trigger activated)
Setting up linux-image-4.15.0-46-generic (4.15.0-46.49) ...
Setting up linux-firmware (1.173.3) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-46-generic
run-parts: failed to exec /etc/initramfs/post-update.d//objcopy_update_hook: Exec format error
run-parts: /etc/initramfs/post-update.d//objcopy_update_hook exited with return code 1
dpkg: error processing package linux-firmware (--configure):
 installed linux-firmware package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-generic:
 linux-image-generic depends on linux-firmware; however:
  Package linux-firmware is not configured yet.

dpkg: error processing package linux-image-generic (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-generic:
 linux-generic depends on linux-image-generic (= 4.15.0.46.48); however:
  Package linux-image-generic is not configured yet.

dpkg: error processing package linux-generic (--configure):
 dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          No apport report written because the error message indicates its a followup error from a previous failure.
                                           Processing triggers for initramfs-tools (0.130ubuntu3.7) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-46-generic
run-parts: failed to exec /etc/initramfs/post-update.d//objcopy_update_hook: Exec format error
run-parts: /etc/initramfs/post-update.d//objcopy_update_hook exited with return code 1
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned error exit status 1
No apport report written because MaxReports is reached already
                                                              Processing triggers for linux-image-4.15.0-46-generic (4.15.0-46.49) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.15.0-46-generic
run-parts: failed to exec /etc/initramfs/post-update.d//objcopy_update_hook: Exec format error
run-parts: /etc/initramfs/post-update.d//objcopy_update_hook exited with return code 1
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-4.15.0-46-generic (--configure):
 installed linux-image-4.15.0-46-generic package post-installation script subprocess returned error exit status 1
No apport report written because MaxReports is reached already
                                                              Errors were encountered while processing:
 linux-firmware
 linux-image-generic
 linux-generic
 initramfs-tools
 linux-image-4.15.0-46-generic
E: Sub-process /usr/bin/dpkg returned an error code (1)
This is the first error :

Code: Select all

update-initramfs: Generating /boot/initrd.img-4.15.0-46-generic
run-parts: failed to exec /etc/initramfs/post-update.d//objcopy_update_hook: Exec format error
objcopy_update_hook is present, but it's an empty file.

second error :

Code: Select all

dpkg: error processing package linux-firmware (--configure):
 installed linux-firmware package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of linux-image-generic:
 linux-image-generic depends on linux-firmware; however:
  Package linux-firmware is not configured yet.
At first I used the Mint GUI updater, and I had unticked "install Grub" which we don't use. But then I retried the update in the terminal, I didn't know how to cherry-pick and refuse the installation of Grub. Apparently it's not the problem, but could it be?

Now for the real problem : here's what I saw online :
- You have a disk size problem : partition is full => not my case (I think)
- You have to apt-get purge, autoremove, then force install. Should I do that?

I have not rebooted since the problem, so I don't know if the failed update of initramfs (et caetera...) has made my computer unbootable or not.
Do you know what's causing the problem? What should I do?
Thanks in advance.
-- lofi.

lofi
Level 1
Level 1
Posts: 4
Joined: Sun Mar 10, 2019 3:10 pm

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

Post by lofi » Thu Mar 14, 2019 11:37 pm

ok, my bad, I created an empty objcopy_update_hook file, I put nothing in it, didn't copy/paste the example provided. Will test that and report if it works.
-- lofi

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

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

Post by linux22 » Fri Mar 15, 2019 12:20 pm

Hello lofi, I have read your message. I think you must check your objcopy_update_hook file inside directory /etc/initramfs/post-update.d and verify the syntax of all lines of code. Some days ago I have got the same error (run-parts: failed to exec /etc/initramfs/post-update.d//objcopy_update_hook) because I had mistaken the first line #! /bin/sh with #! /bin/sh".

This banal error had resulted in hours of trouble until I saw the quotation mark at the end of the line and removed it.

So try again and copy and paste the code listed in my tutorial inside your objcopy_update_hook file.

Anyway if you have enough room in your ESP directory my advice is to leave a working copy of kernel.efi inside a rescue directory and boot from it in case of troubles.

Please keep me informed about your progress.

Regards.

linux22

lofi
Level 1
Level 1
Posts: 4
Joined: Sun Mar 10, 2019 3:10 pm

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

Post by lofi » Sat Mar 16, 2019 7:53 pm

hi linux22,
thanks for your reply.
You may have had a banal error, mine was just lame!

Now with the objcopy_update_hook file, I was able to (almost?) update the kernel and restart. :D
I say "almost", because I had this (please watch the last 2 lines),

Code: Select all

(...)
Setting up linux-firmware (1.173.3) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-46-generic
Signature verification OK
Signature verification OK
update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic
Signature verification OK
Signature verification OK
(…)
Setting up linux-image-generic (4.15.0.46.48) ...
Setting up linux-generic (4.15.0.46.48) ...
Processing triggers for initramfs-tools (0.130ubuntu3.7) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-46-generic
Signature verification OK
Signature verification OK
Processing triggers for linux-image-4.15.0-46-generic (4.15.0-46.49) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.15.0-46-generic
Signature verification OK
Signature verification OK
W: APT had planned for dpkg to do more than it reported back (168 vs 178).
   Affected packages: initramfs-tools:amd64 linux-firmware:amd64 linux-image-4.15.0-46-generic:amd64
But then I did apt-get upgrade again (=> nothing to upgrade) and dpkg -s for the "affected packages" and it said "install ok installed" (btw, how could I inquire about partially successful updates? the warning must have meant something...)
Anyway, rebooting worked, so I think this is fixed!

>if you have enough room in your ESP directory my advice is to leave a working copy of kernel.efi inside a rescue directory and boot from it in case of troubles.
ok, that's what I did.

Thanks a lot!

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

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

Post by linux22 » Mon Mar 18, 2019 8:23 pm

Hello lofi, I do not know the meaning of the last 2 line you get after your upgrade, but I think you should install the updates via mintUpdate. When you run commands like apt-get upgrade you can get an incomplete satisfaction of all dependencies.

In my experiences with the FDE installation described in this tutorial I have reached a correct installation of all available updates via the standard Mint update tool:
i.e. mintUpdate.

Regards.

linux22

lofi
Level 1
Level 1
Posts: 4
Joined: Sun Mar 10, 2019 3:10 pm

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

Post by lofi » Tue Mar 19, 2019 7:57 pm

Hi linux22,
thanks for the reply,
ok I'll update through mintUpdate preferably.
No other problem so far, looking good !

thanks,
lofi

Cont
Level 1
Level 1
Posts: 1
Joined: Fri Aug 09, 2019 4:14 am

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

Post by Cont » Fri Aug 09, 2019 4:34 am

Hi all,

Thanks for this tutorial.

I'm applying it to Mint 19.1 on a PC with SSD

1) It boots correctly.
2) It asks for the password and correctly decrypts the volume creating /dev/mapper/sda_crypt

But then is fails with an error: mount: can't find /root in /etc/fstab.
I'm left in a BusyBox prompt inside the initramfs.

I should state that the SSD I'm installing on is /dev/nvme0n1 and the partitions are /dev/nvme0n1p1 and dev/nvme0n1p2
I believe I changed the corresponding commands to take this into account.

edit:
After looking over the tutorial I believe the problem probably is related to the "objcopy" command in step 4.
Particularly, I believe the part about the .cmdline=/boot/efistub/cmdline.txt is not working properly.
Is there a way to dump the corresponding entries from the kernel.efi file to see if they are correct?

edit2:
"objdump -j .cmdline -s /boot/efi/EFI/Mint/kernel.efi" shows the same data as is in the cmdline.txt file.
So it looks like that is not the problem.

- Cont

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

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

Post by linux22 » Tue Aug 13, 2019 12:02 pm

Hello Cont, I have read your message. I think you must prior try this configuration on a virtual machine and check if it works for you.

I have tested it on VirtualBox simulating a SSD NVMe as installation device and it works fine.

At this moment it is also installed on my home PC with a SSD NVMe Samsung SSD 960 PRO 512GB and it works fine and very fast !!!

If it does not work for you on VM you have probably mistaken some command, substituting the device /dev/sdaX with /dev/nvme0n1pX.

If it does work for you on VM I suggest you:

1) check you SSD with its latest firmware
2) try a new clean installation

Can you list the contents of your fstab, crypttab and cmdline.txt files ?

Please keep me informed about your progress.

PS. I have seen that my tutorial on the new Mint Community site has lost the RED color of some listed command. I have tried to fix them but the color of the characters does not works anymore. Please check all listed commands with the related screenshots.

Regards.

linux22

targus
Level 1
Level 1
Posts: 4
Joined: Thu Aug 29, 2019 3:47 pm

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

Post by targus » Sat Aug 31, 2019 2:55 pm

Hi Linux22,

First of all, I'd like to thank you for your tutorials. I've used this one https://community.linuxmint.com/tutorial/view/2061 last year. Worked perfectly on my laptop.
But a few days ago I had to reinstall my system and I found your new guide so I decided to try it: https://community.linuxmint.com/tutorial/view/2438
Sadly, I'm in the same position as Cont. The laptop boots correctly, asks for the password and correctly decrypts the volume but fails with the same fstab error and shows the initramfs terminal.

I'm using Mint 19.2 with SSD so I also changed all the corresponding commands: "sda" to nvme0n1, "sda1" to nvme0n1p1 and "sda2" to nvme0n1p2 when following the tutorial.

I've tried the original commands in Virtualbox and everything works perfectly. Successful boot and all.

Back to the problem. I have 2 cases. The 1st is booting from Mint Live. The contents of my fstab, crypttab and cmdline.txt files are the following:
mint@mint:~$ cat /mnt/etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/nvme0n1p2_crypt / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=B499-AF3A /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0

mint@mint:~$ cat /mnt/etc/crypttab
nvme0n1p2_crypt UUID=e7d1d224-3743-49d1-a888-d260dc9e9a4e none luks

mint@mint:~$ sudo cat /mnt/boot/efistub/cmdline.txt
/vmlinuz root=/dev/mapper/nvme0n1p2_crypt ro quiet splash

The 2nd is booting from Mint installed on the SSD. The contents of my fstab, crypttab and cmdline.txt files are the following:
Fstab is empty. There is no crypttab or /boot so no cmdline.txt.
https://www.flickr.com/photos/183987290@N06/48654690191

In the initramfs I can use: "mount /dev/mapper/nvme0n1p2_crypt /mnt". This contains the boot folder and the installed Mint files. As if the boot process somehow could decrypt the luks partition but couldn't proceed from there. I have a Dell 7577 laptop with the latest 1.8.0 BIOS update.

I hope you can help me solve this. Thanks.

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

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

Post by linux22 » Mon Sep 02, 2019 3:32 pm

Hello targus, I have read your message. I think your issue is similar to that exposed by Cont.

So I think I must re-schedule a new set of tests for my FDE solution with Linux Mint 19.2 on SSD NVMe.

I think I will be ready within 15 September 2019.

Can you and Cont tell me the manufacturer and model of your SSD NVMe ?

See you soon on this topic.

Regards.

linux22

targus
Level 1
Level 1
Posts: 4
Joined: Thu Aug 29, 2019 3:47 pm

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

Post by targus » Tue Sep 03, 2019 5:16 am

Hi linux22,

I ran some more tests myself: I installed Mint following your tutorial but didn't encrypt the root partition (sda2_crypt / nvme0n1p2_crypt). After rebooting I ran into the same error and the initramfs terminal. Because of this, I think the problem is related to the EFI STUBs not the disk encryption.
After another reboot, I checked the BIOS settings. I can see the SSD disk, the .efi files ("/EFI/Mint/kernel.efi" + "/EFI/Boot/Bootx64.efi") and I can add them to a new UEFI boot option. Kernel.efi to Mint#3, Bootx64.efi to Mint#4, but both options boots to the initramfs screen.

My SSD drive is a "KXG50ZNV512G NVMe Toshiba 512GB" (https://business.toshiba-memory.com/en- ... d/xg5.html). I updated it to the latest AADA4107 (06.2019) firmware but still no luck. I received this drive factory installed with my Dell Inspiron 15 7577.

Hope this helps. Cheers,
Targus

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

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

Post by linux22 » Sat Sep 07, 2019 12:55 pm

Hello targus, I have read your message. I have performed a lot of tests on my PC NUCi5SYH with NVMe Samsung SSD 960 PRO 512GB and it seems running without issues.

But I have done a search on Internet and I have seen a lot of posts reporting many problems related to NVMe PCI drives.

It seems that many motherboards and NVMe drives needs firmware updates because of bugs concerning the power management of NVMe devices. These bugs
are affecting NVMe booting for both Windows and Linux (also without FDE).

So can you check if the firmware of your PC motherboard (BIOS/UEFI firmware) is up-to-date ?

Can you test if your PC set to UEFI can install and run Windows and/or Linux Mint 19.2 with standard installation (not FDE) ?

I am continuing my tests ...

See you soon on this topic.

Regards.

linux22

targus
Level 1
Level 1
Posts: 4
Joined: Thu Aug 29, 2019 3:47 pm

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

Post by targus » Thu Sep 12, 2019 2:01 pm

Hi linux22,

sorry for the late reply, I'm busy with work and the family.
So, I checked and I don't think the problem is with any of the firmware of my devices. Last week I updated my laptop's BIOS (1.8.0) and my SSD's firmware (AADA4107 - 06.2019) to the latest available versions from the manufacturer's (Dell) homepage. My laptop is a Dell Inspiron 15 7577.

As I said before, last year I used your previous guide https://community.linuxmint.com/tutorial/view/2061 (Mint 18.X Full Disk Encryption (directory /boot included) Part 3 - PC with UEFI & HDD with GPT) to install Mint 18 with FDE to my laptop. It worked flawlessly.

Last week I had to install Windows 10 x64 too (standard install, without FDE), to update the firmware of the SSD. There were no errors running this OS.

After this, just to be sure, I installed Mint 19.2 without FDE from Mint Live the standard way. After this one (following your guide - the one I mentioned before) I installed Mint 19.2 with FDE and running it now. Both installations of Mint worked without errors.

I used UEFI with all previous OS installations.

My conclusion is Full Disk Encryption (directory /boot included) with UEFI & SSD with GPT works fine for me. I think the problem is maybe with the EFI STUBS or maybe the boot process.

I hope you can find some solution to this, and I'm not a completely lost cause.

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

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

Post by linux22 » Sun Sep 15, 2019 6:02 am

Hello targus, I have made my tests.

It seems that my solution for Linux Mint FDE with EFI STUB Loader works well on all my PCs with HDD or SSD SATA devices.

It also works on my only PC NUC6i5SYH equipped with a SSD M.2 NVMe PCIe Samsung SSD 960 PRO 512GB. In this PC it also works with Secure Boot enabled and active.

But unfortunately I must admit that I don't know why it seems stucking on some PC with NVMe PCI devices, like your and that of Cont.

I think the problem is linked to the UEFI and to the Linux kernel, with the development of the firmware and the software concerning the NVMe PCI technology.

It seems very strange that this solution works without issues on many PC equipped with HDD and SSD SATA devices and it don't works on some PC equipped with NVMe PCI devices.

I have read tons of posts that describe issues concerning NVMe PCIe devices issues related to its power management (ACPI, ASPM), BIOS modes (RAID/AHCI), ecc.

The truth seems to be that this technology is still very young, like UEFI, and it need much more experience for UEFI/BIOS and NVMe devices, for both hardware and firmware development, but also for the Linux kernel itself.

Anyway I am continuing my tests and if I will found a solutions I will post it here.

Please keep me informed about your progress.

Regards.

linux22

targus
Level 1
Level 1
Posts: 4
Joined: Thu Aug 29, 2019 3:47 pm

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

Post by targus » Sun Sep 15, 2019 7:58 am

Hi linux22,

thanks for the quick reply. This seems strange to me too, but maybe the issue is with Dell, the incompatibility of the firmware or the linux kernel. I can only guess at this point, but I look forward for any solutions and doing some tests on my own.

I hope to have a solution of any kind for this issue.

And the most important of course: Thank you for your hard work on this!

Cheers,
Targus

dobp
Level 1
Level 1
Posts: 2
Joined: Thu Sep 26, 2019 1:32 pm

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

Post by dobp » Thu Sep 26, 2019 8:30 pm

Hello,

On the basis of linux22’s tutorials linked herebelow (thanks a lot for sharing these broad overviews!) and some extra research, I was able to perform earlier this month a FDE dual boot install (Win 10/LM 19.2) including boot partition encryption, together with an encrypted data partition to easily exchange data between the two OSes (cross-access to documents, common profiles for software such as Firefox or Thunderbird, etc.).
https://community.linuxmint.com/tutorial/view/2061
https://community.linuxmint.com/tutorial/view/2191
https://community.linuxmint.com/tutorial/view/2360

Below are the steps I followed for it could help someone willing to achieve a similar thing:

Color code:
Green = to highlight a few system-defined values
Red = to highlight a few user-defined values & choices at the time they are to be defined.

Partition scheme
  • Machine = Asus Zenbook S13 UX392FN with Windows 10 Family Edition OEM
  • LMCD = Linux Mint 19.2 Cinnamon 64bits Live CD
  • SSD = nvme0n1 – 476.94 Gio
  • Windows partitions
    • nvme0n1p1
      • name = EFI system partition
      • filesystem = fat32
      • size = 260 Mio
    • nvme0n1p2
      • name = Microsoft reserved partition
      • filesystem = unknown
      • size = 16 Mio
    • nvme0n1p3
      • name = Basic data partition (or OS when decrypted)
      • filesystem = bitlocker (NTFS)
      • size = 110 Gio
  • Linux partition = nvme0n1p4
  • Data partition = nvme0n1p5
    • name = p5_crypt
    • filesystem = unknown (NTFS with Veracrypt encryption)
    • size = 256.67 Gio
Steps followed
  1. On Windows, turn off Bitlocker encryption
  2. Boot on LMCD
  3. With GParted, reduce the size of Windows OS Partition (nvme0n1p3) and create Linux (nvme0n1p4) and Data (nvme0n1p5) partitions of desired sizes.
  4. Code: Select all

    sudo xed /lib/partman/check.d/07crypto_check_mountpoints
  5. Remove the last nine rows. So we disable the check that inibith Ubiquity from installing the distribution when the /boot partition reside inside an encrypted device. Then save the file and exit.
  6. Fill Linux partition with zeros (optional, security recommendation). Be patient it may take 10-20mn:

    Code: Select all

     sudo dd if=/dev/zero of=/dev/nvme0n1p4 status=progress
  7. Code: Select all

    sudo parted /dev/nvme0n1 unit MiB print
    (optional, just to check that partition list is as expected)
  8. For an iteration number of 1500:

    Code: Select all

    sudo cryptsetup -v --type luks --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 1500 --use-random --verify-passphrase luksFormat /dev/nvme0n1p4
  9. Answer:YES (capital letters required)
  10. Code: Select all

    sudo cryptsetup luksOpen /dev/nvme0n1p4 p4_crypt
  11. Enter LUKS password
  12. Code: Select all

    sudo pvcreate /dev/mapper/p4_crypt
  13. Code: Select all

    sudo vgcreate mint /dev/mapper/p4_crypt
  14. For a 4 Gio swap partition named swap:

    Code: Select all

    sudo lvcreate -L 4G mint -n swap
  15. For a 5 Gio home partition named home:

    Code: Select all

    sudo lvcreate -L 5G mint -n home
  16. For the remaining space on nvme0n1p4 to be used for the root partition named root

    Code: Select all

    sudo lvcreate -l +100%FREE mint -n root
  17. Code: Select all

    sh -c 'ubiquity -b gtk_ui'&
  18. Pursue installation with Ubiquity (check third party software box, “Something Else”, define home and root ext4 mountpoints as well as swap mountpoint, time zone preference) and at the end, choose to « Continue Testing » to remain on LMCD session.
  19. Code: Select all

    sudo mount /dev/mapper/mint-root /mnt
  20. Code: Select all

    sudo mount --bind /dev /mnt/dev
  21. Code: Select all

    sudo mount --bind /dev/pts /mnt/dev/pts
  22. Code: Select all

    sudo mount --bind /sys /mnt/sys
  23. Code: Select all

    sudo mount --bind /proc /mnt/proc
  24. Code: Select all

    sudo mount --bind /run /mnt/run
  25. Code: Select all

    sudo mount /dev/nvme0n1p1 /mnt/boot/efi
  26. Code: Select all

    sudo chroot /mnt apt-get update
  27. Code: Select all

    sudo chroot /mnt apt-get -y install grub-efi
  28. Create the directory /mnt/etc/keys where the LUKS keyfile will be put

    Code: Select all

    sudo mkdir /mnt/etc/keys
  29. Create LUKS keyfile named p4_crypt.key in directory /mnt/etc/keys/

    Code: Select all

    sudo dd bs=512 count=4 if=/dev/random iflag=fullblock of=/mnt/etc/keys/p4_crypt.key status=progress
    (be patient, it takes about 20mn with an Intel i7 CPU)
  30. Code: Select all

    sudo cryptsetup luksAddKey /dev/nvme0n1p4 /mnt/etc/keys/p4_crypt.key
  31. Code: Select all

    sudo sed -i.bak 's/#CRYPTSETUP=/CRYPTSETUP=y/' /mnt/etc/cryptsetup-initramfs/conf-hook
  32. Code: Select all

    echo "KEYFILE_PATTERN=\"/etc/keys/*.key\"" | sudo tee -a /mnt/etc/cryptsetup-initramfs/conf-hook
  33. Code: Select all

    echo "UMASK=0077" | sudo tee -a /mnt/etc/initramfs-tools/initramfs.conf
  34. Code: Select all

    sudo truncate -s 0 /mnt/etc/crypttab
  35. Code: Select all

    sudo blkid
    It is important to make sure that nvme0n1p4 has actually a UUID tag defined. Continuing the process without a UUID tag defined would lead to a boot error, crypttab not being able to identify the partition to decrypt to allow the boot process. An alternative which I understood as arguably less robust is to simply use as identifyer /dev/nvme0n1p4. Choose next command accordingly – UUID version was chosen here.
    • If UUID:

      Code: Select all

      echo "p4_crypt UUID=`sudo blkid -s UUID -o value /dev/nvme0n1p4` /etc/keys/p4_crypt.key luks" | sudo tee -a /mnt/etc/crypttab
    • OR if no UUID:

      Code: Select all

       echo "p4_crypt /dev/nvme0n1p4 /etc/keys/p4_crypt.key luks" | sudo tee -a /mnt/etc/crypttab
  36. Code: Select all

    sudo chmod -R g-rwx,o-rwx /mnt/boot
  37. Code: Select all

    sudo chmod -R g-rwx,o-rwx /mnt/etc/keys
  38. Code: Select all

    sudo chroot /mnt locale-gen --purge --no-archive
  39. Code: Select all

    sudo chroot /mnt update-initramfs -u
  40. Code: Select all

    sudo xed /mnt/etc/default/grub
  41. Modify the file so that it contains the following lines. Then save it and close it.

    Code: Select all

    GRUB_DEFAULT=0
    #GRUB_HIDDEN_TIMEOUT=0
    GRUB_HIDDEN_TIMEOUT_QUIET=true
    GRUB_TIMEOUT=10
    GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
    GRUB_ENABLE_CRYPTODISK=y
    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash cryptdevice=/dev/nvme0n1p4:p4_crypt"
    GRUB_CMDLINE_LINUX=""
  42. Code: Select all

    sudo chroot /mnt update-grub
  43. Code: Select all

    sudo chroot /mnt grub-mkconfig -o /boot/grub/grub.cfg
  44. Code: Select all

    sudo chroot /mnt grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Mint --boot-directory=/boot --modules="all_video boot btrfs cat chain configfile crypto cryptodisk disk diskfilter echo efifwsetup efinet ext2 fat font gettext gcry_arcfour gcry_blowfish gcry_camellia gcry_cast5 gcry_crc gcry_des gcry_dsa gcry_idea gcry_md4 gcry_md5 gcry_rfc2268 gcry_rijndael gcry_rmd160 gcry_rsa gcry_seed gcry_serpent gcry_sha1 gcry_sha256 gcry_sha512 gcry_tiger gcry_twofish gcry_whirlpool gfxmenu gfxterm gfxterm_background gzio halt hfsplus iso9660 jpeg keystatus loadenv loopback linux linuxefi lsefi lsefimmap lsefisystab lssal luks lvm mdraid09 mdraid1x memdisk minicmd normal part_apple part_msdos part_gpt password_pbkdf2 png raid5rec raid6rec reboot search search_fs_uuid search_fs_file search_label sleep squash4 test true verify video zfs zfscrypt zfsinfo" –recheck
  45. Code: Select all

    sudo rm -r /mnt/boot/efi/EFI/ubuntu
  46. Code: Select all

    sudo umount /mnt/boot/efi /mnt/proc /mnt/dev/pts /mnt/dev /mnt/sys /mnt/run /mnt
  47. reboot the computer and boot on the Linux partition
  48. install Veracrypt and create a NTFS Veracrypt-encrypted data partition out of nvme0n1p5. For this set-up it was decided to leave the password field empty and to generate a random keyfile (p5_crypt.key) which would serve as unique decryption key. It would be stored on both Windows Bitlocker-encrypted partition and Linux LUKS-encrypted partition (/etc/keys/) to enable automatic decryption at boot without entering additional password (i.e. trust in Linux Mint, Windows 10, LUKS and Bitlocker as well as in their associated passwords to protect sufficiently the data partition).
  49. To do so, create a new volume with Veracrypt GUI leaving all options to default until the “Volume Password” screen where password field should be left blank and the only box ticked should be “Use keyfiles”.
  50. Click on the “Keyfiles” button. Add a custom keyfile or generate a random one with “Generate Random Keyfiles” button and name it p5_crypt.key. Save this keyfile in the mint user folder (/home/mint/) folder AND on a safe backup place (external drive, flash key, etc.) then enter the following command in the terminal to copy it to the /etc/keys/ folder:

    Code: Select all

    sudo cp ~/ p5_crypt.key /etc/keys/p5_crypt.key
  51. Code: Select all

    sudo blkid
    It is important to make sure that nvme0n1p5 has actually a UUID tag defined. Continuing the process without a UUID tag defined would lead to an error at partition mounting (or even boot error?), crypttab not being able to identify the partition to decrypt to allow the boot process. An alternative which I understood as arguably less robust is to simply use as identifyer /dev/nvme0n1p5. Choose next command accordingly – /dev/nvme0n1p4 was chosen here.
    • If UUID:

      Code: Select all

      echo "p5_crypt UUID=`sudo blkid -s UUID -o value /dev/nvme0n1p5` /dev/null tcrypt-veracrypt,tcrypt-keyfile=/etc/keys/p5_crypt.key,noauto,x-systemd.automount" | sudo tee -a /mnt/etc/crypttab
    • OR if no UUID:

      Code: Select all

      echo "p5_vcrypt /dev/nvme0n1p5 /dev/null tcrypt-veracrypt,tcrypt-keyfile=/etc/keys/p5_crypt.key,noauto,x-systemd.automount" | sudo tee -a /mnt/etc/crypttab
  52. reboot and boot on Windows
  53. Create a folder (C:\Users\UserAccount\Keyfiles for instance) to put data partition's keyfile (copy it from the backup storage used above) on Windows Partition: open command line tool (Run cmd) and enter

    Code: Select all

    mkdir C:\Users\UserAccount\Keyfiles
  54. Install Veracrypt
  55. Open Task Scheduler (Run “taskschd.msc »)
  56. Action => Create a task
    • In General tab, add task name and description (MountDataPartition, Silently mount Veracrypt-encrypted data partition at session logon) and change “Configure for” option to “Windows 10”.
    • In Triggers tab, add a new trigger with “Begin the task” option set “At log on” and to the correct specific user
    • In Action tab, add an action, pasting in Program/script textbox:

      Code: Select all

      C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
      and in “Add arguments (optional)” textbox:

      Code: Select all

      -noninteractive -windowstyle hidden -command "&amp; \"C:\Program Files\VeraCrypt\VeraCrypt.exe\" /volume \Device\Harddisk0\Partition5 /letter A /mountoption label=DATA /keyfile \"C:\Users\UserAccount\Keyfiles\p5_crypt.key\" /tryemptypass /nowaitdlg /quit | out-null; stop-process -name explorer -force"
      The latter command should be customised with actual Veracrypt installation path (C:\Program Files\VeraCrypt\), actual partition path (\Device\Harddisk0\Partition5), the partition letter you want to grant (A), the label you want to grant (DATA), and actual path to the keyfile previously created (C:\Users\UserAccount\Keyfiles\p5_crypt.key).
    • In Conditions tab, uncheck all boxes.
    • In Parameters tab, uncheck all boxes but the penultimate, i.e. “If the running task does not end when requested […]”.
  57. Turn on Bitlocker
  58. Reboot on Linux and then on Windows to make sure Veracrypt partition is accessible on both sides. I did not understand why, but in this process when turning on Bitlocker at first, and rebooting on Linux, Linux was not able to auto-mount Veracrypt partition correctly anymore. However, rebooting on Windows and turning Bitlocker off and on once more solved the issue.
  59. Eventually, apply the method 1 of Apprendix A of following linux22’s tutorial https://community.linuxmint.com/tutorial/view/2360 to enable Secure Boot. Note: During my tests, I installed above FDE Dual Boot set-up with Secure-Boot disabled (and a different BIOS interface with same/similar options) and it worked.

    Edit1: One improvement to bring may be on the Windows side to change permission of p5_crypt.key, so that it could be read/write only by System/root. The associated task would then likely have to be granted higher privileges to run successfully. Not tested.
Last edited by dobp on Fri Sep 27, 2019 10:35 am, edited 8 times in total.

Post Reply

Return to “Tutorials”