Installer fails when using encrypted partitions

Bug #1871500 reported by Michael J. Kidd
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
New
Undecided
Unassigned

Bug Description

During installation of 20.04 beta:

Advanced partitioning attempts to setup encrypted / and swap partitions, attempting to proceed beyond partitioning UI results in failure to mount crypted volume as /target.

Further checks from terminal show no valid filesystem exists on the open dmcrypt volume.

Reproduction details:
 - Existing windows installation partitions, consuming ~1/2 of a 1TB NVMe
 - Create new 1gb EXT4 formatted, non-encrypted /boot partition
 - Create new 70gb encrypted partition
   + Edit the new partition to be / and formatted ext4
 - Create new 16gb encrypted partition
   + Edit the new partition to be type swap
 - Click the button to continue installation

Expected results:
 - Installation continues

Actual results:
 - Time zone selection screen appears, but message pops up indicating a failure to mount the encrypted / volume on /target
 - Unable to click 'Go Back' or 'Continue' or the 'X' at the top of the modal dialog
 - Unable to click anything on the time zone selection window underneath ( greyed out )

Additionally:
 - Attempts to re-use existing encrypted partitions was 100% unsuccessful
   + Tried clicking one, setting it as a raw encrypted partition, setting the password that existed on it, but the installer never presented details about that crypted filesystem's contents
   + Tried pre-opening the crypted volumes from terminal using cryptsetup, which did allow the installation to complete, but was unable to boot due to missing crypttab entries in initramfs.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu22
Architecture: amd64
CasperVersion: 1.442
DistroRelease: Ubuntu 20.04
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed quiet splash ---
LiveMediaBuild: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200402)
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
Package: ubiquity 20.04.9
PackageArchitecture: amd64
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=C.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
Tags: focal ubiquity-20.04.9 ubuntu
Uname: Linux 5.4.0-21-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

_MarkForUpload: True

Revision history for this message
Chris Guiver (guiverc) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:

apport-collect 1871500

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

ps: I know your session will have ended, please use `ubuntu-bug` if possible in the future, as your bug report didn't include the ISO details. If you still have same install media (thumb-drive etc), booting it on the same box and running the command could be very helpful. Thank you for taking time to report, and your well written bug report.

Revision history for this message
Michael J. Kidd (linuxkidd) wrote : Casper.txt

apport information

tags: added: apport-collected ubiquity-20.04.9 ubuntu
description: updated
Revision history for this message
Michael J. Kidd (linuxkidd) wrote : Dependencies.txt

apport information

Revision history for this message
Michael J. Kidd (linuxkidd) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Michael J. Kidd (linuxkidd) wrote : UbiquityDebug.txt

apport information

Revision history for this message
Michael J. Kidd (linuxkidd) wrote : UbiquityPartman.txt

apport information

Revision history for this message
Michael J. Kidd (linuxkidd) wrote : UbiquitySyslog.txt

apport information

Revision history for this message
Michael J. Kidd (linuxkidd) wrote :

Hi Chris,
  Happy to try and help. I wiped the partitions and attempt another install to capture all the data. This was performed with the same installation media. Here's some additional notes:

---- Pre install data:
root@ubuntu:~# fdisk -l /dev/nvme0n1
Disk /dev/nvme0n1: 953.89 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: SAMSUNG MZVLB1T0HALR-000H1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B5045520-C230-4E78-9C44-7C3E56C1B3C7

Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 534527 532480 260M EFI System
/dev/nvme0n1p2 534528 567295 32768 16M Microsoft reserved
/dev/nvme0n1p3 567296 200648424 200081129 95.4G Microsoft basic data
/dev/nvme0n1p4 200648704 201891839 1243136 607M Windows recovery environment
/dev/nvme0n1p5 201893888 813043711 611149824 291.4G Microsoft basic data
/dev/nvme0n1p6 813043712 815140863 2097152 1G Linux filesystem
/dev/nvme0n1p7 815140864 1831622655 1016481792 484.7G Linux filesystem

Notes:
p6 == Original /boot partition from prior install, selecting to format ext4 and use as /boot
p7 == encrypted data partition from prior Fedora 31 installation, keeping for re-use.
  -- I'll add this to crypttab / fstab later

---- Post crash data:
root@ubuntu:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 953.9G 0 disk
├─nvme0n1p9 259:1 0 15.3G 0 part
│ └─nvme0n1p9_crypt 253:1 0 15.2G 0 crypt [SWAP]
├─nvme0n1p1 259:9 0 260M 0 part
├─nvme0n1p2 259:10 0 16M 0 part
├─nvme0n1p3 259:11 0 95.4G 0 part
├─nvme0n1p4 259:12 0 607M 0 part
├─nvme0n1p5 259:13 0 291.4G 0 part
├─nvme0n1p6 259:14 0 1G 0 part
├─nvme0n1p7 259:15 0 484.7G 0 part
└─nvme0n1p8 259:16 0 65.2G 0 part
  └─nvme0n1p8_crypt 253:0 0 65.2G 0 crypt

root@ubuntu:/# mount /dev/mapper/nvme0n1p8_crypt /target/
NTFS signature is missing.
Failed to mount '/dev/mapper/nvme0n1p8_crypt': Invalid argument
The device '/dev/mapper/nvme0n1p8_crypt' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

root@ubuntu:/# mount -t ext4 /dev/mapper/nvme0n1p8_crypt /target/
mount: /target: wrong fs type, bad option, bad superblock on /dev/mapper/nvme0n1p8_crypt, missing codepage or helper program, or other error.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.