creating LUKS partitions with manual partitioning fails to format

[Martin Pitt]

I tried this with the current Xenial amd64 desktop ISO. But the bug was introduced a month or two ago already, I just didn't get around to reporting it yet.

 - start with blank 10 GB qemu image
 - "something else" partitioning
 - create 5000 MB physical volume for encryption (vda1)
 - create 2000 MB physical volume for encryption (also "primary" type) (vda2)
 - create 500 MB ext2 /boot (vda3)
 - configure vda1_crypt for /
 - configure vda2_crypt for /opt
 - ack the "no swap" warning

A few seconds later you get an error "The attempt to mount a file system with type ext4 in Encrypted Volume (vda1_crypt) at / failed."

Both LUKS partitions got created, and vda2_crypt even got formatted, but
vda1_crypt didn't:

$ blkid | grep vda
/dev/vda1: UUID="10c933ae-429b-41c6-b6e1-6d6d030f4223" TYPE="crypto_LUKS" PARTUUID="45be5903-01"
/dev/vda2: UUID="b3731d04-f3c9-485d-a89a-d6017cf5e87b" TYPE="crypto_LUKS" PARTUUID="45be5903-02"
/dev/vda3: UUID="0e7ad77f-ce4d-44c0-9b3c-7b8d18d8d686" TYPE="ext2" PARTUUID="45be5903-03"
/dev/mapper/vda2_crypt: UUID="4a40c613-7d81-431b-8c2f-f61929901c0d" TYPE="ext4"

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ubiquity 2.21.44
ProcVersionSignature: Ubuntu 4.4.0-6.21-generic 4.4.1
Uname: Linux 4.4.0-6-generic x86_64
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CasperVersion: 1.367
CurrentDesktop: Unity
Date: Mon Feb 22 09:39:24 2016
InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash ---
LiveMediaBuild: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160221)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

[Martin Pitt (pitti)]

I just tested this on 15.10 amd64 desktop, and it fails with the same bug. So indeed this isn't a recent regression.

[Martin Pitt (pitti)]

I tested this the other way around:
 - vda1 is a 500 MB /boot ext2
 - vda2_crypt is 5 GB /opt
 - vda3_crypt is 5 GB /

and now it formats vda2_crypt successfully (i. e. the root partition) and fails on /opt. So the location of /boot does not seem to matter much, but the order of LUKS devices seems somewhat relevant. I. e. it looks like it starts formatting from the last device, and then goes "upwards" in the list.

[Martin Pitt (pitti)]

I ran "sudo mkfs -t ext4 -L cryptopt /dev/mapper/vda2_crypt" and "sudo mount /dev/mapper/vda2_crypt /target/opt" manually, pressed "Continue" in the error dialog, selected the time zone and set up user, and now ubiquity is stuck on "Creating ext4 file system for / in partition #1 of Encrypted volume (vda3_crypt)...". This is a bit curious as it already did that mkfs all by itself, but maybe that's just an old status string.

There is no mkfs or other process running that's related to file systems.

[Martin Pitt (pitti)]

corresponding syslog after the above manual mkfs.

[Martin Pitt (pitti)]

What does help is to "sudo killall ubiquity", restart the installation, and use the existing partitioning. I re-checked "Format partition" everywhere, and now it's doing things properly. Perhaps it does not wait long enough in between cryptsetup luksFormat and mkfs?

So this workaround unblocks me for creating a system with multiple LUKS partitions to investigate bug 1432265, but it's of course not very discoverable for users who aren't familiar with the internals of ubiquity.

[Martin Pitt (pitti)]

Unfortunately the above isn't a workaround as the installed system is missing cryptsetup and crypttab in the initrd.

[Martin Pitt (pitti)]

Creating a single LUKS partition for /opt and keeping / on a normal unencrypted ext4 partition works fine.

[Launchpad Janitor (janitor)]

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