Comment 19 for bug 1510731

I filed Bug #1523194. It deals with something a bit different, namely being unable to place /home in its own encrypted partition when using ext4.

Also, when I filed Bug #1523194, I originally assigned it to ubiquity, but someone reassigned it to partman-crypto. Honestly, I'm not convinced that it was properly reassigned. (I've forgotten the details, but if I recall correctly, I ultimately concluded that the ubiquity was at least partially responsible for the bug.) But what I was unable to do with ext4 (place /home in its own encrypted partition) as reported in Bug #1523194, I am now able to do with my preferred file system, which is btrfs. So, because the bug was no longer relevant to me, I gave up on Bug #1523194. (Also, a relatively easy workaround is possible for that bug, namely moving /home to its own encrypted partition after installation.)

But yep, based on Bug #1523194 and what has been reported here and elsewhere, this bug (1510731) seems to be restricted to KDE's implementation of the installer, as used by Kubuntu, KDE neon, and Lubuntu Next (Qt-based).

As can be seen, the initial response to the KDE bug report that I filed included the following:

"Seeing as it is a bug in ubiquity it needs fixing in ubiquity not in neon."

And the KDE bug report had been marked to reflect that the problem was upstream, not with KDE.

But as I see it, the problem with KDE's conclusion is the KDE installer must, in some way, differ from the "upstream" installer used by gtk-based distributions, including Ubuntu, Ubuntu GNOME, Ubuntu MATE, Ubuntu Budgie, etc., NONE of which suffer from this bug. That is, this bug seems to have been introduced by KDE, either by modifying ubiquity, or by using ubiquity-frontend-kde.

Either way, I hope the KDE folks will fix this bug. I've been testing Kubuntu, and I hope to switch over to it as my primary distribution. But being unable use the "create physical volume for encryption" option during installation is a show stopper for me.