[Bug 1104156] Re: "Continue to wait, or Press S to skip mounting or M for manual recovery" when waiting for LUKS passphrase

[Cédric Dufour]

Hello again

I'm currently looking at plymouth source code and trying to find a
solution to elegantly solve the issue mentioned in this bug at the
plymouth level, as Steve Langasek suggests.

Unfortunately, I'm wondering whether this can be achieved.

Plymouth seems to be totally agnostic of where client requests come from
(except to know where to send replies back) and to what purpose (and
thus can not know anything of the logic which may bind some requests to
others). Am I right in this regard?

This means that one could improve the handling of "interactive" requests
that depend on keyboard input (password prompt, question, waiting for
keystroke) and avoid to display the corresponding prompt message as long
a preceding "interactive" request is still unanswered (or not canceled).
This is possible (and already dealt with at some level) because keyboard
input can only match the latest pending request.

BUT I don't see how one could filter out messages to be displayed based on other "interactive" requests.
While plymouth should not display mountall "boredom" messages while cryptsetup is waiting for password input, I'm sure there are existing use cases where messages from one client must be displayed regardless of the "interactive" request(s) of other(s). How can plymouth tell the difference?

Thank you for your replies

Cédric

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

Title:
  "Continue to wait, or Press S to skip mounting or M for manual
  recovery" when waiting for LUKS passphrase

Status in “plymouth” package in Ubuntu:
  New

Bug description:
  Hello,

  (On Quantal) When using passphrase-protected LUKS encryped partition,
  'mountall' shows the "Continue to wait, or Press S to skip mounting or
  M for manual recovery" after the (hardcoded) 3-second BOREDOM_TIMEOUT.

  This is:
   - inappropriate as long as a passphrase is being prompted for
   - useless since the prompt intercepts the key presses (and prevents the S or M option to be used)
   - inelegant (any potentially misleading)

  I first thought of adding a mountpoint-specific option to disable
  boredom messages for appropriate mountpoints. But adding yet-another
  option to the mountpoint stanza somehow seemed wrong.

  On the other hand, if cryptsetup fails after several passphrase
  attemps, one should still be given the choice to Skip or Manually
  recover the partition.

  I don't know how to handle a "state" tracking between 'cryptsetup' and
  'mountall', so that 'mountall' does not get bored as long as a
  passphrase is being prompted for.

  The best way I found to make that issue less "invasive" is to allow
  the boredom timeout to being extended (globally) when a particular
  system setup requires it.

  I thus attach a patch that allows to change the boredom timeout to the
  "dev_wait_time" (or ROOTDELAY, if it is undefined) via a new '--be-
  patient' option and configuration variables in /etc/default/mountall.

  Corresponding patched Quantal 'mountall' package should be available
  shortly from https://launchpad.net/~cedric.dufour/+archive/ppa/

  Hope it can help.

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