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.
Description
Description
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | tsimonq2 | T1 Lubuntu 19.04 | ||
| Resolved | tsimonq2 | T36 Fix full disk encryption on BIOS systems |
Event Timeline
Comment Actions
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?
Comment Actions
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.
Comment Actions
I understand crazy is very much against workarounds, but push is coming to shove here, and we're going to either need to:
- Upload a cryptsetup which changes back to LUKS1 as default.
- 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.
Comment Actions
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.
Comment Actions
This was very much an overestimation. I just need to cherry-pick the first part of this commit.
Trying this and testing it.
Comment Actions
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.
Comment Actions
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.