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

2013-03-01 Thread Steve Langasek
On Fri, Mar 01, 2013 at 01:15:04PM -, 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

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

2013-03-01 Thread 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

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

2013-02-05 Thread Sebastien Bacher
(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) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.ne

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

2013-02-04 Thread Steve Langasek
On Mon, Feb 04, 2013 at 07:43:27PM -, 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 "pr

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

2013-02-04 Thread Cédric Dufour
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 rem

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

2013-02-04 Thread Steve Langasek
On Mon, Feb 04, 2013 at 10:40:51AM -, 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

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

2013-02-04 Thread Cédric Dufour
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

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

2013-02-02 Thread Steve Langasek
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,

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

2013-01-24 Thread Ubuntu Foundations Team Bug Bot
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 n