[Bug 1904270] Re: ubiquity does not support existing LUKS encrypted partitions

[Uwe Geuder]

I have used the "cryptsetup luksOpen` work-around successfully already
years ago.

However, when installing 20.04 with the server installer it does no longer work.
Installation aborts; in the log I found the cause to be

   raise ValueError("encryption key or keyfile must be specified")

from

https://github.com/canonical/curtin/blob/45877d0e1f5774dc424f73b0c1c16b65e0353e63/curtin/commands/block_meta.py#L1394

(Note: This is not necessary the commit that was in use when I used the
installer. I just looked at the current master branch to point to the
message I got. I did upload the crash report, but I don't have a link to
my upload.)

Obviously the installer got confused ny the work-around because it
noticed that there is a LUKS container, but it had never gotten any
secret related to it.

Is there more than one Server installer, that could explain the
discrepancy against the instructions above?

I tried the xubuntu-20.04.2.0 and there the work-around still works.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1904270

Title:
  ubiquity does not support existing LUKS encrypted partitions

Status in ubiquity package in Ubuntu:
  Confirmed

Bug description:
  The ubiquity installer, including both the text version on the Ubuntu
  Server live CD and its GUI version does not support using existing
  LUKS encrypted partitions. That means out of the box it wants to
  completely wipe all existing partitions, this is a serious failure for
  what's now the default installer in Ubuntu 20.04.

  There is a workaround that involves running 'cryptsetup luksOpen'
  before running the installer, so that it can see the LVM LV's that are
  on the encrypted device and use them. But even doing this won't work
  properly because the installer stuffs up the /etc/crypttab and initrd.
  You have to manually create /etc/crypttab and initrd.

  This is a major failure since the installer doesn't support re-using
  partitions that it itself created.

  Steps to reproduce:
  - get a system with a blank disk, or just create a new Virtualbox VM
  - install Ubuntu 20.04 on an encrypted LUKS partition (using the options in the ubiquity installer), creating a / (root), /home and swap LV on top of the LUKS partition/LVM volume group
  - boot the system to verify it starts, then restart into the installer again
  - try to re-use the existing partitions, you can't unless you follow the manual workaround below:

  **Workaround**
  **Ubuntu 20.04: Extra Steps for Re-Using Existing LUKS Encrypted Partition**
  (replace nvme0n1p8 with your encrypted LUKS partition)

  - BEFORE starting the installer (if in Ubuntu or Kubuntu live CD desktop), or at the first step (if using Ubuntu Server text-based live CD installer):
  # open existing LUKS partition (
  cryptsetup luksOpen /dev/nvme0n1p8 nvme0n1p8_crypt

  - Then, either do this at the end after the installer has run, or boot into a live CD environment (e.g. Kubuntu) and do:
  cryptsetup luksOpen /dev/nvme0n1p8 nvme0n1p8_crypt
  mount -o subvol=@ /dev/mapper/MainVG-root /mnt/
  mount /dev/nvme0n1p7 /mnt/boot/
  mount --rbind /dev/ /mnt/dev/
  mount --rbind /sys/ /mnt/sys/
  mount --rbind /run/ /mnt/run/
  mount --rbind /proc/ /mnt/proc/
  chroot /mnt /bin/bash -l
  blkid | grep crypto_LUKS
  # Example: /dev/nvme0n1p8: UUID="8cb9831a-692e-4b0e-936f-72529a3ed56d" TYPE="crypto_LUKS" PARTUUID="139f23d2-a0ff-4f4f-b41f-8083964ac894"
  apt install vim
  vim /etc/crypttab
  # Add a line for the encrypted partiton, e.g:
  # nvme0n1p8_crypt UUID="8cb9831a-692e-4b0e-936f-72529a3ed56d" none luks
  # 
  # MAKE SURE There's a newline at end of /etc/crypttab

  # update the initramfs
  update-initramfs -u -k all

  umount -l /mnt

  # Optional, probably not needed
  grub-install --recheck /dev/nvme0n1
  grub-mkconfig -o /boot/grub/grub.cfg

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: ubiquity (not installed)
  ProcVersionSignature: Ubuntu 5.4.0-53.59-generic 5.4.65
  Uname: Linux 5.4.0-53-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.12
  Architecture: amd64
  CasperMD5CheckResult: skip
  CurrentDesktop: KDE
  Date: Sat Nov 14 21:30:33 2020
  InstallationDate: Installed on 2020-11-02 (11 days ago)
  InstallationMedia: Kubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  SourcePackage: ubiquity
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1904270/+subscriptions