On Mon, 28.04.14 17:22, Przemyslaw Rudy (pru...@o2.pl) wrote:
This patch is a proposal for a problem with not falling back to password
request
if the device with unlocking key for crypt volumes is not mounted for
defined time.
Can you elaborate on the usecase? I mean, this would
On Mon, Apr 28, 2014 at 12:46 AM, Przemek Rudy pru...@o2.pl wrote:
This patch is a proposal for a problem with not falling back to password
request
if the device with unlocking key for crypt volumes is not mounted for defined
time.
Looks good to me (but I didn't test it). Only one minor nit
Hi Tom,
Sure, I'll get rid of this signed-off soon and re-send.
It has been tested with fedora 20 for all three options:
- with device inserted
- with device removed during startup but inserted before the mount timeout
- with device removed
Thanks
Przemek
On 04/28/2014 10:15 AM, Tom Gundersen
On Sun, 27.04.14 23:46, Przemek Rudy (pru...@o2.pl) wrote:
This patch is a proposal for a problem with not falling back to password
request
if the device with unlocking key for crypt volumes is not mounted for
defined time.
Can you elaborate on the usecase? I mean, this would still result
Hi Lennart,
inline...
On 04/28/2014 04:31 PM, Lennart Poettering wrote:
On Sun, 27.04.14 23:46, Przemek Rudy (pru...@o2.pl) wrote:
This patch is a proposal for a problem with not falling back to password
request
if the device with unlocking key for crypt volumes is not mounted for
This patch is a proposal for a problem with not falling back to password request
if the device with unlocking key for crypt volumes is not mounted for defined
time.
---
src/core/dbus-unit.c | 1 +
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/load-fragment.c
