[Bug 595648] Re: Remote unlocking not possible if plymouth is active (Bug or Feature?)

[Felix Eckhofer]

On Raring, something like this works:

  cat /conf/conf.d/cryptroot
  /sbin/cryptsetup luksOpen <source> <target>
  kill $(pidof plymouth)

Where <source> and <target> have to be replaced by the respective
parameters from the output of the first command.

What is the proposed way to fix this issue? It should be rather easy to
create a script which uses the functions from local-top/cryptroot to
parse options from /proc/cmdline and /conf/conf.d/cryptroot, then calls
/sbin/cryptsetup as above and on success kills the plymouth password
prompt. Calling this script from a wrapper which waits for input on
/lib/cryptsetup/passfifo seems similary simple. Would a patch be
accepted if it did that?

-- 
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/595648

Title:
  Remote unlocking not possible if plymouth is active (Bug or Feature?)

Status in “cryptsetup” package in Ubuntu:
  Triaged
Status in “plymouth” package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: cryptsetup

  If plymouth is active, it is no longer possible in an easy way to remotely unlock the disc(s).
  Which means that with a standard Ubuntu setup the README.remote is wrong or incomplete.

  Reason: Plymouth is "stealing" the password prompt because the
  cryptroot script checks if plymouth is active:

  if [ -z "$cryptkeyscript" ]; then
  			cryptkey="Unlocking the disk $cryptsource ($crypttarget)\nEnter passphrase: "
  			if [ -x /bin/plymouth ] && plymouth --ping; then
  				cryptkeyscript="plymouth ask-for-password --prompt"
  				cryptkey=$(echo -e "$cryptkey")
  			else
  				cryptkeyscript="/lib/cryptsetup/askpass"
  			fi
  		fi

  but only askpass has a feature which is checking for a file with a
  password in it.

  Because I am not so good in writing startup fixes, I am proposing this as a bug.
  Possible solutions:
  1. Include a new script, which doesn't use plymouth at all.
  2. Use command line switches to use askpass instead of plymouth.
  3. Patch plymouth, e.g. to include a "pass-as-password" option, which is passing the password along to a running plymouth(d?).

  My knowledge about the inner workings of the startup process is limited, I would prefer solution no. 3.
  Any suggestions?

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