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

[Cédric Dufour]

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.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "mountall.disable_impatient_behavior.patch" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Steve Langasek (vorlon)]

I don't think this bug belongs to mountall. mountall shouldn't have to know anything about cryptsetup; plymouth is responsible for brokering the messages from multiple clients. If it would make more sense to hide the mountall 'press this key' prompt while the passphrase prompt is being displayed, it should be possible to implement this there.

[Cédric Dufour (cdufour-keyword-ubuntu-086000)]

Hello,

In the case of this cryptsetup(passphrase)/mountall(prompt) concurrency, I agree with you.

Note that this issue also presents itself when not using plymouth (though the passphrase prompt would "hide" the mountall "boredom" until the 'return' key is pressed). The mountall "boredom" message will pop up none the less after the passphrase is (successfully or unsucessfully) provided.

However, I think that hard-coding a 3-second timeout in the source code is not a good idea. Timeouts should be configureable.

Thanks and cheers

[Steve Langasek (vorlon)]

On Mon, Feb 04, 2013 at 10:40:51AM -0000, Cédric Dufour wrote:
> Note that this issue also presents itself when not using plymouth
> (though the passphrase prompt would "hide" the mountall "boredom" until
> the 'return' key is pressed).

There is no case in which plymouth is not used.

> However, I think that hard-coding a 3-second timeout in the source code
> is not a good idea. Timeouts should be configureable.

This is an unsubstantiated "should". This is merely the timeout until
which the user is given the opportunity to skip a disk's mounting at boot;
allowing configurability of such a timeout really doesn't add much value.

[Cédric Dufour (cdufour-keyword-ubuntu-086000)]

Hello Steve,

Thanks for your comments.

As for "no case in which plymouth is not used": I'm afraid I grossly misunderstand when plymouth is used.
I experimented the "command-line" behavior I described above when booting in "recovery mode".
Is plymouth also used in "recovery mode" or when one removes the 'splash' parameter from the kernel boot options?
cryptsetup "provisions" for when plymouth is not installed/active; in '/lib/cryptsetup/cryptdisks.functions', function 'do_luks':
[...]
                if [ -x /bin/plymouth ] && plymouth --ping; then
                        KEYSCRIPT="plymouth ask-for-password --prompt"
                        keyscriptarg=$(printf "$keyscriptarg")
                else
                        KEYSCRIPT="/lib/cryptsetup/askpass"
                fi
[...]

But not a big issue I agree. Merely an "esthetic" one.

[Steve Langasek (vorlon)]

On Mon, Feb 04, 2013 at 07:43:27PM -0000, Cédric Dufour wrote:

> Is plymouth also used in "recovery mode" or when one removes the 'splash'
> parameter from the kernel boot options?

Yes, it is. We still need plymouth, even when we're not using the graphical
splash functionality.

> cryptsetup "provisions" for when plymouth is not installed/active; in
> '/lib/cryptsetup/cryptdisks.functions', function 'do_luks':

True. This is for compatibility between Ubuntu and Debian, since Debian
does not require plymouth as part of the base system (currently).

[Sebastien Bacher (seb128)]

(unsubscribing the sponsor team, Steve already reviewed/commented on the patch and it seems it's not the right fix for the issue so doesn't need to be sponsored)

[Cédric Dufour (cdufour-keyword-ubuntu-086000)]

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

[Steve Langasek (vorlon)]

On Fri, Mar 01, 2013 at 01:15:04PM -0000, Cédric Dufour wrote:
> 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?

In the case in question, the message we want to suppress uses the 'keys:'
prefix, which we know is associated with a watch-keystroke command. So in
the case of the Ubuntu plymouth themes that support 'keys:', we can hide
those messages when there's a higher-priority prompt being displayed.

It won't work with other themes, but then the behavior you get with
mountall's text display is buggy with those other themes already.