Public bug reported:
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.
** Affects: ubiquity (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1779548
Title:
Desktop installer lacks an adequate warning of permanent data loss if
attempting to activate existing LUKS containers.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1779548/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
