Can't install /home into separate LUKS encrypted volume

I'll just add that, as a workaround, I installed Ubuntu only into boot (/boot) and root (/). I then booted into the installed Ubuntu and created a new auto-mountable LUKS-encrypted volume formatted with Ext4, to which I moved my home directory.

The above approach works, but for some reason, System Monitor displays /dev/dm-0 as the identifier for the LUKS-encrypted volume that was created with Ext4 during installation, but displays /dev/mapper/vda3_crypt as the identifier for a LUKS-encrypted volume that created with Ext4 after installation.

Strangely, System Monitor displays /dev/mapper/vda2_crypt as the identifier for the LUKS-encrypted volume that was created with Btrfs during installation, and displays /dev/mapper/vda3_crypt as the identifier for a LUKS-encrypted volume that created with Ext4 after installation.

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

Although perhaps not a "duplicate" of Bug #1509877 (assessed to be a "critical" bug for Lubuntu), this bug and that bug at least seem to be related. See https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1509877

This bug may also be related to Bug #1531387.

This bug may also be related to Bug #1361951 related to mke2fs.

Please:

1. Into the tag list, write down the first name of each release where you are seeing this bug.
2. Set this bug status back to "confirmed".

Thank you.

I started report at Bug #1531387 to expand on comment #1 above.

I don't know what, if any, relation Bug #1531387 has to the current bug, but here's a summary of Bug #1531387:

1) Installing root (/) into an Ext4 formatted LUKS partition creates /dev/dm-0, rather than /dev/mapper/sdaX_crypt.

2) Installing root (/) into a Btrfs formatted LUKS partition creates /dev/mapper/sdaX_crypt, rather than /dev/dm-0.

The above seems odd to me. And as I wrote before, I'm under the impression that, unless working with LVM, it is more appropriate to create /dev/mapper/sdaX_crypt, rather than /dev/dm-0, when installing root (/) into a LUKS partition. See https://www.redhat.com/archives/linux-lvm/2009-August/msg00010.html

But whatever the case, if the bug that prevents installing home (/home) into a separate LUKS encrypted volume can be fixed, it would seem best if root (/) were installed into /dev/mapper/sdaX1_crypt and home (/home) were installed into /dev/mapper/sdaX2_crypt. Or perhaps root (/) into /dev/dm-0 and home (/home) into /dev/dm-1. But root (/) into /dev/dm-0 and home (/home) into /dev/mapper/sdaX_crypt would seem odd.

Why do you think this is not a duplicate of #1361951? When it is hung, can you check with ps or the task manager to see if you have the mke2fs process running? If so, run sudo gdb -p <pid of mke2fs> and at the prompt, give it a "bt" command and post its output.

Phillip,

I tried to install the most current daily build (2016-01-28) of Ubuntu 16.04 into /home into separate LUKS encrypted volume, this time using QEMU/KVM. The attached screen shot was taken just after the installation failed. On this attempt, the error differs somewhat what I observed when I first submitted the bug report (and from what I have observed on many other attempts). Nonetheless, the effect is the same: Installation does not proceed.

Note that, as can be seen in the attached screen shot, the mke2fs process wasn't running just after the installation failed.

You ask why I think that this bug isn't a duplicate of Bug #1361951. I acknowledge that this bug may be related to that bug. And indeed, the bug that I am reporting may very well be a manifestation of whatever error gives rise to that bug. But as far as being a "duplicate" of that bug, I don't think so. For one reason, as I mentioned above, the mke2fs process wasn't running just after the installation failed. But beyond that, the issues reported in Bug #1361951 seems to be hardware dependent, and in many cases aren't reproducible. In contrast, as I mentioned in Comment #64 of Bug #1361951, the bug that I am reporting "is reproducible 100% of the time on every computer that I own as well as on virtualbox and QEMU/KVM." In any case, I don't want to mark this bug as a duplicate until we know more.

Also, in addition to preventing a clean installation of /home into separate LUKS encrypted volume, I have noticed that I am unable to upgrade from a working (non-broken) installation of Ubuntu 15.04 in which /home has been previously installed into separate LUKS encrypted volume.

I hope that the above is of some help.

Best regards,
GizmoChicken

Ahh, it also shows that contrary to what you said before, the install did not hang during "creating ext4 system..." but has popped up an error dialog saying it was unable to mount the volume. Please attach /var/log/syslog once this has happened.

Phillip,

When I originally reported the bag back on 2015-12-06, the installer did, in fact, hang during installation when the following was displayed: “Creating ext4 system for /home in partition #1 of Encrypted volume (sda3_crypt)...”

But as I wrote in Comment #9, the screen shot uploaded with Comment #9 occurred when attempting to install the 2016-01-28 build of Ubuntu 16.04, this time on a QEMU/KVM virtual machine, with /home installed into a separate LUKS encrypted volume. And as I also wrote in Comment #9, "the error differs somewhat what I observed when I first submitted the bug report (and from what I have observed on many other attempts)."

Presumably, you work for Canonical. True?

I don't work for Canonical. Rather, I am merely a hobbyist who is trying to help.

Honestly, I don't have time to mess with this any more. I've reset the report to confirmed. If you would prefer not to work on this bug, then please hand it off to someone else for triage. But please stop marking the bug as "incomplete." You have enough information to reproduce the bug if you would like to do so.

Best regards,
GizmoChicken

No, I don't work for Canonical. I was able to reproduce this and it looks like the problem is that only one of the two volumes is being formatted and the other has no filesystem in it. I'll try to do some tracing and see where it is going wrong but it certainly looks like a bug in one of the partman packages.

Bingo!

/lib/partman/init.d/52crypto: IN: NEW_LABEL =dev=mapper=xvda5_crypt loop
parted_server: Read command: NEW_LABEL
parted_server: command_new_label()
parted_server: Note =dev=mapper=xvda5_crypt as changed
parted_server: Opening outfifo
parted_server: command_new_label: requested label with type loop
parted_server: command_new_label: creating

Looks like the culprit right here. The crypto init.d script is asking parted to create a loop label, blowing away the already formatted ext4 partition in xvda5_crypt. init.d scripts are not supposed to modify the disk at all, let alone reformat a disk that has already been completely set up.

The bug isn't in ubiquity, which is why I reassigned it.

Phillip,

You've identified part of the problem. And I thank you for that. But I'm not convinced that you have identified the whole problem. In addition to assigning the bug to partman-crypto, please leave the bug assigned to ubiquity so that others can find the bug and provide additional input.

Thanks,
GizmoChicken

Trust me, I have identified the whole of the problem after enabling full trace of the relevant scripts and going through the logs with a fine tooth comb. The bug is not *in* Ubiquity therefore it is incorrect to leave it tasked there. The Ubiquity developers do not need to know about it as they can not fix it. It also would still say there is a problem in ubiquity after it is fixed in partman-crypto. Unfortunately launchpad does not have the capability to record that a bug affects another package without actually being in that package and needing to be fixed in that package.

I'm facing a similar (if not the same) issue.

My laptop has the following hardware:

- 500 GB HDD (TOSHIBA MQ01ACF050 (AV002D)) (/dev/sda)
- 32 GB SSD (LITEON LST-32S9G-11 SATA 32GB (ZS2110B)) (/dev/sdb)

I'm trying to install Ubuntu 19.04 on it as follow, using disk encryption:

/dev/sda:
- EFI partition: 128 MB
- unencrypted /boot: 1024 MB
- encrypted volume hosting root (/) formatted in ext4: 31 GB

/dev/sdb:
- encrypted volume hosting home partition (/home) formatted in ext4: 500 GB

I set up the system like this, but when pressing "Install Now", I see the following error pop-up:

"The attempt to mount a file system with type ext4 in Encrypted volume (sdb3_crypt) at / failed"

I click on "Continue" nevertheless, but the installer is then stuck at "Creating ext4 file system for /home in partition #1 of Encrypted volume (sda1_crypt)...".

I've attached the logs (/var/log/*) from the live session. The /var/log/partman file might be of interest.

$ dpkg -l | grep ubiquity
ii ubiquity 19.04.9 amd64 Ubuntu live CD installer
ii ubiquity-casper 1.405 all Configuration hooks for live installer
ii ubiquity-frontend-gtk 19.04.9 amd64 GTK+ frontend for Ubiquity live installer
ii ubiquity-slideshow-ubuntu 146 all Ubiquity slideshow for Ubuntu
ii ubiquity-ubuntu-artwork 19.04.9 all Ubuntu artwork for Ubiquity live installer

Just as a follow-up, if I use the following partitioning, the installation completes:

/dev/sda:
- EFI partition: 128 MB
- unencrypted root (/) formatted in ext4: 31 GB

/dev/sdb:
- encrypted volume hosting home partition (/home) formatted in ext4: 500 GB

(basically, only /home on the HDD is encrypted, the rest is not)

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/1523194