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

[TechnoSwiss]

Using the installer for 20.04.3 using the workaround and the installer
is failing with raise ValueError("encryption key or keyfile must be
specified") in the log as well.

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