[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
1104156 at bugs.launchpad.net
Mon Feb 4 10:40:51 UTC 2013
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
--
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
More information about the foundations-bugs
mailing list