I think the answer there is fscrypt - native encryption at the
filesystem level supported by ext4 and some other day - but I'm not sure
what the plans are. Partitioning is hard and the requirement to setup a
separate /boot and crypt device are not always possible, though it is
less of an issue these days with GPT devices.
As I pointed out on another bug report, the goal to dual boot with
encryption is not helped much by new devices being sold with BitLocker
enabled for the drive, forcing you to disable it in order to install
Ubuntu in the first place (one reason I imagine being that the
encryption key is sealed to the Windows boot process in the TPM, so
there's not a way to decrypt it from another OS, or even Windows booted
from a different disk).
That the installer is unable to unlock luks partitions is a bit
unfortunate as it forces users to do more steps manually, and makes
reinstalling Ubuntu harder on systems where you want to keep /home but
replace /; or running multiple distributions in parallel - I've been hit
by that as well.
In any case, I understand and share the concerns raised here and will
try to raise that internally, as this might also simply have went out of
our radar.
** Tags added: rls-hh-incoming
** Changed in: ubiquity (Ubuntu)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1799550
Title:
No way to encrypt at partition level (dual boot)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1799550/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
