Ubiquity does not support LUKS in manual partitioning mode

[Ray-Ven]

After installing (daily build) into an existing lvm, no crypttab was generated in /etc/

after installing oneiric versions of cryptsetup it appeared - upgrading to rarings cryptsetup version didn't delete the file and made it usable.
Installing previous Versions in raring itself didn't bring me the crypttab file, so I guess this is not a daily build problem.
Couldn't find any info about crypttab being deprecated

Thank you

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: cryptsetup 2:1.4.3-4ubuntu2
ProcVersionSignature: Ubuntu 3.8.0-17.27-generic 3.8.6
Uname: Linux 3.8.0-17-generic x86_64
ApportVersion: 2.9.2-0ubuntu6
Architecture: amd64
Date: Thu Apr 11 21:33:49 2013
InstallationDate: Installed on 2013-04-10 (0 days ago)
InstallationMedia: Kubuntu 13.04 "Raring Ringtail" - Alpha amd64 (20130410)
MarkForUpload: True
SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
crypttab:
 # <target name> <source device> <key file> <options>
 ray /dev/sda5 none luks,discard

[Steve Langasek (vorlon)]

I don't understand. Why are you expecting a crypttab to be created on package install? You say you were installing into an existing lvm; you don't say that this was an encrypted one. So what are you expecting to find in /etc/crypttab at install time?

[Ray-Ven (ray-ven)]

sorry,
yes it is encrypted, i just reformatted root and boot partitions, and kept home partition.
from lucid to quantal it was always there after installing.

short description about my installprocedure: booting live-cd, cryptsetup luksOpen, install, chroot, adding a few modules in /etc/modules, edit crypttab, update-initramfs
always worked that way, untill raring, crypttab was always there.

[Steve Langasek (vorlon)]

so you chrooted into the target environment, edited /etc/crypttab, and after reboot the file was not there?

[Ray-Ven (ray-ven)]

no i chrooted directly after installation, from live environment, and there was no /etc/crypttab, even after reinstalling cryptsetup, I thought it might be deprecated, and tried to boot without it - without success, then I thought, info of the encrypted lvm now goes somewhere else, but couldn't find out where - obiously.
I installed old crypttab then - which brought me a fresh crypttab and added my encrypted lvm to it.
I didn't remember, that it was only one line in it, thought it was more complex - would have created it myself if i would have remembered it.
A lot of manuals refer to this file, and I think people might get confused if this has to be created by themselves. I think it's no problem to ship this file with the cryptsetup package, even if it's just saying:
# <target name> <source device> <key file> <options>

Isn't it common to provide empty config files? I think it is.

[Steve Langasek (vorlon)]

The cryptsetup package does include code to create a template /etc/crypttab on first install, and I've confirmed in a raring chroot that this still works correctly. If this is not happening for you, I suspect this is related to ubiquity's support for luks installs overriding and deleting the file because you aren't using the installer's cryptsetup support. Reassigning to ubiquity.

[fugounashi (fugounashi+launchpad)]

present in 14.04.3 and 15.04: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1492889

[Launchpad Janitor (janitor)]

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

[fugounashi (fugounashi+launchpad)]

bug still present as of 16.04

this bug has been present since at least 13.04

this bug prevents installation of a working system

why is it still Undecided and Unassigned?

[Phillip Susi (psusi)]

There is not enough information here to understand or reproduce the problem. Please provide a better description of what you did, what errors you got, and attach the syslog and partman log files. They can be found in /var/log while you are still running the installation, or they are copied to the hard disk after install under /var/log/installer.

[fugounashi (fugounashi+launchpad)]

Dear Phillip,

Thanks for your reply. I did all of that in my original bug report https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1492889 but that has been marked as a duplicate of this one, which is why I posted here with the 16.04 update.

Thanks.

[fugounashi (fugounashi+launchpad)]

installing on existing luks/btrfs doesn't ask for passphrase at boot

ubuntu 14.04.3 LTS, 15.04, 16.04

attached installation syslog and partman are from 16.04

after manual cryptsetup luksOpen as required to install on existing luks/btrfs I selected the existing btrfs as root (having renamed the existing root and home subvolumes)

installation proceeds and installs to new root and home subvolumes however the system is not correctly configured to boot: there is no prompt for passphrase at boot

manually creating an appropriate cryptab and updating initramfs will result in a bootable system

[Launchpad Janitor (janitor)]

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]

[Ian Turner (vectro)]

I'm seeing this in the 18.04 Beta 1 installer also. If you use manual partitioning and provide a /boot which is on LVM on LUKS, ubiquity does not provision an /etc/crypttab and the resulting system is not bootable.

[nicholas (nbros652)]

I don't know what version of Ubuntu I was installing when I first attempted manual partitioning with LUKS (manually configured), but I know I've run into this issue with at least 14.04 and 18.04. At the time that I first had an issue with it, I poked around until I found out what the problem was and fixed it manually during installation time. Since then, I recently put together (a script)[https://github.com/nbros652/LUKS-guided-manual-partitioning] that enables semi-manual partitioning with LUKS. The goal of my script is not to cover all use cases, but to make it possible to do manual paritioning with LVM and LUKS. If you know how to set up logical volumes, it's not difficult to add more partitions manually. What my script does is configure the boot, EFI (if necessary), LUKS and LVM (swap and home) partitions with a few prompts for information from the user. Then it waits for the user to perform installation on the configured partitions. Once installation is completely my script finishes everything off by remounting the system, generating the /etc/crypttab file, chrooting into the installed system and updating the initramfs.

[Michael Neuffer (neuffer)]

Hi Nicolas,

nice script.
I believe that this is a sorely missing feature in the installer.
It definitely should be part of the installer that you can configure LVM on top of a LUKS encrypted partition. At the moment it is not possible to select LVM on an LUKS encrypted device.

In the past I always did this setup manually to work around this sad fact, now I might take your script with a small tweak

- a different name for the LUKS device: rename os -> <devicename>_crypt
that makes it more clear that you have an encrypted device in front of you and reduces the danger of accidentally trashing it.

[clickwir (clickwir)]

Still a problem in 19.04. Made a /boot and / but / was on top of an encrypted LUKS partition. One time, the system installed but never asked for a password on boot. So I tried again and it wouldn't even install.

IF this actually works, it's very fragile and I've yet to see it work.

On top of that, even if you don't use your own premade LUKS partition and try using the one in the GUI installer, it never asks for a password or options. So it never gathers enough data to even have a chance of success.

And honestly, saying "There is not enough information here to understand or reproduce the problem." ... did you try? Because it's pretty simple to do so and see the gaping holes where it doesn't even come close to working. I appreciate you want more info, but at some point you have to try it yourself and I think if you give it any effort you'd see multiple issues.

My guess is that no one has even tested it internally yet.