Page MenuHomeLubuntu Development

Fix EFI encryption
Closed, ResolvedPublic

Description

Use case:
Install Lubuntu on an encrypted partition with UEFI as boot mode.

Expected behaviour:
The installer (calamares) creates an encrypted LUKS container for /, an unencrypted partition for /boot and Grub is installed on the EFI-System-Partition.

Current behaviour:
The separate /boot-partition is not created.
Booting the installed system does not work, because of missing Grub modules on the EFI-System-Partition.

See the upstream issue => Calamares Issue 1083

Possible workaround (untested):
If I remember well, after installation you have to boot the live system, open the LUKS container and copy the /boot/grub/x86_64-efi folder on your EFI-System-Partition (EFI/ubuntu/x86_64-efi).
After this, Grub should find the needed Grub modules to boot the installed system.

Event Timeline

apt-ghetto triaged this task as High priority.Mar 16 2019, 12:51 PM
apt-ghetto created this task.
tsimonq2 changed the visibility from "All Users" to "Public (No Login Required)".Mar 30 2019, 2:38 PM
tsimonq2 changed the edit policy from "All Users" to "Custom Policy".
apt-ghetto updated the task description. (Show Details)Apr 4 2019, 11:35 AM

If we can get this done for the release, I'd like to do so, but if not, it needs to be fixed first thing next cycle.

My understanding from talking to cyphermox is that we have all of the GRUB modules in order. T36: Fix full disk encryption on BIOS systems is a prereq here, because without any EFI systems functioning, we can't confirm this.

In T2#416, @tsimonq2 wrote:

My understanding from talking to cyphermox is that we have all of the GRUB modules in order.

I am not sure, if this is true. As far as I understand it, the Grub modules are under /boot/grub, which is in the encrypted LUKS container. The Grub bootloader is on the EFI-System-Partition and should unlock the LUKS container to load the kernel, but cannot do it, because it does not have all the necessary modules.

As linked in T36: Fix full disk encryption on BIOS systems, we have functioning FDE on BIOS again.

Could someone test the package from -proposed on an EFI system and see if there's still the same results as before?

kc2bez added a subscriber: kc2bez.Apr 9 2019, 7:59 AM
In T2#501, @tsimonq2 wrote:

As linked in T36: Fix full disk encryption on BIOS systems, we have functioning FDE on BIOS again.
Could someone test the package from -proposed on an EFI system and see if there's still the same results as before?

This seems to work for me in a VM. PLEASE someone else confirm this, hopefully on real hardware.

I have tested this on a virtual machine (VMWare Workstation 14 Player with EFI).

Before installing:

wget http://launchpadlibrarian.net/418441015/libkpmcore7_3.3.0-5_amd64.deb
sudo apt install ./libkpmcore7_3.3.0-5_amd64.deb

During the installation I choose to erase the disk and selected the checkbox to encrypt the disk.

After installation and reboot, it works as just fine.

Where exactly is the magic, that it works now?

wxl added a subscriber: wxl.Apr 10 2019, 11:54 AM

Well if you look at the diff it's pretty obvious. They're forcing luks1:

diff -Nru kpmcore-3.3.0/debian/changelog kpmcore-3.3.0/debian/changelog
--- kpmcore-3.3.0/debian/changelog	2018-11-27 07:54:56.000000000 +0000
+++ kpmcore-3.3.0/debian/changelog	2019-04-06 10:40:05.000000000 +0000
@@ -1,3 +1,9 @@
+kpmcore (3.3.0-5) unstable; urgency=medium
+
+  * Use luks1 format only
+
+ -- Jonathan Carter <jcc@debian.org>  Sat, 06 Apr 2019 12:40:05 +0200
+
 kpmcore (3.3.0-4) unstable; urgency=medium
 
   * Version bump (no changes)
diff -Nru kpmcore-3.3.0/debian/patches/force-luks1 kpmcore-3.3.0/debian/patches/force-luks1
--- kpmcore-3.3.0/debian/patches/force-luks1	1970-01-01 00:00:00.000000000 +0000
+++ kpmcore-3.3.0/debian/patches/force-luks1	2019-04-06 10:40:05.000000000 +0000
@@ -0,0 +1,15 @@
+Description: Force luks1 for new filesystems
+
+Force luks1 since cryptsetup 2.1 defaults to luks2 which isn't well supported.
+Author: Jonathan Carter <jcc@debian.org>
+
+--- kpmcore-3.3.0.orig/src/fs/luks.cpp
++++ kpmcore-3.3.0/src/fs/luks.cpp
+@@ -125,6 +125,7 @@ bool luks::create(Report& report, const
+                                 QStringLiteral("512"),
+                                 QStringLiteral("--batch-mode"),
+                                 QStringLiteral("--force-password"),
++                                QStringLiteral("--type=luks1"),
+                                 QStringLiteral("luksFormat"),
+                                 deviceNode });
+     if (!( createCmd.start(-1) &&
diff -Nru kpmcore-3.3.0/debian/patches/series kpmcore-3.3.0/debian/patches/series
--- kpmcore-3.3.0/debian/patches/series	1970-01-01 00:00:00.000000000 +0000
+++ kpmcore-3.3.0/debian/patches/series	2019-04-06 10:40:05.000000000 +0000
@@ -0,0 +1 @@
+force-luks1

I'm absolutely sure that it was because of missing GRUB modules in the first place. cyphermox fixed that in February, but about the same time cryptsetup switched things, disguising the fix.

tsimonq2 closed this task as Resolved.Apr 10 2019, 12:58 PM
tsimonq2 claimed this task.
In T2#552, @apt-ghetto wrote:

I have tested this on a virtual machine (VMWare Workstation 14 Player with EFI).
Before installing:

wget http://launchpadlibrarian.net/418441015/libkpmcore7_3.3.0-5_amd64.deb
sudo apt install ./libkpmcore7_3.3.0-5_amd64.deb

During the installation I choose to erase the disk and selected the checkbox to encrypt the disk.
After installation and reboot, it works as just fine.
Where exactly is the magic, that it works now?

This worked for a BIOS install as well.