Desktop installer lacks an adequate warning of permanent data loss if attempting to activate existing LUKS containers.

[Paul Whittaker]

Background:

I had Ubuntu installed on a laptop using encrypted LVM storage. Apart from /boot, the whole disk was an encrypted LUKS volume, with all data stored on LVM logical volumes inside that encrypted container.

I wanted to install Ubuntu 18.04 to new partitions inside the existing LVM volume group, then migrate my data and settings across.

I was using the latest Ubuntu 18.04 desktop installer ISO image, which I'd written to a USB stick using dd, and which had successfully passed the check for defects.

I knew that there were multiple Ubuntu installers available, having used them in the past, and I was aware that they offered different levels of support for encryption and logical volumes. Since I wanted a desktop install, I was trying out the desktop installer first.

My steps to encounter the bug were as follows:

 1. Booted the installer and followed the installer steps until the section asking where I wanted to install.
 2. Noted that the installer apparently understood LUKS and LVM, since options for creating both of those seemed to be present.
 3. Selected the 'Something else' option, intending to try to activate my existing container.
 4. Highlighted the /dev/sda2 partition holding the existing LUKS container, and indicated that the installer should use this as a LUKS container.
 5. When prompted to enter passwords, I provided the existing LUKS password.

At this point, I still believed that the installer was about to activate my existing LUKS partition. The GUI support hadn't seemed amazing (for example, the LUKS partition hadn't been autodetected), but this didn't seem odd to me: re-using existing encrypted LVM containers isn't a common use case, and I understand developers have a limited amount of time available.

Most importantly for this bug: none of the installer text so far had indicated that these steps would *re-format* an existing LUKS container. If they had, I would have realised that this wasn't the right choice of installer early enough to avoid data loss.

What happened next:

 6. I clicked OK to submit those passwords. (At this point, I suspect the installer had permanently deleted all of my data.)
 7. When the disk partition view refreshed, I saw what I believed was my existing LUKS crypto device.
 8. I tried to indicate that my crypto device was being used as a physical volume for LVM, but the partition menu only included filesystem options such as 'ext3' and 'ext4', so I concluded (too late) that my arrangement wasn't supported by the this installer.
 9. My system failed to reboot correctly, showing errors like 'evms_activate is not available' and 'Waiting for encrytpted source device ...'.

Even then, it wasn't clear to me that my existing LUKS volume had been lost. After some searching online, however, I found the following in the cryptsetup FAQ:

"Some distribution installers offer to create LUKS containers in a way that can be mistaken as activation of an existing container. Creating a new LUKS container on top of an existing one leads to permanent, complete and irreversible data loss."

At this point it became clear what must have happened, and I stopped trying to recover my data.

Note that I did not mind the lack of support in this installer: I just wish that in step 5 above it had been much clearer that it was only offering to create a brand new LUKS partition.

[Launchpad Janitor (janitor)]

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