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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1355617 Title: "plymouth ask-for-password" unable to read keyboard input on Xen PV console (hvc0) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1355617/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
