"plymouth ask-for-password" unable to read keyboard input on Xen PV console (hvc0)

[Richard Godbee]

"plymouth ask-for-password" is unable to read keyboard input when the console is the Xen PV console device (hvc0).

Since the "cryptroot" script that the "cryptsetup" package installs on initramfs's uses "plymouth ask-for-password" instead of /lib/cryptsetup/askpass if plymouth is available, this causes the boot process to hang at the password prompt when trying to boot with an encrypted root device that needs the operator to type the password on the console.

As a very hacky workaround, modifying /usr/share/initramfs-tools/scripts/local-top/cryptroot to always use /lib/cryptsetup/askpass if $cryptkeyscript is not set (see attached patch) and then regenerating the initramfs with "update-initramfs -u" works as expected.

Specifying /lib/cryptsetup/askpass as the "keyscript=" using the kernel command line ("cryptopts=") and/or /etc/crypttab didn't work for whatever reason, but I didn't spend a whole lot of time trying to figure out why.

Some relevant system information:

Ubuntu 14.04 (Trusty) on an amd64 Xen domU

The system was debootstrap'd under Finnix on a VM supplied by Linode.com.

cryptsetup 2:1.6.1-1ubuntu1 amd64
linux-image-3.13.0-33-generic 3.13.0-33.58 amd64
linux-image-virtual 3.13.0.33.39 amd64
linux-virtual 3.13.0.33.39 amd64
plymouth 0.8.8-0ubuntu17 amd64

kernel command line: root=/dev/mapper/crypt-root console=hvc0 ro

contents of /etc/crypttab:

# <target name> <source device> <key file> <options>
crypt-swap /dev/xvdb /dev/urandom swap,cipher=aes-xts-plain64,size=256,hash=sha512
crypt-root /dev/xvdc none rootdev,luks

contents of /etc/fstab:

# <source device> <mount point> <fs type> <mount options>
/dev/xvda /boot ext4 defaults
/dev/mapper/crypt-swap none swap defaults
/dev/mapper/crypt-root / ext4 errors=remount-ro
none /proc proc defaults

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "the very hacky workaround; not suitable for general use" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Launchpad Janitor (janitor)]

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

[Ryan Finnie (fo0bar)]

While this is a bug and should be fixed, I've found a cleaner workaround (and not prone to overwriting by a possible dpkg upgrade). Add keyscript=/lib/cryptsetup/askpass to crypttab, e.g.:

root_crypt UUID=916478f6-fdee-48e1-bc6f-dba0c5145dfa none luks,keyscript=/lib/cryptsetup/askpass

and update-initramfs.

[Richard Godbee (richardgodbee)]

That's very close to the workaround I ended up using on my Trusty VMs:

# grep root /etc/crypttab
crypt-root /dev/xvdc none luks,keyscript=local.askpass

# cat /lib/cryptsetup/scripts/local.askpass
#!/bin/sh
exec /lib/cryptsetup/askpass "$(printf '\nEnter passphrase for %s (%s): ' "$CRYPTTAB_SOURCE" "$CRYPTTAB_NAME")"

Just setting keyscript=/lib/cryptsetup/askpass makes /usr/share/initramfs-tools/scripts/local-top/cryptroot run askpass with an empty string as its sole command-line argument, so askpass doesn't display a prompt before reading the password. This makes it look like the boot process has hung, even though it's actually sitting there waiting for the password.

You can also add a key= option to crypttab, which controls the argument that the .../local-top/cryptroot script passes to the keyscript, but because of how the options string in crypttab is parsed, there can't be any spaces or commas in the string.

[Steve Langasek (vorlon)]

Is this bug still reproducible with plymouth 0.9.0 in Ubuntu 15.04 and in wily?

[Paolo Pisati (p-pisati)]

I have this problem on a bare-metal vivid installation:

ii cryptsetup 2:1.6.1-1ubuntu7 amd64 disk encryption support - startup scripts
ii plymouth 0.9.0-0ubuntu9 amd64 graphical boot animation and logger - main package

What happens is that i get to the plymouth passphrase prompt, but no matter what i type, nothing shows up on the textbox.
Keyboard is working because i can switch to a different tty (tty1, tty2, etc) and the scary thing is that i can even switch to tty7 where i can see the passphrase in clear text that i just typed.

Using richardgodbee workaround above i get to a 'loading ubuntu' plymouth splashscreen, and blindly typing my passphrase makes it work.

[Steve Langasek (vorlon)]

Paolo, I think you're seeing bug #1500751 in the kernel...

[Jonathan Davies (jpds)]

A newly-installed 14.10 guests works correctly on a machine where a 14.04 one doesn't.

[gstlt (gadamowicz)]

I'm facing the same issue on Wily (15.10). It's an upgrade from 14.10 installation. Didn't tried workaround proposed above yet.
Let me know how can I provide more data if you need it. Cheers!

[Daniel van Vugt (vanvugt)]

Ubuntu 14.04 (trusty) reached end of standard support in April 2019:

  https://wiki.ubuntu.com/Releases

If you would like to continue with free support then please update to a
newer Ubuntu version and tell us if the problem still occurs.

If you would like to continue with Ubuntu 14.04 then there is a paid
support option detailed at https://www.ubuntu.com/esm