[systemd-devel] [gummiboot][PATCH 3/5] configure: add AARCH64 support

2015-04-11 Thread Koen Kooi
This is just plumbing to add ARCH_AARCH64 for makefile tests and
defining the machine name.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 configure.ac | 4 
 1 file changed, 4 insertions(+)

diff --git a/configure.ac b/configure.ac
index 27bbe1d..c2077b1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -51,6 +51,7 @@ dnl Define ARCH_NAME conditionals
 SET_ARCH(IA32, i*86*)
 SET_ARCH(X86_64, x86_64*)
 SET_ARCH(IA64, ia64*)
+SET_ARCH(AARCH64, aarch64*)
 
 ARCH=`echo $host | sed s/\(-\).*$//`
 
@@ -61,6 +62,9 @@ AM_COND_IF(ARCH_IA32, [
 AM_COND_IF(ARCH_X86_64, [
 MACHINE_TYPE_NAME=x64])
 
+AM_COND_IF(ARCH_AARCH64, [
+MACHINE_TYPE_NAME=aa64])
+
 AC_SUBST([ARCH])
 AC_SUBST([MACHINE_TYPE_NAME])
 
-- 
2.0.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [gummiboot][PATCH 4/5] util: confine x86 asm to x86 architectures

2015-04-11 Thread Koen Kooi
Also add a stub function that just returns '1' to avoid missing symbols.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 src/efi/util.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/efi/util.c b/src/efi/util.c
index 689bc7c..6ce1f18 100644
--- a/src/efi/util.c
+++ b/src/efi/util.c
@@ -33,14 +33,17 @@ UINT64 ticks_read(VOID) {
 __asm__ volatile (rdtsc : =a (a), =d (d));
 return (d  32) | a;
 }
-#endif
-
-#ifdef __i386__
+#elif __i386__
 UINT64 ticks_read(VOID) {
 UINT64 val;
 __asm__ volatile (rdtsc : =A (val));
 return val;
 }
+#else
+UINT64 ticks_read(VOID) {
+UINT64 val = 1;
+return val;
+}
 #endif
 
 /* count TSC ticks during a millisecond delay */
-- 
2.0.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [gummiboot][PATCH 1/5] Makefile: support non-x86 builds

2015-04-11 Thread Koen Kooi
Move the no-mmx/no-sse CFLAGS to X86-64 and IA32 defines in preparation
for ARM32 and Aarch64 support.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 Makefile.am | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 6568a35..2cca313 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -94,17 +94,23 @@ efi_cflags = \
-ffreestanding \
-fno-strict-aliasing \
-fno-stack-protector \
-   -Wsign-compare \
-   -mno-sse \
-   -mno-mmx
+   -Wsign-compare
 
 if ARCH_X86_64
 efi_cflags += \
-mno-red-zone \
+   -mno-sse \
+   -mno-mmx
-DEFI_FUNCTION_WRAPPER \
-DGNU_EFI_USE_MS_ABI
 endif
 
+if ARCH_IA32
+efi_cflags += \
+   -mno-sse \
+   -mno-mmx
+endif
+
 efi_ldflags = \
$(EFI_LDFLAGS) \
-T $(EFI_LDS_DIR)/elf_$(ARCH)_efi.lds \
-- 
2.0.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [gummiboot][PATCH 5/5] Makefile.am: Add support for AARCH64

2015-04-11 Thread Koen Kooi
Aarch64 and ARM32 lack an EFI capable objcopy, so use the ldflags + -O
binary trick gnu-efi and the Red Hat shimloader are using.

Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 Makefile.am | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 2cca313..eba5ec4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -121,6 +121,17 @@ efi_ldflags = \
-L $(EFI_LIB_DIR) \
$(EFI_LDS_DIR)/crt0-efi-$(ARCH).o
 
+# Aarch64 and ARM32 don't have an EFI capable objcopy
+if ARCH_AARCH64
+efi_ldflags += \
+   --defsym=EFI_SUBSYSTEM=0xa
+
+FORMAT = -O binary
+else
+FORMAT = --target=efi-app-$(ARCH) 
+endif
+
+
 # 
--
 gummiboot_headers = \
src/efi/util.h \
@@ -156,7 +167,7 @@ $(gummiboot_solib): $(gummiboot_objects)
 $(gummiboot): $(gummiboot_solib)
$(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
  -j .dynsym -j .rel -j .rela -j .reloc \
- --target=efi-app-$(ARCH) $ $@
+ $(FORMAT) $ $@
 
 # 
--
 stub_headers = \
@@ -191,7 +202,7 @@ $(stub_solib): $(stub_objects)
 $(stub): $(stub_solib)
$(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
  -j .dynsym -j .rel -j .rela -j .reloc \
- --target=efi-app-$(ARCH) $ $@
+ $(FORMAT) $ $@
 
 # 
--
 CLEANFILES += test-disk.img
-- 
2.0.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [gummiboot][PATCH 2/5] util: use x86 ASM only on x86(-64) platforms.

2015-04-11 Thread Koen Kooi
Signed-off-by: Koen Kooi koen.k...@linaro.org
---
 src/efi/util.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/efi/util.c b/src/efi/util.c
index ba5ed7d..689bc7c 100644
--- a/src/efi/util.c
+++ b/src/efi/util.c
@@ -33,7 +33,9 @@ UINT64 ticks_read(VOID) {
 __asm__ volatile (rdtsc : =a (a), =d (d));
 return (d  32) | a;
 }
-#else
+#endif
+
+#ifdef __i386__
 UINT64 ticks_read(VOID) {
 UINT64 val;
 __asm__ volatile (rdtsc : =A (val));
-- 
2.0.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [gummiboot][PATCH 1/5] Makefile: support non-x86 builds

2015-04-11 Thread Koen Kooi
On 11 April 2015 at 11:41, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Sat, Apr 11, 2015 at 10:23 AM, Koen Kooi koen.k...@linaro.org wrote:
 Move the no-mmx/no-sse CFLAGS to X86-64 and IA32 defines in preparation
 for ARM32 and Aarch64 support.

 Signed-off-by: Koen Kooi koen.k...@linaro.org
 ---
  Makefile.am | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

 Applied to systemd-git.

Thanks!

 Note that there is no gummiboot repository, anymore.

I realized that after sending the patches, I'll try to work against
the systemd tree in the future.

regards,

Koen


 Thanks
 David

 diff --git a/Makefile.am b/Makefile.am
 index 6568a35..2cca313 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -94,17 +94,23 @@ efi_cflags = \
 -ffreestanding \
 -fno-strict-aliasing \
 -fno-stack-protector \
 -   -Wsign-compare \
 -   -mno-sse \
 -   -mno-mmx
 +   -Wsign-compare

  if ARCH_X86_64
  efi_cflags += \
 -mno-red-zone \
 +   -mno-sse \
 +   -mno-mmx
 -DEFI_FUNCTION_WRAPPER \
 -DGNU_EFI_USE_MS_ABI
  endif

 +if ARCH_IA32
 +efi_cflags += \
 +   -mno-sse \
 +   -mno-mmx
 +endif
 +
  efi_ldflags = \
 $(EFI_LDFLAGS) \
 -T $(EFI_LDS_DIR)/elf_$(ARCH)_efi.lds \
 --
 2.0.1

 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Koen Kooi

Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 0/2] Empty environment variables in unit files work

2014-11-20 Thread Koen Kooi

 Op 19 nov. 2014, om 19:44 heeft Iago López Galeiras i...@endocode.com het 
 volgende geschreven:
 
 with this file:
 
 [Unit]
 Description=Test empty variables
 
 [Service]
 Environment=TEST= TEST2=
 ExecStart=/bin/bash -c env
 
 [Install]
 WantedBy=default.target
 
 I get this output:
 
 Nov 19 16:59:07 arch-tree systemd[1]: Starting Test empty variables...
 Nov 19 16:59:07 arch-tree systemd[1]: Started Test empty variables.
 Nov 19 16:59:07 arch-tree bash[131]: 
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
 Nov 19 16:59:07 arch-tree bash[131]: PWD=/
 Nov 19 16:59:07 arch-tree bash[131]: TEST=
 Nov 19 16:59:07 arch-tree bash[131]: SHLVL=1
 Nov 19 16:59:07 arch-tree bash[131]: TEST2=
 Nov 19 16:59:07 arch-tree bash[131]: _=/usr/sbin/env
 
 
 Iago López Galeiras (2):
  test: empty environment variables in unit files

Nitpick: 'empty' looks like a verb there, changing it to 'test: support empty 
environment variables in unit files' (like the TODO entry) would avoid a lot of 
confusion.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [question] networkd: Any support for hooks?

2014-10-03 Thread Koen Kooi

Op 2 okt. 2014, om 15:29 heeft Tom Gundersen t...@jklm.no het volgende 
geschreven:

 On Thu, Oct 2, 2014 at 2:20 PM, Lennart Poettering
 lenn...@poettering.net wrote:
 On Thu, 02.10.14 13:00, Koen Kooi (k...@dominion.thruhere.net) wrote:
 
 
 Op 2 okt. 2014, om 07:36 heeft Tom Gundersen t...@jklm.no het volgende 
 geschreven:
 
 Hi Cameron,
 
 On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com 
 wrote:
 ifupdown [1], NetworkManager, and WICD all support hooks for when a
 network interface is configured or deconfigured (before and after
 these actions).
 
 Are there any plans to support something along these lines? If so,
 what will that look like?
 
 If there are no plans, how do networkd's developers feel about adding
 the feature (will not merge, or will accept patches, etc.) ?
 
 I am sceptical to adding hooks, so would need a lot of convincing.
 What we do, however, is to expose the configuration state using the
 sd-network C API, which external programs can watch and react on (see
 how timesyncd and resolved currently works).
 
 For specific hooks, we may want to integrate them directly upstream,
 but it really depends on what functionality you have in mind.
 
 For my use-case (fiber 'modem' doing PPPoE over vlan) I'd like to
 launch accelpppd to do PPPoE as soon as the vlan is up. That get me
 my internet back a few ms earlier when rebooting the modem :)
 
 Hmm, Tom has some patches adding native pppoe support to networkd
 (without pppd), iirc. Might be a better option to finish those.
 
 Tom?
 
 Yes, I have some WIP patches to do PPPoE directly from networkd [0].
 If you are interested in using this, I'll clean it up and get it ready
 for merging/testing.

I'm certainly interested, but I can't promise to test it in a timely fashion 
since it needs to run on my fiber modem.

regards,

Koen

 
 Cheers,
 
 Tom
 
 [0]: http://cgit.freedesktop.org/~tomegun/systemd/log/?h=ppp

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [question] networkd: Any support for hooks?

2014-10-02 Thread Koen Kooi

Op 2 okt. 2014, om 07:36 heeft Tom Gundersen t...@jklm.no het volgende 
geschreven:

 Hi Cameron,
 
 On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com 
 wrote:
 ifupdown [1], NetworkManager, and WICD all support hooks for when a
 network interface is configured or deconfigured (before and after
 these actions).
 
 Are there any plans to support something along these lines? If so,
 what will that look like?
 
 If there are no plans, how do networkd's developers feel about adding
 the feature (will not merge, or will accept patches, etc.) ?
 
 I am sceptical to adding hooks, so would need a lot of convincing.
 What we do, however, is to expose the configuration state using the
 sd-network C API, which external programs can watch and react on (see
 how timesyncd and resolved currently works).
 
 For specific hooks, we may want to integrate them directly upstream,
 but it really depends on what functionality you have in mind.

For my use-case (fiber 'modem' doing PPPoE over vlan) I'd like to launch 
accelpppd to do PPPoE as soon as the vlan is up. That get me my internet back a 
few ms earlier when rebooting the modem :)

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 2/2] logind: add support for gpio-keys Power Button

2014-09-27 Thread Koen Kooi
This might be too broad since it will listen on *all* gpio-keys based
input devices for a power button press, but such is life.

root@arietta-g25:~# udevadm info -a /dev/input/event0

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/keys/input/input0/event0':
KERNEL==event0
SUBSYSTEM==input
DRIVER==

  looking at parent device '/devices/keys/input/input0':
KERNELS==input0
SUBSYSTEMS==input
DRIVERS==
ATTRS{name}==keys
ATTRS{phys}==gpio-keys/input0
ATTRS{uniq}==
ATTRS{properties}==0

  looking at parent device '/devices/keys':
KERNELS==keys
SUBSYSTEMS==platform
DRIVERS==gpio-keys
ATTRS{keys}==116
ATTRS{switches}==
ATTRS{driver_override}==(null)
ATTRS{disabled_keys}==
ATTRS{disabled_switches}==
---
 src/login/70-power-switch.rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/login/70-power-switch.rules b/src/login/70-power-switch.rules
index 695d246..7bbe096 100644
--- a/src/login/70-power-switch.rules
+++ b/src/login/70-power-switch.rules
@@ -11,5 +11,6 @@ SUBSYSTEM==input, KERNEL==event*, SUBSYSTEMS==acpi, 
TAG+=power-switch
 SUBSYSTEM==input, KERNEL==event*, KERNELS==thinkpad_acpi, 
TAG+=power-switch
 SUBSYSTEM==input, KERNEL==event*, ATTRS{name}==twl4030_pwrbutton, 
TAG+=power-switch
 SUBSYSTEM==input, KERNEL==event*, ATTRS{name}==tps65217_pwr_but, 
TAG+=power-switch
+SUBSYSTEM==input, KERNEL==event*, ATTRS{name}==keys, TAG+=power-switch
 
 LABEL=power_switch_end
-- 
1.9.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH 1/2] logind: add support for TPS65217 Power Button

2014-09-27 Thread Koen Kooi
This PMIC is found on TI AM335x based boards like the beaglebone and
beaglebone black.

root@beaglebone-white:~# udevadm info -a /dev/input/event0

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device
'/devices/ocp.3/44e0b000.i2c/i2c-0/0-0024/input/input0/event0':
KERNEL==event0
SUBSYSTEM==input
DRIVER==

  looking at parent device
'/devices/ocp.3/44e0b000.i2c/i2c-0/0-0024/input/input0':
KERNELS==input0
SUBSYSTEMS==input
DRIVERS==
ATTRS{name}==tps65217_pwr_but
ATTRS{phys}==
ATTRS{uniq}==
ATTRS{properties}==0

  looking at parent device '/devices/ocp.3/44e0b000.i2c/i2c-0/0-0024':
KERNELS==0-0024
SUBSYSTEMS==i2c
DRIVERS==tps65217
ATTRS{name}==tps65217

  looking at parent device '/devices/ocp.3/44e0b000.i2c/i2c-0':
KERNELS==i2c-0
SUBSYSTEMS==i2c
DRIVERS==
ATTRS{name}==OMAP I2C adapter

  looking at parent device '/devices/ocp.3/44e0b000.i2c':
KERNELS==44e0b000.i2c
SUBSYSTEMS==platform
DRIVERS==omap_i2c

  looking at parent device '/devices/ocp.3':
KERNELS==ocp.3
SUBSYSTEMS==platform
DRIVERS==
---
 src/login/70-power-switch.rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/login/70-power-switch.rules b/src/login/70-power-switch.rules
index a6997f7..695d246 100644
--- a/src/login/70-power-switch.rules
+++ b/src/login/70-power-switch.rules
@@ -10,5 +10,6 @@ ACTION==remove, GOTO=power_switch_end
 SUBSYSTEM==input, KERNEL==event*, SUBSYSTEMS==acpi, TAG+=power-switch
 SUBSYSTEM==input, KERNEL==event*, KERNELS==thinkpad_acpi, 
TAG+=power-switch
 SUBSYSTEM==input, KERNEL==event*, ATTRS{name}==twl4030_pwrbutton, 
TAG+=power-switch
+SUBSYSTEM==input, KERNEL==event*, ATTRS{name}==tps65217_pwr_but, 
TAG+=power-switch
 
 LABEL=power_switch_end
-- 
1.9.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Having systemd shutdown when pressing the power button

2014-09-27 Thread Koen Kooi

Op 28 aug. 2014, om 15:42 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Thu, 28.08.14 10:50, Koen Kooi (k...@dominion.thruhere.net) wrote:
 
 Hi,
 
 Heya,
 
 I am working on a system (http://www.acmesystems.it/arietta) where I
 hooked up the button as a power key:
 
  
 https://github.com/koenkooi/linux/commit/c823e0b046efcfff61e21fa4c89d5d68090ef6de
 
 Evtest shows it doing the right thing (issuing KEY_POWER) when being
 pressed, but systemd seems to totally ignore it. I've seen this
 behaviour in the past and noticed the DE (GNOME2, old but it works)
 would pick it up and present the dialog. Since this is a headless
 system I want systemd to handle it instead of the DE (which isn't
 installed).  Every doc or blog post I read says that systemd should
 already be handling it, but it isn't in my case. I suspect that
 systemd only handles ACPI powerkey events, but I haven't actually
 looked at the code.
 
 Are more people experiencing this and does someone have a workaround
 or fix?
 
 You have to tag your input devices with the power-switch udev tag,
 otherwise logind won't pick up the device.
 
 See 70-power-switch.rules for the current default:
 
SUBSYSTEM==input, KERNEL==event*, SUBSYSTEMS==acpi, 
 TAG+=power-switch
SUBSYSTEM==input, KERNEL==event*, KERNELS==thinkpad_acpi, 
 TAG+=power-switch

Thanks, I've sent 2 patches to add rules for more power buttons, but...

 
 I'd really like to open this up, to be done on all kbds by default, but
 I feel uneasy about listening to all keypresses on all keyboards by
 default We don't want that logind is woken up on virtually *all*
 keypresses on the entire system, all the time.

... patch 2/2 opens up gpio-keys for this. All the boards I have in my office 
use gpio-keys for things like up/down, volume or other 'control' type of 
things. Matrix setups use a different driver, so I don't expect this to catch 
proper keyboards. Having said that, I can understand if you reject 2/2.

regards,

Koen

 
 David Hermann did a kernel patch to improve the situation:
 
 https://www.mail-archive.com/linux-input@vger.kernel.org/msg11143.html
 
 With this in place, userspace can set a mask of input keys it is
 interested in, and we could use that for logind to just subscribe to
 power keypresses and be happy...
 
 Unfortunately though the patch got repeatedly ignored by the input
 maintainers, even though it got resent multiple times... :-(
 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Having systemd shutdown when pressing the power button

2014-08-28 Thread Koen Kooi
Hi,

I am working on a system (http://www.acmesystems.it/arietta) where I hooked up 
the button as a power key:


https://github.com/koenkooi/linux/commit/c823e0b046efcfff61e21fa4c89d5d68090ef6de

Evtest shows it doing the right thing (issuing KEY_POWER) when being pressed, 
but systemd seems to totally ignore it. I've seen this behaviour in the past 
and noticed the DE (GNOME2, old but it works) would pick it up and present the 
dialog. Since this is a headless system I want systemd to handle it instead of 
the DE (which isn't installed).
Every doc or blog post I read says that systemd should already be handling it, 
but it isn't in my case. I suspect that systemd only handles ACPI powerkey 
events, but I haven't actually looked at the code.

Are more people experiencing this and does someone have a workaround or fix?

thanks,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Offline systemd unit file installer

2014-08-11 Thread Koen Kooi

Op 11 aug. 2014, om 12:47 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Sat, 09.08.14 06:44, Paassen, Hiram van (hiram.van.paas...@mastervolt.com) 
 wrote:
 
 Am I correct in thinking this only works on systemd enabled host
 systems or if you cross-compile for the same architecture? So you can
 use the just compiled version of systemctl?
 
 Well, what do you expect? I mean, you want to run the tool offline, so
 you need to be able to run it on the machine you want to run it offline
 on...
 
 Neither of which is the case for us...
 
 Am I expected to compile systemd twice in that case, one time as part
 of the host 'toolchain' and a second for the actual target?  I was
 rather hoping for something portable like a shell or python script.
 
 systemd is written in C. Sorry.
 
 Note that there's no need to the systemctl version to be in sync of the
 image you are putting together and the OS you build it on. The code in
 systemctl has been stable since quite a while now. Most distributions
 should include it, unless you run Slackware or so. But systemd upstream
 is really not the place to work around your weird choice of distro to
 build systemd images from...
 
 That said, systemctl enable just creates a couple of symlinks in
 /etc/systemd/system, you can easily do the equivalent in a handwritten
 shell script.

This is what we did for openembedded:


https://github.com/openembedded/oe-core/blob/master/meta/recipes-core/systemd/systemd-systemctl/systemctl

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [RFC/PATCH 3/3] coredump: compress core files

2014-06-25 Thread Koen Kooi

Op 25 jun. 2014, om 10:59 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Wed, 25.06.14 07:28, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
 
 Hi,
 a POC patch to compress coredumps after they are written. In my simple
 tests, this brings huge savings, because the compressed coredump can
 compress to ~5%.
 
 Unfortunately the core is first written uncompressed, then compressed
 by reading from disk and writing to the output file. This is ugly and
 slow, but I don't see a way around, if we want to get the backtrace
 without keeping everything in memory.
 
 I have the suspicion that there indeed is no other nice way for
 this... Hence looks good to me.
 
 'coredumpctl gdb' is not implemented yet (the decompression part is
 missing).
 
 Hmm, we probably should add a coredump.conf option for this to turn on.
 
 Hmm, thinking about this, another idea might be to simply let the fs
 solve this by adding a high-level coredump.conf option to turn on
 FS_COMPR_FL for the coredump. This should do the right thing on btrfs
 (afaics at least), but of course would leave other file systems out. But
 then again, we develop the OS for tomorrow, not for yesterday here...
 
 But then again, maybe this stuff shouldn't be exclusive. Maybe a new
 coredump.conf option Compress=(filesystem|file|no) or so? (and maybe
 even Compress=auto, which does the right thing automatically, depending
 if the fs supports compression) After all, doing both file-level and
 filesystem-level compression makes little sense...

The way btrfs currently does compression is to compress every (iirc 4k) block 
separately. Compressing the whole file at once will give a much bigger saving, 
especially when using xz. So btrfs/lzo will give you ~50% compression ratio vs 
the 5% mentioned above, a huge difference. I don't know how reiser4 or zfs 
tackle this.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] readahead: ARM: fix rotational media detection for MMC

2014-05-14 Thread Koen Kooi

Op 13 mei 2014, om 23:47 heeft Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl 
het volgende geschreven:

 On Tue, May 13, 2014 at 02:14:20PM +, Chaiken, Alison wrote:
 I wrote:
 The ARM runtime reports the major device type associated with
 /proc/self/mountinfo as MMC_BLOCK_MAJOR, causing on_ssd() in
 readahead-common.c to return false.   on_ssd() should return true, as
 MMC like SSD is not rotational.
 
 Lennart writes:
 Not following here. fs_on_ssd() will actually check for the high-level
 ID_SSD property, as well as the queue/rotational sysfs attribute for
 the block device.
 
 Those other checks are not reached, as the beginning of fs_on_ssd() has
if (major(st.st_dev) == 0) {}
 encapsulating them, and major(st.st_dev)=MMC_BLOCK_MAJOR, not 0.
 No, those other checks are *below* the if.
 
 What do
 
 1. udevadm info /dev/mmcXXX | grep SSD

I noticed that on my machines with an SSD the string 'SSD' only appears in the 
name reported by the disk (e.g. Samsung 840 Pro SSD).

 2. cat /sys/class/block/mmcXXX/queue/rotational
 
 say?

I tried it on 2 different ARM machines, one running 3.8, the other 3.15rc.

Kernel 3.8:

~# udevadm info /dev/mmcblk0
P: /devices/ocp.3/mmc.4/mmc_host/mmc0/mmc0:b368/block/mmcblk0
N: mmcblk0
S: disk/by-id/mmc-USD_0x4e851282
S: disk/by-path/platform-mmc.4
E: DEVLINKS=/dev/disk/by-id/mmc-USD_0x4e851282 /dev/disk/by-path/platform-mmc.4
E: DEVNAME=/dev/mmcblk0
E: DEVPATH=/devices/ocp.3/mmc.4/mmc_host/mmc0/mmc0:b368/block/mmcblk0
E: DEVTYPE=disk
E: ID_NAME=USD
E: ID_PART_TABLE_TYPE=dos
E: ID_PATH=platform-mmc.4
E: ID_PATH_TAG=platform-mmc_4
E: ID_SERIAL=0x4e851282
E: MAJOR=179
E: MINOR=0
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=20422

~# cat /sys/class/block/mmcblk0/queue/rotational 
0

Kernel 3.15rc3:

~# udevadm info /dev/mmcblk0
P: /devices/6800.ocp/4809c000.mmc/mmc_host/mmc0/mmc0:b368/block/mmcblk0
N: mmcblk0
S: disk/by-id/mmc-USD_0x4e74a777
S: disk/by-path/platform-4809c000.mmc
E: DEVLINKS=/dev/disk/by-id/mmc-USD_0x4e74a777 
/dev/disk/by-path/platform-4809c000.mmc
E: DEVNAME=/dev/mmcblk0
E: 
DEVPATH=/devices/6800.ocp/4809c000.mmc/mmc_host/mmc0/mmc0:b368/block/mmcblk0
E: DEVTYPE=disk
E: ID_NAME=USD
E: ID_PART_TABLE_TYPE=dos
E: ID_PATH=platform-4809c000.mmc
E: ID_PATH_TAG=platform-4809c000_mmc
E: ID_SERIAL=0x4e74a777
E: MAJOR=179
E: MINOR=0
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: UDISKS_PARTITION_TABLE=1
E: UDISKS_PARTITION_TABLE_COUNT=2
E: UDISKS_PARTITION_TABLE_SCHEME=mbr
E: UDISKS_PRESENTATION_NOPOLICY=0
E: USEC_INITIALIZED=32370

~# cat /sys/class/block/mmcblk0/queue/rotational 
0

regards,

Koen

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?

2014-04-29 Thread Koen Kooi

Op 28 apr. 2014, om 17:48 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Mon, 28.04.14 12:22, Manuel Reimer (manuel.s...@nurfuerspam.de) wrote:
 
 
 Lukasz Skalski l.skalski at samsung.com writes:
 You can define which RTC (/dev/rtcX) should be read -
 (rtc1) RTC used to set the system time option in kernel menuconfig.
 
 Yes, this is possible. But my RTC does not exist until I do the following on
 shell:
 
 echo ds1307 0x68  /sys/class/i2c-adapter/i2c-1/new_device
 
 Is there some other config option to tell the kernel to auto-initialize the
 I2C clock module?
 
 Isn't this something devicetree can solve? (not that i knew anything
 about devicetree or embedded hardware...)

Devicetree can handle that, but the following under the i2c node:

rtc@68 {
compatible = dallas,ds1307;
reg = 0x68;
};

While I haven't tried it, you might be able to use aliases to make the ds1307 
rtc0, but if not, do a 'status=disabled' in the on-chip rtc node.

regards,

Koen

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd v212 build error

2014-04-01 Thread Koen Kooi

Op 28 mrt. 2014, om 12:41 heeft Tom Gundersen t...@jklm.no het volgende 
geschreven:

 On Fri, Mar 28, 2014 at 12:09 PM, Michael Olbrich
 m.olbr...@pengutronix.de wrote:
 Hi,
 
 compiling systemd v212 fails here with:
 [...]
 src/libsystemd/sd-rtnl/rtnl-message.c: In function 
 'sd_rtnl_message_append_u8':
 src/libsystemd/sd-rtnl/rtnl-message.c:462:38: error: 'IFLA_IPTUN_TTL' 
 undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c:462:38: note: each undeclared 
 identifier is reported only once for each function it appears in
 src/libsystemd/sd-rtnl/rtnl-message.c:463:38: error: 'IFLA_IPTUN_TOS' 
 undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c:464:38: error: 'IFLA_IPTUN_PROTO' 
 undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c:465:38: error: 'IFLA_IPTUN_PMTUDISC' 
 undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c:466:38: error: 
 'IFLA_IPTUN_ENCAP_LIMIT' undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c: In function 
 'sd_rtnl_message_append_u16':
 src/libsystemd/sd-rtnl/rtnl-message.c:508:45: error: 'IFLA_IPTUN_FLAGS' 
 undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c:511:45: error: 
 'IFLA_IPTUN_6RD_PREFIXLEN' undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c:512:45: error: 
 'IFLA_IPTUN_6RD_RELAY_PREFIXLEN' undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c: In function 
 'sd_rtnl_message_append_u32':
 src/libsystemd/sd-rtnl/rtnl-message.c:561:38: error: 'IFLA_IPTUN_LOCAL' 
 undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c:562:38: error: 'IFLA_IPTUN_REMOTE' 
 undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c:564:38: error: 'IFLA_IPTUN_FLAGS' 
 undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c:565:38: error: 'IFLA_IPTUN_FLOWINFO' 
 undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c:566:38: error: 'IFLA_GRE_FLOWINFO' 
 undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c: In function 
 'sd_rtnl_message_append_in6_addr':
 src/libsystemd/sd-rtnl/rtnl-message.c:687:38: error: 'IFLA_IPTUN_6RD_PREFIX' 
 undeclared (first use in this function)
 src/libsystemd/sd-rtnl/rtnl-message.c: In function 
 'sd_rtnl_message_enter_container':
 src/libsystemd/sd-rtnl/rtnl-message.c:976:79: error: 'IFLA_BRIDGE_MAX' 
 undeclared (first use in this function)
 make[3]: *** [src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-message.lo] 
 Error 1
 make[3]: *** Waiting for unfinished jobs
 make[2]: *** [all-recursive] Error 1
 make[1]: *** [all] Error 2
 [...]
 
 From what I can tell these where added in Linux 3.7, so the corresponding
 headers are currently needed. Should these be added to missing.h? I think
 we can use IFLA_IPTUN_MAX/IFLA_BRIDGE_MAX if the enums are needed.
 
 Thanks for the report. I'm looking at fixing this now (but to do it
 nicely I decided to do a bigger rewrite of the whole rtnl type-system
 logic, so not quite done yet).
 
 I'd be happy with accepting a patch to missing.h to make this compile,
 but it should all be redundant pretty soon, so maybe not worth the
 effort.
 
 Side note: we might want to revisit how old kernels we want to
 support. Especially for building, we may want to just require
 something a bit more recent (maybe 3.10 or 3.12)?

3.10 is LTS, so picking that would make my life easier in the future.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] failed to store sound card state

2014-04-01 Thread Koen Kooi

Op 28 mrt. 2014, om 12:33 heeft Colin Guthrie gm...@colin.guthr.ie het 
volgende geschreven:

 'Twas brillig, and Koen Kooi at 28/03/14 08:45 did gyre and gimble:
 
 Op 28 mrt. 2014, om 01:46 heeft Cristian Rodríguez
 crrodrig...@opensuse.org het volgende geschreven:
 
 El 27/03/14 20:21, Felix Miata escribió:
 I see this repeated often during reboot attempts that do not
 proceed as expected to swiftly do the deed. It seems to be
 prerequisite to shutdown/reboot. I can't recall ever seeing
 anything like it when sysvinit was employed. Why does rebooting
 require the storing of a sound card state, particularly when
 there are no connected speakers and no sound system has been
 employed the entire time since booting (typical of multiuser
 rather than graphical startup, 3 on Grub cmdline)?
 
 Hey! :-)
 
 This is not a systemd issue.. but an implementation detail of the
 alsa units instead.
 
 rpm -qf /usr/lib/systemd/system/alsa*.service | uniq 
 alsa-utils-1.0.27.2-4.2.1.x86_64
 
 I filed a bug for that 2.5 years ago:
 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5459 (server
 is down right now). I also created a patch to fix it on startup:
 http://patchwork.openembedded.org/patch/12965/ Extending that to the
 shutdown unit should be straightforward.
 
 That doesn't seem like the correct behaviour.
 
 I thought it was the job of alsactl restore to initialise the device
 to sensible values in the absence of asound.state. There is an internal
 database inside alsa to do this and relatively generic code for HDA
 hardware IIRC.

Well, it didn't work for all non-x86 hardware I tried it on, maybe it works 
only for HDA based hw.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] failed to store sound card state

2014-03-28 Thread Koen Kooi

Op 28 mrt. 2014, om 01:46 heeft Cristian Rodríguez crrodrig...@opensuse.org 
het volgende geschreven:

 El 27/03/14 20:21, Felix Miata escribió:
 I see this repeated often during reboot attempts that do not proceed as
 expected to swiftly do the deed. It seems to be prerequisite to
 shutdown/reboot. I can't recall ever seeing anything like it when
 sysvinit was employed. Why does rebooting require the storing of a sound
 card state, particularly when there are no connected speakers and no
 sound system has been employed the entire time since booting (typical of
 multiuser rather than graphical startup, 3 on Grub cmdline)?
 
 Hey! :-)
 
 This is not a systemd issue.. but an implementation detail of the alsa units 
 instead.
 
 rpm -qf /usr/lib/systemd/system/alsa*.service | uniq
 alsa-utils-1.0.27.2-4.2.1.x86_64

I filed a bug for that 2.5 years ago: 
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5459 (server is down 
right now). I also created a patch to fix it on startup: 
http://patchwork.openembedded.org/patch/12965/
Extending that to the shutdown unit should be straightforward.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] machine-id: add --root option to operate on an alternate fs tree

2014-03-14 Thread Koen Kooi

Op 14 mrt. 2014, om 05:43 heeft Greg KH gre...@linuxfoundation.org het 
volgende geschreven:

 This makes it possible to initialize the /etc/machine-id file on an
 arbitrary filesystem hierarchy.  This helps systems that wish to run
 this at image creation time in a subdirectory, or from initramfs before
 pivot-root is called.

Awesome, this saves me an nspawn invocation in my deploy scripts!


 
 diff --git a/man/systemd-machine-id-setup.xml 
 b/man/systemd-machine-id-setup.xml
 index 5c34b345d012..b879b40b997d 100644
 --- a/man/systemd-machine-id-setup.xml
 +++ b/man/systemd-machine-id-setup.xml
 @@ -96,6 +96,14 @@
 paraThe following options are understood:/para
 
 variablelist
 +varlistentry
 +termoption--root=ROOT/option/term
 +listitemparaTakes a directory path
 +as an argument. All paths will be
 +prefixed with the given alternate ROOT
 +path, including config search paths.
 +/para/listitem
 +/varlistentry
 xi:include href=standard-options.xml 
 xpointer=help /
 xi:include href=standard-options.xml 
 xpointer=version /
 /variablelist
 diff --git a/src/core/machine-id-setup.c b/src/core/machine-id-setup.c
 index 1b55da7e56b8..7d52b468a11a 100644
 --- a/src/core/machine-id-setup.c
 +++ b/src/core/machine-id-setup.c
 @@ -59,18 +59,22 @@ static int shorten_uuid(char destination[36], const char 
 *source) {
 return -EINVAL;
 }
 
 -static int generate(char id[34]) {
 -int fd, r;
 +static int generate(char id[34], const char *root) {
 +int fd, r = 0;
 unsigned char *p;
 sd_id128_t buf;
 char *q;
 ssize_t k;
 const char *vm_id;
 +char *dbus_machine_id;
 
 assert(id);
 
 +if (asprintf(dbus_machine_id, %s/var/lib/dbus/machine-id, root)  
 0)
 +return log_oom();
 +
 /* First, try reading the D-Bus machine id, unless it is a symlink */
 -fd = open(/var/lib/dbus/machine-id, 
 O_RDONLY|O_CLOEXEC|O_NOCTTY|O_NOFOLLOW);
 +fd = open(dbus_machine_id, O_RDONLY|O_CLOEXEC|O_NOCTTY|O_NOFOLLOW);
 if (fd = 0) {
 k = loop_read(fd, id, 33, false);
 close_nointr_nofail(fd);
 @@ -83,7 +87,7 @@ static int generate(char id[34]) {
 id[33] = 0;
 
 log_info(Initializing machine ID from D-Bus 
 machine ID.);
 -return 0;
 +goto finish;
 }
 }
 }
 @@ -105,7 +109,8 @@ static int generate(char id[34]) {
 r = shorten_uuid(id, uuid);
 if (r = 0) {
 log_info(Initializing machine ID 
 from KVM UUID.);
 -return 0;
 +r = 0;
 +goto finish;
 }
 }
 }
 @@ -124,7 +129,8 @@ static int generate(char id[34]) {
 r = shorten_uuid(id, e);
 if (r = 0) {
 log_info(Initializing machine ID 
 from container UUID.);
 -return 0;
 +r = 0;
 +goto finish;
 }
 }
 }
 @@ -134,7 +140,7 @@ static int generate(char id[34]) {
 r = sd_id128_randomize(buf);
 if (r  0) {
 log_error(Failed to open /dev/urandom: %s, strerror(-r));
 -return r;
 +goto finish;
 }
 
 for (p = buf.bytes, q = id; p  buf.bytes + sizeof(buf); p++, q += 2) 
 {
 @@ -147,15 +153,27 @@ static int generate(char id[34]) {
 
 log_info(Initializing machine ID from random generator.);
 
 -return 0;
 +finish:
 +free(dbus_machine_id);
 +return r;
 }
 
 -int machine_id_setup(void) {
 +int machine_id_setup(const char *root) {
 _cleanup_close_ int fd = -1;
 -int r;
 +int r = 0;
 bool writable = false;
 struct stat st;
 char id[34]; /* 32 + \n + \0 */
 +char *etc_machine_id = NULL;
 +char *run_machine_id = NULL;
 +
 +if (asprintf(etc_machine_id, %s/etc/machine-id, root)  0)
 +return log_oom();
 +
 +if (asprintf(run_machine_id, %s/run/machine-id, root)  0) {
 +r = log_oom();
 +goto finish;
 +}
 
 RUN_WITH_UMASK() 

Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec

2014-03-14 Thread Koen Kooi

Op 14 mrt. 2014, om 15:23 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Fri, 14.03.14 14:49, Koen Kooi (koen.k...@linaro.org) wrote:
 
 It would be good if in the long run OS installers could adopt this and
 use the right partition type GUIDs automatically, to make this discovery
 work. For now however, you need to manually change the GPT type GUIDs of
 your installation if you want to make use of this scheme.
 
 So how do I get UUIDs allocated for 32bit and 64bit ARM?
 
 Do you use GPT on ARM?

The short answer: yes. 

 I have now added them to the spec and systemd, since people kept asking
 all the time...
 
 They are not too useful though for avoiding root= on the kernel cmdline,
 since we only look for root disks on the ESP partition, and EFI isn't
 that real on ARM...

ARM ltd. likes to pretend arm64 will be UEFI+ACPI only, but yes, it's not that 
real yet. Having said that, what prompted this was the discussion of the 
portable container format, which mandates an ESP partition. If we're going to 
do that on arm we should also make sure to supports this partition spec :)

regards,

Koen

 But it might be useful for systemd-nspawn -i, and thus I added it
 now. 
 
 I wonder if I should just add one for each arch we support, to put an
 end to the story...
 
 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] RTC on BeagleBone Black or embedded platforms

2014-02-28 Thread Koen Kooi

Op 27 feb. 2014, om 18:56 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Thu, 27.02.14 10:46, Mike (bellyac...@gmail.com) wrote:
 
 Heya,
 
 My biggest dilemma at this time right now is with the RTC.  The
 BeagleBone Black does have a RTC and it gets assigned to /dev/rtc0.
 There is however no battery backup for this device.  I've added a
 
 Hmm, what's the point of such an RTC? I mean, Linux uses an RTC only to
 initialize the system clock from and then never looks at it again. But
 if the RTC has no battery it's entirely pointless to ever look at it, so
 what is an RTC good for that has no battery?

To prevent clock-drift, the RTC does a better job at that than the kernel. 
Personally, I just have my DHCP server provide an ntp entry and have connman do 
its ntp thing :)

regards,

Koen

 
 DS1307 with a battery to allow having a somewhat sane date
 maintained.  Therein lies the dilemma, the code is only setup to
 access /dev/rtc.  I'm sure that I can figure out with a (gasp) shell
 script or small c program how to set / get the date from the DS1307,
 it just seems that would be a very crude kludge.
 
 If you have two RTCs one of which has no battery, why expose that to
 userspace at all? Can't you just disable that driver, and only use the
 working onen?
 
 My question then is would it be considered to add options to the
 current timedated code that accepted device name and possibly path
 to the appropriate /etc/adjtime file?
 
 It really sounds as if this is a local configuration problem of what is
 exposed by the kernel...
 
 Also note that PID will do the initial timezone bump for /dev/rtc only,
 too. Supporting an alternative RTC would also mean we'd ave t touch the
 earliest boot code.
 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat
 ___
 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] needed steps to get rebootless upgrade

2014-02-17 Thread Koen Kooi

Op 17 feb. 2014, om 14:50 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Mon, 17.02.14 08:16, Vasiliy Tolstov (v.tols...@selfip.ru) wrote:
 
 Hi all. I'm very interesting on creating system like cromeos that can
 do upgrade without reboot.
 
 ChromeOS doesn't support reboot-less upgrades. 
 
 In case of using systemd - what i need to do?
 I have two disk (ramdisk) system1 and system2 that have old (system1)
 and new (system2) filesystems.
 How can i get upgrade system1 with system2?
 As i understand i need to reload each running service to use new
 system2 for it?
 Can somebody says me more detailed steps to get this?
 
 Such reboot-less upgrades are hardly possible. There are large parts of
 the system you cannot upgrade during runtime, such as the kernel or
 dbus-daemon and other bits. And even if you could replace all these
 things, upgrades during runtime between arbitrary versions unlikely
 would be well tested, and hence risky business...
 
 Anyway systemd won't help you with this I fear...

If we stretch the definition of 'reboot' a bit, would it be possible to 
shutdown, jump back into the initramfs, do the updates and jump to the main 
rootfs again? It assumes you have an initramfs and all your apps will close, 
but the machine doesn't reboot :)

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] needed steps to get rebootless upgrade

2014-02-17 Thread Koen Kooi

Op 17 feb. 2014, om 17:03 heeft H. Peter Anvin h...@zytor.com het volgende 
geschreven:

 On 02/17/2014 06:40 AM, Koen Kooi wrote:
 
 If we stretch the definition of 'reboot' a bit, would it be possible
 to shutdown, jump back into the initramfs, do the updates and jump to
 the main rootfs again? It assumes you have an initramfs and all your
 apps will close, but the machine doesn't reboot :)
 
 
 And what is the point, then?

Checkbox for the marketing department :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Problems with systemd master

2014-02-15 Thread Koen Kooi

Op 14 feb. 2014, om 19:16 heeft Greg KH gre...@linuxfoundation.org het 
volgende geschreven:

 On Fri, Feb 14, 2014 at 02:30:00PM -0300, Cristian Rodríguez wrote:
 El 14/02/14 13:32, Richard Purdie escribió:
 
 Both conditions are checked, can you find out why the second seems to
 fail too, it shouldn't?
 CONFIG_FHANDLE is in your kernel?
 
 No, it wasn't. I enabled that and that image started working better,
 thanks!
 
 
 I believe we should throw a big fat warning when this feature is disabled..
 I wonder what 's the most proper way to test this at runtime though.
 
 Just test if the syscall is actually there or not, should be easy enough
 to test for, unless glibc wraps it up and emulates it if it is not in
 the kernel.

I wish CONFIG_IKCONFIG_PROC=y was mandatory, it would make debugging (and 
checking) these kind of things a lot easier!

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] porteus and systemd

2013-12-30 Thread Koen Kooi

Op 30 dec. 2013, om 13:36 heeft Mantas Mikulėnas graw...@gmail.com het 
volgende geschreven:

 On Mon, Dec 30, 2013 at 1:06 PM, Roelof Wobben r.wob...@home.nl wrote:
 hello,
 
 Im trying to port Cinnamon to porteus.
 Porteus is a slackware based distro which work with modules.
 
 The problem is that Cinnamon works the best with systemd and slackware
 refuses to use systemd.
 Now I want to try to make systemd work on a porteus system so that I have a
 slackware based system with systemd and Cinnamon.
 
 The biggest problem is that im not a coder.
 
 If you can port Cinnamon to a distro, most likely you can port systemd
 to a distro just as well.
 
 0. Install all dependencies – a recent kernel with required options;
 PAM; a /sbin/login with PAM support. The requirements are listed in
 the README [1].

Historically slackware has always refused to support PAM, so this is quite a 
big step to take :)

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd shutdown vs ostree

2013-09-15 Thread Koen Kooi

Op 14 sep. 2013, om 11:04 heeft Jan Alexander Steffens jan.steff...@gmail.com 
het volgende geschreven:

 On Sat, Sep 14, 2013 at 10:52 AM, Koen Kooi k...@dominion.thruhere.net 
 wrote:
 Please keep in mind that pstore is x86 only. EFI isn't x86 only, but 
 exceedingly rare outside of that arch.
 
 What? Pstore itself isn't. It's a generic interface to persistent
 platform storage. There are backends using EFI variables, NVRAM
 (PowerPC) or the APEI ERST (x86). As a last resort there's also a
 platform-independent RAM backend which may at least survive a simple
 reboot.

OK, so x86 and ppc only. That will leaves out arm, mips and others.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd shutdown vs ostree

2013-09-14 Thread Koen Kooi

Op 13 sep. 2013, om 00:31 heeft Jan Alexander Steffens jan.steff...@gmail.com 
het volgende geschreven:

 On Thu, Sep 12, 2013 at 10:51 PM, Lennart Poettering
 lenn...@poettering.net wrote:
 I think the really late shutdown logs should more liekly end up in some
 EFI var and then flushed out on next boot or so...
 
 That sounds good. Maybe use the pstore system? 

Please keep in mind that pstore is x86 only. EFI isn't x86 only, but 
exceedingly rare outside of that arch.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] udev: make net_id more robust

2013-06-18 Thread Koen Kooi

Op 7 jun. 2013, om 20:25 heeft Kay Sievers k...@vrfy.org het volgende 
geschreven:

 On Fri, Jun 7, 2013 at 3:27 PM, Sean McGovern gsean...@gmail.com wrote:
 Onboard network controllers are not always on PCI domain 0.
 
 +sysname = udev_device_get_sysname(names-pcidev);
 +
 +if(!sysname)
 +return -ENOENT;
 +
 +if(!strlen(sysname))
 +return -ENOENT;
 
 None of these checks should be needed.
 
 +if(sscanf(sysname, %lx:%x:%x.%d, domain, bus, slot, func) != 
 4)
 +return -ENOENT;
 
 We only support domain 0, and ignore all other devices so far.

What about non-PCI devices, like the netwerk controllers in embedded SoCs?

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Socket is dying, how to automatically restart it?

2013-05-09 Thread Koen Kooi

Op 23 apr. 2013, om 23:03 heeft George McCollister 
george.mccollis...@gmail.com het volgende geschreven:

 On 04/20/2013 08:04 AM, Koen Kooi wrote:
 Op 18 apr. 2013, om 19:18 heeft George 
 McCollistergeorge.mccollis...@gmail.com  het volgende geschreven:
 
 On 04/10/2013 12:03 PM, Koen Kooi wrote:
 Hi,
 
 I have a bit of a heisenbug where dropbear.socket will just die and needs 
 a systemctl restart dropbear.socket. I can't tell why it's dying, just 
 that it does within 3 days of uptime. After restarting it it seems to be 
 rock solid again for at least some weeks.
 
 The real way to fix this is to find out why it dies, but till someone 
 figures that out I'm looking to a way to automatically restart the socket 
 when it fails, kinda like Restart=Always for services. Is such a thing 
 possible? This is with 195 and 196, haven't tried 201 yet.
 I'm having exactly the same problem with sshd.socket (openssh) with systemd 
 197. I've done a netstat after it dies (just says dead no useful 
 information) and port 22 still shows up under listening. systemctl start 
 sshd.socket fixes the problem. I just upgraded to systemd 201 so I'll let 
 you know if the problem shows up again. The problem happens intermittently 
 so its been a bit elusive.
 It is indeed elusive, it hasn't happened to me in the past week, so progress 
 is slow on this.
 ¸
 regards,
 
 Koen
 This is really strange but I think I just accidentally found a way to 
 reproduce the problem.
 1) Reboot
 2) Verify ssh works
 3) login as root and run: systemctl --system daemon-reload
 
 Can't ssh anymore.
 
 If I do 'systemctl start sshd.socket' I can ssh again and doing 'systemctl 
 --system daemon-reload' again doesn't seem to break it.

I did a daemon reload the past week as well after reboot and yesterday my 
workstation suspended and dropped the connection, so I had to reconnect, which 
failed.

regards,

Koen


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 2/2] udev: fix for devices without PCI

2013-05-03 Thread Koen Kooi

Op 3 mrt. 2013, om 19:22 heeft Kay Sievers k...@vrfy.org het volgende 
geschreven:

 On Sun, Mar 3, 2013 at 7:10 PM, Rob Clark robdcl...@gmail.com wrote:
 On Sun, Mar 3, 2013 at 1:06 PM, Kay Sievers k...@vrfy.org wrote:
 On Sun, Mar 3, 2013 at 6:55 PM, Rob Clark robdcl...@gmail.com wrote:
 On many arm embedded SoC's (phones, tablets, etc), there is no PCI bus.
 So it is not an error if names_pci() fails to find a parent PCI device.
 
 As the comment in the code lines above states, all these names work on
 for PCI based setups.
 
 Other buses and architectures would need proper code to handle them,
 not just skip over the pci prefix. We cannot do that.
 
 Of course, if you have a better idea in mind, I am all-ears.  I'm not
 a systemd/udev expert, so certainly don't claim that it is the best
 fix.  It would be nice for this to work somehow properly on the
 various PCI-less systems out there.
 
 It depends on the bus type used for the parent device(s), we would
 need to compose a stable and predictable name from the properties of
 the parent device(s). In most cases it's probably a simple platform
 bus hack, which we will see.
 
 What does:
  ls -l /sys/class/net
 print on these systems?

On an TI AM335x SoC (e.g. beaglebone): 

root@xfcebone:~# ls -l /sys/class/net/
lrwxrwxrwx1 root root 0 May  3 06:23 eth0 - 
../../devices/ocp.2/4a10.ethernet/net/eth0
lrwxrwxrwx1 root root 0 May  3 06:23 lo - 
../../devices/virtual/net/lo

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Socket is dying, how to automatically restart it?

2013-04-20 Thread Koen Kooi

Op 18 apr. 2013, om 19:18 heeft George McCollister 
george.mccollis...@gmail.com het volgende geschreven:

 On 04/10/2013 12:03 PM, Koen Kooi wrote:
 Hi,
 
 I have a bit of a heisenbug where dropbear.socket will just die and needs a 
 systemctl restart dropbear.socket. I can't tell why it's dying, just that it 
 does within 3 days of uptime. After restarting it it seems to be rock solid 
 again for at least some weeks.
 
 The real way to fix this is to find out why it dies, but till someone 
 figures that out I'm looking to a way to automatically restart the socket 
 when it fails, kinda like Restart=Always for services. Is such a thing 
 possible? This is with 195 and 196, haven't tried 201 yet.

 I'm having exactly the same problem with sshd.socket (openssh) with systemd 
 197. I've done a netstat after it dies (just says dead no useful information) 
 and port 22 still shows up under listening. systemctl start sshd.socket fixes 
 the problem. I just upgraded to systemd 201 so I'll let you know if the 
 problem shows up again. The problem happens intermittently so its been a bit 
 elusive.

It is indeed elusive, it hasn't happened to me in the past week, so progress is 
slow on this.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Add ARCH parameter to /etc/os-release

2013-04-19 Thread Koen Kooi

Op 18 apr. 2013, om 14:08 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Thu, 18.04.13 09:26, Koen Kooi (k...@dominion.thruhere.net) wrote:
 
 So it returns something that could be considered usefull on my laptop, but 
 the output on the beaglebone is useless. On ARM you need to know the 
 following to see if you can execute the binary:
 
 1) instruction set revision (armvX, e.g. armv5te, armv6, armv7a)
 2) OABI or EABI
 3) floating point calling conventions, softp vs hardfp
 
 Are these even encoded in the ELF header? If you take an armv7a binary
 and execute it on arm5te, what happens? will the kernel quickly say
 Nah, incompatible binary? Or will it run until the first unknown
 instruction comes and the segfault or sigbus?

Usually sigbus, but it depends on what you're trying to mix. It's a mess on 
ARM, don't try to understand it :)

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Add ARCH parameter to /etc/os-release

2013-04-18 Thread Koen Kooi

Op 17 apr. 2013, om 20:19 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Mon, 08.04.13 22:09, Askar Safin (safinas...@mail.ru) wrote:
 
 
 I'm not sure what problem the proposal is trying to solve.  Maybe it'd
 be clearer if that was provided.
 I want to know what is the arches of the systems on my computer. I. e. I 
 want to do the following:
 
 for DISK in /dev/sd*; do
  mount $DISK /mnt
  source /mnt/etc/os-release
  echo Arch of $DISK is $ARCH
 done
 
 And I want to use this $ARCH to do setarch, i. e.:
  mount /dev/some-dev /mnt
  source /mnt/etc/os-release
  setarch $ARCH chroot /mnt
 So, this /mnt system will see uname -m output which is meaningful for the 
 system.
 
 My suggestion would be to write a little tool that does the equivalent
 to this:
 
 readelf -h /usr/lib*/libdl*.so | grep Machine | cut -c38- | uniq
 
 This will list you the architectures for which you have dynamic loaders
 installed. Since the dynamic loaders are hardcoded in all dynamic ELF
 binaries this list will tell you binaries of which archs you can execute
 on your system.

On my i7 laptop:

[koen@rrMBP mplayer2]$ readelf -h /usr/lib*/libdl*.so | grep Machine | cut 
-c38- | uniq
Advanced Micro Devices X86-64
Intel 80386

And on a cortex A8 device:

root@beaglebone:~# readelf -h /usr/lib*/libdl*.so | grep Machine | cut -c38- | 
uniq
ARM

So it returns something that could be considered usefull on my laptop, but the 
output on the beaglebone is useless. On ARM you need to know the following to 
see if you can execute the binary:

1) instruction set revision (armvX, e.g. armv5te, armv6, armv7a)
2) OABI or EABI
3) floating point calling conventions, softp vs hardfp

The first item is like i386, i486 etc. It's compatible only one way. The second 
is academical at this point, only luddites running kernel 2.4 are interested in 
OABI.
And then we get to the clusterfuck, floatingpoint ABI. I need to install 
binutils on my hardfloat system to see if that also says 'ARM', I bet it does.

But it does answer the can I nspawn into this rootfs? question for different 
architectures like powerpc vs x86 :)

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Socket is dying, how to automatically restart it?

2013-04-18 Thread Koen Kooi

Op 17 apr. 2013, om 21:05 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Wed, 10.04.13 19:03, Koen Kooi (k...@dominion.thruhere.net) wrote:
 
 Hi,
 
 I have a bit of a heisenbug where dropbear.socket will just die and
 needs a systemctl restart dropbear.socket. I can't tell why it's
 dying, just that it does within 3 days of uptime. After restarting it
 it seems to be rock solid again for at least some weeks.
 
 The real way to fix this is to find out why it dies, but till someone
 figures that out I'm looking to a way to automatically restart the
 socket when it fails, kinda like Restart=Always for services. Is such
 a thing possible? This is with 195 and 196, haven't tried 201 yet.
 
 So, two things:
 
 When a service continuously dies we'll put the listening socket into
 fail state eventually. But you can see these ones easily in systemctl
 status, since they have a specific result
 service-failed-permanent. (results are shown next to the Active:
 field if a unit failed).
 
 And if the somebody invokes shutdown() on the listening socket (not the
 connection socket), but that's a really weird thing to do. But people do
 weird things, and this has occured before.
 
 Otherwise I have no idea what could have happened. Any chance you can
 reproduce this with strace attached to PID 1 or so?

Still trying to reproduce it in a way I can instrument it.

 Is dropbear forked off one instance per connection, or one instance for
 all?

Looks like one instance per connection. 

But I'm going to replace dropbear with openssh in the medium term because 
dropbear doesn't do enough PAM to register itself with logind, so things like 
'screen' get killed on logout.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to run *ctl command using systemd-nspawn

2013-04-17 Thread Koen Kooi

Op 17 apr. 2013, om 17:20 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Wed, 17.04.13 17:09, Lennart Poettering (lenn...@poettering.net) wrote:
 
 
 On Tue, 16.04.13 09:11, Koen Kooi (k...@dominion.thruhere.net) wrote:
 
 Hi,
 
 To help with flashing the onboard eMMC of a 10 boards I'm using 
 systemd-nspawn to run package postinstall scripts that generate UUIDs and 
 some other things and it's working great for that! Every board now has a 
 unique value in /etc/machine-id instead it being empty and systemd 
 randomizing it on startup.
 
 What doesn't work however is something like this:
 
 systemd-nspawn -D ${PART2MOUNT} /usr/bin/timedatectl set-timezone 
 Europe/Paris
 
 or this:
 
 systemd-nspawn -D ${PART2MOUNT} /usr/bin/hostnamectl set-hostname 
 BeagleBoneBlack
 
 I know I can run the lowlevel 'ln -sf zoneinfo /etc/timezone' or echo the 
 name into /etc/hostname, but I'd like to use the *ctl commands because they 
 work and have error handling built-in. 
 it looks like I would need -b to get the *ctl commands to work, but -b
 doesn't support running single commands and exiting.
 
 timedatectl is just a frontend to timedated. So, without running
 timedated inside of the container this is not going to be easy to do.
 
 Ah, I missed that you'd actually be OK with booting up the whole thing
 for this command... You'd just need a nice way to run something after
 boot-up is complete, and that immeidately shuts down the container
 afterwards, right?

Exactly!

 Hmm, here's an idea:
 
 we could add a generator to systemd which looks for systemd.run= or so
 on the kernel cmdline and simply generates throw-away unit files from
 that, that runs the specified command(s) and triggers a shutdown
 afterwards... Would that work for you?
 
 i.e. you'd then call:
 
 systemd-nspawn -bD /srv/foobar \
   systemd.run='/usr/bin/timedatectl set-timezone Europe/Paris' \
   systemd.run='/usr/bin/timedatectl set-hostname BeagleBoneBlack'
 
 and so on...
 
 I think that would be reasonably pretty?

And it totally works for my usecase as well!

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] How to run *ctl command using systemd-nspawn

2013-04-16 Thread Koen Kooi
Hi,

To help with flashing the onboard eMMC of a 10 boards I'm using 
systemd-nspawn to run package postinstall scripts that generate UUIDs and some 
other things and it's working great for that! Every board now has a unique 
value in /etc/machine-id instead it being empty and systemd randomizing it on 
startup.

What doesn't work however is something like this:

systemd-nspawn -D ${PART2MOUNT} /usr/bin/timedatectl set-timezone 
Europe/Paris

or this:

systemd-nspawn -D ${PART2MOUNT} /usr/bin/hostnamectl set-hostname 
BeagleBoneBlack

I know I can run the lowlevel 'ln -sf zoneinfo /etc/timezone' or echo the 
name into /etc/hostname, but I'd like to use the *ctl commands because they 
work and have error handling built-in. 
it looks like I would need -b to get the *ctl commands to work, but -b doesn't 
support running single commands and exiting.

My goal is to be able to drop in a rootfs tarball and change timezone and 
hostname settings in a config file for the flasher script and avoid generating 
N different tarballs. For use in the office lab I use something like [1] to 
generate the hostnames based on board revision and serial number.

So, is there a way to *ctl command using systemd-nspawn in a rootfs that wasn't 
specially prepared (e.g. helper units/targets) for that?

regards,

Koen

[1] https://plus.google.com/100242854243155306943/posts/ddoZgvLnixa
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to run *ctl command using systemd-nspawn

2013-04-16 Thread Koen Kooi

Op 16 apr. 2013, om 20:00 heeft Kok, Auke-jan H auke-jan.h@intel.com 
het volgende geschreven:

 On Tue, Apr 16, 2013 at 12:11 AM, Koen Kooi k...@dominion.thruhere.net 
 wrote:
 Hi,
 
 To help with flashing the onboard eMMC of a 10 boards I'm using 
 systemd-nspawn to run package postinstall scripts that generate UUIDs and 
 some other things and it's working great for that! Every board now has a 
 unique value in /etc/machine-id instead it being empty and systemd 
 randomizing it on startup.
 
 What doesn't work however is something like this:
 
systemd-nspawn -D ${PART2MOUNT} /usr/bin/timedatectl set-timezone 
 Europe/Paris
 
 or this:
 
systemd-nspawn -D ${PART2MOUNT} /usr/bin/hostnamectl set-hostname 
 BeagleBoneBlack
 
 I know I can run the lowlevel 'ln -sf zoneinfo /etc/timezone' or echo the 
 name into /etc/hostname, but I'd like to use the *ctl commands because they 
 work and have error handling built-in.
 it looks like I would need -b to get the *ctl commands to work, but -b 
 doesn't support running single commands and exiting.
 
 My goal is to be able to drop in a rootfs tarball and change timezone and 
 hostname settings in a config file for the flasher script and avoid 
 generating N different tarballs. For use in the office lab I use something 
 like [1] to generate the hostnames based on board revision and serial number.
 
 So, is there a way to *ctl command using systemd-nspawn in a rootfs that 
 wasn't specially prepared (e.g. helper units/targets) for that?
 
 crazy thought, but, for completeness, there should probably be
 equivalent handling of init=/path/to/alternative/init in
 systemd-nspawn
 
 also the man page shows what you want should just work:
 
 SYNOPSIS
   systemd-nspawn [OPTIONS...] [COMMAND] [ARGS...]
 
 but I guess there's some issues there.

No commands allowed with -b :(
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How to run *ctl command using systemd-nspawn

2013-04-16 Thread Koen Kooi

Op 16 apr. 2013, om 20:14 heeft Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl 
het volgende geschreven:

 On Tue, Apr 16, 2013 at 09:11:51AM +0200, Koen Kooi wrote:
 Hi,
 
 To help with flashing the onboard eMMC of a 10 boards I'm using 
 systemd-nspawn to run package postinstall scripts that generate UUIDs and 
 some other things and it's working great for that! Every board now has a 
 unique value in /etc/machine-id instead it being empty and systemd 
 randomizing it on startup.
 
 What doesn't work however is something like this:
 
  systemd-nspawn -D ${PART2MOUNT} /usr/bin/timedatectl set-timezone 
 Europe/Paris
 
 or this:
 
  systemd-nspawn -D ${PART2MOUNT} /usr/bin/hostnamectl set-hostname 
 BeagleBoneBlack
 
 I know I can run the lowlevel 'ln -sf zoneinfo /etc/timezone' or echo the 
 name into /etc/hostname, but I'd like to use the *ctl commands because they 
 work and have error handling built-in. 
 it looks like I would need -b to get the *ctl commands to work, but -b 
 doesn't support running single commands and exiting.
 
 My goal is to be able to drop in a rootfs tarball and change timezone and 
 hostname settings in a config file for the flasher script and avoid 
 generating N different tarballs. For use in the office lab I use something 
 like [1] to generate the hostnames based on board revision and serial number.
 
 So, is there a way to *ctl command using systemd-nspawn in a rootfs that 
 wasn't specially prepared (e.g. helper units/targets) for that?
 
 With very recent systemd just run:
 
 PID=$(head -n1 /sys/fs/cgroup/systemd/machine/$NAME/system/tasks)
 nsenter -m -u -i -n -p -t $PID /usr/bin/timedatectl set-timezone Europe/Paris
 ...
 nsenter -m -u -i -n -p -t $PID systemctl halt
 
 where NAME is either speicified with -M or the name of the tree root.


I'll update my util-linux to get nsenter and give that a try, thanks!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Socket is dying, how to automatically restart it?

2013-04-12 Thread Koen Kooi

Op 11 apr. 2013, om 21:09 heeft David Strauss da...@davidstrauss.net het 
volgende geschreven:

 On Wed, Apr 10, 2013 at 11:00 PM, Koen Kooi k...@dominion.thruhere.net 
 wrote:
 restarting it once it fails
 
 Is it the socket or the service?

socket
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] PATCH - add ARM based Chromebook lid switch

2013-04-12 Thread Koen Kooi

Op 12 apr. 2013, om 18:24 heeft Robert Schweikert rjsch...@suse.com het 
volgende geschreven:

 Thanks Kay for pointing me in the right direction
 
 
 From fced3673ee1001dc905206f9a92ea2062f951d3c Mon Sep 17 00:00:00 2001
 From: Robert Schweikert rjsch...@suse.com
 Date: Fri, 12 Apr 2013 12:08:16 -0400
 Subject: [PATCH] rules: add lid switch of ARM based Chromebook as a power
 switch to logind
 
 ---
 src/login/70-power-switch.rules | 1 +
 1 file changed, 1 insertion(+)
 
 diff --git a/src/login/70-power-switch.rules b/src/login/70-power-switch.rules
 index 36fb827..d925ab7 100644
 --- a/src/login/70-power-switch.rules
 +++ b/src/login/70-power-switch.rules
 @@ -9,5 +9,6 @@ ACTION==remove, GOTO=power_switch_end
 
 SUBSYSTEM==input, KERNEL==event*, SUBSYSTEMS==acpi, TAG+=power-switch
 SUBSYSTEM==input, KERNEL==event*, KERNELS==thinkpad_acpi, 
 TAG+=power-switch
 +SUBSYSTEM==input, KERNEL==event*, KERNELS==gpio-keys.8, 
 TAG+=power-switch

Won't that trigger on every gpio-keys entry that devicetree labels as 8? I 
don't think it's a lid switch for all boards with gpio-keys.8 out there and 
even if it was, the .8 is just as stable as ethX, you shouldn't depend on it.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Socket is dying, how to automatically restart it?

2013-04-11 Thread Koen Kooi

Op 10 apr. 2013, om 22:20 heeft Kok, Auke-jan H auke-jan.h@intel.com 
het volgende geschreven:

 On Wed, Apr 10, 2013 at 1:12 PM, David Strauss da...@davidstrauss.net wrote:
 Are you sure it's not the corresponding service that really failed?
 
 actually, that's a good point, but if the socket unit is dead, I
 assume that systemd no longer is bind()ed to the ports...
 
 Koen, can you verify that that is the case?

I can try, I'll leave a board up a few days and see what happens.

FWIW, restarting it once it fails is enough to fix it:

root@soekris:/media/# systemctl status dropbear.socket
dropbear.socket
  Loaded: loaded (/lib/systemd/system/dropbear.socket; enabled)
  Active: active (listening) since Tue 2013-03-26 20:43:06 CET; 2 weeks 
1 days ago
Accepted: 5; Connected: 2
  CGroup: name=systemd:/system/dropbear.socket


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Socket is dying, how to automatically restart it?

2013-04-10 Thread Koen Kooi
Hi,

I have a bit of a heisenbug where dropbear.socket will just die and needs a 
systemctl restart dropbear.socket. I can't tell why it's dying, just that it 
does within 3 days of uptime. After restarting it it seems to be rock solid 
again for at least some weeks.

The real way to fix this is to find out why it dies, but till someone figures 
that out I'm looking to a way to automatically restart the socket when it 
fails, kinda like Restart=Always for services. Is such a thing possible? This 
is with 195 and 196, haven't tried 201 yet.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Socket is dying, how to automatically restart it?

2013-04-10 Thread Koen Kooi

Op 10 apr. 2013, om 19:13 heeft Mantas Mikulėnas graw...@gmail.com het 
volgende geschreven:

 On Wed, Apr 10, 2013 at 8:03 PM, Koen Kooi k...@dominion.thruhere.net wrote:
 Hi,
 
 I have a bit of a heisenbug where dropbear.socket will just die and needs a 
 systemctl restart dropbear.socket. I can't tell why it's dying, just that it 
 does within 3 days of uptime. After restarting it it seems to be rock solid 
 again for at least some weeks.
 
 The real way to fix this is to find out why it dies,
 
 After death, does `systemctl status dropbear.socket` show any error
 messages in the status line?

No, only that it's dead, so systemd knows that it's has failed somehow

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Add ARCH parameter to /etc/os-release

2013-04-07 Thread Koen Kooi

Op 6 apr. 2013, om 22:41 heeft Reindl Harald h.rei...@thelounge.net het 
volgende geschreven:

 
 
 Am 06.04.2013 22:37, schrieb Askar Safin:
 What is primary arch?  The arch of init? ls? the package manager?
 As far as I know today there is no true symmetric multiarch. Every 
 multiarched system has one clear primary arch. And several additional 
 arches. So, today (I think) the parameter ARCH should content all arches and 
 the primary arch should go first. If this situation changes in the future, 
 then ARCH can be list of equal arches.
 
 usually the kernel ones?
 Yes, this is good idea. But then, of course, this is arch of this system's 
 own kernel, not arch of current running kernel.
 
 i would wonder if this below is not predictable the arch from the running 
 kernel
 
 [harry@srv-rhsoft:~]$ /usr/bin/uname -i
 x86_64

No, run that kernel on a 32bit Atom cpu and it will still return x86_64. I only 
/proc/cpuinfo had a standard layout :(

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Add ARCH parameter to /etc/os-release

2013-04-07 Thread Koen Kooi

Op 7 apr. 2013, om 11:47 heeft Reindl Harald h.rei...@thelounge.net het 
volgende geschreven:

 
 
 Am 07.04.2013 09:56, schrieb Koen Kooi:
 
 Op 6 apr. 2013, om 22:41 heeft Reindl Harald h.rei...@thelounge.net het 
 volgende geschreven:
 
 Am 06.04.2013 22:37, schrieb Askar Safin:
 What is primary arch?  The arch of init? ls? the package manager?
 As far as I know today there is no true symmetric multiarch. Every 
 multiarched system has one clear primary arch. And several additional 
 arches. So, today (I think) the parameter ARCH should content all arches 
 and the primary arch should go first. If this situation changes in the 
 future, then ARCH can be list of equal arches.
 
 usually the kernel ones?
 Yes, this is good idea. But then, of course, this is arch of this system's 
 own kernel, not arch of current running kernel.
 
 i would wonder if this below is not predictable the arch from the running 
 kernel
 
 [harry@srv-rhsoft:~]$ /usr/bin/uname -i
 x86_64
 
 No, run that kernel on a 32bit Atom cpu and it will still return x86_64
 
 how will you do that?

Enable 64 bit support and 32 bit compat, build, boot.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Add ARCH parameter to /etc/os-release

2013-04-07 Thread Koen Kooi

Op 7 apr. 2013, om 22:11 heeft Reindl Harald h.rei...@thelounge.net het 
volgende geschreven:

 
 
 Am 07.04.2013 22:04, schrieb Koen Kooi:
 
 Op 7 apr. 2013, om 11:47 heeft Reindl Harald h.rei...@thelounge.net het 
 volgende geschreven:
 
 
 
 Am 07.04.2013 09:56, schrieb Koen Kooi:
 
 Op 6 apr. 2013, om 22:41 heeft Reindl Harald h.rei...@thelounge.net het 
 volgende geschreven:
 
 Am 06.04.2013 22:37, schrieb Askar Safin:
 What is primary arch?  The arch of init? ls? the package manager?
 As far as I know today there is no true symmetric multiarch. Every 
 multiarched system has one clear primary arch. And several additional 
 arches. So, today (I think) the parameter ARCH should content all arches 
 and the primary arch should go first. If this situation changes in the 
 future, then ARCH can be list of equal arches.
 
 usually the kernel ones?
 Yes, this is good idea. But then, of course, this is arch of this 
 system's own kernel, not arch of current running kernel.
 
 i would wonder if this below is not predictable the arch from the running 
 kernel
 
 [harry@srv-rhsoft:~]$ /usr/bin/uname -i
 x86_64
 
 No, run that kernel on a 32bit Atom cpu and it will still return x86_64
 
 how will you do that?
 
 Enable 64 bit support and 32 bit compat, build, boot
 
 bullshit, you can not run a 64bit kernel on a 32bit CPU
 the other direction yes, but not this way

Yes, you can, just set CONFIG_64BIT and 32 bit compat, the kernel will run fine 
on an Atom E6xx and uname will report x86_64. 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] bootctl: fix help text

2013-03-29 Thread Koen Kooi
It currently says 'time settings', change that to 'boot settings'.

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 src/boot/bootctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/boot/bootctl.c b/src/boot/bootctl.c
index a920277..af694fd 100644
--- a/src/boot/bootctl.c
+++ b/src/boot/bootctl.c
@@ -38,7 +38,7 @@ static int help(void) {
  -h --help  Show this help\n
 --version   Show package version\n
Commands:\n
- status Show current time settings\n,
+ status Show current boot settings\n,
program_invocation_short_name);
 
 return 0;
-- 
1.8.1.4

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd-analyze-197 broken

2013-01-15 Thread Koen Kooi

Op 15 jan. 2013, om 06:20 heeft Kok, Auke-jan H auke-jan.h@intel.com 
het volgende geschreven:

 On Mon, Jan 14, 2013 at 8:21 PM, Holger Winkelmann h...@travelping.com 
 wrote:
 I'm just following this discussion and would ask the developer to keep the 
 embedded folks in mind. Embedded systems hardly have all the dependencies 
 available or even phyton but need a debug tool too. So far I know systemd 
 will address this embedded UseCases as well.
 
 This is my perspective as well, but there are folks that can not
 relate to this, and I think it's not fair.

I ended up reverting the commits that introduced gi.repository and friends. I 
still dislike needed python + extra just for 'systemd-analyze blame', it's a 
waste of space on my embedded systems. Then again, I package it seperately so I 
can use system without all that.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Proposal: integrate biosdevname into systemd tree

2013-01-04 Thread Koen Kooi

Op 4 jan. 2013, om 10:54 heeft Reindl Harald h.rei...@thelounge.net het 
volgende geschreven:

 
 
 Am 04.01.2013 10:40, schrieb Alexander E. Patrakov:
 2013/1/4 Reindl Harald h.rei...@thelounge.net:
 but hopefully /etc/udev/rules.d/70-persistent-net.rules will be recognized
 forever if it exists because there are many servers especially virtual
 ones where you hardly need to control ethernet device names to avoid
 breaking iptables-scripts as example
 
 Yes, the existing rules will continue to be recognized. The bug is
 that even they are intrinsically unreliable (as happened with that
 rented server), so I think you actually don't want that.
 
 how can something like this be unreliable?
 hwaddresses does not change randomly

Actually, they do for a lot of 'embedded' setups. If you have an SMSC 
usb-ethernet chip with a blank eeprom (e.g. a beagleboard xM) the kernel will 
assign a random mac on 1) every reboot (3.x kernels) or 2) every ifup (2.6.x 
kernels). If you have a board where the bootloader is supposed to read an 
eeprom or hidden register and pass it to the kernel this will fail if you use a 
devicetree enabled kernel since the kernel driver writers from the silicon 
vendor don't care about the bootloader (e.g. beaglebone). 
There are patches available to assign a static mac based on e.g. die IDs, but 
those aren't in mainine linux yet. And that's just for the 2 platforms I care 
for at $dayjob and I don't think they are the only ones.
It sucks, it's a bug and must be fixed, but right now you can't say 
'hwaddresses does not change randomly' :(

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] eudev fork and patches there

2012-12-18 Thread Koen Kooi

Op 19 dec. 2012, om 06:20 heeft microcai micro...@fedoraproject.org het 
volgende geschreven:

 On 2012年12月17日星期一 CST下午10时36分48秒, Kay Sievers wrote:
 On Mon, Dec 17, 2012 at 2:04 PM, Koen Kooi k...@dominion.thruhere.net 
 wrote:
 Op 17 dec. 2012, om 12:17 heeft Zbigniew Jędrzejewski-Szmek 
 zbys...@in.waw.pl het volgende geschreven:
 
 eudev has made a project annoucement [1], and I thought it would be
 worthwhile to go through their patches and cherry-pick. I've now done
 that (until cc5c144a70fc37e 'Merge pull request #32') and the results
 regarding patches which can be used directly are not very impressive:
 one patch to fix clang warnings. There are quite a few
 build/compiler-warning in their tree, but they just seem to be fixes
 for problems introduced with their changes.
 Potentially usefull would also be the patch c189ab 'Fix unused result
 warnings', but it would be good if somebody familar with the code took
 a look if it is enough to print warnings (or even if they should be
 printed) or some more definite action should be taken.
 Also potentially usefull are the changes to allow 'make distcheck'
 without gtk-doc, but they are spread out over multiple commits in a
 messy way, so could only be used as inspiration.
 There's also nice patch bfc850 'Add fallback path when accept4() is
 not available.' Do we care about kernels  2.6.28? (This version is
 according to man accept4(2), patch text mentions different versions.)
 
 Keep in mind that your *libc has to support accept4() as well. I ran into 
 that problem a long time ago [1]. Backporting support for accept4() is 
 trivial. For systemd you'll need 2 more backports: cgroup mountpoint and 
 the active terminal thing.
 Also note that epoll() was added to non-x86 architectures a lot later than 
 x86.
 
 We generally do not want to work around kernel or libc bugs. So I'm
 not interested in such a patch.
 
 People who want or need to play these match-and-mix games with new
 userspace on old systems should fix the dependencies where they are
 missing, not expect magic workarounds from tools. There are many
 subtle dependencies on various things which are not available on old
 kernels and libc, this is just a very obvious one. We should not
 pretend we support that model, we just don't. And it will get even
 harder in the future, as we are trying to build a real OS now not a
 bag of bits.
 
 We surely will not make anything harder than it needs to be, but
 pretending bleeding edge tools will or should work on 2 years old
 kernels is a promise we do not want to make with systemd/udev. In this
 case, it would be the job of the libc, not the user of libc.
 
 We surely support things the other way around, what the kernel is
 doing, which is new kernels on old systems, but doing it both ways is
 not really the goal for us.
 
 agree. people should just upgrade their kernel. does kernel really remove old 
 hardware support? if not, then why are we stick to old kernels?

I get stuck on older kernels when the (silicon)vendor only has support for 
their chip/board in their vendor kernel, not in mainline. 

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] eudev fork and patches there

2012-12-17 Thread Koen Kooi

Op 17 dec. 2012, om 12:17 heeft Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl 
het volgende geschreven:

 Hi,
 
 eudev has made a project annoucement [1], and I thought it would be
 worthwhile to go through their patches and cherry-pick. I've now done
 that (until cc5c144a70fc37e 'Merge pull request #32') and the results
 regarding patches which can be used directly are not very impressive:
 one patch to fix clang warnings. There are quite a few
 build/compiler-warning in their tree, but they just seem to be fixes
 for problems introduced with their changes.
 
 Potentially usefull would also be the patch c189ab 'Fix unused result
 warnings', but it would be good if somebody familar with the code took
 a look if it is enough to print warnings (or even if they should be
 printed) or some more definite action should be taken.
 
 Also potentially usefull are the changes to allow 'make distcheck'
 without gtk-doc, but they are spread out over multiple commits in a
 messy way, so could only be used as inspiration.
 
 There's also nice patch bfc850 'Add fallback path when accept4() is
 not available.' Do we care about kernels  2.6.28? (This version is
 according to man accept4(2), patch text mentions different versions.)

Keep in mind that your *libc has to support accept4() as well. I ran into that 
problem a long time ago [1]. Backporting support for accept4() is trivial. For 
systemd you'll need 2 more backports: cgroup mountpoint and the active terminal 
thing.
Also note that epoll() was added to non-x86 architectures a lot later than x86.

regards,

Koen

[1] http://dominion.thruhere.net/koen/cms/optimizing-the-boot-process
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] *.py: don't hardcode /usr/bin/python

2012-12-03 Thread Koen Kooi

Op 1 dec. 2012, om 05:04 heeft Ramkumar Ramachandra artag...@gmail.com het 
volgende geschreven:

 Michael Biebl wrote:
 2012/11/30 Ramkumar Ramachandra artag...@gmail.com:
 Execute python using /usr/bin/env python instead of hard-coding the
 
 I'm not really a fan of using /usr/bin/env, as you can pick up a
 random python version depending on how your PATH is setup.
 Besides, you need to spawn an additional binary.
 I would assume that pretty much every distro ships the python
 interpreter as /usr/bin/python.
 
 I don't follow your reasoning: it is idiomatic to use /usr/bin/env
 $interpreter, because every distro does not necessarily ship it as
 /usr/bin/$interpreter.

Even better: 'env' is located in /bin on some distros :)


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] GPIO Reset Button

2012-11-17 Thread Koen Kooi

Op 10 nov. 2012, om 01:17 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Fri, 02.11.12 09:56, Pawel Pastuszak (pawelpastus...@gmail.com) wrote:
 
 Hi all,
 
 I was wondering if there is an way to attach an GPIO line to reboot the
 system. I am currently working on an Embedded device that has an GPIO line
 which needs to act as an reboot button this GPIO comes up as an
 /sys/class/gpio/gpio103/ which i want to have it trigger when it switches
 state to low and do an system soft reboot. Does systemd allow any
 functionally like this?
 
 No. We only look for input devices marked with the power-switch
 tag. 
 
 The kernel can create input devices for GPIO lines
 (CONFIG_KEYBOARD_GPIO), IIRC? Maybe that's useful to achieve this?

It should be a matter of:

static struct gpio_keys_button my_awesome_gpio_keys[] = {
{
.code   = KEY_POWER,
.gpio   = GPIO_TO_PIN(1, 16),
.active_low = true,
.desc   = left,
.type   = EV_KEY,
.wakeup = 1,
},
};

static struct gpio_keys_platform_data my_awesome_gpio_key_info = {
.buttons= my_awesome_gpio_keys,
.nbuttons   = ARRAY_SIZE(my_awesome_gpio_keys),
};

static struct platform_device my_awesome_keys = {
.name   = gpio-keys,
.id = -1,
.dev= {
.platform_data  = my_awesome_gpio_key_info,
},
};

Or with devicetree:

gpio_keys {
compatible = gpio-keys;
pinctrl-names = default;
pinctrl-0 = bone_lcd3_cape_keys_00A0_pins; // add a 
pinctrl section about if needed, otherwise delete these 2 lines

#address-cells = 1;
#size-cells = 0;

button@1 {
debounce_interval = 50;
linux,code = 105; // replace with proper 
KEY_POWER code
label = left;
gpios = gpio2 16 0x0;
gpio-key,wakeup;
autorepeat;
};
};

That will give you a native evdev device that emits KEY_POWER when you toggle 
the GPIO. 

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [ANNOUNCE] systemd 195

2012-10-23 Thread Koen Kooi

Op 23 okt. 2012, om 02:56 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 Heya!
 
 A non-trivial amount of cool new features, but primarily bug fixes bug
 fixes bug fixes.


In both 194 and 195 I have trouble building system for my embedded systems:

| src/journal/journal-gatewayd.c: In function 'respond_oom':
| src/journal/journal-gatewayd.c:117:9: warning: implicit declaration of 
function 'MHD_create_response_from_buffer' [-Wimplicit-function-declaration]
| src/journal/journal-gatewayd.c:117:76: error: 'MHD_RESPMEM_PERSISTENT' 
undeclared (first use in this function)
| src/journal/journal-gatewayd.c:117:76: note: each undeclared identifier is 
reported only once for each function it appears in
| src/journal/journal-gatewayd.c: In function 'respond_error':
| src/journal/journal-gatewayd.c:148:66: error: 'MHD_RESPMEM_MUST_FREE' 
undeclared (first use in this function)
| src/journal/journal-gatewayd.c: In function 'request_reader_entries':
| src/journal/journal-gatewayd.c:186:32: error: 
'MHD_CONTENT_READER_END_OF_STREAM' undeclared (first use in this function)
| src/journal/journal-gatewayd.c:197:32: error: 
'MHD_CONTENT_READER_END_WITH_ERROR' undeclared (first use in this function)
| src/journal/journal-gatewayd.c: In function 'request_handler_entries':
| src/journal/journal-gatewayd.c:524:9: warning: implicit declaration of 
function 'MHD_create_response_from_callback' [-Wimplicit-function-declaration]
| src/journal/journal-gatewayd.c:524:18: warning: assignment makes pointer from 
integer without a cast [enabled by default]
| src/journal/journal-gatewayd.c: In function 'request_reader_fields':
| src/journal/journal-gatewayd.c:585:32: error: 
'MHD_CONTENT_READER_END_OF_STREAM' undeclared (first use in this function)
| src/journal/journal-gatewayd.c:590:32: error: 
'MHD_CONTENT_READER_END_WITH_ERROR' undeclared (first use in this function)
| src/journal/journal-gatewayd.c: In function 'request_handler_fields':
| src/journal/journal-gatewayd.c:671:18: warning: assignment makes pointer from 
integer without a cast [enabled by default]
| src/journal/journal-gatewayd.c: In function 'request_handler_redirect':
| src/journal/journal-gatewayd.c:697:72: error: 'MHD_RESPMEM_MUST_FREE' 
undeclared (first use in this function)
| src/journal/journal-gatewayd.c: In function 'request_handler_file':
| src/journal/journal-gatewayd.c:733:9: warning: implicit declaration of 
function 'MHD_create_response_from_fd_at_offset' 
[-Wimplicit-function-declaration]
| src/journal/journal-gatewayd.c:733:18: warning: assignment makes pointer from 
integer without a cast [enabled by default]
| src/journal/journal-gatewayd.c: In function 'request_handler_machine':
| src/journal/journal-gatewayd.c:815:72: error: 'MHD_RESPMEM_MUST_FREE' 
undeclared (first use in this function)
| src/journal/journal-gatewayd.c: In function 'main':
| src/journal/journal-gatewayd.c:889:33: error: 'MHD_OPTION_LISTEN_SOCKET' 
undeclared (first use in this function)

Is there a version check for the microhttpd version missing?

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [HEADS-UP] Early-boot SysV service support is going away

2012-09-19 Thread Koen Kooi

Op 18 sep. 2012, om 00:59 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 Heya,
 
 In a month or two we'll make the SysV service logic in systemd
 generator-based. This helps us clean up our codebase a bit and makes
 SysV service support an optional plugin rather than something that is
 built into PID1.
 
 Effectively, by doing this move very little will change in behaviour for
 SysV scripts, with one exception however: we will remove support for
 early-boot SysV scripts. Early-boot SysV scripts are those for the
 special S, boot, or b runlevel that exist on some distributions.
 These runlevels are highly distro specific, have never been really
 standardized and are really cumbersome to support right now with a lot
 of per-distribution hacks.
 
 Please do not misunderstand this: it's one thing supporting normal SysV
 scripts, it's another one supporting them in the early boot part of the
 things. The former is going to stay for a long time, the latter however
 is going to be removed in a couple of month.
 
 Anyway, this is basically just a heads-up about this, so that you folks
 who still need this can think about good solutions what to do
 instead. Here's what I can propose:
 
 a) port the early-boot init scripts to native systemd units. You
 probably should do that anyway, and in most cases there should be very
 little left that systemd doesn't do on its own anyway in the early-boot
 process. We recommend to go this way, of course.
 
 or 
 
 b) Try to forward-port support for these magic runlvels to what's
 coming. Probably a lot of work, since due to the conversion to a
 generator this is a lot more work than it might appear right now. The
 code structure of the sysv logic will change quite substantially.
 
 or 
 
 c) write an explicit generator for these services, in the specific
 syntax of your distro. 
 
 Anyway, please think about it, we'd just like to make you aware of this
 in time.
 
 At least Debian, Suse, Ubuntu, Angstrom appear to be candidates where
 this lost functionality might be noticable.

I checked and the base system masks off all of those and uses systemd units for 
all the early stuff. So angstrom is safe :)

Does this change protect from dbus getting the short end of the stick when 
using a non-LSB sysv script? Systemd always seems to solve problems by not 
starting the dbus service in this case. I haven't filed a bug since it's only 
triggered by horribly broken sysv scripts and I managed to fix most of them (or 
used native units).

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] diverting HandlePowerKey

2012-08-22 Thread Koen Kooi

Op 16 aug. 2012, om 16:37 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Thu, 16.08.12 14:47, Mantas Mikulėnas (graw...@gmail.com) wrote:
 
 On Thu, Aug 16, 2012 at 2:23 PM, Robin Becker ro...@reportlab.com wrote:
 However, on my netbooks I like to use the power button to launch oblogout
 which brings up a bunch of buttons that allow me to
 logout/suspend/restart/halt etc etc. I can of course continue to use acpid
 to handle the power button, but that seems opposed to the spirit of systemd.
 
 acpid is still okay, I believe. Even though it comes with a single
 shell script for all actions, it is not part of boot process, and it's
 not a required part of acpid either – acpid actually has a built-in
 filtering mechanism in /etc/acpi/events, and the shell script is just
 default configuration.
 
 However, running X11 programs from a daemon, regardless whether it it
 is logind or acpid, is not recommended. Sure, it might be okay for a
 single-user machine, but I have ended up with two, three X servers
 fairly often even on my personal laptop.
 
 It'd be a bit better if the button/lid events were handled by a
 program running inside the Openbox session (the events can be read
 from /run/acpid.socket).
 
 No, nobody should use the acpid client protocol for this. 
 
 On Linux ACPI key presses are processed like any other keys, and thus
 are propagated to the X server. The desktop environment should handle
 these keys and then do whatever is necessary (show a dialog box, react
 immediatey, ...).

And ACPI is x86 only, so you should really focus on catching the KEY_POWER event
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] timedated: gather timezone from /etc/localtime sym target

2012-08-10 Thread Koen Kooi

Op 8 aug. 2012, om 18:51 heeft Lennart Poettering lenn...@poettering.net het 
volgende geschreven:

 On Tue, 07.08.12 00:31, Shawn Landen (shawnland...@gmail.com) wrote:
 
 keep other method for now, consider dropping later.
 
 Supporting relative links here could be problematic as timezones in
 /usr/share/zoneinfo are often themselves symlinks (and symlinks to
 symlinks), so this implamentation only only support absolute links.
 
 Hmm, I am not entirely sure this is really the best thing to do. Always
 requiring a symlink for /etc/localtime breaks a couple of things: we
 can't just bind mount things over in an nspawn container, embedded
 devices have to ship /usr/share/zoneinfo/, which is probably something
 they might want to avoid.

For the embedded systems that need TZ support I ship a subset of timezones, 
it's not that much data. If you're worried about the TZ sizes you shouldn't 
enable TZ support :)

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] How do I disable old init.d scripts?

2012-06-25 Thread Koen Kooi

Op 25 jun. 2012, om 15:25 heeft Paul Menzel het volgende geschreven:

 Dear systemd folks,
 
 
 how can I disable init.d scripts which systemd loads for compatibility
 reasons?
 
$ ls /etc/init.d/motd  (or any other init.d script)
/etc/init.d/motd
$ systemd-analyze blame | grep motd
   543ms motd.service
$ sudo systemctl disable motd.service
Failed to issue method call: No such file or directory

Try:

systemctl mask motd.service

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] setting up to allow separate udev and systemd builds

2012-06-14 Thread Koen Kooi

Op 14 jun. 2012, om 10:38 heeft Wulf C. Krueger het volgende geschreven:

 Hello Lucas,
 
 On 14.06.2012 15:48, Lucas De Marchi wrote:
 on source-based distros like gentoo or lfs, and on distros that do not
 Don't you have the ability to split the built package in gentoo?
 
 I can confirm and emphasize what William already wrote - for us
 source-based distros

I just have to ask: what are non-source based distros based on? Pixie dust?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] pam_systemd.so and su

2012-03-22 Thread Koen Kooi

Op 22 mrt. 2012, om 02:11 heeft Lennart Poettering het volgende geschreven:

 On Thu, 22.03.12 00:41, Lennart Poettering (lenn...@poettering.net) wrote:
 
 On Sun, 18.03.12 16:08, Canek Peláez Valdés (can...@gmail.com) wrote:
 
 Hi; I'm using systemd 43 in Gentoo, and I usally have this line at the
 end of /etc/pam.d/system-auth:
 
 -sessionoptionalpam_systemd.so
 
 When I use su to become root, after logout the following message appears:
 
 ...killed.
 
 Not always, but most of the time. Without the line with
 pam_systemd.so, the message never appears.
 
 So, two questions:
 
 1. Why is my session being killed at logout time?
 
 2. The pam_systemd.so is really necessary? The ...killed. message
 appears after two or three seconds, and it's slightly annoying.
 
 Which version of systemd is this? (If it isnt 44, please upgrade first,
 then try to reproduce this)
 
 Do you have audit enabled in the kernel and are using pam_loginuid?
 
 Normally, when the pam session close hooks are called logind responds to
 this by killing the main process of the session if it still
 exists. This is probably the source of the problem here.
 
 I have now commited a patch to git that might fix your issue. Please
 test:
 
 http://cgit.freedesktop.org/systemd/systemd/commit/?id=75c8e3cffd7da8eede614cf61384957af2c82a29
 
 I assume this fixes your problem, but since our kernels actually have
 audit enabled I am a bit too lazy trying to reproduce the issue here, so
 I'd be very thankful if you could test this!

On the CONFIG_AUDIT front, I just found out that CONFIG_AUDITSYSCALL is not 
supported on ARM and MIPS:

depends on AUDIT  (X86 || PPC || S390 || IA64 || UML || SPARC64 || SUPERH)

There's a patch for ARM that might make it into a recent kernel: 
http://git.kernel.org/?p=linux/kernel/git/viro/audit.git;a=patch;h=29ef73b7a823b77a7cd0bdd7d7cded3fb6c2587b



regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd39: journald segfault brings down some user services

2012-03-09 Thread Koen Kooi

Op 9 mrt. 2012, om 00:37 heeft David Lambert het volgende geschreven:

 On 03/08/2012 03:07 PM, Warpme wrote:
 
 I haven't set any limits in journal.conf - so maybe I should set them. 
 Unfortunately there is no man for this file (or I miss something) - so I 
 prefer to first understand it then next modify content..
 
 Please see my earler post on guessing the journald.conf settings and large 
 file sizes. Maybe we have a common problem here?

I can confirm the large filesizes, even with xz compression enabled. What's the 
best way to debug this?

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] systemd39: journald segfault brings down some user services

2012-03-09 Thread Koen Kooi

Op 9 mrt. 2012, om 10:15 heeft Michael Biebl het volgende geschreven:

 Am 9. März 2012 09:46 schrieb Koen Kooi k...@dominion.thruhere.net:
 
 Op 9 mrt. 2012, om 00:37 heeft David Lambert het volgende geschreven:
 
 On 03/08/2012 03:07 PM, Warpme wrote:
 
 I haven't set any limits in journal.conf - so maybe I should set them. 
 Unfortunately there is no man for this file (or I miss something) - so I 
 prefer to first understand it then next modify content..
 
 Please see my earler post on guessing the journald.conf settings and large 
 file sizes. Maybe we have a common problem here?
 
 I can confirm the large filesizes, even with xz compression enabled. What's 
 the best way to debug this?
 
 Have you build systemd with coredump enabled?
 I had the same issue until I realized that systemd-coredump was
 storing coredumps in the journal (my journal grew easily over 3 GB in
 very short time this way).
 
 The Debian package now builds with --disable-coredump.

How can I check there are actual coredumps in the journal? I don't mind 
disabling them, but it would be nice to find out why the journal is filling up. 
And why there are so many coredumps :)

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [HEADS-UP] Support for /etc/os-release now kinda mandatory

2012-02-14 Thread Koen Kooi

Op 14 feb. 2012, om 10:16 heeft Lennart Poettering het volgende geschreven:

 On Mon, 13.02.12 18:39, Lennart Poettering (lenn...@poettering.net) wrote:
 
 We are taking this as first step for removing all the per-distro
 ifdeffery we have in systemd. Since many major and a lot of minor
 distributions have adopted /etc/os-release already (including finally
 our own Fedora, as per last week) this shouldn't really break anything
 for most folks. And if your distribution still hasn't adopted
 /etc/os-release consider our move additional incentive to do so now.
 
 BTW, in case your distribution doesn't know /etc/os-release yet, and
 you'd like to change that: here's the documentation for this file with
 an example how it should look like:
 
 http://www.freedesktop.org/software/systemd/man/os-release.html
 
 Just a quick note: we now added a CPE field to this, on popular
 request. If you have already adopted this file in your distro, then it
 might be a good idea to update it to include the CPE name for your
 distribution.
 
 (Also, yes, the subject of this thread was borked, it's /etc/os-release,
 not /dev/os-release. Sorry for the confusion).

Excuse my ignorance, what is CPE?

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Support machines with multiple RTCs?

2011-11-22 Thread Koen Kooi

Op 22 nov. 2011, om 18:28 heeft Kay Sievers het volgende geschreven:

 On Tue, Nov 22, 2011 at 18:10, Martin Langhoff
 martin.langh...@gmail.com wrote:
 I have just been perusing the systemd code, and wondering whether it
 supports systems that have two RTCs (where usually only one of them is
 the battery-backed clock, the other isn't battery backed but can wake
 the system up).
 
 Background: OLPC's new laptop, XO-1.75, is an ARM SoC that has exactly
 that configuration. Linux kernels from 2.6.32 (and maybe earlier) can
 handle multiple RTCs, and let you configure which one to use to sync
 the clock in early boot (so userland doesn't have to).
 
 I have just reported a related bug in Fedora's initscripts (
 https://bugzilla.redhat.com/show_bug.cgi?id=756089 ), and a quick
 check of systemd sources hints at similar trouble here...
 
 Two key things seem to be missing:
 
  #1 -- check for the hctosys property. If _any_ rtc present in the
 system has sysfs attribute hctosys == 1, it means that the kernel took
 care of it all, and userland doesn't need to call hwclock, at all.
 
 Systemd requires that the time was set by the kernel. It does not
 support any other config natively, that would be done by plugging-in
 hwclock like it was on non-systemd systems.
 
 The kernel's hctosys is hard coded in the kernel config, right?
 
  #2 -- is customary to prefer /dev/rtc if present -- so that we can
 symlink to the right rtc from udev. src/util.c seems to hardcode rtc0.
 
 Udev does that by default today:
  SUBSYSTEM==rtc, DRIVERS==rtc_cmos, SYMLINK+=rtc

That looks to be specific to x86 RTCs, in my case when using the RTC of the 
PMIC on omap3/4 I get:

  looking at device 
'/devices/platform/omap/omap_i2c.1/i2c-1/1-004b/twl_rtc/rtc/rtc0':
KERNEL==rtc0
SUBSYSTEM==rtc
DRIVER==
ATTR{name}==twl_rtc
ATTR{date}==2011-11-22
ATTR{time}==20:17:03
ATTR{since_epoch}==1321993023
ATTR{max_user_freq}==64
ATTR{hctosys}==1
ATTR{wakealarm}==

regards,

Koen

signature.asc
Description: Message signed with OpenPGP using GPGMail
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] systemd-analyze blame lacks fsck info

2011-10-18 Thread Koen Kooi
Hi,

Every now and them 'systemd-analyze time' reports that it booted in slightly 
under 3 minutes instead of the 5.6s I expect, but systemd-analyze blame shows 
only times in the 600ms range. Babysitting the boot shows that fsck is the 
culprit. 
Was excluding things like fsck-root a design decision for 'blame'? If not, any 
hints to get it included in the list?

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] docs: fix build without xsltproc

2011-10-11 Thread Koen Kooi

Op 11 okt. 2011, om 01:59 heeft Lennart Poettering het volgende geschreven:

 On Tue, 11.10.11 01:36, Kay Sievers (kay.siev...@vrfy.org) wrote:
 
 
 On Tue, Oct 11, 2011 at 01:17, Lennart Poettering
 lenn...@poettering.net wrote:
 On Sun, 02.10.11 20:07, Koen Kooi (k...@dominion.thruhere.net) wrote:
 
 Make would choke on missing rules for man/systemd.1
 
 Hmm, I think this is a misunderstanding:
 
 The original idea here was to require xsltproc when you build from git,
 but ship the pre-generated man pages in the tarball so that you don't
 need xsltproc when you build from a tarball. configure is a script that
 only works properly for the tarball case, and generally is not suitable
 for finding dependencies necessary for git builds. (i.e. it won't
 install autoconf/automake either, ust assumes they are there.)
 
 Or am I missing something here?
 
 No, discussed that already on IRC already. I don't think we can do
 that with current autotools. It would be nice though to support direct
 builds from git, but I think it needs more than conditionals.
 
 One option here would be to introduce a --disable-docs option.
 
 The other option, obviously, is to fix xsltproc, wait for it to be
 fixed, to do the right thing, which was the plan last time I talked to
 Koen. :)
 
 Fix xsltproc? Hmm? What do you mean? What should it to differently? I
 mean, if it isn't installed it can't do anything differently, can it?

The problem I was trying to fix in systemd was that I don't have the .xsl files 
in my build sysroot, only on my host. In the past xsltproc happily looked 
outside the sysroot and things just worked. But a while ago xsltproc was fixed 
to obey the sysroot and won't find the xsl files on my buildhost anymore. I 
think we can all agree that that setup needs to get fixed :)

I misunderstood the purpose of the HAVE_XSLTPROC in Makefile.am and sent the 
patch. Kay explained on IRC that HAVE_XSLTPROC actually means 
BUILD_FROM_TARBALL, so I'm happy to drop this patch.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] docs: fix build without xsltproc

2011-10-02 Thread Koen Kooi
Make would choke on missing rules for man/systemd.1

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 Makefile.am |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index f4a17aa..fb48537 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -750,6 +750,7 @@ EXTRA_DIST += \
 src/dbus-loop.h \
 src/spawn-agent.h
 
+if HAVE_XSLTPROC
 MANPAGES = \
man/systemd.1 \
man/systemctl.1 \
@@ -844,6 +845,7 @@ EXTRA_DIST += \
$(XML_IN_FILES) \
${nodist_man_MANS:=.in} \
${XML_IN_FILES:.xml.in=.html.in}
+endif
 
 systemd_SOURCES = \
src/main.c
-- 
1.6.6.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH 3/3] analyze: draw kernel boot time as well

2011-09-25 Thread Koen Kooi

Op 23 sep. 2011, om 16:29 heeft Lennart Poettering het volgende geschreven:

 On Thu, 22.09.11 15:26, Koen Kooi (k...@dominion.thruhere.net) wrote:
 
 Sample output: 
 http://dominion.thruhere.net/koen/angstrom/systemd/omap4430-panda-201109221422.svg
 
 I'd be willing to merge this, but only if it also covers initrd!

Good, I'll take a stab at that!


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [RFC][PATCH v2] analyze: draw kernel and initrd boot time as well

2011-09-25 Thread Koen Kooi
Sample output without initrd: 
http://dominion.thruhere.net/koen/angstrom/systemd/omap4430-panda-201109221422.svg

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---

Second attempt at this, please check the logic in this patch, a quick test on 
F15 looks OK, but I'd like more datapoints from initrd users.

Changes since v1:
* add initrd bar, tested on a F15 install

 src/systemd-analyze |   34 +++---
 1 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/src/systemd-analyze b/src/systemd-analyze
index ac64040..bc588bb 100755
--- a/src/systemd-analyze
+++ b/src/systemd-analyze
@@ -116,7 +116,11 @@ elif sys.argv[1] == 'plot':
 data = acquire_time_data()
 s = sorted(data, key = lambda i: i[1])
 
-count = 0
+# Account for kernel and initrd bars if they exist
+if initrd_time  0:
+count = 2
+else:
+count = 1
 
 for name, ixt, aet, axt, iet in s:
 
@@ -130,7 +134,7 @@ elif sys.argv[1] == 'plot':
 bar_space = bar_height * 0.1
 
 # 1000px = 10s, 1px = 10ms
-width = (finish_time - start_time)/1 + border*2
+width = (finish_time)/1 + border*2
 height = count * (bar_height + bar_space) + border * 2
 
 if width  1000:
@@ -147,7 +151,7 @@ elif sys.argv[1] == 'plot':
 context.set_line_width(1)
 context.set_source_rgb(0.7, 0.7, 0.7)
 
-for x in range(0, max((finish_time - start_time)/1,110), 100):
+for x in range(0, max((finish_time)/1,110), 100):
 context.move_to(x, 0)
 context.line_to(x, height-border*2)
 
@@ -163,11 +167,27 @@ elif sys.argv[1] == 'plot':
 banner = Running on %s (%s %s) %s % (os.uname()[1], os.uname()[2], 
os.uname()[3], os.uname()[4])
 draw_text(context, 0, -15, banner, hcenter = 0, vcenter = 1)
 
-for x in range(0, max((finish_time - start_time)/1,110), 100):
+for x in range(0, max((finish_time)/1,110), 100):
 draw_text(context, x, -5, %lus % (x/100), vcenter = 0, 
hcenter = 0)
 
 y = 0
 
+# draw boxes for kernel and initrd boot time
+if initrd_time  0:
+draw_box(context, 0, y, initrd_time/1, bar_height, 0.8, 
0.6, 0.6)
+draw_text(context, 10, y + bar_height/2, kernel, hcenter = 0)
+y += bar_height + bar_space
+
+draw_box(context, initrd_time/1, y, start_time/1, 
bar_height, 0.8, 0.6, 0.6)
+draw_text(context, initrd_time/1 + 10, y + bar_height/2, 
initrd, hcenter = 0)
+y += bar_height + bar_space
+
+else:
+draw_box(context, 0, y, start_time/1, bar_height, 0.8, 
0.6, 0.6)
+draw_text(context, 10, y + bar_height/2, kernel, hcenter = 0)
+y += bar_height + bar_space
+
+   
 for name, ixt, aet, axt, iet in s:
 
 drawn = False
@@ -176,7 +196,7 @@ elif sys.argv[1] == 'plot':
 if ixt = start_time and ixt = finish_time:
 
 # Activating
-a = ixt - start_time
+a = ixt
 b = min(filter(lambda x: x = ixt, (aet, axt, iet, 
finish_time))) - ixt
 
 draw_box(context, a/1, y, b/1, bar_height, 1, 
0, 0)
@@ -188,7 +208,7 @@ elif sys.argv[1] == 'plot':
 if aet = start_time and aet = finish_time:
 
 # Active
-a = aet - start_time
+a = aet
 b = min(filter(lambda x: x = aet, (axt, iet, 
finish_time))) - aet
 
 draw_box(context, a/1, y, b/1, bar_height, .8, 
.6, .6)
@@ -200,7 +220,7 @@ elif sys.argv[1] == 'plot':
 if axt = start_time and axt = finish_time:
 
 # Deactivating
-a = axt - start_time
+a = axt
 b = min(filter(lambda x: x = axt, (iet, 
finish_time))) - axt
 
 draw_box(context, a/1, y, b/1, bar_height, .6, 
.4, .4)
-- 
1.6.6.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] analyze: always draw 1s marker for scale

2011-09-22 Thread Koen Kooi
In situations like this:

root@omap4430-panda:~# systemd-analyze
Startup finished in 1499ms (kernel) + 916ms (userspace) = 2416ms

The svg plot will only have the 0s marker and no subsequent markers for scale. 
This patch forces the 1s marker to always be drawn.

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 src/systemd-analyze |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/systemd-analyze b/src/systemd-analyze
index ae7dcfb..649d0e1 100755
--- a/src/systemd-analyze
+++ b/src/systemd-analyze
@@ -147,7 +147,7 @@ elif sys.argv[1] == 'plot':
 context.set_line_width(1)
 context.set_source_rgb(0.7, 0.7, 0.7)
 
-for x in range(0, (finish_time - start_time)/1, 100):
+for x in range(0, max((finish_time - start_time)/1,110), 100):
 context.move_to(x, 0)
 context.line_to(x, height-border*2)
 
@@ -163,7 +163,7 @@ elif sys.argv[1] == 'plot':
 banner = Running on %s (%s %s) %s % (os.uname()[1], os.uname()[2], 
os.uname()[3], os.uname()[4])
 draw_text(context, 0, -15, banner, hcenter = 0, vcenter = 1)
 
-for x in range(0, (finish_time - start_time)/1, 100):
+for x in range(0, max((finish_time - start_time)/1,110), 100):
 draw_text(context, x, -5, %lus % (x/100), vcenter = 0, 
hcenter = 0)
 
 y = 0
-- 
1.6.6.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] gperf: add missing.h that was present in the C version to the m4

2011-08-01 Thread Koen Kooi
This fixes:

src/load-fragment-gperf.c:413:51: error: 'RLIMIT_RTTIME' undeclared (first use 
in this function)

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 src/load-fragment-gperf.gperf.m4 |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/src/load-fragment-gperf.gperf.m4 b/src/load-fragment-gperf.gperf.m4
index 650f444..8e52890 100644
--- a/src/load-fragment-gperf.gperf.m4
+++ b/src/load-fragment-gperf.gperf.m4
@@ -2,6 +2,7 @@
 #include stddef.h
 #include conf-parser.h
 #include load-fragment.h
+#include missing.h
 %}
 struct ConfigPerfItem;
 %null_strings
-- 
1.6.6.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] The Linux Way or Some ideas to make systemd better

2011-07-17 Thread Koen Kooi
Op 17 jul 2011, om 05:32 heeft Sergey het volgende geschreven:
 Why is this better?
 =
 Because it's flexible, portable, simple, easy to support and it's unix-way.
 
 Such structure would work under any circumstances on almost any configuration.
 Users of other Linux distributions can install `sysunixd`/`sysinetd` and it
 will work out of box, together with any existing init system.
 
 If someone, having a tightly integrated bunch of native upstart scripts, 
 cannot
 switch entire init system, he can still install `sysunixd` and `sysinetd` and
 get some speed improvements. Even if he cannot use `sysunixd` and `sysinetd`
 for starting services he can still benefit from faster disks mounting using
 `sysmountd`.
 
 It's extremely portable. Users of other operating systems can install almost
 every component (except systemd-cgroups). Such structure can be ported even
 to the systems that don't support UNIX sockets (just disable `sysunixd`
 and patch `libsystemd` to use different communication method).
 
 It does not have any extra dependencies. So if someone needs to build a 
 compact
 system for netbook with 128MB RAM he can install just `systemd` and save a few
 MB of RAM without dbus (Xorg+IceWM don't need dbus) and other systemd 
 services.
 There's also no need in dbus on ssh/dns/http-servers.

FWIW, I run systemd on a 300MHz arm926 with 64MB ram :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] Add the most common consoles that MeeGo needs

2011-07-01 Thread Koen Kooi

Op 1 jul 2011, om 20:02 heeft Chris Ferron het volgende geschreven:

 On 07/01/2011 10:11 AM, Koen Kooi wrote:
 Op 1 jul 2011, om 18:19 heeft Chris Ferron het volgende geschreven:
 
 MeeGo will use several consoles depending on the hardware adaptations.
 This patch adds the most common to the serial-getty unit Install section so 
 when systemd is built for MeeGo as its distribution, you get the most 
 common Aliased for installation by the user.
 
 
 
 From c50559ea74069061401c8a218d73d515d7b9cd09 Mon Sep 17 00:00:00 2001
 From: Chris Ferronchris.e.fer...@linux.intel.com
 Date: Fri, 1 Jul 2011 08:54:37 -0700
 Subject: [PATCH] Add the most common consoles that MeeGo as a distribution
  will need.
 
 ---
  units/serial-getty@.service.m4 |9 +
  1 files changed, 9 insertions(+), 0 deletions(-)
 
 diff --git a/units/serial-getty@.service.m4 b/units/serial-getty@.service.m4
 index 082290c..aea47be 100644
 --- a/units/serial-getty@.service.m4
 +++ b/units/serial-getty@.service.m4
 @@ -9,6 +9,9 @@
  Description=Serial Getty on %I
  BindTo=dev-%i.device
  After=dev-%i.device systemd-user-sessions.service 
 plymouth-quit-wait.service
 +m4_ifdef(`TARGET_MEEGO',
 +After=dev-%i.device systemd-user-sessions.service
 +)m4_dnl
  m4_ifdef(`TARGET_FEDORA',
  After=rc-local.service
  )m4_dnl
 @@ -44,3 +47,9 @@ KillMode=process
  # Some login implementations ignore SIGTERM, so we send SIGHUP
  # instead, to ensure that login terminates cleanly.
  KillSignal=SIGHUP
 +
 +m4_ifdef(`TARGET_MEEGO',
 +[Install]
 +Alias=sysinit.target.wants/serial-getty@ttyS0.service 
 sysinit.target.wants/serial-getty@ttyS1.service 
 sysinit.target.wants/serial-getty@tty01.service 
 sysinit.target.wants/serial-getty@ttyO2.service
 +)m4_dnl
 An a lot of OMAP systems ttyO1 is hooked up to the bluetooth UART, so I 
 don't know how usefull running a getty on that is.
 
 regards,
 
 Koen
 Thanks for the comment. There may be a good amount of OMAP systems that will 
 use tty01 as a non console.
 But this change should only be included in the MeeGo distribution. In MeeGo 
 at this time we do not have any OMAP adaptations that have this behaviour,

Beagleboard and pandaboard have bluetooth on ttyO1 and meego runs on that, or 
have I misunderstood.

 but we do have supported hardware adaptations that do use tty01 as a console.
 
 So for MeeGo we want the Aliases so that if users using MeeGo on a supported 
 hardware adaptations want to enable the tty01 then they can.
 As Aliases do not mean the tty* will spawn, they are a perfect for giving the 
 users in MeeGo the support and option.

Ok
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [HEADSUP] We no longer spawn 6 gettys by default

2011-06-29 Thread Koen Kooi

Op 29 jun 2011, om 14:37 heeft Robert Schwebel het volgende geschreven:

 On Wed, Jun 29, 2011 at 11:15:02AM +0200, Stef Bon wrote:
 I think it's ok to only activate the getty programs on demand. Maybe
 use only mingetty?? Who works on the serial line these days?
 
 The embedded folks.

Indeed! The first thing I did with systemd was to get serial console working :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] device units rely on udev rules?

2011-05-10 Thread Koen Kooi

Op 9 mei 2011, om 22:23 heeft Kay Sievers het volgende geschreven:

 On Mon, May 9, 2011 at 22:08, Lennart Poettering lenn...@poettering.net 
 wrote:
 On Mon, 09.05.11 22:02, Lennart Poettering (lenn...@poettering.net) wrote:
 
 It's still in the 10 second range on a 600MHz cortex-a8 machine
 booting from an SD card. I need to dig out my 400MHz arm920t to see
 how long it takes there. So having udev-less operation in systemd
 would be nice, even if it's only used on 'embedded'
 
 Have you checked what precisely takes so long? My guess is that some
 driver has a slow sysfs uevent trigger callback, and that might be
 fixable in the driver. You might want to use strace with timestamps to
 figure out why udev trigger might be so slow.
 
 Also note that only very few devices are exposed and depended on by
 systemd. In an embedded env you might be able to simple trigger those
 explicitly first, and then trigger the rest afterwards. That way you
 don't have to wait 10s, and the triggering will be dispatched in the bg,
 but you still get the flexibility that udev can handle hotplugged
 devices.
 
 Kay, opinions?
 
 Guess that should work fine. I guess we could short-cut some stuff too
 if it helps for custom setups, so systemd would look if the device is
 already there, instead of wait for the tag to show up. But we would
 need to find out if that really helps.
 
 Real numbers of the most recent udev on such systems would help, so we
 get an idea what we are dealing with.
 
 Things like:
  time (udevadm trigger; udevadm settle)

root@beagleboard-systemd:~# time ( udevadm trigger ; udevadm settle)

real3m0.475s
user0m0.008s
sys 0m0.117s



 would be good to know too. If that looks like something to fix, the output of:
  udevadm monitor

monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[1305015564.600250] change   /devices/omapdss/display0 (omapdss)
KERNEL[1305015564.600768] change   /devices/omapdss/display1 (omapdss)
KERNEL[1305015564.601165] change   /devices/platform/arm-pmu.0 (platform)
KERNEL[1305015564.601501] change   /devices/platform/ehci-omap.0 (platform)
KERNEL[1305015564.601959] change   /devices/platform/ehci-omap.0/usb1 (usb)
KERNEL[1305015564.602386] change   /devices/platform/ehci-omap.0/usb1/1-0:1.0 
(usb)
KERNEL[1305015564.602813] change   /devices/platform/ehci-omap.0/usb1/1-2 (usb)
KERNEL[1305015564.603240] change   /devices/platform/ehci-omap.0/usb1/1-2/1-2.1 
(usb)
KERNEL[1305015564.603698] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.1/1-2.1:1.0 (usb)
KERNEL[1305015564.604125] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.1/1-2.1:1.0/0003:04F2:0402.0001 (hid)
KERNEL[1305015564.604736] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.1/1-2.1:1.0/input/input2 (input)
KERNEL[1305015564.605163] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.1/1-2.1:1.0/input/input2/event2 
(input)
KERNEL[1305015564.606628] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.1/1-2.1:1.1 (usb)
KERNEL[1305015564.607177] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.1/1-2.1:1.1/0003:04F2:0402.0002 (hid)
KERNEL[1305015564.608245] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.1/1-2.1:1.1/input/input3 (input)
UDEV  [1305015564.609832] change   /devices/omapdss/display0 (omapdss)
KERNEL[1305015564.610351] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.1/1-2.1:1.1/input/input3/event3 
(input)
KERNEL[1305015564.610778] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.1/usb_device/usbdev1.3 (usb_device)
KERNEL[1305015564.612091] change   /devices/platform/ehci-omap.0/usb1/1-2/1-2.2 
(usb)
KERNEL[1305015564.614013] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.2/1-2.2:1.0 (usb)
UDEV  [1305015564.614166] change   /devices/omapdss/display1 (omapdss)
KERNEL[1305015564.614654] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.2/1-2.2:1.0/0003:046D:C00E.0003 (hid)
KERNEL[1305015564.615661] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input4 (input)
KERNEL[1305015564.616729] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input4/event4 
(input)
KERNEL[1305015564.619232] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.2/1-2.2:1.0/input/input4/mouse0 
(input)
KERNEL[1305015564.619781] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.2/usb_device/usbdev1.4 (usb_device)
KERNEL[1305015564.620269] change   /devices/platform/ehci-omap.0/usb1/1-2/1-2.4 
(usb)
KERNEL[1305015564.620727] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.4/1-2.4:1.0 (usb)
KERNEL[1305015564.621978] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2.4/usb_device/usbdev1.5 (usb_device)
KERNEL[1305015564.623962] change   
/devices/platform/ehci-omap.0/usb1/1-2/1-2:1.0 (usb)
KERNEL[1305015564.624450] change   
/devices/platform/ehci-omap.0/usb1/1-2/usb_device/usbdev1.2 (usb_device)
KERNEL[1305015564.624847] change   

Re: [systemd-devel] device units rely on udev rules?

2011-05-10 Thread Koen Kooi

Op 10 mei 2011, om 10:36 heeft Kay Sievers het volgende geschreven:

 On Tue, May 10, 2011 at 10:26, Koen Kooi k...@dominion.thruhere.net wrote:
 Op 9 mei 2011, om 22:23 heeft Kay Sievers het volgende geschreven:
 
 Things like:
  time (udevadm trigger; udevadm settle)
 
 root@beagleboard-systemd:~# time ( udevadm trigger ; udevadm settle)
 
 real3m0.475s
 
 3 Minutes?

It's 3 minutes exactly (+trigger and shell overhead) every time, so I guess I'm 
hitting some kind of timeout

 
 UDEV  [1305015564.609832] change   /devices/omapdss/display0 (omapdss)
 ...
 UDEV  [1305015572.270141] change   /devices/virtual/block/loop1 (block)
 
 Between the first and last event are 7 seconds. Where are the 3
 minutes spent? What do I miss?
 
 Kay

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] device units rely on udev rules?

2011-05-10 Thread Koen Kooi

Op 10 mei 2011, om 11:55 heeft Kay Sievers het volgende geschreven:

 On Tue, May 10, 2011 at 11:26, Koen Kooi k...@dominion.thruhere.net wrote:
 
 Op 10 mei 2011, om 10:36 heeft Kay Sievers het volgende geschreven:
 
 On Tue, May 10, 2011 at 10:26, Koen Kooi k...@dominion.thruhere.net wrote:
 Op 9 mei 2011, om 22:23 heeft Kay Sievers het volgende geschreven:
 
 Things like:
  time (udevadm trigger; udevadm settle)
 
 root@beagleboard-systemd:~# time ( udevadm trigger ; udevadm settle)
 
 real3m0.475s
 
 3 Minutes?
 
 It's 3 minutes exactly (+trigger and shell overhead) every time, so I guess 
 I'm hitting some kind of timeout
 
 It's 180 sec, yeah. Doesn't it print what device it waited for?

udevadm doesn't

 If you add: ... settle --timeout=10 does it print something?

root@beagleboard-systemd:~# time ( udevadm trigger ; udevadm settle 
--timeout=10)   


real0m10.427s
user0m0.023s
sys 0m0.102s

Changing it to '1' doesn't print anything either. Should udev-monitor print the 
device it's waiting for?

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] device units rely on udev rules?

2011-05-10 Thread Koen Kooi

Op 10 mei 2011, om 14:14 heeft Lennart Poettering het volgende geschreven:

 On Tue, 10.05.11 14:11, Harald Hoyer (harald.ho...@gmail.com) wrote:
 
 
 Am 10.05.2011 14:09, schrieb Lennart Poettering:
 On Tue, 10.05.11 13:47, Koen Kooi (k...@dominion.thruhere.net) wrote:
 
 What udev version is that? I'm running current -git, maybe something
 was broken, don't know it though.
 
 [  122.891967]27udevd[88]: unable to receive ctrl connection: Function 
 not implemented
 
 Time to rebuild eglibc I guess.
 
 Hmm, does your kernel lack AF_UNIX/SOCK_SEQPACKET support?
 
 Lennart
 
 
 Might be time, for a .config list of required features :-)
 
 Neither accept4 nor AF_UNIX/SOCK_SEQPACKET are optional kernel
 features. However, they are relatively new kernel features and some
 archs had trouble keeping up in enabling them even though the code
 exists in the kernel.
 
 Currently our README mentions that we need kernel = 2.6.30. It might
 make sense to include another line mentioning that on ARM/MIPS/others
 you need an even newer one.

Udev has this: 
http://git.kernel.org/?p=linux/hotplug/udev.git;a=patch;h=67a77c8bf299f6264f001677becd056316ebce2f

I backported that kernel patch to 2.6.32 since I can test that, but the systemd 
tests were all run with 2.6.37. The problem is that eglibc was built against 
yet another different version of headers, which lacked the syscall for arm.

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] device units rely on udev rules?

2011-05-10 Thread Koen Kooi

Op 10 mei 2011, om 19:01 heeft Kay Sievers het volgende geschreven:

 On Tue, May 10, 2011 at 17:34, Koen Kooi k...@dominion.thruhere.net wrote:
 
 So after rebuilding eglibc against 2.6.37 headers and udev from git:
 
 root@beagleboard-systemd:~# time ( udevadm trigger ; udevadm settle )
 
 real0m10.475s
 
 Ok, at least the timeout issue seems gone.
 
 How many device do you have?
  find /sys -name uevent | wc -l

root@beagleboard-systemd:/usr/bin#  find /sys -name uevent | wc -l
462

 How many devices have a modalias:
  find /sys -name modalias | wc -l

root@beagleboard-systemd:/usr/bin# find /sys -name modalias | wc -l
84



 And the matching systemd-analyze plot: 
 http://dominion.thruhere.net/koen/angstrom/systemd/git-with-accept4.svg
 
 What does:
  time udevadm test /sys/class/tty/ttyO0
 show?

root@beagleboard-systemd:/usr/bin# time udevadm test /sys/class/tty/ttyO0
run_command: calling: test
udevadm_test: version 168
This program is for debugging only, it does not run any program,
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

parse_file: reading '/lib/udev/rules.d/42-qemu-usb.rules' as rules file
parse_file: reading '/lib/udev/rules.d/50-firmware.rules' as rules file
parse_file: reading '/etc/udev/rules.d/50-udev-default.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-cdrom_id.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-floppy.rules' as rules file
parse_file: reading '/etc/udev/rules.d/60-persistent-alsa.rules' as rules file
parse_file: reading '/etc/udev/rules.d/60-persistent-input.rules' as rules file
parse_file: reading '/etc/udev/rules.d/60-persistent-serial.rules' as rules file
parse_file: reading '/etc/udev/rules.d/60-persistent-storage-tape.rules' as 
rules file
parse_file: reading '/etc/udev/rules.d/60-persistent-storage.rules' as rules 
file
parse_file: reading '/lib/udev/rules.d/60-persistent-v4l.rules' as rules file
parse_file: reading '/lib/udev/rules.d/61-mobile-action.rules' as rules file
parse_file: reading '/lib/udev/rules.d/61-persistent-storage-edd.rules' as 
rules file
parse_file: reading '/lib/udev/rules.d/70-acl.rules' as rules file
parse_file: reading '/lib/udev/rules.d/70-hid2hci.rules' as rules file
parse_file: reading '/lib/udev/rules.d/75-cd-aliases-generator.rules' as rules 
file
parse_file: reading '/etc/udev/rules.d/75-net-description.rules' as rules file
parse_file: reading '/lib/udev/rules.d/75-persistent-net-generator.rules' as 
rules file
parse_file: reading '/lib/udev/rules.d/75-probe_mtd.rules' as rules file
parse_file: reading '/etc/udev/rules.d/75-tty-description.rules' as rules file
parse_file: reading '/etc/udev/rules.d/78-sound-card.rules' as rules file
parse_file: reading '/etc/udev/rules.d/80-drivers.rules' as rules file
parse_file: reading '/lib/udev/rules.d/95-keyboard-force-release.rules' as 
rules file
parse_file: reading '/lib/udev/rules.d/95-keymap.rules' as rules file
parse_file: reading '/etc/udev/rules.d/95-udev-late.rules' as rules file
parse_file: reading '/lib/udev/rules.d/97-bluetooth-hid2hci.rules' as rules file
parse_file: reading '/lib/udev/rules.d/97-bluetooth.rules' as rules file
parse_file: reading '/lib/udev/rules.d/99-systemd.rules' as rules file
parse_file: reading '/etc/udev/rules.d/local.rules' as rules file
parse_file: reading '/etc/udev/rules.d/permissions.rules' as rules file
parse_file: reading '/etc/udev/rules.d/run.rules' as rules file
parse_file: reading '/etc/udev/rules.d/udev.rules' as rules file
udev_rules_new: rules use 27348 bytes tokens (2279 * 12 bytes), 15978 bytes 
buffer
udev_rules_new: temporary index used 16860 bytes (843 * 20 bytes)
udev_device_new_from_syspath: device 0x1fd50d0 has devpath 
'/devices/platform/omap/omap_uart.0/tty/ttyO0'
udev_device_new_from_syspath: device 0x1fe48e0 has devpath 
'/devices/platform/omap/omap_uart.0/tty/ttyO0'
udev_device_read_db: device 0x1fe48e0 filled with db file data
udev_rules_apply_to_event: GROUP 20 /etc/udev/rules.d/50-udev-default.rules:11
udev_device_new_from_syspath: device 0x1fdf078 has devpath 
'/devices/platform/omap/omap_uart.0'
udev_device_new_from_syspath: device 0x1fdf2b8 has devpath 
'/devices/platform/omap'
udev_device_new_from_syspath: device 0x1fdf438 has devpath '/devices/platform'
udev_rules_apply_to_event: GROUP 20 /etc/udev/rules.d/permissions.rules:43
udev_rules_apply_to_event: RUN 'socket:/org/kernel/udev/monitor' 
/etc/udev/rules.d/run.rules:2
udev_event_execute_rules: no node name set, will use kernel supplied name 
'ttyO0'
udev_node_add: creating device node '/dev/ttyO0', devnum=252:0, mode=0660, 
uid=0, gid=20
udev_node_mknod: preserve file '/dev/ttyO0', because it has correct dev_t
udev_node_mknod: preserve permissions /dev/ttyO0, 020660, uid=0, gid=20
node_symlink: preserve already existing symlink '/dev/char/252:0' to '../ttyO0'
udev_device_update_db: created db file '/run/udev/data/c252:0' for 
'/devices/platform/omap

Re: [systemd-devel] [PATCH] Angstrom support

2011-05-09 Thread Koen Kooi

Op 5 mei 2011, om 19:54 heeft Gustavo Sverzut Barbieri het volgende geschreven:

 On Thu, May 5, 2011 at 1:17 PM, Harald Hoyer harald.ho...@gmail.com wrote:
 diff --git a/src/util.c b/src/util.c
 index f0051ee..5af9161 100644
 --- a/src/util.c
 +++ b/src/util.c
 @@ -3426,6 +3426,18 @@ void status_welcome(void) {
 
 if (!ansi_color)
 const_color = 1;35; /* Bright Magenta for MeeGo */
 +#elif defined(TARGET_ANGSTROM)
 +
 +if (!pretty_name) {
 +if ((r = read_one_line_file(/etc/angstrom-version, 
 pretty_name))  0) {
 +
 +if (r != -ENOENT)
 +log_warning(Failed to read 
 /etc/angstrom-version: %s, strerror(-r));
 +}
 +}
 +
 +   if (!ansi_color)
 +   const_color = 1;35; /* Bright Magenta for Angstrom */
  #endif
 
  if (!pretty_name  !const_pretty)
 
 
 
 
 
 Hmm, wouldn't it make sense to symlink
 
 /etc/SuSE-release
 /etc/gentoo-release
 /etc/altlinux-release
 /etc/debian_version
 /etc/mandriva-release
 /etc/meego-release
 
 to /etc/system-release or provide /etc/lsb-release ???
 
 All those #ifdefs are taking overhand...
 
 that would be good! :-) but who has the right/final-world to get these
 distros to do it?
 
 Maybe Koen is in that position with Angstron? :-) 

Angstrom now provides /etc/os-release and the offending hunk has been dropping 
in the V2 version of the patch. Anything else that needs to get addressed 
before the patch can go in?

regards,

Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [Patch V2] Angstrom support

2011-05-06 Thread Koen Kooi
This commit consists of the initial work to include Angstrom as a ported
distribution for systemd.

Angstrom tries to follow the debian way as much as possible, but deviates
where it doesn't make sense for 'embedded'.

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 Makefile.am|7 +++
 configure.ac   |7 +++
 src/locale-setup.c |2 +-
 src/service.c  |   10 +-
 4 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 49d2ee8..f3f7818 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -96,6 +96,12 @@ AM_CPPFLAGS += \
-DKBD_SETFONT=\/bin/setfont\ \
-DDEFAULT_FONT=\LatArCyrHeb-16\
 else
+if TARGET_ANGSTROM
+AM_CPPFLAGS += \
+   -DKBD_LOADKEYS=\/usr/bin/loadkeys\ \
+   -DKBD_SETFONT=\/usr/bin/setfont\ \
+   -DDEFAULT_FONT=\LatArCyrHeb-16\
+else
 AM_CPPFLAGS += \
-DKBD_LOADKEYS=\/bin/loadkeys\ \
-DKBD_SETFONT=\/bin/setfont\ \
@@ -105,6 +111,7 @@ endif
 endif
 endif
 endif
+endif
 
 rootbin_PROGRAMS = \
systemd \
diff --git a/configure.ac b/configure.ac
index dcd4b9d..b5b7ac3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -295,6 +295,7 @@ if test z$with_distro = z; then
 test -f /etc/altlinux-release  with_distro=altlinux
 test -f /etc/mandriva-release  with_distro=mandriva
 test -f /etc/meego-release  with_distro=meego
+test -f /etc/angstrom-version  with_distro=angstrom
 if test x`lsb_release -is 2/dev/null` = xUbuntu; then
 with_distro=ubuntu
 fi
@@ -375,6 +376,11 @@ case $with_distro in
 AC_DEFINE(TARGET_MEEGO, [], [Target is MeeGo])
 M4_DISTRO_FLAG=-DTARGET_MEEGO=1
;;
+angstrom)
+SYSTEM_SYSVRCND_PATH=/etc
+AC_DEFINE(TARGET_ANGSTROM, [], [Target is Ångström])
+M4_DISTRO_FLAG=-DTARGET_ANGSTROM=1
+;;
 other)
 ;;
 *)
@@ -425,6 +431,7 @@ AM_CONDITIONAL(TARGET_FRUGALWARE, test x$with_distro = 
xfrugalware)
 AM_CONDITIONAL(TARGET_ALTLINUX, test x$with_distro = xaltlinux)
 AM_CONDITIONAL(TARGET_MANDRIVA, test x$with_distro = xmandriva)
 AM_CONDITIONAL(TARGET_MEEGO, test x$with_distro = xmeego)
+AM_CONDITIONAL(TARGET_ANGSTROM, test x$with_distro = xangstrom)
 
 AM_CONDITIONAL(HAVE_PLYMOUTH, test -n $have_plymouth)
 AM_CONDITIONAL(HAVE_SYSV_COMPAT, test $SYSTEM_SYSV_COMPAT = yes)
diff --git a/src/locale-setup.c b/src/locale-setup.c
index d9adfa3..33111da 100644
--- a/src/locale-setup.c
+++ b/src/locale-setup.c
@@ -136,7 +136,7 @@ int locale_setup(void) {
 log_warning(Failed to read /etc/sysconfig/language: 
%s, strerror(-r));
 }
 
-#elif defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU)
+#elif defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_ANGSTROM)
 if (r = 0 
 (r = parse_env_file(/etc/default/locale, NEWLINE,
 LANG,  variables[VARIABLE_LANG],
diff --git a/src/service.c b/src/service.c
index e7a5622..f826754 100644
--- a/src/service.c
+++ b/src/service.c
@@ -65,7 +65,7 @@ static const struct {
 { boot.d, SPECIAL_SYSINIT_TARGET,   RUNLEVEL_SYSINIT },
 #endif
 
-#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_FRUGALWARE)
+#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_FRUGALWARE) || defined(TARGET_ANGSTROM)
 /* Debian style rcS.d */
 { rcS.d,  SPECIAL_SYSINIT_TARGET,   RUNLEVEL_SYSINIT },
 #endif
@@ -246,7 +246,7 @@ static char *sysv_translate_name(const char *name) {
 if (!(r = new(char, strlen(name) + sizeof(.service
 return NULL;
 
-#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU)
+#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_ANGSTROM)
 if (endswith(name, .sh))
 /* Drop Debian-style .sh suffix */
 strcpy(stpcpy(r, name) - 3, .service);
@@ -297,7 +297,7 @@ static int sysv_translate_facility(const char *name, const 
char *filename, char
 x-display-manager,SPECIAL_DISPLAY_MANAGER_SERVICE,
 null, NULL,
 
-#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU)
+#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_ANGSTROM)
 mail-transport-agent, SPECIAL_MAIL_TRANSFER_AGENT_TARGET,
 #endif
 
@@ -887,7 +887,7 @@ static int service_load_sysv_name(Service *s, const char 
*name) {
 
 /* For SysV services we strip the boot.*, rc.* and *.sh
  * prefixes/suffixes. */
-#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU)
+#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_ANGSTROM)
 if (endswith(name, .sh.service))
 return -ENOENT;
 #endif
@@ -914,7 +914,7 @@ static int service_load_sysv_name

[systemd-devel] [PATCH] Angstrom support

2011-05-05 Thread Koen Kooi
This commit consists of the initial work to include Angstrom as a ported
distribution for systemd.

Angstrom tries to follow the debian way as much as possible, but deviates
where it doesn't make sense for 'embedded'.

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 Makefile.am|7 +++
 configure.ac   |7 +++
 src/locale-setup.c |2 +-
 src/service.c  |   10 +-
 src/util.c |   12 
 5 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 49d2ee8..f3f7818 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -96,6 +96,12 @@ AM_CPPFLAGS += \
-DKBD_SETFONT=\/bin/setfont\ \
-DDEFAULT_FONT=\LatArCyrHeb-16\
 else
+if TARGET_ANGSTROM
+AM_CPPFLAGS += \
+   -DKBD_LOADKEYS=\/usr/bin/loadkeys\ \
+   -DKBD_SETFONT=\/usr/bin/setfont\ \
+   -DDEFAULT_FONT=\LatArCyrHeb-16\
+else
 AM_CPPFLAGS += \
-DKBD_LOADKEYS=\/bin/loadkeys\ \
-DKBD_SETFONT=\/bin/setfont\ \
@@ -105,6 +111,7 @@ endif
 endif
 endif
 endif
+endif
 
 rootbin_PROGRAMS = \
systemd \
diff --git a/configure.ac b/configure.ac
index dcd4b9d..b5b7ac3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -295,6 +295,7 @@ if test z$with_distro = z; then
 test -f /etc/altlinux-release  with_distro=altlinux
 test -f /etc/mandriva-release  with_distro=mandriva
 test -f /etc/meego-release  with_distro=meego
+test -f /etc/angstrom-version  with_distro=angstrom
 if test x`lsb_release -is 2/dev/null` = xUbuntu; then
 with_distro=ubuntu
 fi
@@ -375,6 +376,11 @@ case $with_distro in
 AC_DEFINE(TARGET_MEEGO, [], [Target is MeeGo])
 M4_DISTRO_FLAG=-DTARGET_MEEGO=1
;;
+angstrom)
+SYSTEM_SYSVRCND_PATH=/etc
+AC_DEFINE(TARGET_ANGSTROM, [], [Target is Ångström])
+M4_DISTRO_FLAG=-DTARGET_ANGSTROM=1
+;;
 other)
 ;;
 *)
@@ -425,6 +431,7 @@ AM_CONDITIONAL(TARGET_FRUGALWARE, test x$with_distro = 
xfrugalware)
 AM_CONDITIONAL(TARGET_ALTLINUX, test x$with_distro = xaltlinux)
 AM_CONDITIONAL(TARGET_MANDRIVA, test x$with_distro = xmandriva)
 AM_CONDITIONAL(TARGET_MEEGO, test x$with_distro = xmeego)
+AM_CONDITIONAL(TARGET_ANGSTROM, test x$with_distro = xangstrom)
 
 AM_CONDITIONAL(HAVE_PLYMOUTH, test -n $have_plymouth)
 AM_CONDITIONAL(HAVE_SYSV_COMPAT, test $SYSTEM_SYSV_COMPAT = yes)
diff --git a/src/locale-setup.c b/src/locale-setup.c
index d9adfa3..33111da 100644
--- a/src/locale-setup.c
+++ b/src/locale-setup.c
@@ -136,7 +136,7 @@ int locale_setup(void) {
 log_warning(Failed to read /etc/sysconfig/language: 
%s, strerror(-r));
 }
 
-#elif defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU)
+#elif defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_ANGSTROM)
 if (r = 0 
 (r = parse_env_file(/etc/default/locale, NEWLINE,
 LANG,  variables[VARIABLE_LANG],
diff --git a/src/service.c b/src/service.c
index e7a5622..f826754 100644
--- a/src/service.c
+++ b/src/service.c
@@ -65,7 +65,7 @@ static const struct {
 { boot.d, SPECIAL_SYSINIT_TARGET,   RUNLEVEL_SYSINIT },
 #endif
 
-#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_FRUGALWARE)
+#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_FRUGALWARE) || defined(TARGET_ANGSTROM)
 /* Debian style rcS.d */
 { rcS.d,  SPECIAL_SYSINIT_TARGET,   RUNLEVEL_SYSINIT },
 #endif
@@ -246,7 +246,7 @@ static char *sysv_translate_name(const char *name) {
 if (!(r = new(char, strlen(name) + sizeof(.service
 return NULL;
 
-#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU)
+#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_ANGSTROM)
 if (endswith(name, .sh))
 /* Drop Debian-style .sh suffix */
 strcpy(stpcpy(r, name) - 3, .service);
@@ -297,7 +297,7 @@ static int sysv_translate_facility(const char *name, const 
char *filename, char
 x-display-manager,SPECIAL_DISPLAY_MANAGER_SERVICE,
 null, NULL,
 
-#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU)
+#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_ANGSTROM)
 mail-transport-agent, SPECIAL_MAIL_TRANSFER_AGENT_TARGET,
 #endif
 
@@ -887,7 +887,7 @@ static int service_load_sysv_name(Service *s, const char 
*name) {
 
 /* For SysV services we strip the boot.*, rc.* and *.sh
  * prefixes/suffixes. */
-#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU)
+#if defined(TARGET_DEBIAN) || defined(TARGET_UBUNTU) || 
defined(TARGET_ANGSTROM)
 if (endswith(name, .sh.service))
 return -ENOENT;
 #endif
@@ -914,7 +914,7