[systemd-devel] [PATCH] machine: fix uninitialized variable
---
src/machine/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/machine/machine.c b/src/machine/machine.c
index c0fa1b2..7e90d61 100644
--- a/src/machine/machine.c
+++ b/src/machine/machine.c
@@ -353,7 +353,7 @@ int machine_start(Machine *m, sd_bus_message *properties,
sd_bus_error *error) {
static int machine_stop_scope(Machine *m) {
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
char *job = NULL;
-int r;
+int r = 0;
assert(m);
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sysusers: fix uninitialized warning
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 1209a5a..c0af693 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -1312,6 +1312,8 @@ static int parse_line(const char *fname, unsigned line,
const char *buffer) {
h = groups;
break;
+default:
+return -EBADMSG;
}
i-type = action[0];
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: fix uninitialized warning
On Sun, Jul 6, 2014 at 1:33 PM, Ronny Chevalier
chevalier.ro...@gmail.com wrote:
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 1209a5a..c0af693 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -1312,6 +1312,8 @@ static int parse_line(const char *fname, unsigned line,
const char *buffer) {
h = groups;
break;
+default:
+return -EBADMSG;
}
Hm, this code-path should never happen, right? Is your compiler complaining?
-t
i-type = action[0];
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] machine: fix uninitialized variable
Thanks for the report. I pushed a slightly different fix. We generally
prefer to just return directly the value rather than assigning it to r
first (when possible).
-t
On Sun, Jul 6, 2014 at 1:33 PM, Ronny Chevalier
chevalier.ro...@gmail.com wrote:
---
src/machine/machine.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/machine/machine.c b/src/machine/machine.c
index c0fa1b2..7e90d61 100644
--- a/src/machine/machine.c
+++ b/src/machine/machine.c
@@ -353,7 +353,7 @@ int machine_start(Machine *m, sd_bus_message *properties,
sd_bus_error *error) {
static int machine_stop_scope(Machine *m) {
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
char *job = NULL;
-int r;
+int r = 0;
assert(m);
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: fix uninitialized warning
2014-07-06 14:06 GMT+02:00 Tom Gundersen t...@jklm.no:
On Sun, Jul 6, 2014 at 1:33 PM, Ronny Chevalier
chevalier.ro...@gmail.com wrote:
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 1209a5a..c0af693 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -1312,6 +1312,8 @@ static int parse_line(const char *fname, unsigned
line, const char *buffer) {
h = groups;
break;
+default:
+return -EBADMSG;
}
Hm, this code-path should never happen, right? Is your compiler complaining?
-t
Yes because it doesn't know that the IN_SET forbid this. So it just
fix the warning.
i-type = action[0];
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysusers: fix uninitialized warning
On Sun, Jul 6, 2014 at 2:14 PM, Ronny Chevalier
chevalier.ro...@gmail.com wrote:
2014-07-06 14:06 GMT+02:00 Tom Gundersen t...@jklm.no:
On Sun, Jul 6, 2014 at 1:33 PM, Ronny Chevalier
chevalier.ro...@gmail.com wrote:
---
src/sysusers/sysusers.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 1209a5a..c0af693 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -1312,6 +1312,8 @@ static int parse_line(const char *fname, unsigned
line, const char *buffer) {
h = groups;
break;
+default:
+return -EBADMSG;
}
Hm, this code-path should never happen, right? Is your compiler complaining?
-t
Yes because it doesn't know that the IN_SET forbid this. So it just
fix the warning.
Fair enough then. Applied.
Thanks!
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] journal: add LZ4 as optional compressor
On Sun, Jul 06, 2014 at 01:05:29PM +0200, Ronny Chevalier wrote: 2014-07-05 20:56 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: +if (src_size 9) +return -ENOSPC; Also, I am not sure that ENOSPC is appropriate here (and everywhere) ? Why not ENOMEM (since there is no devices involved) ? Goood idea. Thanks for all the comments, I will fix them before next submission. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] journal: add LZ4 as optional compressor
On Sun, Jul 06, 2014 at 02:57:17PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Sun, Jul 06, 2014 at 01:05:29PM +0200, Ronny Chevalier wrote: 2014-07-05 20:56 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: +if (src_size 9) +return -ENOSPC; Also, I am not sure that ENOSPC is appropriate here (and everywhere) ? Why not ENOMEM (since there is no devices involved) ? Goood idea. Actually ENOMEM is used for failed allocations, which we need to distinguish. So it's either E2BIG or ENOSPC. Neither is too good. Thanks for all the comments, I will fix them before next submission. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl escaping of unit names
Hello everybody,
I join this mailing list because I want to discuss extending systemctl
with a method to escape unit names. Currently systemd and systemctl
deal with escaped unit names but there are many potential name sources
which doesn't have out-of-the-box escaping methods.
The issue is a Debian bug related to a service unit for a network
device [0].
Current situation
* systemctl somewhat supports escaping of paths for the unit types
device and mount (in function unit_name_mangle).
* systemctl prevents broken unit names by escaping invalid characters,
but doesn't escape in a transparent way clear_name-escaped_name
(it isn't supposed to do that, because ready-to-use i. e. escaped
unit names are expected)
* systemd does not provide access to the escaping methods in a
practical way for most environments. Although the escape mechanism is
documented, have systemd integrators implement it by themself has some
disadvantages:
1. It can't be simply done in shell only.
2. Lots of independently created escapes potentially lead to errors,
which can cause various effects up to security risks or system
hangs.
Proposal
1. Extend systemctl unit name interpretation with a syntax to escape in
controlled manner, preferably capable of escaping only parts of a
given name to support compound names with verbatim content (given by
users typing anything they imagine in their GUI).
2. The syntax must match this criteria
* no valid C escaped string (to clearly distinguish valid names)
* a possible end token could be easily preencoded in shell and
common languages
3. Document this.
Possible syntax:
Start token: '\' + '#' + number of characters to be encoded (C-lib-parsed) + '#'
End token: none ;-)
Example 1 (UTF-8, decimal number):
Raw: tunnel_\#14#Nürnberg-Link.device
Escaped: tunnel_N\xC3\xBCrnberg\x2DLink.device
Example 2 (Latin1, hex number)
Raw: tunnel_\#0xD#Nürnberg-Link.device
Escaped: tunnel_N\xFCrnberg\x2DLink.device
In POSIX shell:
name=Nürnberg-Link
LC_ALL=C
systemctl start tunnel_\\#${#name}#${name}.device
Reasons
I and possible more in the world are really tired of implementing
nested escapes. Therefore the approach is to give the number of
characters instead of any end token. This is friendly to programmers
and CPUs, isn't it?
Any objections?
Regards,
Gero
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747044
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misleading udev error messages regarding virtual interfaces
Hi, Sorry for a delayed reply. On Thu, Jul 03, 2014 at 01:46:53PM +0200, Lennart Poettering wrote: it would be good to know what the precise error output is you get now with this new change... With systemd-215 udevd still complains (and segfaults) about the virtual interface: -- $ journalctl | grep udevd Jul 06 12:21:05 hermes systemd-udevd[46]: starting version 215 Jul 06 12:21:05 hermes systemd-udevd[226]: starting version 215 Jul 06 12:21:06 hermes systemd-udevd[234]: renamed network interface wlan0 to wlp1s0 Jul 06 12:21:09 hermes systemd-udevd[226]: worker [233] terminated by signal 11 (Segmentation fault) Jul 06 12:21:09 hermes kernel: systemd-udevd[233]: segfault at 0 ip 7ff524a0571a sp 7fffc8a69540 error 4 in libc-2.19.so[7ff524907000+1a4000] Jul 06 12:21:09 hermes systemd-udevd[226]: worker [233] failed while handling '/devices/virtual/net/veth7DH07K' -- As before, things seem to work i.e. I can still see servers inside containers. The kernel is 3.15.3. Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpV0OOFAJwHM.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Is there a reason to forcefully create /etc/mtab?
Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpLVP4W5dKM6.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, L+ (as well as any other + directives) only force-overwrite files if this is needed, e. g. if a symlink points to the wrong desination. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, Jul 6, 2014 at 1:08 PM, Ivan Shapovalov intelfx...@gmail.com wrote: On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, L+ (as well as any other + directives) only force-overwrite files if this is needed, e. g. if a symlink points to the wrong desination. Right. I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sunday 06 July 2014 at 13:13:55, Mike Gilbert wrote: On Sun, Jul 6, 2014 at 1:08 PM, Ivan Shapovalov intelfx...@gmail.com wrote: On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, L+ (as well as any other + directives) only force-overwrite files if this is needed, e. g. if a symlink points to the wrong desination. Right. I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. No, they aren't referring to the same object. This makes a difference when you mount a foreign system image for maintainance. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd fails to get DHCPv4 lease with disabled IPv6
Hi, With systemd-215 networkd fails to set up the DHCPv4 on WAN interface: -- $ journalctl -u systemd-networkd.service | grep wlp1s0 Jul 06 12:21:07 hermes systemd-networkd[355]: wlp1s0 : link configured Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : gained carrier Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : could not start IPv6 router discovery Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : failed -- Interestingly, if I restart networkd, the (DHCPv4) lease _is_ obtained, but the default route is _not_ set. The reason why IPv6 router discovery fails is because I boot with 'ipv6.disable=1' on the kernel cmdline. So, is there now a hard dependency on IPv6 being enabled? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgp83Y_9BlFWH.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl escaping of unit names
On Sun, Jul 06, 2014 at 04:01:52PM +0200, Gero Treuner wrote: Hello everybody, I join this mailing list because I want to discuss extending systemctl with a method to escape unit names. Currently systemd and systemctl deal with escaped unit names but there are many potential name sources which doesn't have out-of-the-box escaping methods. The issue is a Debian bug related to a service unit for a network device [0]. Current situation * systemctl somewhat supports escaping of paths for the unit types device and mount (in function unit_name_mangle). * systemctl prevents broken unit names by escaping invalid characters, but doesn't escape in a transparent way clear_name-escaped_name (it isn't supposed to do that, because ready-to-use i. e. escaped unit names are expected) * systemd does not provide access to the escaping methods in a practical way for most environments. Although the escape mechanism is documented, have systemd integrators implement it by themself has some disadvantages: 1. It can't be simply done in shell only. 2. Lots of independently created escapes potentially lead to errors, which can cause various effects up to security risks or system hangs. Proposal 1. Extend systemctl unit name interpretation with a syntax to escape in controlled manner, preferably capable of escaping only parts of a given name to support compound names with verbatim content (given by users typing anything they imagine in their GUI). Hi, this is not useful. The *instance* part is escaped, because it refers to file system paths and other things which are not controlled by systemd or by users of systemd. Unit *names* are controlled, so it's much more productive to simply set some rules which limit what is allowed. All units have a free-text Description= field, which can hold whatever the user wants. I and possible more in the world are really tired of implementing nested escapes. This is a good reason to implement a helper in systemctl... Therefore the approach is to give the number of characters instead of any end token. This is friendly to programmers and CPUs, isn't it? ... no, a few extra cycles spent on string processing do not really matter. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747044 Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, Jul 06, 2014 at 09:15:28PM +0400, Ivan Shapovalov wrote: On Sunday 06 July 2014 at 13:13:55, Mike Gilbert wrote: On Sun, Jul 6, 2014 at 1:08 PM, Ivan Shapovalov intelfx...@gmail.com wrote: On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, L+ (as well as any other + directives) only force-overwrite files if this is needed, e. g. if a symlink points to the wrong desination. Right. I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. No, they aren't referring to the same object. This makes a difference when you mount a foreign system image for maintainance. Cool :( So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpzLf2uY3vGl.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, Jul 06, 2014 at 01:44:05PM -0400, Leonid Isaev wrote: On Sun, Jul 06, 2014 at 09:15:28PM +0400, Ivan Shapovalov wrote: On Sunday 06 July 2014 at 13:13:55, Mike Gilbert wrote: On Sun, Jul 6, 2014 at 1:08 PM, Ivan Shapovalov intelfx...@gmail.com wrote: On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? Thanks, L+ (as well as any other + directives) only force-overwrite files if this is needed, e. g. if a symlink points to the wrong desination. Right. I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. No, they aren't referring to the same object. This makes a difference when you mount a foreign system image for maintainance. Cool :( So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? No, the latter is fine, or even better. The solution is for systmed-tmpfiles to stop complaining when the fs is readonly. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd fails to get DHCPv4 lease with disabled IPv6
On Sun, Jul 6, 2014 at 7:17 PM, Leonid Isaev lis...@umail.iu.edu wrote: Hi, With systemd-215 networkd fails to set up the DHCPv4 on WAN interface: -- $ journalctl -u systemd-networkd.service | grep wlp1s0 Jul 06 12:21:07 hermes systemd-networkd[355]: wlp1s0 : link configured Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : gained carrier Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : could not start IPv6 router discovery Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : failed -- Interestingly, if I restart networkd, the (DHCPv4) lease _is_ obtained, but the default route is _not_ set. The reason why IPv6 router discovery fails is because I boot with 'ipv6.disable=1' on the kernel cmdline. So, is there now a hard dependency on IPv6 being enabled? Hm, this is unfortunate. In the meantime you can only enable DHCPv4 by setting DHCP=v4 (as opposed to DHCP=yes). -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
Hi, On Sun, Jul 06, 2014 at 08:13:56PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Sun, Jul 06, 2014 at 01:44:05PM -0400, Leonid Isaev wrote: So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? No, the latter is fine, or even better. The solution is for systmed-tmpfiles to stop complaining when the fs is readonly. Well, I actually would like it to complain (that's why I keep / read-only). I'd rather change L+ to L... Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpMEK60D0vTU.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, 06.07.14 13:01, Leonid Isaev (lis...@umail.iu.edu) wrote: Hi, I have a read-only / filesystem and /etc/mtab points to /proc/self/mounts as it should. So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - - ../proc/self/mounts. Is this intentional? Besides failing on ro /, it is also confusing because /etc/mtab can be supplied by a package (in archlinux, the 'filesystem' package), so why tmpfiles instead of including this symlink with systemd? The same question applies to the entire etc.conf: why does tmpfiles touch /etc at all, especially if /etc is already properly set up? tmpfiles won't do anything with the symlink if it already exists and already points to the right place. It will only create the symlink (and possible delete the existing file) if it is missing or not of the righ type or not pointing to the right place. The reason I added this was current behaviour of mount(8), which created /etc/mtab as file if it was missing, and that even with -n. (which got fixed in git upstream afaik, but not yet released?). This is useful when /etc is booted up empty. Anyway, the tmpfiles stuff we do is intended to be a NOP if /etc is already set up properly. Of course, we could be a pinch smarter here, and actually understand relative symlinks when comparing if the existing symlink aready points to the right place... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, 06.07.14 13:44, Leonid Isaev (lis...@umail.iu.edu) wrote: I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. No, they aren't referring to the same object. This makes a difference when you mount a foreign system image for maintainance. Cool :( So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? Well, it's slightly nicer to use relative symlinks for things like this, since this means that if you install an OS hierarchy into some subdirectory somewhere the symlinks will always point to files inside of the hierarchy, and not into the host's OS hierarchy, if you follow what I mean. I figure we should fix tmpfiles to understand that relative and absolute symlinks are both OK, even though it should probably create only relative symlinks. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?
On Sun, 06.07.14 20:13, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: I think the path matching is a little naive; Using a simple string comparison, /proc/self/mounts != ../proc/self/mounts even though both paths refer to the same object. No, they aren't referring to the same object. This makes a difference when you mount a foreign system image for maintainance. Cool :( So... the solution would be for distro packages to ship mtab as a symlink to ../proc instead of /proc? No, the latter is fine, or even better. The solution is for systmed-tmpfiles to stop complaining when the fs is readonly. I am pretty sure we should complain in that case: after all the mtab situation was bad enough that we included it in the taint flags since a long time (the ones printed with systemctl show -p Tainted). I'd really prefer if we would complain if something we are told to do cannot be done. However, I think we should try our best to figure out that what is already in place might already be completely in order, even if that means that we need to teach tmpfiles to understand when relative and absolute symlinks are equivalent. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] arch: add crisv32
On Fri, 04.07.14 20:30, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:
On 03/07/14 14:27, Lennart Poettering wrote:
BTW, to clarify what this is about I will now rename the tupel macro
from ARCH_TUPLE to LIB_ARCH_TUPLE or so, since this is about locations
for shared libraries, nothing else.
Please consider calling it something with MULTIARCH in if you're using
Debian multiarch tuples, maybe LIB_MULTIARCH or LIB_MULTIARCH_TUPLE -
that's the consistent Debian/Ubuntu naming for these tuples (e.g.
DEB_{HOST,BUILD}_MULTIARCH in dpkg-architecture).
In particular, please avoid calling it multilib, which seems to be
fairly consistently used to refer to the lib/lib64/lib32 style of
naming.
Our understanding so far was more that multilib refers to the scheme
which allows you to run executables of different, but compatible archs
on the same system. In this scheme you would have your each executable
only of one arch around, but you can relatively freely combine
executables of different arches into one operating system. An individual
set of libraries would have to be around for every arch you want to run
executables of.
OTOH multiarch refers to a much more extensive scheme where the same
OS image shall be bootable on different (possibly even incompatible)
arches, which means you not only require the set of libraries for each
arch you want to support but also the executables.
Or with other words: on multilib your /usr/bin/ls binary can be i386 or
x86_64 but you have to chose one at a time, and can only installl one at
the same time. On multiarch you could have both binaries around, and
when you boot on an actual 32bit processor you get one, while if you
boot on a 64bit processor you would get the other.
Now, Fedora/Redhat only does multilib in this sense, and they are
using lib64 for x86_64 libraries (and lib for i386). Debian appears
to go for multiarch, with different paths. But it's not the name of
the paths that is the distinction between multilib and multiarch, it's
more about whether you have to make a choice about your executables or
not.
(Personally, multilib sounds realistic and useful to me. multiarch sounds
like one of those things where people do things just because they can,
not because they are truly useful...)
Well, I am particularly interested in getting this into place so that
the debian tuples are used regardless on which distro we built,
i.e. even on distros that lack dpkg-architecture.
I don't think you'll necessarily get that from #ifdefs, although I'd
like to be proved wrong.
Zbigniew tracked done the necessary macros to check for to distuingish
the various ARM ABIs. This means things are looking pretty good on this
front. The only problem: systemd is apparently used on more archs that
Debian has been ported to, and given that we kinda hook into Debian here
for norming the tuples, we probably have to make up temporary tuples for
the remaining archs, until Debian picks up those archs too...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] journal: add LZ4 as optional compressor
On Sat, 05.07.14 20:56, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
-bool uncompress_blob(const void *src, uint64_t src_size,
- void **dst, uint64_t *dst_alloc_size, uint64_t*
dst_size, uint64_t dst_max) {
+int compress_blob_lz4(const void *src, uint64_t src_size, void *dst,
uint64_t *dst_size) {
+#ifdef HAVE_LZ4
+int r;
+assert(src);
+assert(src_size 0);
+assert(dst);
+assert(dst_size);
+
+/* Returns false if we couldn't compress the data or the
+ * compressed result is longer than the original */
+
+if (src_size 9)
+return -ENOSPC;
+
+r = LZ4_compress_limitedOutput(src, dst + 8, src_size, src_size - 8
- 1);
+if (r = 0)
+return -ENOSPC;
Maybe EAGAIN? Would feel a bit like a kernel API then ;-).
+buf1 = malloc(LZ4_BUFSIZE);
+buf2 = malloc(LZ4_BUFSIZE);
+out = malloc(LZ4_COMPRESSBOUND(LZ4_BUFSIZE));
+if (!buf1 || !buf2 || !out)
+return log_oom();
Shouldn't we just return -ENOMEM here? Feels like a library function, not
a program function, hence it should not log at the anything but debug,
really
+out = malloc(4*LZ4_BUFSIZE);
+if (!out)
+return log_oom();
Same here...
Looks good otheriwse.
BTW, have you checked whether reuseing the XZ context might make the XZ
more competitive?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl escaping of unit names
On Sun, 06.07.14 16:01, Gero Treuner
(gt_18_lists.freedesktop@innocircle.com) wrote:
1. Extend systemctl unit name interpretation with a syntax to escape in
controlled manner, preferably capable of escaping only parts of a
given name to support compound names with verbatim content (given by
users typing anything they imagine in their GUI).
2. The syntax must match this criteria
* no valid C escaped string (to clearly distinguish valid names)
* a possible end token could be easily preencoded in shell and
common languages
3. Document this.
Possible syntax:
Start token: '\' + '#' + number of characters to be encoded (C-lib-parsed) +
'#'
End token: none ;-)
Example 1 (UTF-8, decimal number):
Raw: tunnel_\#14#Nürnberg-Link.device
Escaped: tunnel_N\xC3\xBCrnberg\x2DLink.device
Example 2 (Latin1, hex number)
Raw: tunnel_\#0xD#Nürnberg-Link.device
Escaped: tunnel_N\xFCrnberg\x2DLink.device
In POSIX shell:
name=Nürnberg-Link
LC_ALL=C
systemctl start tunnel_\\#${#name}#${name}.device
Reasons
I and possible more in the world are really tired of implementing
nested escapes. Therefore the approach is to give the number of
characters instead of any end token. This is friendly to programmers
and CPUs, isn't it?
I'd prefer if we wouldn't make things more complex by inventing new
syntaxes. I think I'd prefer if we'd simply add a new tool
systemd-escape which escapes or unescapes all parameters, depending on
some switch. (And maybe we could even add an extra switch to allow users
to query whant unit_name_mangle() would normally do, without actually
using it immediately.) With that in place you could then do:
systemctl status foobar@$(systemctl-escape $XYZ).service
Which feels quite OK to me, and is reasonably simple to understand.
(And I think I would prefer this as seperate tool from systemctl -- and
not just as new verbs), since this appears to not be directly related to
what systemctl otherwise does which is control the system...)
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl escaping of unit names
2014-07-06 22:12 GMT+02:00 Lennart Poettering lenn...@poettering.net:
(And I think I would prefer this as seperate tool from systemctl -- and
not just as new verbs), since this appears to not be directly related to
what systemctl otherwise does which is control the system...)
I ended up with something like this. See attached patch.
I've put it in /lib/systemd/ as I wasn't sure at that time that it
would be accepted upstream so I didn't want to put it in $PATH
If there is consensus, I'll just move it from
rootlibexec_PROGRAMS to rootbin_PROGRAMS
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
From c8d500e547063b0d0480d34869ee6fd97ec0e01a Mon Sep 17 00:00:00 2001
From: Michael Biebl bi...@debian.org
Date: Wed, 4 Jun 2014 01:57:11 +0200
Subject: [PATCH] Add systemd-escape helper
---
Makefile.am | 8
src/escape/escape.c | 25 +
2 files changed, 33 insertions(+)
create mode 100644 src/escape/escape.c
diff --git a/Makefile.am b/Makefile.am
index 8af619c..9b319c9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -349,6 +349,7 @@ dist_kernelinstall_SCRIPTS = \
rootlibexec_PROGRAMS = \
systemd \
+ systemd-escape \
systemd-cgroups-agent \
systemd-initctl \
systemd-update-utmp \
@@ -2003,6 +2004,13 @@ systemd_cgroups_agent_LDADD = \
libsystemd-shared.la
# --
+systemd_escape_SOURCES = \
+ src/escape/escape.c
+
+systemd_escape_LDADD = \
+ libsystemd-shared.la
+# -
+
systemctl_SOURCES = \
src/systemctl/systemctl.c
diff --git a/src/escape/escape.c b/src/escape/escape.c
new file mode 100644
index 000..1db6a0f
--- /dev/null
+++ b/src/escape/escape.c
@@ -0,0 +1,25 @@
+#include stdio.h
+#include stdlib.h
+
+#include log.h
+#include unit-name.h
+
+int main(int argc, char *argv[]) {
+char *escaped_name = NULL;
+
+if (argc != 2) {
+log_error(This program requires on argument.);
+return EXIT_FAILURE;
+}
+
+escaped_name = unit_name_escape(argv[1]);
+
+if (!escaped_name) {
+log_error(Failed to escape name.);
+return EXIT_FAILURE;
+}
+
+printf(%s, escaped_name);
+
+return EXIT_SUCCESS;
+}
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl escaping of unit names
2014-07-06 22:28 GMT+02:00 Michael Biebl mbi...@gmail.com: If there is consensus, I'll just move it from rootlibexec_PROGRAMS to rootbin_PROGRAMS And moving it to $PATH probably means adding a short man page -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl escaping of unit names
On Sun, Jul 06, 2014 at 10:28:55PM +0200, Michael Biebl wrote:
+#include stdio.h
+#include stdlib.h
+
+#include log.h
+#include unit-name.h
+
+int main(int argc, char *argv[]) {
+char *escaped_name = NULL;
+
+if (argc != 2) {
+log_error(This program requires on argument.);
an or one?
+return EXIT_FAILURE;
+}
+
+escaped_name = unit_name_escape(argv[1]);
+
+if (!escaped_name) {
+log_error(Failed to escape name.);
Maybe just log_oom()?
+return EXIT_FAILURE;
+}
+
+printf(%s, escaped_name);
+
+return EXIT_SUCCESS;
What about adding a --template parameter, to be used as
systemd-escape --template myunit@.service /some/path -
myunit@some-path.service
?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl escaping of unit names
2014-07-06 23:22 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
On Sun, Jul 06, 2014 at 10:28:55PM +0200, Michael Biebl wrote:
+#include stdio.h
+#include stdlib.h
+
+#include log.h
+#include unit-name.h
+
+int main(int argc, char *argv[]) {
+char *escaped_name = NULL;
+
+if (argc != 2) {
+log_error(This program requires on argument.);
an or one?
Ah, right. Thanks for spotting that typo.
+return EXIT_FAILURE;
+}
+
+escaped_name = unit_name_escape(argv[1]);
+
+if (!escaped_name) {
+log_error(Failed to escape name.);
Maybe just log_oom()?
Ok.
+return EXIT_FAILURE;
+}
+
+printf(%s, escaped_name);
+
+return EXIT_SUCCESS;
What about adding a --template parameter, to be used as
systemd-escape --template myunit@.service /some/path -
myunit@some-path.service
Why not. Let me add that including a short man page.
Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] journal: add LZ4 as optional compressor
On Sun, Jul 06, 2014 at 09:47:02PM +0200, Lennart Poettering wrote:
On Sat, 05.07.14 20:56, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
-bool uncompress_blob(const void *src, uint64_t src_size,
- void **dst, uint64_t *dst_alloc_size, uint64_t*
dst_size, uint64_t dst_max) {
+int compress_blob_lz4(const void *src, uint64_t src_size, void *dst,
uint64_t *dst_size) {
+#ifdef HAVE_LZ4
+int r;
+assert(src);
+assert(src_size 0);
+assert(dst);
+assert(dst_size);
+
+/* Returns false if we couldn't compress the data or the
+ * compressed result is longer than the original */
+
+if (src_size 9)
+return -ENOSPC;
+
+r = LZ4_compress_limitedOutput(src, dst + 8, src_size, src_size -
8 - 1);
+if (r = 0)
+return -ENOSPC;
Maybe EAGAIN? Would feel a bit like a kernel API then ;-).
I think it would be confusing... But I see now that there's
EFBIG and ENOBUFS, which seem to fit much better: file to big, no space in
buffer.
+buf1 = malloc(LZ4_BUFSIZE);
+buf2 = malloc(LZ4_BUFSIZE);
+out = malloc(LZ4_COMPRESSBOUND(LZ4_BUFSIZE));
+if (!buf1 || !buf2 || !out)
+return log_oom();
Shouldn't we just return -ENOMEM here? Feels like a library function, not
a program function, hence it should not log at the anything but debug,
really
+out = malloc(4*LZ4_BUFSIZE);
+if (!out)
+return log_oom();
Same here...
This is in the fd streaming code, which outputs error messages on its own.
They
could be moved to the caller, but code would get more complicated with little
gain.
I'll keep it this way for now, since there's only one caller and it doesn't
really
matter.
Looks good otheriwse.
BTW, have you checked whether reuseing the XZ context might make the XZ
more competitive?
No, I haven't. But I seriously doubt how it could improve things enough to
make a difference ( 2 orders).
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd fails to get DHCPv4 lease with disabled IPv6
On Sun, Jul 06, 2014 at 08:43:01PM +0200, Tom Gundersen wrote: On Sun, Jul 6, 2014 at 7:17 PM, Leonid Isaev lis...@umail.iu.edu wrote: Hi, With systemd-215 networkd fails to set up the DHCPv4 on WAN interface: -- $ journalctl -u systemd-networkd.service | grep wlp1s0 Jul 06 12:21:07 hermes systemd-networkd[355]: wlp1s0 : link configured Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : gained carrier Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : could not start IPv6 router discovery Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : failed -- Interestingly, if I restart networkd, the (DHCPv4) lease _is_ obtained, but the default route is _not_ set. The reason why IPv6 router discovery fails is because I boot with 'ipv6.disable=1' on the kernel cmdline. So, is there now a hard dependency on IPv6 being enabled? Hm, this is unfortunate. In the meantime you can only enable DHCPv4 by setting DHCP=v4 (as opposed to DHCP=yes). That worked... thanks. BTW, is yes/true still a valid argument for DHCP (because the manpage says otherwise)? Best, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpnK_trkgcLi.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd fails to get DHCPv4 lease with disabled IPv6
On Sun, Jul 6, 2014 at 11:52 PM, Leonid Isaev lis...@umail.iu.edu wrote: On Sun, Jul 06, 2014 at 08:43:01PM +0200, Tom Gundersen wrote: On Sun, Jul 6, 2014 at 7:17 PM, Leonid Isaev lis...@umail.iu.edu wrote: Hi, With systemd-215 networkd fails to set up the DHCPv4 on WAN interface: -- $ journalctl -u systemd-networkd.service | grep wlp1s0 Jul 06 12:21:07 hermes systemd-networkd[355]: wlp1s0 : link configured Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : gained carrier Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : could not start IPv6 router discovery Jul 06 12:21:08 hermes systemd-networkd[355]: wlp1s0 : failed -- Interestingly, if I restart networkd, the (DHCPv4) lease _is_ obtained, but the default route is _not_ set. The reason why IPv6 router discovery fails is because I boot with 'ipv6.disable=1' on the kernel cmdline. So, is there now a hard dependency on IPv6 being enabled? Hm, this is unfortunate. In the meantime you can only enable DHCPv4 by setting DHCP=v4 (as opposed to DHCP=yes). That worked... thanks. BTW, is yes/true still a valid argument for DHCP (because the manpage says otherwise)? yes is a synonym for both and no for none. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-sysusers and gshadow
Hi, Shouldn't systemd-sysusers update /etc/gshadow when adding 'basic' groups? From sysusers.c I don't see that gshadow (and shadow) is updated, and this seems to cause problems on package updates. Consider the following scenario: 1. A package is updated, so timestamp of /usr gets ahead of /etc/.updated. 2. On next boot, new groups are added to /etc/group. In the case of archlinux these are dialout, tape and cdrom -- which I had to manually groupdel. 3. gshadow is out-of-sync with group, so routine cron-based grpck fails. Does it mean that on each update, a package manager should touch /etc/.updated? Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpTYZ8wwQ0je.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] journal: add LZ4 as optional compressor
Looks good otheriwse. BTW, have you checked whether reuseing the XZ context might make the XZ more competitive? No, I haven't. But I seriously doubt how it could improve things enough to make a difference ( 2 orders). I generated some coredumps, fixed some messages, and things seem to still work... Pushed now, but still disabled by default. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] using /dev/root in fstab
On Mon, Jul 7, 2014 at 7:29 AM, microcai micro...@fedoraproject.org wrote: a long ago, /dev/root is an symblic to real root device. no matter it is on NFS or HDD, we can use /dev/root / auto defaults 0 0 in fstab to mount / as readwrite. Is it any better than just using 'rw' in the kernel command line? -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
