Bug 383219 - Bug in ubiquity-frontend-kde: Can't create LUKS encrypted volumes during manual disk setup in KDE Neon and Kubuntu 17.10 (does not affect Ubuntu, Ubuntu MATE, or Ubuntu Budgie)
Summary: Bug in ubiquity-frontend-kde: Can't create LUKS encrypted volumes during manu...
Status: CLOSED UPSTREAM
Alias: None
Product: neon
Classification: KDE Neon
Component: Live/Install images (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR critical
Target Milestone: ---
Assignee: Neon Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-07 04:37 UTC by GizmoChicken
Modified: 2017-09-14 03:38 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description GizmoChicken 2017-08-07 04:37:33 UTC
This bug, which affects KDE neon, is the SAME bug that has affected Kubuntu from 15.10 through the current daily build of 17.10.

For the Kubuntu bug report, see https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1510731

I'll quote David Schoen from his bug report, which equally describes the situation on KDE neon:

"Selecting 'Manual' under disk setup if I add a "/boot" and then create the next partition as "physical volume for encryption" I'm then given no way to use that volume (i.e formatting and setting up the passphrase so I can put LVM or FS on it). See crypto-no-usable-options.png.

"None of the available buttons on the screen do anything useful at this point and additionally it's very easy to accidentally trigger [Launchpad] bug #1510730 while looking for some way to apply the layout.

"Basically there doesn't seem to be any way to do custom layouts using crypto in ubiquity currently."


I'll just add the following:

I can confirm this bug exists in the latest daily build of Kubuntu 17.10 amd64 (downloaded 2017-08-06), both when installing onto a newer UEFI system and when installing onto an older BIOS system.

I haven't tested the latest daily build of Ubuntu, but I can confirm that this bug does NOT exist in Ubuntu 16.04.3 or Ubuntu 17.04.

Moreover, this bug does NOT exist in the latest daily build of Ubuntu MATE 17.10 amd64 (downloaded 2017-08-06), and does NOT exist in the latest daily build of Ubuntu Budgie 17.10 amd64 (downloaded 2017-08-06).

Note that lauchpad user Artemgy mentions in the Kubuntu bug report that the bug exists in Lubuntu Next 17.10 amd64, and that Lubuntu Next 17.10 derives its variant of Ubiquity from Kubuntu.
Comment 1 Harald Sitter 2017-08-07 08:23:45 UTC
Seeing as it is a bug in ubiquity it needs fixing in ubiquity not in neon.
Comment 2 GizmoChicken 2017-08-07 16:02:07 UTC
"it needs fixing in ubiquity not in neon."

But KDE neon doesn't use the vanilla upstream version of Ubiquity that is used with Ubuntu and most flavors of Ubuntu.  Rather, KDE neon uses a MODIFIED version of Ubiquity that seems to be the same MODIFIED version of Ubiquity that is used by Kubuntu.

That is, this bug seems to have been introduced by KDE.

If not proper to report the bug for KDE neon, then where to report it?
Comment 3 Harald Sitter 2017-08-11 08:47:53 UTC
The version used by neon and Kubuntu is a different frontend on the same backend in the same code base maintained by the same people. So, it is ubiquity. The bug's not been introduced by KDE as ubiquity is not maintained by KDE.
Comment 4 GizmoChicken 2017-08-11 19:24:50 UTC
“The version [of the installer] used by neon and Kubuntu [has] a different frontend on the same backend...”

Yes, I came that realization after my initial posting here.  Indeed, as I posted in Comment 17 for Bug #1510731 on Launchpad, “this bug may be in the ubiquity-frontend-kde package,” and NOT in the “ubiquity” package itself.  See https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1510731/comments/17 

I updated the bug summary for this report so that it no longer refers to ubiquity.

As I mentioned elsewhere, this bug does NOT affect Ubuntu 17.10, Ubuntu MATE 17.10, Ubuntu Budgie 17.10, or in any of the flavors that use the “ubiquity-frontend-gtk” package.  Rather, it seems to affect only KDE neon, Kubuntu, and Lubuntu Next (Qt-based), all of which use the ubiquity-frontend-kde package.

So it would seem that the bug resides, at least in part, in  the “ubiquity-frontend-kde” package, which I presume is maintained by KDE.

As I also mentioned in Comment 17 for Bug #1510731 on Launchpad, “[u]nfortunately, the ubiquity-frontend-kde package doesn't seem to have its own bug submission page, but instead relies on bug reports submitted [on Launchpad], for ubiquity. See https://packages.ubuntu.com/artful/ubiquity-frontend-kde ” 


QUESTIONS:

If, as I presume, the “ubiquity-frontend-kde” package is indeed maintained by KDE, where is the appropriate place to submit a bug report for that package?  Here?  Somewhere else on the KDE bug reporting system?  Somewhere else on Launchpad?


ADDITIONAL COMMENTS:

I acknowledge that KDE’s frontend is more visually appealing than the frontend used by the gtk-based Ubuntu flavors, including Ubuntu 17.10, Ubuntu MATE 17.10, and Ubuntu Budgie 17.10.  But unfortunately, the changed frontend seems to result in at least one major regression in the overall installation process, namely an inability to create LUKS encrypted volumes during manual disk setup. 

Looking at Bug #1510731 on Launchpad, this bug seems to have existed in Kubuntu since Kubuntu 15.10, and probably longer.  When I first noticed the bug, I was happily using Unity, and so the bug, while interesting, didn’t really affect me. 

Now, I’m considering switching from vanilla Ubuntu to another Ubuntu flavor, or perhaps to another distribution.  If the neon/Kubuntu installer would allow me to easily create LUKS encrypted volumes during manual disk setup, KDE neon and Kubuntu would be my top contenders.  In fact, I even created (but haven’t yet published) a short video that demonstrates a little-known feature in KDE Plasma that would be very attractive to my fellow Unity refugees. 

But without an ability to easily create LUKS encrypted volumes during manual disk setup, I’ll have to look elsewhere.

If, as I presume, the “ubiquity-frontend-kde” package is indeed maintained by KDE, then I’m not sure whether its development should be considered “upstream” of, or “parallel” to, the development of KDE neon and Kubuntu. But even if the KDE neon and Kubuntu devs consider the “ubiquity-frontend-kde” package to be “upstream” of their respective projects, the mere use of the “ubiquity-frontend-kde” package (which has regressions compared to the “ubiquity-frontend-gtk” package) in place of the “ubiquity-frontend-gtk” package could, in-and-of-itself, be considered a bug. So with that in mind, I hope that the neon/Kubuntu devs will either:  (a) insure that the “ubiquity-frontend-kde” package is fixed upstream (or wherever); or (b) revert to the “ubiquity-frontend-gtk” package, which, although less visually appealing, at least works without regressions.
Comment 5 Christoph Feck 2017-08-30 23:42:04 UTC
> “ubiquity-frontend-kde” package, which I presume is maintained by KDE.

No, it is not.

> Somewhere else on Launchpad?

Yes, https://packages.ubuntu.com/zesty/ubiquity-frontend-kde says to use Launchpad for bugs.
Comment 6 GizmoChicken 2017-08-31 16:35:40 UTC
Thanks much for the reply.

>> “ubiquity-frontend-kde” package, which I presume is maintained by KDE.

>No, it is not.

The “ubiquity-frontend-kde” package was created for use with the Kubuntu installer, and now is being used with the Kubuntu and KDE Neon installers.  

If KDE isn't supporting the “ubiquity-frontend-kde” package, then I'm at a loss as to who is supporting it.

>> Somewhere else on Launchpad?

>Yes, https://packages.ubuntu.com/zesty/ubiquity-frontend-kde says to use Launchpad for bugs.

Yes, a bug report has been filed on Launchpad for the "ubiquity" package.  However, as I previously explained, “[u]nfortunately, the ubiquity-frontend-kde package doesn't seem to have its own bug submission page, but instead relies on bug reports submitted [on Launchpad], for ubiquity. See https://packages.ubuntu.com/artful/ubiquity-frontend-kde ”

Also unfortunately, because the bug report has been filed for ubiquity (as opposed to being separately filed for the "ubiquity-frontend-kde" package), the bug report (which is almost two years old) doesn't seem to have received any attention from Kubuntu/Neon devs.

As an aside, for those who want to create, and install into, LUKS encrypted volumes during manual disk setup (as opposed to using the default full disk encryption option), installing Ubuntu server first, and then adding KDE packages later, is one potential workaround, as described here:

https://www.reddit.com/r/kde/comments/6wty79/a_recipe_for_installing_a_minimal_lightweight_kde/

And here:

https://www.reddit.com/r/kde/comments/6wty79/a_recipe_for_installing_a_minimal_lightweight_kde/dmbgsne/?context=3
Comment 7 Christoph Feck 2017-09-13 22:28:59 UTC
If those two packages are maintained by different people, please ask in a forum of your distribution how to find the maintainers of the -kde frontend. It is possible that Kubuntu maintainers are totally unaware of the fact that "their" bugs land unreviewed into the inbox of ubiquity developers.
Comment 8 GizmoChicken 2017-09-14 03:38:37 UTC
I've posted various places, but no one from Kubuntu every acknowledges that their installer introduces a bug relative to the GTK installer used by vanilla Ubuntu.

Anyway, with regard to KDE Neon, as I see it, the "bug" is that KDE Neon uses the “ubiquity-frontend-kde” package in the first place.  Rather, KDE Neon should use the text-based installer used by Ubuntu Server.  Or, at the very least, an ISO including the text-based installer should be offered as an option.