Page MenuHomeLubuntu Development

Fix full disk encryption on BIOS systems
Closed, ResolvedPublic

Description

LUKS full disk encryption was working, not sure when it stopped. @guiverc noticed it this week and I can confirm from my test today that it is not functional.

Event Timeline

kc2bez triaged this task as Unbreak Now! priority.Mar 30 2019, 5:28 PM
kc2bez created this task.
kc2bez added a parent task: T1: Lubuntu 19.04.

My research has led me to this issue reported in Calamares. Basically there was a change to cryptsetup to default to LUKS2. LUKS2 and GRUB2 don't play well together. Which thing do we patch or do we abandon LUKS for now? @tsimonq2 @wxl what are your thoughts on this? Do you think I am on the right track here so far?

How is it handled by ubiquity? They should have the same problem.

kc2bez added a comment.Apr 3 2019, 1:11 PM
In T36#354, @apt-ghetto wrote:

How is it handled by ubiquity? They should have the same problem.

Ubiquity uses a separate /boot partition that is unencrypted.

In T36#356, @kc2bez wrote:
In T36#354, @apt-ghetto wrote:

How is it handled by ubiquity? They should have the same problem.

Ubiquity uses a separate /boot partition that is unencrypted.

Yes, you're right. In this case, the LUKS container is opened by the kernel and not by Grub.

I guess, a separate, unencrypted /boot partition would solve our automatic encryption problems (for BIOS and for UEFI boot mode). But then we should (must) disable the key file.

tsimonq2 renamed this task from Fix full disk encryption on BIOS systems. to Fix full disk encryption on BIOS systems.Apr 8 2019, 7:51 AM

I understand crazy is very much against workarounds, but push is coming to shove here, and we're going to either need to:

  1. Upload a cryptsetup which changes back to LUKS1 as default.
  2. Implement the workaround.

Doing number two seems to involve digging into and modifying a considerable amount of Calamares code to get working.

So, someone needs to talk to cyphermox like yesterday to see if he objects to building cryptsetup with --with-default-luks-format=LUKS1 since upstream isn't budging (either they're eventually going to have to budge or GRUB is).

I'll be more than happy to do the change, test it, and upload it. I'm just not comfortable doing it without an explicit ack from cyphermox.

tsimonq2 claimed this task.Apr 8 2019, 8:14 AM

Actually, xnox is the last uploader here, hmm.

I'll take this one. This will involve testing the update and uploading it, but as long as it works, I see no reason not to JFDI.

I will very likely get grumbled at for doing this so close to release, so I'll probably still coordinate with cyphermox and xnox.

In T36#420, @tsimonq2 wrote:

I understand crazy is very much against workarounds, but push is coming to shove here, and we're going to either need to:

  1. Upload a cryptsetup which changes back to LUKS1 as default.
  2. Implement the workaround.

Doing number two seems to involve digging into and modifying a considerable amount of Calamares code to get working.

This was very much an overestimation. I just need to cherry-pick the first part of this commit.

Trying this and testing it.

Apparently highvoltage uploaded this fix to Debian a few days ago. No problem, right? Wrong.

When synced to Ubuntu, it's FTBFS only on s390x. Being a Debian Developer, I tried on an s390x Debian porterbox. Couldn't reproduce it.

doko might have been looking at it but I might run it by Adam and Steve to see if either of them have ideas/objections to me just skipping tests on s390x.

We owe mitya57 some beer. 😄

Here's the Bileto ticket in which he's testing a potential fix in qtbase for this. Upstream pull request here.

I'm calling this a release blocker.

As @apt-ghetto suggested in T2, following worked for me.

Before beginning installation, run the folllowing

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

sudo apt install ./libkpmcore7_3.3.0-5_amd64.deb

Then run the installation, selecting full disk install and encryption.

I don't know what is working in background herebut it seems to do the job.

tsimonq2 closed this task as Resolved.Apr 12 2019, 12:21 PM

AWESOME! Thanks!