Bug in ubiquity-frontend-kde: Can't create LUKS encrypted volumes during manual disk setup in Kubuntu 17.10 (does not affect Ubuntu, Ubuntu MATE, or Ubuntu Budgie)

[David Schoen]

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 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.

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: ubiquity 2.21.37
ProcVersionSignature: Ubuntu 4.2.0-16.19-generic 4.2.3
Uname: Linux 4.2.0-16-generic x86_64
ApportVersion: 2.19.1-0ubuntu3
Architecture: amd64
CasperVersion: 1.365
CurrentDesktop: KDE
Date: Tue Oct 27 23:56:19 2015
InstallCmdLine: noprompt cdrom-detect/try-usb=true file=/cdrom/preseed/kubuntu.seed boot=casper maybe-ubiquity initrd=/casper/initrd.lz quiet splash --- BOOT_IMAGE=/casper/vmlinuz.efi
LiveMediaBuild: Kubuntu 15.10 "Wily Werewolf" - Release amd64 (20151021)
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Reviewing your log files attached to this bug report it seems that there is a problem with your installation media (CD/DVD). You can verify the integrity of the Ubuntu ISO files you downloaded by following the instructions at https://help.ubuntu.com/community/HowToMD5SUM. You might also retry your installation with new media. In the event that is is not in fact an error with your installation media please set the bug's status back to New. Thanks and good luck!

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[David Schoen (neerolyte)]

I verified the sha256sum of the kubuntu-15.10-desktop-amd64.iso, it's fine.

The iso isn't burnt to CD/DVD it's been put on a usb using usb-creator-gtk.

Booting the USB and using it's self check (i.e typing "check" at the initial "boot: " prompt) checks all the files and confirms "Check finished: no errors found".

I'm unable to perform the check at https://help.ubuntu.com/community/Installation/CDIntegrityCheck (because of https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1325801 ) , but I believe it's the same as running "check" manually(?).

[David Schoen (neerolyte)]

I can reproduce this by booting a verified copy of kubuntu-15.10-desktop-amd64.iso in a Virtualbox VM.

[David Schoen (neerolyte)]

> *** This bug is a duplicate of bug 1510730 ***
> https://bugs.launchpad.net/bugs/1510730

How? 1510730 is about a crash when doing a useless edit that happens to be a crypto partition, this bug is about there being no way to use a crypto partition at all (regardless of the crash, that's easy enough to work around).

FWIW the work around for this bug ended up being:
 * accept the guided encrypted+lvm layout
 * do normal install
 * boot off usb disk
 * shrink ext4 + LV
 * create new LV + FS I wanted (btrfs)
 * "rsync -PavH --delete .../old/ .../new/"
 * edit fstab
 * delete old fs/LV
 * resize new LV + btrfs reboot

The workaround for 1510730 is simply not to edit the crypto partition a second time.

[GizmoChicken (gizmochicken)]

Have you tried with Ubuntu rather than Kubuntu? If not, you might want to try with Ubuntu, just to rule out whether this is a Kubuntu specific issue.

Using the “something else” option presented during installation of Ubuntu 15.10 and Ubuntu 16.04 (onto a non-UEFI system with a gpt formatted drive), I have been able to create a LUKS-encrypted volume on sda2, and I have been able to install boot (/boot) into non-encrypted sda1, and root (/) into LUKS-encrypted sda2.

I have noticed, however, that, after creating the LUKS-encrypted volume on sda2 (using the create the next partition as "physical volume for encryption" that you mention), I sometimes have to wait a bit (sometimes a minute or more) before "sda2_crypt" (or something like that, I don't recall the exact label) is created, into which I can install root. Maybe your installation hangs t this point?

Although the above works for me, I have NOT been able to install boot (/boot) into non-encrypted sda1, root (/) into LUKS-encrypted sda2, and home (/home) into into LUKS-encrypted sda3. Rather, although I am able to create all of the LUKS-encrypted volumes, the installer hangs during installation when the following is displayed:

“Creating ext4 system for /home in partition #1 of Encrypted volume (sda3_crypt)...”

See https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1523194 for the issue that I'm describing.

[David Schoen (neerolyte)]

I haven't tried the Ubuntu disk, the bug is about the Kubuntu disk and I have very limited bandwidth so I'm not going out of my way to verify each and every disk available.

[GizmoChicken (gizmochicken)]

Even though I don't use Kubuntu, just for kicks, I tried installing Kubuntu 15.10 with boot (/boot) into non-encrypted sda1 and root (/) into LUKS-encrypted sda2. I got the same result as reported by David Schoen, namely, the installer failed to create "sda2_crypt" into which root (/) could be installed.

As I previously noted, I can accomplish this (install boot into non-encrypted sda1 and root into LUKS-encrypted sda2) using Ubuntu 15.10 and Ubuntu 16.04. So this seems to be a Kubuntu specific problem.

For those interested in attempting to accomplish this with Ubuntu 15.10 or Ubuntu 16.04, here are a few tips:

(1) Use a standalone copy of gparted to create at least two partitions, the first (sda1) for boot and the second (sda2) for root. That is, create the desired partitions before starting the Ubuntu installation. Although you could use less, I typically use 1 GB for sda1.

(2) During the Ubuntu install, select the "something else" option. Configure the installer to install boot (/boot) into the non-encrypted sda1. (I typically format sda1 to EXT4, but many recommend using EXT2.) Using the "create physical volume for encryption" option, create a LUKS-encrypted volume on sda2. Wait a bit (sometimes a minute or more), and "sda2_crypt" will appear among the list of installable locations. Configure the installer to install root (/) into the "sda2_crypt" previously created. (I typically format sda2_crypt to EXT4.)

(3) At least as of now, do NOT attempt to install home or any other directories into separate partitions. Just stick to installing boot into sda1 and root into sda2_crypt. (You can have other partitions on your disk, but don't attempt to install anything into them.)

(4) Do NOT attempt to create a swap partition during installation. Instead, acknowledge the warning regarding the lack of swap space during installation and move on to the next step. (You can create a swap file on sda2_crypt once installation is complete. Or if you really want a swap partition, there are ways of creating them after installation, provide you have left some space on your disk when creating partitions using gparted.)

For those who want to install boot (/boot) into non-encrypted sda1, root (/) into LUKS-encrypted sda2, and home (/home) into into LUKS-encrypted sda3, please see my bug report at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1523194

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[GizmoChicken (gizmochicken)]

This bug seems related to, or is a duplicate of, the following: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1509820

[wandlerer (jwandler)]

bug exists in kubuntu 14.04.4 also.

the last version that worked properly was 12.04 alternate - ie server, which isn't an option anymore. it seems to get lost when the dialog for the passwords should pop up and then can't recover.

[Yuriy Grishin (ygrishin-lists)]

I can confirm this bug still exists in Kubuntu 17.04 amd64.

In my case though what I am trying to achieve at the end of the day is slightly different: to have a dm-crypt/LUKS / without LVM layer.

I recently installed Ubuntu server 16.04.2 LTS and there it's perfectly doable.

[Artemgy (artemgy)]

I confirm this bug exists in Lubuntu Next 17.10 amd64, which derives its Ubiquity from Kubuntu.

I can also confirm that the bug did NOT exist in Lubuntu installs 15.10, 16.04, 16.10 all amd64, which is derived from the main Ubuntu Ubiquity.

My workaround was to
1) manually create, format and open the physical volume for encryption
2) launch Ubiquity, and in Manual disk layout choose the /dev/mapper/sdaX_crypt volume as / (root) without formatting
3) complete the installation but choose Continue Testing
4) chroot into target, create crypttab and check fstab, update-initramfs

for step-by-step instructions see https://github.com/artmg/lubuild/blob/master/help/configure/LxQt-Kubuntu-Ubiqity-manual-encryption-bug.md

[Artemgy (artemgy)]

Marked https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1705845 as duplicate of this

[GizmoChicken (gizmochicken)]

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.

This bug also exist in the latest build of KDE NEON User Edition, which seems to use the same, or very similar, variant of Ubiquity.

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 Artemgy mentions that bug exists in Lubuntu Next 17.10 amd64, and that Lubuntu Next 17.10 derives its variant of Ubiquity from Kubuntu.

[GizmoChicken (gizmochicken)]

Because this bug also affects KDE neon, I filed the following bug report on the KDE Bugtracking System:

https://bugs.kde.org/show_bug.cgi?id=383219

[GizmoChicken (gizmochicken)]

Just a guess, but this bug may be in the ubiquity-frontend-kde package. If so, that would explain why the bug is NOT seen in Ubuntu, Ubuntu MATE, Ubuntu Budgie, or in any of the flavors that use the ubiquity-frontend-gtk package.

Unfortunately, the ubiquity-frontend-kde package doesn't seem to have its own bug submission page, but instead relies on bug reports submitted here, for ubiquity. See https://packages.ubuntu.com/artful/ubiquity-frontend-kde

Hopefully someone from KDE, or whoever is responsible for the ubiquity-frontend-kde package, will have a look at this bug report.

[Artemgy (artemgy)]

The fact that 1523194 has been assigned to partman-crypto indicates the underlying cause _could_ be there.

However the ubiquity-frontend-gtk does NOT suffer the symptoms that ubiquity-frontend-kde does. Therefore I wonder if ubiquity-frontend-gtk has been modified to accommodate, and I hope the bug you raised in the KDE tracker gets some traction so that ubiquity-frontend-kde can also be made to work around the underlying issue.

[GizmoChicken (gizmochicken)]

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.

[GizmoChicken (gizmochicken)]

I still hope that this bug report will eventually receive some attention from the Kubuntu devs.

But in the meantime, 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

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1510731

[vfspirit (vfspirit)]

I found a somewhat simpler workaround for this (17.04 and 17.10):

On the "Installation type" screen, I select guided partitioning with luks & lvm. This way the two fields for the passwords appear. Then, I enter my desired password, switch back to manual partitioning, and click next.

This way, when I create the physical volume for encryption, the encrypted volume shows up as expected.

[Harri Heikkilä (hh61)]

Warning about https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1510731/comments/22

If you select first quided partitioning, it will overwrite your existing partition table no mattter if you press back!

So that workaround works only if you have noting to keep in existing disk!

[Brandon Bell (brandonbell)]

I can confirm that this problem still exists with Kubuntu 18.04.

In my case, I'm not even setting up a separate /boot partition as I want a fully-encrypted disk.

After simply choosing "physical volume for encryption" on the only available partition, the Install Now button becomes active but clicking it does nothing. Then, clicking the Back button results in the two following errors:
* "An error occurred while creating the keyfile."
* "An error occurred while configuring encrypted volumes. The configuration has been aborted."

I have even gotten Ubiquity to crash a few times from various attempts to set up the scheme.

[J (metal450)]

This bug was reported four and a half years ago. Trying to install Kubuntu 20.04...I still see no way to setup manual partitioning w/ encryption....

[J (metal450)]

...As this bug is "confirmed" with importance "high," just wondering if it's ever going to be addressed? Note that the Mint installer is not broken in this way - it affects Kubuntu but not Mint.

[Bleuzen (bleuzen)]

Still not working in 20.10.
Is there any hope on this getting fixed?

[Your name as you would like it displayed throughout Launchpad (plutoisnolongeraplanet-deactivatedaccount-deactivatedaccount)]

Workaround:

1. Install ubiquity-frontend-gtk;
2. Edit the "Install Kubuntu" shortcut. In the command field, instead of "ubiquity kde_ui", put "ubiquity gtk_ui".

Done!

Wouldn't switching to Calamares solve this problem?
https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/1915598

Edit: alternatively, instead of putting ubiquity gtk_ui, just put "ubiquity" in the shortcut.

[Your name as you would like it displayed throughout Launchpad (plutoisnolongeraplanet-deactivatedaccount-deactivatedaccount)]

This bug eight years old! Why it was never fixed?!

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1264813

[remram44 (remirampin)]

The bug is still present in Kubuntu 21.10

[Xavier Gnata (xavier-gnata-gmail)]

The bug is still present in Kubuntu 22.04 :( :(
If someone could have a look at this bug. Again, it is a security issue.

[Douglas Silva (o-alquimista)]

Simple workaround from comment #22 works.

For clarity, let me just add that you DON'T need to press the "Install now" button while the "guided partitioning" option is selected. Don't do this or you'll lose data, as others have pointed out. Simply type the decryption password twice and then switch to "Manual", and only then continue to the next screen.

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1510731/comments/22

[Maximilian Stinsky (mstinsky)]

Still bugged for kubuntu 23.10 install.