Ubiquity needs to not disable the LVM and encryption options for dual boot

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

I can confirm that this is a bug because, although encrypted Ubuntu can be installed alongside another OS in numerous ways to allow dual booting, none of the ways of doing so is even remotely straightforward. So I agree that that this should be fixed.

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

(1) First, BACKUP all your data before proceeding. Then, after verifying your backup, use a standalone copy of gparted to reformat your drive appropriately. What constitutes reformatting your drive "appropriately" will, of course, differ from situation to situation. If intending to dual boot Ubuntu with one of W7, W8 or W10, I suggest creating one Ext4 partition (which Windows doesn't recognize) at the end of your disk with sufficient free (non-formatted) space before it. (This Ext4 partition serves as a place holder and will be deleted later.) The amount of non-formatted space should equal the amount of space that you want to devote to W7, W8 or W10. Then install W7, W8 or W10 into that FREE SPACE. Once Windows is installed, reboot into the standalone copy of gparted. Your Windows installation should be in the first two or three partitions. Now delete the Ext4 partition (the place holder) that you created before installing Windows. In place of the place holder partition that you just deleted, create AT LEAST two new Ext4 partitions, the first (smaller) for boot and the second (larger) for root. (Note: Depending on whether your system uses UEFI or BIOS, and also depending whether you are using a GPT or MS-DOS partition table, you will either create these additional partitions as multiple primary partitions or as multiple logical partitions within a single extended partition.) That is, create the desired partitions before starting the Ubuntu installation. Although you could use less, I typically use 1 GB for the boot (smaller) partition.

(2) Boot into the Ubuntu installation media. During the Ubuntu install, select the "something else" option. Configure the installer to install boot (/boot) into the first (smaller) of the two Ext4 previously created. (I typically format it to EXT4, but many recommend using EXT2.) Using the "create physical volume for encryption" option, create a LUKS-encrypted volume on the second (larger) of the two Ext4 partitions previously created. Wait a bit (sometimes a minute or more), and "sda2_crypt" (or similar) will appear among the list of installable locations. Configure the installer to install root (/) into the "sda2_crypt" (or whatever) previously created. (I typically format this encrypted volume 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 the smaller partition and root into the larger partition. (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 within your encrypted volume once i...

This should be really fixed...

Encrypted ubuntu installation SHOULD be treated equally as plain-text installation.

It seems that encrypted installation can be chosen only if the whole system disk is overwritten... I think Ubiquity just can use the free area of the system disk I've prepared for Ubuntu..

Note that I CAN INSTALL Ubuntu in that way when I forgo encryption by choosing "Alongside...". That's not fair for security-inclined people..

So, I'm forced to go manual disk trickery like this: https://www.jayway.com/2015/11/22/ubuntu-full-disk-encrypted-macosx/ And there is plenty other similar tutorials on the Internet.

With Ubuntu 16.10. this issue got more important for me.
I upgraded from 16.04. to 16.10. and my encrypted setup broke as systemd was only seldom able to boot.
19 of 20 times it wasn't possible to boot as there was some issue in systemd where it wasn't able to mount partitions.
As I wasn't able to to fix it (although I tried a lot), I just decided to reinstall.

Which means I must decide over the encryption setup again, which could be incompatible with the next Ubuntu upgrade and therefore break my setup again.

This really isn't cool.

PS: Besides from that encryption should be standard in the year 2016

This is more important now that there is no home encryption option in Bionic for users installing alongside Windows.

https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1756840/comments/17

I notice that bug #1773457 has been marked as a duplicate of this one.

It is a duplicate, but with one important difference: /boot should also be encrypted.

As per comment #5 by @spm2011, I repeat the key points here for convenience:

• There is a bug with Grub that prevents wide scale adoption of this, for which refer to bug #1773457

• Reference for full-system encryption including /boot and without wiping any other OS:
https://help.ubuntu.com/community/ManualFullSystemEncryption

Will it be possible to install a fully encrypted dual boot system with the 19.04 installer?

The answer is no.
It is still impossible to install an encrypted kubuntu on a dual boot system.
What's the official way to encrypt /home with 19.04 ??
This hack written in 2015 ?? : http://blog.botux.fr/en/2015/09/ubuntu-installation-manual-full-disk-encryption-lvm-on-luks/

In answer to Xavier Gnata…
Have you tried this method?
https://help.ubuntu.com/community/ManualFullSystemEncryption
Be aware that it is designed for 18.04 and so it might not work with 19.04 unless modified.

To Paddy Landau : Your link is a variant of http://blog.botux.fr/en/2015/09/ubuntu-installation-manual-full-disk-encryption-lvm-on-luks/
This method does work with 19.04 with some mirror adaptation (e.g. swap is now a file) even if I still have an issue this the grub menu not showing up during the boot but is it mostly unrelated.

The problem is that is use to be very simple (up to 18.04) to install kubuntu with an encrypted home. Up to 18.04 it used to be as simple as ticking a box in the installer. This box does not exist anymore and there is no simple way to install an encrypter kubuntu with a dual boot. That's a serious regression. the installer offers "lvm" as a partition type in manual mode but there is no way to create such a partition and then assign it to /.

In a nutshell : the installer allows the installation of an encrypted kubuntu on a full disk but not on a dual boot. There is no reason not to support this. I understand that the encrypted home prior to 18.04 was not perfect but it was better than noting.

I believe there is a use-case for an encrypted home+swap which should be considered. If you use Linux in an enterprise setup and your employees need both Windows and Linux for their daily tasks you will want to have their machines set up for dual boot. If they also happen to use laptops which they take home regularly for work there is a serious risk of their computers being stolen on the way home. This would compromise secret documents, source code, local emails if there is no encryption present. We don't care about the system being compromised (highly unlikely that we will ever get it back), we care about stolen data. Currently, we solve this problem with an installer script that was created based on the article mentioned above, but we are hoping the installer will support this out-of-the-box in the next release.

"we are hoping the installer will support this out-of-the-box in the next release."
That would be nice because it is a regression compared to 18.04 which was (IIRC) the last version offering a simple way to encrypt /home in the installer. As the swap should also be encrypted, the simplest way to go is to encrypt /. If we encrypt / I understand that we still need a /boot not encrypted...or do we have a way to encrypt the whole / including /boot?

The user should not have to care about these "details". The need is to have a simple way to encrypt the user data. "Simple" means "in the installer".

/boot can be encrypted. See the link you yourself gave two messages above.

In my case, I have a non-encrypted EFI System Partition (ESP), with the appropriate UEFI GRUB 2 loader with the LVM and LUKS V1 modules (GRUB 2 does not currently support booting from LUKS2 devices). The rest of the disk is a single LUKS V1 partition. GRUB happily opens this, and finds the LVM set up, and /boot is one of the LVM volumes I have set up (swap is another).

The downside of this is that you need to give a LUKS V1 password TWICE: once for GRUB to open the LUKS partition, then the LVM volume and mount /boot; then a second time after GRUB has passed control to the linux kernel in the initramfs as the linux kernel needs to go through the device discovery process and remount the drives. It is possible to set things up so that the linux kernel can open the LUKS partition with a keyfile - the technique is outlined in this linuxquestions.org answer: https://www.linuxquestions.org/questions/linux-security-4/security-implications-of-keyfiles-on-a-luks-encrypted-boot-4175614861 ; and it in turn links to two other documents which describe things in more detail:

https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
https://www.pavelkogan.com/2015/01/25/linux-mint-encryption/

The above links point out that when the system is booted, the keyfile is unencrypted with a copy on the ramdisk, which is likely unacceptable to some people. Holding the keyfile on a separate USB drive which can be removed could be a solution for some people.

It would be helpful if GRUB2 and other bootloaders had a standard method by which LUKS keys could be passed in a secure manner to the kernel being booted, but that is beyond the scope of this bug. As it is, 'full disk encryption' is significantly less functional on GNU/Linux than Bitlocker is on Microsoft Windows.

@Xavier Gnata

"That would be nice because it is a regression compared to 18.04 which was (IIRC) the last version offering a simple way to encrypt /home in the installer."

We are using Ubuntu Mate 18.04.01 LTS. You can not encrypt anything (not /home, not /boot, not /) in the installer if you have a Windows already present on the hard drive that you want to keep.

I do agree with you, the user needs to have a simple way to encrypt their data, with a tick in the installer. We would love this to work, and it does, but only if you are installing Linux only. We would love this to work in a dual boot setup as well.

I thought that 18.04 still offers the option to encrypt /home but I was wrong :(
"Ubuntu 18.04 LTS and newer Ubuntu versions no longer include an option in the installer to encrypt the home directory. This option was removed from the Ubuntu installer because it uses eCryptfs, which is considered "buggy, under-maintained""

It means that there is no "simple" way to encrypt your data with Ubuntu >17.10 and a dual boot.
That's a bit security issue. One cannot ask the users to use the command line to chroot. The installer shall provide a way to preform these steps automatically.
Maybe it is not that simple. maybe it won't work in some case. However it would be better than no encryption at all.