>I'm not disputing that, but this is not nearly so easy to fix as you >suppose, and we're certainly not going to revert the plymouth support which >fixed many other, much higher-impact bugs.
This is the point I don't understand. Why is a "killall plymouth*" bad? This would allow for an easy solution, kill plymouth after remote log in and use the askpass "fallback" as it is currently implemented. Leave everything as it is if I am sitting in front of the machine using plymouth to unlock. I do not want to disable plymouth completely, just for the remote sessions. An more complicated solution would be to introduce a "--accept-pass SECRET" option to plymouth to inject the password from a second console (the remote login) into the currently waiting plymouth(d?) process which asks for the password. Alternatively plymouth could check for the same file askpass is checking, but I would prefer the first solution. But this would definitely mean some more lines of code, I agree. -- Remote unlocking not possible if plymouth is active (Bug or Feature?) https://bugs.launchpad.net/bugs/595648 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
