[Bug 1355617] Re: "plymouth ask-for-password" unable to read keyboard input on Xen PV console (hvc0)

[Richard Godbee]

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.

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

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

Status in “plymouth” package in Ubuntu:
  Confirmed

Bug description:
  "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

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