Can't unlock an encrypted disk when installting new ubuntu

Bug #1743447 reported by Maraschin
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I can't unlock an encrypted disk neither using app disks or sudo cryptsetup luksOpen when doing a new ubuntu installation...
I tried on Ubuntu daily 18.04 LTS (2018-01-15) and ubuntu 17.10

I'm trying to do a new installation of ubuntu, but I want to use encrypted disks and a dual boot for windows.
Basically I can't use the normal installation. To accomplish that I created the encrypted disks, lvm and partitions using ubuntu-server. Since 17.10 and 18.04 both have some kind of bug that when you reboot the system the keyboard defaults to US, I can't enter the password, my keyboard is Swedish with English as language and I use characters that do not exist in the US keyboard.

So, I started the ubuntu desktop installation, ran the try mode, select the appropriate keyboard and tried to unlock the partitions.

On both cases it just hang without report any error.
With app "disks" I can select the cancel button but cryptsetup will hang forever, not even control-c helps.
I than try start the normal installation:
- with ubuntu 18.04 (daily 2018-01-15), the installation stops after I select the language and press continue... (it just hangs there!)

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: cryptsetup 2:1.7.3-4ubuntu1
ProcVersionSignature: Ubuntu 4.13.0-25.29-generic 4.13.13
Uname: Linux 4.13.0-25-generic x86_64
ApportVersion: 2.20.8-0ubuntu6
Architecture: amd64
CasperVersion: 1.388
CurrentDesktop: ubuntu:GNOME
Date: Mon Jan 15 19:25:50 2018
LiveMediaBuild: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180115)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
cmdline: file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash --- maybe-ubiquity
crypttab: # <target name> <source device> <key file> <options>
fstab:
 overlay / overlay rw 0 0
 tmpfs /tmp tmpfs nosuid,nodev 0 0

Revision history for this message
Maraschin (carlo-maraschin) wrote :
Revision history for this message
Maraschin (carlo-maraschin) wrote :

I tried the daily desktop 18.04 2018-02-19 yesterday and it does work now. I am able to unlock the encrypted disk and do a normal installation ...

But after the installation was completed the system will not be able to identify the disks and prompt for the encryption keys. I then try to boot with safe mode...

Here the output:
Begin: waiting for root file system...
Begin: Running /scripts/local-block ...
done.
done.
Gave up waiting for root file system devices. Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules: is /dev)
ALERT! UUID=(long number here ...) doe not exist. Dropping to a shell!

BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3) built-in shell (ssh)
Enter 'help' for a list of build-in commands.

(initramsf) [ 64.614480] usb 2-1.8.3: USB diconnect, device number 7

And here the systems HALT, I'm not able to do anything... not even enter the help command :-/

Revision history for this message
Maraschin (carlo-maraschin) wrote :

I managed access /dev via initramsf and the UUID from the installation doesn't match the ones listed in /dev/disk/by-uuid/...

Should this happen???
I will try to do a new installation to see if it happens again.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in cryptsetup (Ubuntu):
status: New → Confirmed
Revision history for this message
michael da cova (michael-dacova) wrote :

I have the same issue but with an upgraded installation

where my second disk (backup usb)

my workaround was

sudo cryptsetup luksOpen /dev/sdb crypthome

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.