On Sun, 25.05.14 12:39, Przemek Rudy (pru...@o2.pl) wrote:
-Set *manager_get_units_requiring_mounts_for(Manager *m, const char *path) {
+Set *manager_get_units_need_mounts_for(Manager *m, const char *path,
bool strong) {
Please don't invent new bools halfway. Please always use the same logic
On 21.05.2014 10:03, Lennart Poettering wrote:
On Sun, 18.05.14 19:36, Przemek Rudy (pru...@o2.pl) wrote:
diff --git a/src/core/automount.c b/src/core/automount.c
index 65e6d6f..d4359b9 100644
--- a/src/core/automount.c
+++ b/src/core/automount.c
@@ -124,7 +124,7 @@ static int
On 05/27/2014 01:37 PM, Harald Hoyer wrote:
On 21.05.2014 10:03, Lennart Poettering wrote:
On Sun, 18.05.14 19:36, Przemek Rudy (pru...@o2.pl) wrote:
diff --git a/src/core/automount.c b/src/core/automount.c
index 65e6d6f..d4359b9 100644
--- a/src/core/automount.c
+++ b/src/core/automount.c
Updated using 'UNIT_REQUIRES' instead 'true'.
---
src/core/automount.c | 2 +-
src/core/dbus-unit.c | 3 +-
src/core/load-fragment-gperf.gperf.m4 | 3 +-
src/core/load-fragment.c | 8 +--
src/core/load-fragment.h | 2 +-
On Sun, 18.05.14 19:36, Przemek Rudy (pru...@o2.pl) wrote:
diff --git a/src/core/automount.c b/src/core/automount.c
index 65e6d6f..d4359b9 100644
--- a/src/core/automount.c
+++ b/src/core/automount.c
@@ -124,7 +124,7 @@ static int automount_add_mount_links(Automount *a) {
if (r 0)
Combined into one ptach.
I see it is not clear how this patch is related to the cryptsetup password
timeout. Note the cryptsetup timeout is done by the cryptsetup service. Thus it
will occur only if the cryptsetup is reached and the key is not valid. But that
is true only for the key file on
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
12 matches
Mail list logo
