Cristian Axenie | 8 Sep 14:43 2010
Picon

Systemd port on custom embedded linux

Hello all !

I have some questions regarding some options to enable/disable when using systemd on a custom embedded  Linux distro. I've managed to port systemd-8 for a Tegra2 similar board, based on ARMv7 CPU. The embedded OS is a Fedora like system and I have used the systemd-8-1.fc14.src.rpm.
Next the most important setup steps are given. When configuring the package I've used the following options :
--with-distro=other \
--with-sysvinit-path=/etc/rc.d/init.d \
--with-sysvrcd-path=/etc/rc.d \
--with-syslog-service=rsyslog.service \
--with-dbuspolicydir=/etc/dbus-1/system.d \
--with-dbussessionservicedir=/usr/share/dbus-1/services \
--with-dbussystemservicedir=/usr/share/dbus-1/services/../system-services \
--with-dbusinterfacedir=/usr/share/dbus-1/services/../interfaces

Another aspect refers to the fact that on the embedded system I don't need a graphical interface so systemdadm will not be necessary, and also due to the fact that I'm cross-compiling I have eliminated the org.freedesktop.systemd1.%.xml target from Makefile.in in order to skip running the ARM binary ./systemd --introspect=${ <at> :.xml=}  on the host build system. Also the porting guide was considered when preparing the package for cross-compilation.
After the compilation I've added init=/bin/systemd to my kernel boot line and after freeing the init memory the system hangs with a "Failed to mount /dev : No such device" message. The compilation environment was properly configured with all the dependencies version required by systemd although there were some options that were diabled. For example, for udev I have disabled introspection support.
Any hints will be appreciated !

Best !

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Kay Sievers | 8 Sep 15:06 2010

Re: Systemd port on custom embedded linux

On Wed, Sep 8, 2010 at 14:43, Cristian Axenie <cristian.axenie <at> gmail.com> wrote:
> I have some questions regarding some options to enable/disable when using
> systemd on a custom embedded  Linux distro. I've managed to port systemd-8
> for a Tegra2 similar board, based on ARMv7 CPU. The embedded OS is a Fedora
> like system and I have used the systemd-8-1.fc14.src.rpm.
> Next the most important setup steps are given. When configuring the package
> I've used the following options :
> --with-distro=other \
> --with-sysvinit-path=/etc/rc.d/init.d \
> --with-sysvrcd-path=/etc/rc.d \
> --with-syslog-service=rsyslog.service \
> --with-dbuspolicydir=/etc/dbus-1/system.d \
> --with-dbussessionservicedir=/usr/share/dbus-1/services \
> --with-dbussystemservicedir=/usr/share/dbus-1/services/../system-services \
> --with-dbusinterfacedir=/usr/share/dbus-1/services/../interfaces
>
> Another aspect refers to the fact that on the embedded system I don't need a
> graphical interface so systemdadm will not be necessary, and also due to the
> fact that I'm cross-compiling I have eliminated the
> org.freedesktop.systemd1.%.xml target from Makefile.in in order to skip
> running the ARM binary ./systemd --introspect=${ <at> :.xml=}  on the host build
> system. Also the porting guide was considered when preparing the package for
> cross-compilation.

> After the compilation I've added init=/bin/systemd to my kernel boot line
> and after freeing the init memory the system hangs with a "Failed to mount
> /dev : No such device" message.

You have CONFIG_DEVTMPFS=y in your kernel?

> The compilation environment was properly
> configured with all the dependencies version required by systemd although
> there were some options that were diabled. For example, for udev I have
> disabled introspection support.

Udev itself has no idea of any introspection, it's just a library
GUdev, which you don't need for systemd.

Kay
_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Gustavo Sverzut Barbieri | 8 Sep 15:34 2010

Re: Systemd port on custom embedded linux

On Wed, Sep 8, 2010 at 10:06 AM, Kay Sievers <kay.sievers <at> vrfy.org> wrote:
>> After the compilation I've added init=/bin/systemd to my kernel boot line
>> and after freeing the init memory the system hangs with a "Failed to mount
>> /dev : No such device" message.
>
> You have CONFIG_DEVTMPFS=y in your kernel?

BTW, if this is always required now we should update README (and then
I can change my Gentoo ebuild to check for it)

BR,

--

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri <at> gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
Kay Sievers | 8 Sep 15:37 2010

Re: Systemd port on custom embedded linux

On Wed, Sep 8, 2010 at 15:34, Gustavo Sverzut Barbieri
<barbieri <at> profusion.mobi> wrote:
> On Wed, Sep 8, 2010 at 10:06 AM, Kay Sievers <kay.sievers <at> vrfy.org> wrote:
>>> After the compilation I've added init=/bin/systemd to my kernel boot line
>>> and after freeing the init memory the system hangs with a "Failed to mount
>>> /dev : No such device" message.
>>
>> You have CONFIG_DEVTMPFS=y in your kernel?
>
> BTW, if this is always required now we should update README (and then
> I can change my Gentoo ebuild to check for it)

It will not work without it.

Kay
Cristian Axenie | 8 Sep 15:39 2010
Picon

Re: Systemd port on custom embedded linux

I've managed to rebuild my kernel with the CONFIG_DEVTMPFS activated and now the problem doesn't reproduces anymore. Now it seems that /sys/fs/cgroup cannot be mounted. Any other known issues or other kernel config options to be activated ?

Best !

On Wed, Sep 8, 2010 at 4:34 PM, Gustavo Sverzut Barbieri <barbieri <at> profusion.mobi> wrote:
On Wed, Sep 8, 2010 at 10:06 AM, Kay Sievers <kay.sievers <at> vrfy.org> wrote:
>> After the compilation I've added init=/bin/systemd to my kernel boot line
>> and after freeing the init memory the system hangs with a "Failed to mount
>> /dev : No such device" message.
>
> You have CONFIG_DEVTMPFS=y in your kernel?

BTW, if this is always required now we should update README (and then
I can change my Gentoo ebuild to check for it)

BR,

--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri <at> gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Kay Sievers | 8 Sep 15:41 2010

Re: Systemd port on custom embedded linux

On Wed, Sep 8, 2010 at 15:39, Cristian Axenie <cristian.axenie <at> gmail.com> wrote:
> I've managed to rebuild my kernel with the CONFIG_DEVTMPFS activated and now
> the problem doesn't reproduces anymore. Now it seems that /sys/fs/cgroup
> cannot be mounted. Any other known issues or other kernel config options to
> be activated ?

You need this patch:
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=676db4af043014e852f67ba0349dae0071bd11f3
or a brand new kernel that has it.

Kay
Cristian Axenie | 8 Sep 16:25 2010
Picon

Re: Systemd port on custom embedded linux

I've managed to add the cgroupfs support and the systems doesn't complain when mounting any filesystem. Due to the fact that I have disabled selinux and auditing support I get the following messages :

[   18.770000] Freeing init memory: 152K
[   19.430000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP -AUDIT -SELINUX)
[   19.470000] systemd[1]: /sbin/modprobe failed with error code 1.
[   19.480000] systemd[1]: No hostname configured.
[   19.490000] systemd[1]: Set hostname to <localhost>.
[   19.500000] systemd[1]: Netlink failure for request 2: Operation not supported
[   19.520000] systemd[1]: Failed to configure loopback device: Operation not supported
[   19.550000] systemd[1]: Failed to create private D-Bus server: Operating system does not support abstract socket namespace
[   19.570000] systemd[1]: Failed to allocate manager object: Input/output error
[   19.590000] systemd-cgroups-agent[672]: Failed to get D-Bus connection: Operating system does not support abstract socket namespace

It seems that I have stripped to much of the functionality required for systemd to work when trying to make it lightweight.  Should I reconsider some aspects ? Can you point the vital elements ?

Best !

On Wed, Sep 8, 2010 at 4:41 PM, Kay Sievers <kay.sievers <at> vrfy.org> wrote:
On Wed, Sep 8, 2010 at 15:39, Cristian Axenie <cristian.axenie <at> gmail.com> wrote:
> I've managed to rebuild my kernel with the CONFIG_DEVTMPFS activated and now
> the problem doesn't reproduces anymore. Now it seems that /sys/fs/cgroup
> cannot be mounted. Any other known issues or other kernel config options to
> be activated ?

You need this patch:
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=676db4af043014e852f67ba0349dae0071bd11f3
or a brand new kernel that has it.

Kay

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Gustavo Sverzut Barbieri | 8 Sep 16:32 2010

Re: Systemd port on custom embedded linux

On Wed, Sep 8, 2010 at 11:25 AM, Cristian Axenie
<cristian.axenie <at> gmail.com> wrote:
> I've managed to add the cgroupfs support and the systems doesn't complain
> when mounting any filesystem. Due to the fact that I have disabled selinux
> and auditing support I get the following messages :
>
> [   18.770000] Freeing init memory: 152K
> [   19.430000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP
> -AUDIT -SELINUX)
> [   19.470000] systemd[1]: /sbin/modprobe failed with error code 1.

probably it's because of missing unix, autofs4 or ipv6 modules (or
built-in support).

while unix and autofs4 are required, ipv6 should be optional and I'll
send a patch later today for it. Anyway, if its is ipv6 don't worry as
it is just informative.

> [   19.480000] systemd[1]: No hostname configured.
> [   19.490000] systemd[1]: Set hostname to <localhost>.
> [   19.500000] systemd[1]: Netlink failure for request 2: Operation not
> supported
> [   19.520000] systemd[1]: Failed to configure loopback device: Operation
> not supported

these are due ipv6, my patch will fix them as well.

> [   19.550000] systemd[1]: Failed to create private D-Bus server: Operating
> system does not support abstract socket namespace
> [   19.570000] systemd[1]: Failed to allocate manager object: Input/output
> error
> [   19.590000] systemd-cgroups-agent[672]: Failed to get D-Bus connection:
> Operating system does not support abstract socket namespace

you need udev and dbus with --with-systemdsystemunitdir=/lib/systemd/system

> It seems that I have stripped to much of the functionality required for
> systemd to work when trying to make it lightweight.  Should I reconsider
> some aspects ? Can you point the vital elements ?

these should make it work. If you don't need sysv init compatibility,
then check out the patch I've send... at least it will remove some
stat/open and avoid some checks you don't need.

--

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri <at> gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Cristian Axenie | 8 Sep 16:44 2010
Picon

Re: Systemd port on custom embedded linux

TIA for the patch. I would like to see this working. Where should the patch be available?
As for the systemd unit dir in dbus setup it is present and I am now adding it to udev configuration.

Best !


On Wed, Sep 8, 2010 at 5:32 PM, Gustavo Sverzut Barbieri <barbieri <at> profusion.mobi> wrote:
On Wed, Sep 8, 2010 at 11:25 AM, Cristian Axenie
> I've managed to add the cgroupfs support and the systems doesn't complain
> when mounting any filesystem. Due to the fact that I have disabled selinux
> and auditing support I get the following messages :
>
> [   18.770000] Freeing init memory: 152K
> [   19.430000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP
> -AUDIT -SELINUX)
> [   19.470000] systemd[1]: /sbin/modprobe failed with error code 1.

probably it's because of missing unix, autofs4 or ipv6 modules (or
built-in support).

while unix and autofs4 are required, ipv6 should be optional and I'll
send a patch later today for it. Anyway, if its is ipv6 don't worry as
it is just informative.


> [   19.480000] systemd[1]: No hostname configured.
> [   19.490000] systemd[1]: Set hostname to <localhost>.
> [   19.500000] systemd[1]: Netlink failure for request 2: Operation not
> supported
> [   19.520000] systemd[1]: Failed to configure loopback device: Operation
> not supported

these are due ipv6, my patch will fix them as well.


> [   19.550000] systemd[1]: Failed to create private D-Bus server: Operating
> system does not support abstract socket namespace
> [   19.570000] systemd[1]: Failed to allocate manager object: Input/output
> error
> [   19.590000] systemd-cgroups-agent[672]: Failed to get D-Bus connection:
> Operating system does not support abstract socket namespace

you need udev and dbus with --with-systemdsystemunitdir=/lib/systemd/system


> It seems that I have stripped to much of the functionality required for
> systemd to work when trying to make it lightweight.  Should I reconsider
> some aspects ? Can you point the vital elements ?

these should make it work. If you don't need sysv init compatibility,
then check out the patch I've send... at least it will remove some
stat/open and avoid some checks you don't need.

--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri <at> gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Gustavo Sverzut Barbieri | 8 Sep 16:59 2010

Re: Systemd port on custom embedded linux

On Wed, Sep 8, 2010 at 11:44 AM, Cristian Axenie
<cristian.axenie <at> gmail.com> wrote:
> TIA for the patch. I would like to see this working. Where should the patch
> be available?

just sent them to mail list:

  http://lists.freedesktop.org/archives/systemd-devel/2010-September/000272.html
  http://lists.freedesktop.org/archives/systemd-devel/2010-September/000273.html

while they should not depend on each other, the way build.h is done
the patches do depend... or you just apply ipv6 patch and fix the
conflict, it is pretty simple.

> As for the systemd unit dir in dbus setup it is present and I am now adding
> it to udev configuration.

yeah, my system did not work properly until i did that.

--

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri <at> gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
Cristian Axenie | 8 Sep 17:19 2010
Picon

Re: Systemd port on custom embedded linux

The patches aren't applying correctly ! For what version of systemd were extracted?

Best !

On Wed, Sep 8, 2010 at 5:59 PM, Gustavo Sverzut Barbieri <barbieri <at> profusion.mobi> wrote:
On Wed, Sep 8, 2010 at 11:44 AM, Cristian Axenie
> TIA for the patch. I would like to see this working. Where should the patch
> be available?

just sent them to mail list:

 http://lists.freedesktop.org/archives/systemd-devel/2010-September/000272.html
 http://lists.freedesktop.org/archives/systemd-devel/2010-September/000273.html

while they should not depend on each other, the way build.h is done
the patches do depend... or you just apply ipv6 patch and fix the
conflict, it is pretty simple.


> As for the systemd unit dir in dbus setup it is present and I am now adding
> it to udev configuration.

yeah, my system did not work properly until i did that.



--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri <at> gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Cristian Axenie | 10 Sep 10:14 2010
Picon

Re: Systemd port on custom embedded linux

Hi, again !
I've managed to apply the patches and fixed all conflicts, modified DBus and Udev and the problem persists regarding the abstract socket namespace. Mainly I think there is a DBus problem.
Here's my boot output :

[   18.750000] Freeing init memory: 152K
[   19.400000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP -AUDIT -SELINUX +IPV6 -SYSVINIT)
[   19.440000] systemd[1]: /sbin/modprobe failed with error code 1.
[   19.450000] systemd[1]: No hostname configured.
[   19.460000] systemd[1]: Set hostname to <localhost>.
[   19.470000] systemd[1]: Netlink failure for request 2: Operation not supported
[   19.490000] systemd[1]: Failed to configure loopback device: Operation not supported
[   19.510000] systemd[1]: Failed to create private D-Bus server: Operating system does not support abstract socket namespace
[   19.540000] systemd[1]: Failed to allocate manager object: Input/output error
[   19.560000] systemd-cgroups-agent[672]: Failed to get D-Bus connection: Operating system does not support abstract socket namespace

Any ideas ?

Best !

On Wed, Sep 8, 2010 at 6:19 PM, Cristian Axenie <cristian.axenie <at> gmail.com> wrote:
The patches aren't applying correctly ! For what version of systemd were extracted?

Best !


On Wed, Sep 8, 2010 at 5:59 PM, Gustavo Sverzut Barbieri <barbieri <at> profusion.mobi> wrote:
On Wed, Sep 8, 2010 at 11:44 AM, Cristian Axenie
> TIA for the patch. I would like to see this working. Where should the patch
> be available?

just sent them to mail list:

 http://lists.freedesktop.org/archives/systemd-devel/2010-September/000272.html
 http://lists.freedesktop.org/archives/systemd-devel/2010-September/000273.html

while they should not depend on each other, the way build.h is done
the patches do depend... or you just apply ipv6 patch and fix the
conflict, it is pretty simple.


> As for the systemd unit dir in dbus setup it is present and I am now adding
> it to udev configuration.

yeah, my system did not work properly until i did that.



--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri <at> gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202


_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Tomasz Torcz | 10 Sep 10:39 2010
Picon

Re: Systemd port on custom embedded linux

On Fri, Sep 10, 2010 at 11:14:13AM +0300, Cristian Axenie wrote:
> Hi, again !
> I've managed to apply the patches and fixed all conflicts, modified DBus and
> Udev and the problem persists regarding the abstract socket namespace.
> Mainly I think there is a DBus problem.
> Here's my boot output :
> 
> [   18.750000] Freeing init memory: 152K
> [   19.400000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP
> -AUDIT -SELINUX +IPV6 -SYSVINIT)
> [   19.440000] systemd[1]: /sbin/modprobe failed with error code 1.
> [   19.450000] systemd[1]: No hostname configured.
> [   19.460000] systemd[1]: Set hostname to <localhost>.
> [   19.470000] systemd[1]: Netlink failure for request 2: Operation not
> supported
> [   19.490000] systemd[1]: Failed to configure loopback device: Operation
> not supported
> [   19.510000] systemd[1]: Failed to create private D-Bus server: Operating
> system does not support abstract socket namespace
> [   19.540000] systemd[1]: Failed to allocate manager object: Input/output
> error
> [   19.560000] systemd-cgroups-agent[672]: Failed to get D-Bus connection:
> Operating system does not support abstract socket namespace
> 
> Any ideas ?

   Being this embedded system, I guess that you are cross-compiling all the
software?  If so, have you noticed following messages in D-Bus configure:

WARNING: Cannot check for abstract sockets when cross-compiling, please use --enable-abstract-sockets

  So I believe you need to recompile d-bus with --enable-abstract-sockets appended
to ./configure line.

--

-- 
Tomasz Torcz              ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg <at> chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton (LKML)
Cristian Axenie | 10 Sep 14:03 2010
Picon

Re: Systemd port on custom embedded linux

Hi !

The abstract socket namespace support was enabled when compiling dbus. I will try to look up the places where systemd tries to create a dbus server and to establish a dbus connection.

Best !

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Wulf C. Krueger | 10 Sep 15:41 2010

Re: Systemd port on custom embedded linux

> The abstract socket namespace support was enabled when compiling dbus.

It's simply a bug: https://bugs.freedesktop.org/show_bug.cgi?id=29895

Best regards, Wulf
_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Cristian Axenie | 14 Sep 15:47 2010
Picon

Re: Systemd port on custom embedded linux

Hi !
I've managed to patch the source code to eliminate the sysvinit and ipv6 problems during bootup but now I encountered some error messages that refer to other issues.
 
Here is each line of the output and my ideas :

[   18.760000] Freeing init memory: 152K
[   19.410000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP -AUDIT -SELINUX -IPV6 -SYSVINIT)
[   19.450000] systemd[1]: /sbin/modprobe failed with error code 1.


Here it seems that the kmod_setup() returns erroneously due to the fact that some modules aren't present, or the modprobe parameters aren't valid.


[   19.500000] systemd[1]: Failed to fully start up daemon: No such file or directory
[   19.590000] systemd[1]: Failed to open /dev/autofs: No such file or directory
[   19.600000] systemd[1]: Failed to initialize automounter: No such file or directory
[   19.610000] systemd[1]: Unit dev-hugepages.automount entered maintenance state.
[   19.630000] systemd[1]: Failed to open /dev/autofs: No such file or directory
[   19.640000] systemd[1]: Failed to initialize automounter: No such file or directory
[   19.660000] systemd[1]: Unit dev-mqueue.automount entered maintenance state.
[   19.670000] systemd[1]: Failed to open /dev/autofs: No such file or directory
[   19.690000] systemd[1]: Failed to initialize automounter: No such file or directory
[   19.700000] systemd[1]: Unit proc-sys-fs-binfmt_misc.automount entered maintenance state.
[   19.720000] systemd[1]: Failed to open /dev/autofs: No such file or directory
[   19.730000] systemd[1]: Failed to initialize automounter: No such file or directory
[   19.750000] systemd[1]: Unit sys-kernel-debug.automount entered maintenance state.
[   19.760000] systemd[1]: Failed to open /dev/autofs: No such file or directory
[   19.780000] systemd[1]: Failed to initialize automounter: No such file or directory
[   19.790000] systemd[1]: Unit sys-kernel-security.automount entered maintenance state.


Here the manager cannot be properly started due to the fact that  m->mount_auto = arg_mount_auto;  doesn't have a proper value and the automounter functionality seems to be missing.

[   79.580000] systemd[1]: Job dev-tty3.device/start timed out.
Starting Getty on tty3 failed.
[   79.620000] systemd[1]: Job dev-tty2.device/start timed out.
Starting Getty on tty2 failed.
[   79.650000] systemd[1]: Job dev-tty6.device/start timed out.
Starting Getty on tty6 failed.
[   79.680000] systemd[1]: Job dev-tty4.device/start timed out.
Starting Getty on tty4 failed.
[   79.710000] systemd[1]: Job dev-tty5.device/start timed out.
Starting Getty on tty5 failed.
[   80.160000] systemd[1]: Job dev-ttyS0.device/start timed out.
Starting Serial Getty on ttyS0 failed.

And finally, the control cannot be passed to a console.


Any corrections and suggestions are appreciated.

Best !



On Fri, Sep 10, 2010 at 3:03 PM, Cristian Axenie <cristian.axenie <at> gmail.com> wrote:
Hi !

The abstract socket namespace support was enabled when compiling dbus. I will try to look up the places where systemd tries to create a dbus server and to establish a dbus connection.

Best !

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Gustavo Sverzut Barbieri | 14 Sep 16:58 2010

Re: Systemd port on custom embedded linux

On Tue, Sep 14, 2010 at 10:47 AM, Cristian Axenie
<cristian.axenie <at> gmail.com> wrote:
> Hi !
> I've managed to patch the source code to eliminate the sysvinit and ipv6
> problems during bootup but now I encountered some error messages that refer
> to other issues.
>
> Here is each line of the output and my ideas :
>
> [   18.760000] Freeing init memory: 152K
> [   19.410000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP
> -AUDIT -SELINUX -IPV6 -SYSVINIT)
> [   19.450000] systemd[1]: /sbin/modprobe failed with error code 1.
>
>
> Here it seems that the kmod_setup() returns erroneously due to the fact that
> some modules aren't present, or the modprobe parameters aren't valid.
>
>
> [   19.500000] systemd[1]: Failed to fully start up daemon: No such file or
> directory
> [   19.590000] systemd[1]: Failed to open /dev/autofs: No such file or
> directory
> [   19.600000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   19.610000] systemd[1]: Unit dev-hugepages.automount entered maintenance
> state.
> [   19.630000] systemd[1]: Failed to open /dev/autofs: No such file or
> directory
> [   19.640000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   19.660000] systemd[1]: Unit dev-mqueue.automount entered maintenance
> state.
> [   19.670000] systemd[1]: Failed to open /dev/autofs: No such file or
> directory
> [   19.690000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   19.700000] systemd[1]: Unit proc-sys-fs-binfmt_misc.automount entered
> maintenance state.
> [   19.720000] systemd[1]: Failed to open /dev/autofs: No such file or
> directory
> [   19.730000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   19.750000] systemd[1]: Unit sys-kernel-debug.automount entered
> maintenance state.
> [   19.760000] systemd[1]: Failed to open /dev/autofs: No such file or
> directory
> [   19.780000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   19.790000] systemd[1]: Unit sys-kernel-security.automount entered
> maintenance state.
>
>
> Here the manager cannot be properly started due to the fact that
> m->mount_auto = arg_mount_auto;  doesn't have a proper value and the
> automounter functionality seems to be missing.
>
> [   79.580000] systemd[1]: Job dev-tty3.device/start timed out.
> Starting Getty on tty3 failed.
> [   79.620000] systemd[1]: Job dev-tty2.device/start timed out.
> Starting Getty on tty2 failed.
> [   79.650000] systemd[1]: Job dev-tty6.device/start timed out.
> Starting Getty on tty6 failed.
> [   79.680000] systemd[1]: Job dev-tty4.device/start timed out.
> Starting Getty on tty4 failed.
> [   79.710000] systemd[1]: Job dev-tty5.device/start timed out.
> Starting Getty on tty5 failed.
> [   80.160000] systemd[1]: Job dev-ttyS0.device/start timed out.
> Starting Serial Getty on ttyS0 failed.
>
> And finally, the control cannot be passed to a console.
>
>
> Any corrections and suggestions are appreciated.

Likely you don't have autofs4 compiled, do you? It is required to work.

Lennart, maybe we should make the kmod-setup take another flag "MUST"
and "OPTIONAL", do modprobe for each module in separate and fail if
"MUST" are not present? Right now it is confusing for users.

--

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri <at> gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart Poettering | 14 Sep 18:40 2010
Picon

Re: Systemd port on custom embedded linux

On Tue, 14.09.10 11:58, Gustavo Sverzut Barbieri (barbieri <at> profusion.mobi) wrote:

> Lennart, maybe we should make the kmod-setup take another flag "MUST"
> and "OPTIONAL", do modprobe for each module in separate and fail if
> "MUST" are not present? Right now it is confusing for users.

Well, I don't believe that it is "user"'s job to compile a kernel and
systemd. People who compile unix.ko or autofs4.ko as a module should
just stop doing this. Quite frankly the kernel should just stop allowing
people to compile unix.ko as a module. I think people who consider
themselves smart enough to compile their own kernel should be capable of
dealing with the fallout of doing so...

Lennart

--

-- 
Lennart Poettering - Red Hat, Inc.
Kay Sievers | 14 Sep 18:45 2010

Re: Systemd port on custom embedded linux

On Tue, Sep 14, 2010 at 18:40, Lennart Poettering
<lennart <at> poettering.net> wrote:
> On Tue, 14.09.10 11:58, Gustavo Sverzut Barbieri (barbieri <at> profusion.mobi) wrote:
>
>> Lennart, maybe we should make the kmod-setup take another flag "MUST"
>> and "OPTIONAL", do modprobe for each module in separate and fail if
>> "MUST" are not present? Right now it is confusing for users.
>
> Well, I don't believe that it is "user"'s job to compile a kernel and
> systemd. People who compile unix.ko or autofs4.ko as a module should
> just stop doing this. Quite frankly the kernel should just stop allowing
> people to compile unix.ko as a module. I think people who consider
> themselves smart enough to compile their own kernel should be capable of
> dealing with the fallout of doing so...

Yeah, many of these modules should just be a module if you _develop_
the kernel. It's very useful to be able to do modprobe/rmmod if you
hack on unix.c, but in other setups it's just plain useless to ever
have unix.ko and all these things.

I too think systemd should try to bootup in all cases, but also
complain loudly if stuff like this happens, and is in the way for
systemd to work reliably.

Kay
Cristian Axenie | 17 Sep 15:49 2010
Picon

Re: Systemd port on custom embedded linux

Hi !
I've managed to solve some problems appearing during boot but some persist.
The current setup makes the system freeze in the current step :

[   10.230000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP -AUDIT -SELINUX -IPV6 -SYSVINIT)
[   10.250000] systemd[1]: No hostname configured.
[   10.260000] systemd[1]: Set hostname to <localhost>.
[   10.290000] systemd[1]: Failed to fully start up daemon: No such file or directory
[   10.370000] systemd[1]: Failed to initialize automounter: No such file or directory
[   10.380000] systemd[1]: Unit proc-sys-fs-binfmt_misc.automount entered maintenance state.
Starting /etc/rc.local Compatibility...

Regarding the automounter, I have used autofs v5 and not autofs4, should this make a difference ?
Any ideas of those return messages when automounter enters the waiting state (Failed to initialize automounter: No such file or directory) and themanager startup problem ( Failed to fully start up daemon: No such file or directory) ?

Best !

On Tue, Sep 14, 2010 at 5:58 PM, Gustavo Sverzut Barbieri <barbieri <at> profusion.mobi> wrote:
On Tue, Sep 14, 2010 at 10:47 AM, Cristian Axenie
> I've managed to patch the source code to eliminate the sysvinit and ipv6
> problems during bootup but now I encountered some error messages that refer
> to other issues.
>
> Here is each line of the output and my ideas :
>
> [   18.760000] Freeing init memory: 152K
> [   19.410000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP
> -AUDIT -SELINUX -IPV6 -SYSVINIT)
> [   19.450000] systemd[1]: /sbin/modprobe failed with error code 1.
>
>
> Here it seems that the kmod_setup() returns erroneously due to the fact that
> some modules aren't present, or the modprobe parameters aren't valid.
>
>
> [   19.500000] systemd[1]: Failed to fully start up daemon: No such file or
> directory
> [   19.590000] systemd[1]: Failed to open /dev/autofs: No such file or
> directory
> [   19.600000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   19.610000] systemd[1]: Unit dev-hugepages.automount entered maintenance
> state.
> [   19.630000] systemd[1]: Failed to open /dev/autofs: No such file or
> directory
> [   19.640000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   19.660000] systemd[1]: Unit dev-mqueue.automount entered maintenance
> state.
> [   19.670000] systemd[1]: Failed to open /dev/autofs: No such file or
> directory
> [   19.690000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   19.700000] systemd[1]: Unit proc-sys-fs-binfmt_misc.automount entered
> maintenance state.
> [   19.720000] systemd[1]: Failed to open /dev/autofs: No such file or
> directory
> [   19.730000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   19.750000] systemd[1]: Unit sys-kernel-debug.automount entered
> maintenance state.
> [   19.760000] systemd[1]: Failed to open /dev/autofs: No such file or
> directory
> [   19.780000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   19.790000] systemd[1]: Unit sys-kernel-security.automount entered
> maintenance state.
>
>
> Here the manager cannot be properly started due to the fact that
> m->mount_auto = arg_mount_auto;  doesn't have a proper value and the
> automounter functionality seems to be missing.
>
> [   79.580000] systemd[1]: Job dev-tty3.device/start timed out.
> Starting Getty on tty3 failed.
> [   79.620000] systemd[1]: Job dev-tty2.device/start timed out.
> Starting Getty on tty2 failed.
> [   79.650000] systemd[1]: Job dev-tty6.device/start timed out.
> Starting Getty on tty6 failed.
> [   79.680000] systemd[1]: Job dev-tty4.device/start timed out.
> Starting Getty on tty4 failed.
> [   79.710000] systemd[1]: Job dev-tty5.device/start timed out.
> Starting Getty on tty5 failed.
> [   80.160000] systemd[1]: Job dev-ttyS0.device/start timed out.
> Starting Serial Getty on ttyS0 failed.
>
> And finally, the control cannot be passed to a console.
>
>
> Any corrections and suggestions are appreciated.

Likely you don't have autofs4 compiled, do you? It is required to work.

Lennart, maybe we should make the kmod-setup take another flag "MUST"
and "OPTIONAL", do modprobe for each module in separate and fail if
"MUST" are not present? Right now it is confusing for users.


--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri <at> gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
enaut | 17 Sep 16:51 2010

Re: Systemd port on custom embedded linux

Am 17.09.2010 15:49, schrieb Cristian Axenie:
> Hi !
> I've managed to solve some problems appearing during boot but some 
> persist.
> The current setup makes the system freeze in the current step :
>
> [   10.230000] systemd[1]: systemd 8 running in system mode. (+PAM 
> +LIBWRAP -AUDIT -SELINUX -IPV6 -SYSVINIT)
> [   10.250000] systemd[1]: No hostname configured.
well pretty obvious set your hostname in /etc/hostname
> [   10.260000] systemd[1]: Set hostname to <localhost>.
> [   10.290000] systemd[1]: Failed to fully start up daemon: No such 
> file or directory
That one I did not find the sollution so far but on the other hand I 
have no related problems (Desktop is working and stuff) and its not 
related to the previous message. Somthing I think possible is that the 
unit files are not clean meaning som references to not existing units.
> [   10.370000] systemd[1]: Failed to initialize automounter: No such 
> file or directory
I had to install the autofs tools to get this working. Not sure about 
the packagename though.
> [   10.380000] systemd[1]: Unit proc-sys-fs-binfmt_misc.automount 
> entered maintenance state.
> Starting /etc/rc.local Compatibility...
iirc I solved this by installing the 2.6.36 kernel series...
>
> Regarding the automounter, I have used autofs v5 and not autofs4, 
> should this make a difference ?
> Any ideas of those return messages when automounter enters the waiting 
> state (Failed to initialize automounter: No such file or directory) 
> and themanager startup problem ( Failed to fully start up daemon: No 
> such file or directory) ?
>
> Best !
Lennart Poettering | 21 Sep 00:28 2010
Picon

Re: Systemd port on custom embedded linux

On Fri, 17.09.10 16:49, Cristian Axenie (cristian.axenie <at> gmail.com) wrote:

> Hi !
> I've managed to solve some problems appearing during boot but some persist.
> The current setup makes the system freeze in the current step :
> 
> [   10.230000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP
> -AUDIT -SELINUX -IPV6 -SYSVINIT)
> [   10.250000] systemd[1]: No hostname configured.
> [   10.260000] systemd[1]: Set hostname to <localhost>.
> [   10.290000] systemd[1]: Failed to fully start up daemon: No such file or
> directory
> [   10.370000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   10.380000] systemd[1]: Unit proc-sys-fs-binfmt_misc.automount entered
> maintenance state.
> Starting /etc/rc.local Compatibility...
> 
> Regarding the automounter, I have used autofs v5 and not autofs4, should
> this make a difference ?

No. We actually rely on v5 features. it's a bit confusing that the
kernel still exposes that under the label "autofs4" though.

> Any ideas of those return messages when automounter enters the waiting state
> (Failed to initialize automounter: No such file or directory) and themanager
> startup problem ( Failed to fully start up daemon: No such file or
> directory) ?

This looks as if your /dev/autofs node is missing. Normally this should
be created via devtmpfs and hence be available already when systemd
first looks at it.

Lennart

--

-- 
Lennart Poettering - Red Hat, Inc.
Cristian Axenie | 21 Sep 13:11 2010
Picon

Re: Systemd port on custom embedded linux

Hi ! I've managed to boot my system with systemd although I still have some problems with autofs.

[   10.690000] Freeing init memory: 152K
[   11.050000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP -AUDIT -SELINUX -IPV6 -SYSVINIT)
[   11.070000] systemd[1]: No hostname configured.
[   11.080000] systemd[1]: Set hostname to <localhost>.
[   11.120000] systemd[1]: Failed to fully start up daemon: No such file or directory
[   11.200000] systemd[1]: Failed to initialize automounter: No such file or directory
[   11.210000] systemd[1]: Unit proc-sys-fs-binfmt_misc.automount entered maintenance state.
Starting /etc/rc.local Compatibility...
Starting Getty on ttyS0...

localhost login: _

Now I'm facing some problems when trying to shutdown / halt / reboot the board. The following message is similar for all the mentioned commands :

Broadcast message from root (Thu Jan  1 00:04:52 2009):

The system is going down for system halt NOW!
[  296.080000] systemd-initctl[698]: Received environment initctl request. This is not implemented in systemd.

The system freezes !

Best !


On Tue, Sep 21, 2010 at 1:28 AM, Lennart Poettering <lennart <at> poettering.net> wrote:
On Fri, 17.09.10 16:49, Cristian Axenie (cristian.axenie <at> gmail.com) wrote:

> Hi !
> I've managed to solve some problems appearing during boot but some persist.
> The current setup makes the system freeze in the current step :
>
> [   10.230000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP
> -AUDIT -SELINUX -IPV6 -SYSVINIT)
> [   10.250000] systemd[1]: No hostname configured.
> [   10.260000] systemd[1]: Set hostname to <localhost>.
> [   10.290000] systemd[1]: Failed to fully start up daemon: No such file or
> directory
> [   10.370000] systemd[1]: Failed to initialize automounter: No such file or
> directory
> [   10.380000] systemd[1]: Unit proc-sys-fs-binfmt_misc.automount entered
> maintenance state.
> Starting /etc/rc.local Compatibility...
>
> Regarding the automounter, I have used autofs v5 and not autofs4, should
> this make a difference ?

No. We actually rely on v5 features. it's a bit confusing that the
kernel still exposes that under the label "autofs4" though.

> Any ideas of those return messages when automounter enters the waiting state
> (Failed to initialize automounter: No such file or directory) and themanager
> startup problem ( Failed to fully start up daemon: No such file or
> directory) ?

This looks as if your /dev/autofs node is missing. Normally this should
be created via devtmpfs and hence be available already when systemd
first looks at it.

Lennart

--
Lennart Poettering - Red Hat, Inc.

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Cristian Axenie | 23 Sep 13:09 2010
Picon

Re: Systemd port on custom embedded linux

Hi !

Any ideas about the following behavior?

~ # reboot
Broadcast message from root (ttyS0)

The system is going down for system halt NOW!
[  296.080000] systemd-initctl[698]: Received environment initctl request. This is not implemented in systemd.

And then the system freezes !

It seems that the initctl tries to request a command to set/unset the environment when rebooting the system. Is this related to the fact that the reboott service is setting in the Environment=RUNLEVEL=6 variable ?

Next a snapshot of some units in the system is given to analyze the possible cause for the failure :

getty <at> ttyS0.service                           loaded active       running    
halt.service                                  loaded inactive     dead       
killall.service                               loaded inactive     dead       
poweroff.service                              loaded inactive     dead       
rc-local.service                              loaded active       exited     
reboot.service                                loaded inactive     dead       
rsyslog.service                               failed inactive     dead       
single.service                                loaded inactive     dead       
systemd-initctl.service                       loaded inactive     dead       
systemd-logger.service                        loaded inactive     dead       
systemd-shutdownd.service                     loaded inactive     dead          
systemd-initctl.socket                        loaded active       listening

Any hint will be appreciated !
Best !

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Andrey Borzenkov | 23 Sep 14:26 2010
Picon

Re: Systemd port on custom embedded linux


Thu, 23 Sep 2010 14:09:16 +0300 письмо от Cristian Axenie <cristian.axenie <at> gmail.com>:

> Hi !
> Any ideas about the following behavior? 
> ~ # reboot
> Broadcast message from root (ttyS0)
> The system is going down for system halt NOW!
> [? 296.080000] systemd-initctl[698]: Received environment initctl request.
> This is not implemented in systemd.
> And then the system freezes !
> It seems that the initctl tries to request a command to set/unset the
> environment when rebooting the system. Is this related to the fact that the
> reboott service is setting in the Environment=RUNLEVEL=6 variable ?

Are you using halt emulation from systemd or original sysvinit utilities?

It could be related to the fact that this is not enough. Standard halt command
from sysvinit behaves differently depending whether it is called by user or
by /sbin/init. When called by user it simply pokes init via initctl which then
re-executes halt once more and this time it really preforms halt. The check is

	/*
	 *	First see if we were started directly from init.
	 */
	if (getenv("INIT_VERSION") && (r = getenv("RUNLEVEL")) != NULL)

So on Mandriva I had to add INIT_VERSION to reboot/halt/poweroff units to make
systemd coexist with sysvinit utilities.

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Cristian Axenie | 23 Sep 16:59 2010
Picon

Re: Systemd port on custom embedded linux

Hi and thanks for the quick reply !
I've added the

 Environment=INIT_VERSION=sysvinit-1234

in my units and now I can control the reboot/poweroff/halt of my system !

Best !




2010/9/23 Andrey Borzenkov <arvidjaar <at> mail.ru>

Thu, 23 Sep 2010 14:09:16 +0300 письмо от Cristian Axenie <cristian.axenie <at> gmail.com>:

> Hi !
> Any ideas about the following behavior?
> ~ # reboot
> Broadcast message from root (ttyS0)
> The system is going down for system halt NOW!
> [? 296.080000] systemd-initctl[698]: Received environment initctl request.
> This is not implemented in systemd.
> And then the system freezes !
> It seems that the initctl tries to request a command to set/unset the
> environment when rebooting the system. Is this related to the fact that the
> reboott service is setting in the Environment=RUNLEVEL=6 variable ?

Are you using halt emulation from systemd or original sysvinit utilities?

It could be related to the fact that this is not enough. Standard halt command
from sysvinit behaves differently depending whether it is called by user or
by /sbin/init. When called by user it simply pokes init via initctl which then
re-executes halt once more and this time it really preforms halt. The check is

       /*
        *      First see if we were started directly from init.
        */
       if (getenv("INIT_VERSION") && (r = getenv("RUNLEVEL")) != NULL)

So on Mandriva I had to add INIT_VERSION to reboot/halt/poweroff units to make
systemd coexist with sysvinit utilities.



_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart Poettering | 27 Sep 02:24 2010
Picon

Re: Systemd port on custom embedded linux

1;2591;0cOn Thu, 23.09.10 16:26, Andrey Borzenkov (arvidjaar <at> mail.ru) wrote:

> It could be related to the fact that this is not enough. Standard halt command
> from sysvinit behaves differently depending whether it is called by user or
> by /sbin/init. When called by user it simply pokes init via initctl which then
> re-executes halt once more and this time it really preforms halt. The check is
> 
> 	/*
> 	 *	First see if we were started directly from init.
> 	 */
> 	if (getenv("INIT_VERSION") && (r = getenv("RUNLEVEL")) != NULL)
> 
> So on Mandriva I had to add INIT_VERSION to reboot/halt/poweroff units to make
> systemd coexist with sysvinit utilities.

Hmm, I don't really follow here. And I wonder why this worked fine on
Fedora and Suse...

Should we set INIT_VERSION in the upstream systemd version somewhere? If
so, care to prep a patch?

Could you elaborate on the rationale for this?

Lennart

--

-- 
Lennart Poettering - Red Hat, Inc.
Andrey Borzenkov | 27 Sep 18:03 2010
Picon

Re: Systemd port on custom embedded linux


Mon, 27 Sep 2010 02:24:01 +0200 письмо от Lennart Poettering <lennart <at> poettering.net>:

> 1;2591;0cOn Thu, 23.09.10 16:26, Andrey Borzenkov (arvidjaar <at> mail.ru) wrote:
> > It could be related to the fact that this is not enough. Standard halt
> command
> > from sysvinit behaves differently depending whether it is called by user
> or
> > by /sbin/init. When called by user it simply pokes init via initctl which
> then
> > re-executes halt once more and this time it really preforms halt. The
> check is
> > 
> > 	/*
> > 	 *	First see if we were started directly from init.
> > 	 */
> > 	if (getenv("INIT_VERSION") && (r =
> getenv("RUNLEVEL")) != NULL)
> > 
> > So on Mandriva I had to add INIT_VERSION to reboot/halt/poweroff units to
> make
> > systemd coexist with sysvinit utilities.
> Hmm, I don't really follow here. And I wonder why this worked fine on
> Fedora and Suse...

Most likely because they use "halt -f" which bypasses above check to actually
shutdown system.

> Should we set INIT_VERSION in the upstream systemd version somewhere? If
> so, care to prep a patch?

I do not think so. Shutdown sequence is distro-specific; apparently all distros
supported by upstream do not need. I had to add it because Mandriva is using plain
/sbin/halt (without -f) and at this early stage I did not want to request any
changes in standard initscripts. If it comes to adding Mandriva as own distro - we'll see.

> Could you elaborate on the rationale for this?

Using standard initscripts/sysvinit-tools shutdown sequence looks like

1. User calls halt/reboot/poweroff
2. Halt tells init to change runlevel via /dev/initctl
3. init starts shutdown sequence for requested runlevel (0/6)
4. As final initscript /etc/init.d/halt is executed that runs /sbin/halt to actually
perform system shutdown.

Check in /sbin/halt is needed to distinguish between 1 and 4 unless -f is given.
_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart Poettering | 27 Sep 02:17 2010
Picon

Re: Systemd port on custom embedded linux

On Thu, 23.09.10 14:09, Cristian Axenie (cristian.axenie <at> gmail.com) wrote:

> Hi !
> 
> Any ideas about the following behavior?
> 
> ~ # reboot
> Broadcast message from root (ttyS0)
> 
> The system is going down for system halt NOW!
> [  296.080000] systemd-initctl[698]: Received environment initctl request.
> This is not implemented in systemd.

Hmm, interesting. Normally this environment stuff is only used for
controlling the type of a poweroff (i.e. halt vs. poweroff), and matters
little.

Note that this messages should only become visible if you try to control
systemd with implementations of halt/reboot/poweroff/shutdown from the
old sysvinit package. It is recommended to use the native systemd
implementations instead which you get by symlinking /bin/systemctl to
the various binaries.

For more details see:

http://lists.freedesktop.org/archives/systemd-devel/2010-June/000072.html

> And then the system freezes !

Completely? Or just the process?

> It seems that the initctl tries to request a command to set/unset the
> environment when rebooting the system. Is this related to the fact that the
> reboott service is setting in the Environment=RUNLEVEL=6 variable ?

No. This is done internally of the old sysvinit poweroff binary.

> Any hint will be appreciated !

My guess is that some kind of ordering loop makes it impossible to put
together and execute the shutdown transaction. Check syslog/dmesg.

Does "systemctl poweroff" work?

Lennart

--

-- 
Lennart Poettering - Red Hat, Inc.
Cristian Axenie | 27 Sep 12:07 2010
Picon

Re: Systemd port on custom embedded linux

Hi !
I've managed to add the proper symlinks in sbin and the reboot/halt/poweroff/shutdown are now handled by systemctl. I also removed the INIT_VERSION environment entry from the corresponding units. Should I consider to keep the entries in the current units (i.e.: /etc/init.d/reboot) that are unmounting the filesystems or should systemctl handle all the unmounting actions safely ?

Best !



On Mon, Sep 27, 2010 at 3:17 AM, Lennart Poettering <lennart <at> poettering.net> wrote:
On Thu, 23.09.10 14:09, Cristian Axenie (cristian.axenie <at> gmail.com) wrote:

> Hi !
>
> Any ideas about the following behavior?
>
> ~ # reboot
> Broadcast message from root (ttyS0)
>
> The system is going down for system halt NOW!
> [  296.080000] systemd-initctl[698]: Received environment initctl request.
> This is not implemented in systemd.

Hmm, interesting. Normally this environment stuff is only used for
controlling the type of a poweroff (i.e. halt vs. poweroff), and matters
little.

Note that this messages should only become visible if you try to control
systemd with implementations of halt/reboot/poweroff/shutdown from the
old sysvinit package. It is recommended to use the native systemd
implementations instead which you get by symlinking /bin/systemctl to
the various binaries.

For more details see:

http://lists.freedesktop.org/archives/systemd-devel/2010-June/000072.html

> And then the system freezes !

Completely? Or just the process?

> It seems that the initctl tries to request a command to set/unset the
> environment when rebooting the system. Is this related to the fact that the
> reboott service is setting in the Environment=RUNLEVEL=6 variable ?

No. This is done internally of the old sysvinit poweroff binary.

> Any hint will be appreciated !

My guess is that some kind of ordering loop makes it impossible to put
together and execute the shutdown transaction. Check syslog/dmesg.

Does "systemctl poweroff" work?

Lennart

--
Lennart Poettering - Red Hat, Inc.

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart Poettering | 27 Sep 17:39 2010
Picon

Re: Systemd port on custom embedded linux

On Mon, 27.09.10 13:07, Cristian Axenie (cristian.axenie <at> gmail.com) wrote:

> Hi !
> I've managed to add the proper symlinks in sbin and the
> reboot/halt/poweroff/shutdown are now handled by systemctl. I also removed
> the INIT_VERSION environment entry from the corresponding units. Should I
> consider to keep the entries in the current units (i.e.: /etc/init.d/reboot)
> that are unmounting the filesystems or should systemctl handle all the
> unmounting actions safely ?

For now you should reuse the classic reboot scripts. Eventually we hope
to replace them with C tools however, and in fact Fabiano already
started working on this.

Lennart

--

-- 
Lennart Poettering - Red Hat, Inc.
Andrey Borzenkov | 27 Sep 18:06 2010
Picon

Re: Systemd port on custom embedded linux


Mon, 27 Sep 2010 17:39:15 +0200 письмо от Lennart Poettering <lennart <at> poettering.net>:

> On Mon, 27.09.10 13:07, Cristian Axenie (cristian.axenie <at> gmail.com) wrote:
> > Hi !
> > I've managed to add the proper symlinks in sbin and the
> > reboot/halt/poweroff/shutdown are now handled by systemctl. I also
> removed
> > the INIT_VERSION environment entry from the corresponding units. Should I
> > consider to keep the entries in the current units (i.e.:
> /etc/init.d/reboot)
> > that are unmounting the filesystems or should systemctl handle all the
> > unmounting actions safely ?
> For now you should reuse the classic reboot scripts. Eventually we hope
> to replace them with C tools however, 

Why? What exactly is wrong with how systemctl implements them currently?

> and in fact Fabiano already
> started working on this.

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Kay Sievers | 27 Sep 19:29 2010

Re: Systemd port on custom embedded linux

2010/9/27 Andrey Borzenkov <arvidjaar <at> mail.ru>:
> Mon, 27 Sep 2010 17:39:15 +0200 письмо от Lennart Poettering <lennart <at> poettering.net>:
>> On Mon, 27.09.10 13:07, Cristian Axenie (cristian.axenie <at> gmail.com) wrote:

>> > I've managed to add the proper symlinks in sbin and the
>> > reboot/halt/poweroff/shutdown are now handled by systemctl. I also
>> removed
>> > the INIT_VERSION environment entry from the corresponding units. Should I
>> > consider to keep the entries in the current units (i.e.:
>> /etc/init.d/reboot)
>> > that are unmounting the filesystems or should systemctl handle all the
>> > unmounting actions safely ?
>> For now you should reuse the classic reboot scripts. Eventually we hope
>> to replace them with C tools however,
>
> Why? What exactly is wrong with how systemctl implements them currently?

Lennart meant the entire reboot/shutdown including killall and umount
and all the stuff, so we don't need to run any of the old distro
scripts at all by default.

Kay
_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Cristian Axenie | 30 Sep 11:03 2010
Picon

Re: Systemd port on custom embedded linux

Hi all!
Next a failing context for DBus daemon is described both when using systemctl enable dbus.service to generate links in the specific .target.wants dirs or by using the default unit configuration after building systemd.

So, after enabling the dbus unit and booting the board I get :

    9.500000] Freeing init memory: 152K
[   10.010000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP -AUDIT -SELINUX -IPV6 -SYSVINIT)
[   10.030000] systemd[1]: No hostname configured.
[   10.040000] systemd[1]: Set hostname to <localhost>.
[   10.070000] systemd[1]: Failed to fully start up daemon: No such file or directory
[   10.130000] systemd[1]: Failed to initialize automounter: No such file or directory
[   10.150000] systemd[1]: Unit sys-kernel-security.automount entered maintenance state.
Starting udev Kernel Device Manager...
[   10.190000] systemd[1]: Failed to initialize automounter: No such file or directory
[   10.200000] systemd[1]: Unit proc-sys-fs-binfmt_misc.automount entered maintenance state.
[   10.270000] udev[674]: starting version 162
Starting udev Wait for Complete Device Initialization...
Starting udev Retry Failed Events...
Starting Getty on ttyS0...
Starting D-Bus System Message Bus...

localhost login:

I am able to login and when running ps :

  898 root       0:00 /sbin/udevd
 1134 root       0:00 //lib/systemd/systemd-cgroups-agent /systemd-1/udev-retry
 1135 root       0:00 login -- root
 1137 root       0:00 //lib/systemd/systemd-cgroups-agent /systemd-1/dbus.servi
 1138 root       0:00 [dbus-daemon]
 1139 root       0:00 //lib/systemd/systemd-cgroups-agent /systemd-1/dbus.servi
 1140 root       0:00 -sh
 1153 root       0:00 ps

DBus daemon seems dead and when trying to use systemctl to list the units it blocks, but when sending SIGINT it returns to command line.

When using the default units configuration in the filesystem the DBus daemon doesn't start, even if I try to start connmand (just an example). If I try to start it manually it works.

Any suggestions ?


Best !

On Mon, Sep 27, 2010 at 8:29 PM, Kay Sievers <kay.sievers <at> vrfy.org> wrote:
2010/9/27 Andrey Borzenkov <arvidjaar <at> mail.ru>:
> Mon, 27 Sep 2010 17:39:15 +0200 письмо от Lennart Poettering <lennart <at> poettering.net>:
>> On Mon, 27.09.10 13:07, Cristian Axenie (cristian.axenie <at> gmail.com) wrote:

>> > I've managed to add the proper symlinks in sbin and the
>> > reboot/halt/poweroff/shutdown are now handled by systemctl. I also
>> removed
>> > the INIT_VERSION environment entry from the corresponding units. Should I
>> > consider to keep the entries in the current units (i.e.:
>> /etc/init.d/reboot)
>> > that are unmounting the filesystems or should systemctl handle all the
>> > unmounting actions safely ?
>> For now you should reuse the classic reboot scripts. Eventually we hope
>> to replace them with C tools however,
>
> Why? What exactly is wrong with how systemctl implements them currently?

Lennart meant the entire reboot/shutdown including killall and umount
and all the stuff, so we don't need to run any of the old distro
scripts at all by default.

Kay

_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Cristian Axenie | 1 Oct 01:06 2010
Picon

Re: Systemd port on custom embedded linux

Hi..again !

I've manged to solve my problems ! It seems I had to add an :
ExecStartPre=/bin/rm -f /var/run/messagebus.pid
to my dbus.target unit to ensure that dbus-daemon always starts correctly. Now the system bus is healthy and I can use it properly.

Best !

2010/9/30 Cristian Axenie <cristian.axenie <at> gmail.com>
Hi all!
Next a failing context for DBus daemon is described both when using systemctl enable dbus.service to generate links in the specific .target.wants dirs or by using the default unit configuration after building systemd.

So, after enabling the dbus unit and booting the board I get :

    9.500000] Freeing init memory: 152K
[   10.010000] systemd[1]: systemd 8 running in system mode. (+PAM +LIBWRAP -AUDIT -SELINUX -IPV6 -SYSVINIT)
[   10.030000] systemd[1]: No hostname configured.
[   10.040000] systemd[1]: Set hostname to <localhost>.
[   10.070000] systemd[1]: Failed to fully start up daemon: No such file or directory
[   10.130000] systemd[1]: Failed to initialize automounter: No such file or directory
[   10.150000] systemd[1]: Unit sys-kernel-security.automount entered maintenance state.
Starting udev Kernel Device Manager...
[   10.190000] systemd[1]: Failed to initialize automounter: No such file or directory
[   10.200000] systemd[1]: Unit proc-sys-fs-binfmt_misc.automount entered maintenance state.
[   10.270000] udev[674]: starting version 162
Starting udev Wait for Complete Device Initialization...
Starting udev Retry Failed Events...
Starting Getty on ttyS0...
Starting D-Bus System Message Bus...

localhost login:

I am able to login and when running ps :

  898 root       0:00 /sbin/udevd
 1134 root       0:00 //lib/systemd/systemd-cgroups-agent /systemd-1/udev-retry
 1135 root       0:00 login -- root
 1137 root       0:00 //lib/systemd/systemd-cgroups-agent /systemd-1/dbus.servi
 1138 root       0:00 [dbus-daemon]
 1139 root       0:00 //lib/systemd/systemd-cgroups-agent /systemd-1/dbus.servi
 1140 root       0:00 -sh
 1153 root       0:00 ps

DBus daemon seems dead and when trying to use systemctl to list the units it blocks, but when sending SIGINT it returns to command line.

When using the default units configuration in the filesystem the DBus daemon doesn't start, even if I try to start connmand (just an example). If I try to start it manually it works.

Any suggestions ?


Best !


On Mon, Sep 27, 2010 at 8:29 PM, Kay Sievers <kay.sievers <at> vrfy.org> wrote:
2010/9/27 Andrey Borzenkov <arvidjaar <at> mail.ru>:
> Mon, 27 Sep 2010 17:39:15 +0200 письмо от Lennart Poettering <lennart <at> poettering.net>:
>> On Mon, 27.09.10 13:07, Cristian Axenie (cristian.axenie <at> gmail.com) wrote:

>> > I've managed to add the proper symlinks in sbin and the
>> > reboot/halt/poweroff/shutdown are now handled by systemctl. I also
>> removed
>> > the INIT_VERSION environment entry from the corresponding units. Should I
>> > consider to keep the entries in the current units (i.e.:
>> /etc/init.d/reboot)
>> > that are unmounting the filesystems or should systemctl handle all the
>> > unmounting actions safely ?
>> For now you should reuse the classic reboot scripts. Eventually we hope
>> to replace them with C tools however,
>
> Why? What exactly is wrong with how systemctl implements them currently?

Lennart meant the entire reboot/shutdown including killall and umount
and all the stuff, so we don't need to run any of the old distro
scripts at all by default.

Kay


_______________________________________________
systemd-devel mailing list
systemd-devel <at> lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Michael Biebl | 1 Oct 01:20 2010
Picon

Re: Systemd port on custom embedded linux

2010/10/1 Cristian Axenie <cristian.axenie <at> gmail.com>:
> Hi..again !
>
> I've manged to solve my problems ! It seems I had to add an :
> ExecStartPre=/bin/rm -f /var/run/messagebus.pid
> to my dbus.target unit to ensure that dbus-daemon always starts correctly.

I hope you mean dbus.service here.

You do know that dbus upstream since 1.4.0 already contains unit files
for systemd which have all the necessary bits?

--

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
cristian.axenie | 1 Oct 01:25 2010
Picon

Re: Systemd port on custom embedded linux

Yes of course, I meant dbus.service, excuse me for the mistake! I am using in my build environment dbus 1.3.2
at the moment and tha's why I use some older variants of units! Thanks for making it clear! 
Best!
------Original Message------
From: Michael Biebl
To: Cristian Axenie
Cc: systemd-devel <at> lists.freedesktop.org
Cc: Kay Sievers
Subject: Re: [systemd-devel] Systemd port on custom embedded linux
Sent: Oct 1, 2010 02:20

2010/10/1 Cristian Axenie <cristian.axenie <at> gmail.com>:
> Hi..again !
>
> I've manged to solve my problems ! It seems I had to add an :
> ExecStartPre=/bin/rm -f /var/run/messagebus.pid
> to my dbus.target unit to ensure that dbus-daemon always starts correctly.

I hope you mean dbus.service here.

You do know that dbus upstream since 1.4.0 already contains unit files
for systemd which have all the necessary bits?

--

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Sent from my BlackBerry® wireless device
Lennart Poettering | 14 Sep 18:37 2010
Picon

Re: Systemd port on custom embedded linux

On Tue, 14.09.10 16:47, Cristian Axenie (cristian.axenie <at> gmail.com) wrote:

> [   19.590000] systemd[1]: Failed to open /dev/autofs: No such file or

Seems the automounter is not compiled in. Either don't use .automount
units or enable it in the kernel. My recommendation is the latter.

> Here the manager cannot be properly started due to the fact that
> m->mount_auto = arg_mount_auto;  doesn't have a proper value and the
> automounter functionality seems to be missing.

m->mount_auto is actually not related to the automounter. This is
admittedly confusing, but we kinda inheritaed that terminology.

m->mount_auto is an option to control whether systemd should mount
filesystems listed as "auto" in /etc/fstab, or if somebody else is
responsible for that.

The automounter may be used to establish file systems where the actual
mounting is delayed until first access.

> [   79.580000] systemd[1]: Job dev-tty3.device/start timed out.
> Starting Getty on tty3 failed.

Seems you have no virtual console. In that case it's probably a good
idea to remove the gettys from /etc/systemd/system/getty.target.wants/

> [   80.160000] systemd[1]: Job dev-ttyS0.device/start timed out.
> Starting Serial Getty on ttyS0 failed.

Seems you have tried booting with a serial console, but the /dev/ttyS0
device never appeared in the sysfs tree.

> And finally, the control cannot be passed to a console.

What do you mean by this?

Lennart

--

-- 
Lennart Poettering - Red Hat, Inc.

Gmane