Changing over to systemd (no dhcp)

DISCUSSION [email protected] 11 participants 22 messages Jan 18, 2017 – Jan 23, 2017

Share & tools

[email protected]

author

2017-01-18 15:10 UTC #0 lore raw

We have a configuration for our embedded system which is working via SysV, but we're investigating moving over to systemd.

Not sure if this is 'wise' - if anyone has technological arguments for/against then I'd be interested - but I wanted to investigate it anyway.

I've modified local.conf (right or wrong) with

DISTRO_FEATURES_append = " systemd"

VIRTUAL-RUNTIME_init_manager = "systemd"

DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"

VIRTUAL-RUNTIME_initscripts = ""

KERNEL_ENABLE_CGROUPS = "1"

I also found a readme
(https://cgit.freedesktop.org/systemd/systemd/tree/README#n37) about the kernel requirements for systemd, and it does at least now boot.

However although eth0 is coming up ('ifconfig eth0'), there doesn't seem to be any dhcp happening - no IP etc.

Previously (under SysV) I had the busybox dhcp client; now it seems that is missing. There's a symlink /etc/systemd/system/busybox-udhcpc.service to /dev/null

I'm using

Poky Jethro

Kernel 4.4.0

Busybox 1.23.2 (with 'CONFIG_FEATURE_SYSTEMD=y')

I wondered if this is just a simple switch I'm missing somewhere, or is there a whole load more modifications I need to dig into and hand-craft? (Was hoping for something 'out of the box'..)

Thanks

systemd-networkd is the systemd daemon for setting up the network. It looks like the PACKAGECONFIG settings exist for it in
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/systemd/systemd_232.bb
but it isn't enabled by default. Add that and it should work.

Rick

Quoted 60 lines · On Wed, Jan 18, 2017 at 7:10 AM, <[email protected]> wrote:

We have a configuration for our embedded system which is working via SysV, but we’re investigating moving over to systemd.
Not sure if this is ‘wise’ – if anyone has technological arguments for/against then I’d be interested – but I wanted to investigate it anyway.
I’ve modified local.conf (right or wrong) with
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = ""
KERNEL_ENABLE_CGROUPS = "1"
I also found a readme (https://cgit.freedesktop.org/
systemd/systemd/tree/README#n37) about the kernel requirements for systemd, and it does at least now boot.
However although eth0 is coming up (‘ifconfig eth0’), there doesn’t seem to be any dhcp happening – no IP etc.
Previously (under SysV) I had the busybox dhcp client; now it seems that is missing. There’s a symlink /etc/systemd/system/busybox-udhcpc.service to /dev/null
I’m using
Poky Jethro
Kernel 4.4.0
Busybox 1.23.2 (with ‘CONFIG_FEATURE_SYSTEMD=y’)
I wondered if this is just a simple switch I’m missing somewhere, or is there a whole load more modifications I need to dig into and hand-craft? (Was hoping for something ‘out of the box’….)
Thanks
--
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

Andre McCurdy

2017-01-18 21:35 UTC #2 lore raw

In reply to [email protected]

Quoted 27 lines · On Wed, Jan 18, 2017 at 7:10 AM, <[email protected]> wrote:

We have a configuration for our embedded system which is working via SysV, but we’re investigating moving over to systemd.
Not sure if this is ‘wise’ – if anyone has technological arguments for/against then I’d be interested – but I wanted to investigate it anyway.
I’ve modified local.conf (right or wrong) with
DISTRO_FEATURES_append = " systemd" VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" VIRTUAL-RUNTIME_initscripts = "" KERNEL_ENABLE_CGROUPS = "1"
I also found a readme
(https://cgit.freedesktop.org/systemd/systemd/tree/README#n37) about the kernel requirements for systemd, and it does at least now boot.
However although eth0 is coming up (‘ifconfig eth0’), there doesn’t seem to be any dhcp happening – no IP etc.
Previously (under SysV) I had the busybox dhcp client; now it seems that is missing. There’s a symlink /etc/systemd/system/busybox-udhcpc.service to /dev/null
I’m using

Quoted 7 lines

Poky Jethro
Kernel 4.4.0
Busybox 1.23.2 (with ‘CONFIG_FEATURE_SYSTEMD=y’)
I wondered if this is just a simple switch I’m missing somewhere, or is there a whole load more modifications I need to dig into and hand-craft? (Was hoping for something ‘out of the box’….)

Try:

VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

Enabling systemd is somewhat documented by the example in {meta-poky,openembedded-core/meta}/conf/local.conf.sample.extended, which is:

#
# Use systemd for system initialization
#
# DISTRO_FEATURES_append = " systemd"
# DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" # VIRTUAL-RUNTIME_init_manager = "systemd"
# VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

Rick Altherr

2017-01-19 00:21 UTC #3 lore raw

I was wondering about this recently. Why are these snippets put in local.conf.sample.extended instead of separate, well-named .inc files that can be shared by multiple distros? The current model seems to encourage putting lots of configuration in local.conf that probably should be in the distro or machine conf.

Rick

Quoted 61 lines · Andre McCurdy

Quoted 1 line · On Wed, Jan 18, 2017 at 7:10 AM, <[email protected]> wrote:
We have a configuration for our embedded system which is working via
SysV,
Quoted 4 lines
but we’re investigating moving over to systemd.
Not sure if this is ‘wise’ – if anyone has technological arguments for/against then I’d be interested – but I wanted to investigate it
anyway.
Quoted 9 lines
I’ve modified local.conf (right or wrong) with
DISTRO_FEATURES_append = " systemd" VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" VIRTUAL-RUNTIME_initscripts = "" KERNEL_ENABLE_CGROUPS = "1"
Quoted 5 lines
I also found a readme
(https://cgit.freedesktop.org/systemd/systemd/tree/README#n37) about the kernel requirements for systemd, and it does at least now boot.
However although eth0 is coming up (‘ifconfig eth0’), there doesn’t seem
to
Quoted 3 lines
be any dhcp happening – no IP etc.
Previously (under SysV) I had the busybox dhcp client; now it seems that
is
Quoted 5 lines
missing. There’s a symlink /etc/systemd/system/busybox-udhcpc.service to /dev/null
I’m using
Quoted 7 lines
Poky Jethro
Kernel 4.4.0
Busybox 1.23.2 (with ‘CONFIG_FEATURE_SYSTEMD=y’)
I wondered if this is just a simple switch I’m missing somewhere, or is there a whole load more modifications I need to dig into and hand-craft? (Was hoping for something ‘out of the box’….)
Try:
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
Enabling systemd is somewhat documented by the example in {meta-poky,openembedded-core/meta}/conf/local.conf.sample.extended, which is:
#
# Use systemd for system initialization
#
# DISTRO_FEATURES_append = " systemd"
# DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" # VIRTUAL-RUNTIME_init_manager = "systemd"
# VIRTUAL-RUNTIME_initscripts = "systemd-compat-units" --
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

[email protected]

author

2017-01-19 07:21 UTC #4 lore raw

Yes, I’d agree with that, Rick.

We run automated regression builds from a fresh version control checkout – but because local.conf is generated when the build environment is set up, it isn’t suitable for version control. So any mods to it found during development have to be (remembered to be) put into local.conf.sample, so that the same build is assured for anyone anywhere.

I’ve long felt/assumed that local.conf was for truly local mods, for that user and/or for their temporary try-outs.

Similarly – and this is going even more off-topic so I’ll save the detail for a separate thread – I’ve still not yet got to grips with whether, when I want to add a particular package, I should be modifying my image recipe or set up a custom distro)

From: Rick Altherr [mailto:[email protected]]
Sent: 19 January 2017 00:22
To: Andre McCurdy <[email protected]>
Cc: [email protected]; Yocto discussion list <[email protected]>
Subject: Re: [yocto] Changing over to systemd (no dhcp)

Rick

On Wed, Jan 18, 2017 at 1:35 PM, Andre McCurdy <[email protected] <mailto:[email protected]> > wrote:

Quoted 27 lines · On Wed, Jan 18, 2017 at 7:10 AM, <[email protected]…

We have a configuration for our embedded system which is working via SysV, but we’re investigating moving over to systemd.
Not sure if this is ‘wise’ – if anyone has technological arguments for/against then I’d be interested – but I wanted to investigate it anyway.
I’ve modified local.conf (right or wrong) with
DISTRO_FEATURES_append = " systemd" VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" VIRTUAL-RUNTIME_initscripts = "" KERNEL_ENABLE_CGROUPS = "1"
I also found a readme
(https://cgit.freedesktop.org/systemd/systemd/tree/README#n37) about the kernel requirements for systemd, and it does at least now boot.
However although eth0 is coming up (‘ifconfig eth0’), there doesn’t seem to be any dhcp happening – no IP etc.
Previously (under SysV) I had the busybox dhcp client; now it seems that is missing. There’s a symlink /etc/systemd/system/busybox-udhcpc.service to /dev/null
I’m using

Quoted 7 lines

Poky Jethro
Kernel 4.4.0
Busybox 1.23.2 (with ‘CONFIG_FEATURE_SYSTEMD=y’)
I wondered if this is just a simple switch I’m missing somewhere, or is there a whole load more modifications I need to dig into and hand-craft? (Was hoping for something ‘out of the box’….)

Try:

VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

Enabling systemd is somewhat documented by the example in {meta-poky,openembedded-core/meta}/conf/local.conf.sample.extended, which is:

--
_______________________________________________
yocto mailing list
[email protected] <mailto:[email protected]>
https://lists.yoctoproject.org/listinfo/yocto

ChenQi

2017-01-19 08:31 UTC #5 lore raw

Hi Colin,

For the dhcp problem, what you need is a network manager. Any network manager that supports dhcp would do the job. systemd-networkd might be sufficient in your case.

For the local.conf problem, you could use a layer to manage all common things shared by the team.

For the package adding problem, it depends on the purpose.
1) if adding the package is only for local work (dev or test), do it in local.conf
2) otherwise, do it in image recipe
Distro conf files are not suitable for such kinds of modification.

Best Regards,
Chen Qi

Quoted 91 lines · On 01/19/2017 03:21 PM, [email protected] wrote:

Yes, I’d agree with that, Rick.
We run automated regression builds from a fresh version control checkout – but because local.conf is generated when the build environment is set up, it isn’t suitable for version control. So any mods to it found during development have to be (remembered to be) put into local.conf.sample, so that the same build is assured for anyone anywhere.
I’ve long felt/assumed that local.conf was for truly local mods, for that user and/or for their temporary try-outs.
Similarly – and this is going even more off-topic so I’ll save the detail for a separate thread – I’ve still not yet got to grips with whether, when I want to add a particular package, I should be modifying my image recipe or set up a custom distro)
*From:*Rick Altherr [mailto:[email protected]]
*Sent:* 19 January 2017 00:22
*To:* Andre McCurdy <[email protected]>
*Cc:* [email protected]; Yocto discussion list <[email protected]> *Subject:* Re: [yocto] Changing over to systemd (no dhcp)
I was wondering about this recently. Why are these snippets put in local.conf.sample.extended instead of separate, well-named .inc files that can be shared by multiple distros? The current model seems to encourage putting lots of configuration in local.conf that probably should be in the distro or machine conf.
Rick
On Wed, Jan 18, 2017 at 1:35 PM, Andre McCurdy <[email protected] <mailto:[email protected]>> wrote:
On Wed, Jan 18, 2017 at 7:10 AM, <[email protected] <mailto:[email protected]>> wrote:
> We have a configuration for our embedded system which is working via SysV,
> but we’re investigating moving over to systemd.
>
> Not sure if this is ‘wise’ – if anyone has technological arguments > for/against then I’d be interested – but I wanted to investigate it anyway.
>
> I’ve modified local.conf (right or wrong) with
>
> DISTRO_FEATURES_append = " systemd"
> VIRTUAL-RUNTIME_init_manager = "systemd"
> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
> VIRTUAL-RUNTIME_initscripts = ""
> KERNEL_ENABLE_CGROUPS = "1"
>
> I also found a readme
> (https://cgit.freedesktop.org/systemd/systemd/tree/README#n37)
about the
> kernel requirements for systemd, and it does at least now boot. >
> However although eth0 is coming up (‘ifconfig eth0’), there doesn’t seem to
> be any dhcp happening – no IP etc.
>
> Previously (under SysV) I had the busybox dhcp client; now it seems that is
> missing. There’s a symlink /etc/systemd/system/busybox-udhcpc.service to
> /dev/null
>
> I’m using
>
> Poky Jethro
> Kernel 4.4.0
> Busybox 1.23.2 (with ‘CONFIG_FEATURE_SYSTEMD=y’)
>
> I wondered if this is just a simple switch I’m missing somewhere, or is
> there a whole load more modifications I need to dig into and hand-craft?
> (Was hoping for something ‘out of the box’….)
Try:
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
Enabling systemd is somewhat documented by the example in {meta-poky,openembedded-core/meta}/conf/local.conf.sample.extended, which is:
#
# Use systemd for system initialization
#
# DISTRO_FEATURES_append = " systemd"
# DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" # VIRTUAL-RUNTIME_init_manager = "systemd"
# VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
--
_______________________________________________
yocto mailing list
[email protected] <mailto:[email protected]>
https://lists.yoctoproject.org/listinfo/yocto

[email protected]

author

2017-01-19 10:07 UTC #6 lore raw

Thanks Chen.

Currently looking into getting networkd hooked in. (no luck yet!)

I'll also look into moving stuff from local.conf to elsewhere, but where you say "Distro conf files are not suitable for such kinds of modification", I'm wondering what sort of modifications they *are* suitable/intended for? (i.e. the purpose of a distro as opposed to an image recipe)

From: ChenQi [mailto:[email protected]]
Sent: 19 January 2017 08:32
To: [email protected]; 'Rick Altherr' <[email protected]>; 'Andre McCurdy' <[email protected]>
Cc: 'Yocto discussion list' <[email protected]>
Subject: Re: [yocto] Changing over to systemd (no dhcp)

Hi Colin,

For the dhcp problem, what you need is a network manager. Any network manager that supports dhcp would do the job. systemd-networkd might be sufficient in your case.

For the local.conf problem, you could use a layer to manage all common things shared by the team.

Best Regards,
Chen Qi

On 01/19/2017 03:21 PM, [email protected] <mailto:[email protected]> wrote:

Yes, I'd agree with that, Rick.

We run automated regression builds from a fresh version control checkout - but because local.conf is generated when the build environment is set up, it isn't suitable for version control. So any mods to it found during development have to be (remembered to be) put into local.conf.sample, so that the same build is assured for anyone anywhere.

I've long felt/assumed that local.conf was for truly local mods, for that user and/or for their temporary try-outs.

Similarly - and this is going even more off-topic so I'll save the detail for a separate thread - I've still not yet got to grips with whether, when I want to add a particular package, I should be modifying my image recipe or set up a custom distro)

From: Rick Altherr [mailto:[email protected]]
Sent: 19 January 2017 00:22
To: Andre McCurdy <mailto:[email protected]> <[email protected]>
Cc: [email protected] <mailto:[email protected]> ; Yocto discussion list <mailto:[email protected]> <[email protected]>
Subject: Re: [yocto] Changing over to systemd (no dhcp)

Rick

On Wed, Jan 18, 2017 at 1:35 PM, Andre McCurdy <[email protected] <mailto:[email protected]> > wrote:

Quoted 5 lines · On Wed, Jan 18, 2017 at 7:10 AM, <[email protected]…

We have a configuration for our embedded system which is working via SysV, but we're investigating moving over to systemd.
Not sure if this is 'wise' - if anyone has technological arguments for/against then I'd be interested - but I wanted to investigate it

anyway.

Quoted 9 lines

I've modified local.conf (right or wrong) with
DISTRO_FEATURES_append = " systemd" VIRTUAL-RUNTIME_init_manager = "systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" VIRTUAL-RUNTIME_initscripts = "" KERNEL_ENABLE_CGROUPS = "1"

Quoted 5 lines

I also found a readme
(https://cgit.freedesktop.org/systemd/systemd/tree/README#n37) about the kernel requirements for systemd, and it does at least now boot.
However although eth0 is coming up ('ifconfig eth0'), there doesn't seem

Quoted 3 lines

be any dhcp happening - no IP etc.
Previously (under SysV) I had the busybox dhcp client; now it seems that

Quoted 5 lines

missing. There's a symlink /etc/systemd/system/busybox-udhcpc.service to /dev/null
I'm using

Quoted 7 lines

Poky Jethro
Kernel 4.4.0
Busybox 1.23.2 (with 'CONFIG_FEATURE_SYSTEMD=y')
I wondered if this is just a simple switch I'm missing somewhere, or is there a whole load more modifications I need to dig into and hand-craft? (Was hoping for something 'out of the box'..)

Try:

VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"

Enabling systemd is somewhat documented by the example in {meta-poky,openembedded-core/meta}/conf/local.conf.sample.extended, which is:

--
_______________________________________________
yocto mailing list
[email protected] <mailto:[email protected]>
https://lists.yoctoproject.org/listinfo/yocto

ChenQi

2017-01-20 02:11 UTC #7 lore raw

Quoted 7 lines · On 01/19/2017 06:06 PM, [email protected] wrote:

Thanks Chen.
Currently looking into getting networkd hooked in. (no luck yet!)
I’ll also look into moving stuff from local.conf to elsewhere, but where you say “Distro conf files are not suitable for such kinds of modification”, I’m wondering what sort of modifications they *are* suitable/intended for? (i.e. the purpose of a distro as opposed to an image recipe)

Hi Colin,

From my understanding, 'image' is an item related to components in rootfs while 'distro' is an item related to the functionality of the components. So in Yocto, variables related to image, e.g. IMAGE_INSTALL, IMAGE_FEATURE, etc, control what should be in rootfs; and variables related to distro, e.g. DISTRO_FEATURES, control the behavior of the program, whether to support 'x11', whether to support 'pam', etc.

You can look at poky.conf in meta-poky for more info on the concept of distro. And you can look at IMAGE_FEATURES for more info on the concept of image.

Best Regards,
Chen Qi

Quoted 131 lines

*From:*ChenQi [mailto:[email protected]]
*Sent:* 19 January 2017 08:32
*To:* [email protected]; 'Rick Altherr' <[email protected]>; 'Andre McCurdy' <[email protected]> *Cc:* 'Yocto discussion list' <[email protected]>
*Subject:* Re: [yocto] Changing over to systemd (no dhcp)
Hi Colin,
For the dhcp problem, what you need is a network manager. Any network manager that supports dhcp would do the job. systemd-networkd might be sufficient in your case.
For the local.conf problem, you could use a layer to manage all common things shared by the team.
For the package adding problem, it depends on the purpose.
1) if adding the package is only for local work (dev or test), do it in local.conf
2) otherwise, do it in image recipe
Distro conf files are not suitable for such kinds of modification.
Best Regards,
Chen Qi
On 01/19/2017 03:21 PM, [email protected] <mailto:[email protected]> wrote:
Yes, I’d agree with that, Rick.
We run automated regression builds from a fresh version control checkout – but because local.conf is generated when the build environment is set up, it isn’t suitable for version control. So any mods to it found during development have to be (remembered to be) put into local.conf.sample, so that the same build is assured for anyone anywhere.
I’ve long felt/assumed that local.conf was for truly local mods, for that user and/or for their temporary try-outs.
Similarly – and this is going even more off-topic so I’ll save the detail for a separate thread – I’ve still not yet got to grips with whether, when I want to add a particular package, I should be modifying my image recipe or set up a custom distro)
*From:*Rick Altherr [mailto:[email protected]]
*Sent:* 19 January 2017 00:22
*To:* Andre McCurdy <[email protected]> <mailto:[email protected]> *Cc:* [email protected] <mailto:[email protected]>; Yocto discussion list <[email protected]> <mailto:[email protected]> *Subject:* Re: [yocto] Changing over to systemd (no dhcp)
I was wondering about this recently. Why are these snippets put in local.conf.sample.extended instead of separate, well-named .inc files that can be shared by multiple distros? The current model seems to encourage putting lots of configuration in local.conf that probably should be in the distro or machine conf.
Rick
On Wed, Jan 18, 2017 at 1:35 PM, Andre McCurdy <[email protected] <mailto:[email protected]>> wrote:
On Wed, Jan 18, 2017 at 7:10 AM, <[email protected] <mailto:[email protected]>> wrote:
> We have a configuration for our embedded system which is working via SysV,
> but we’re investigating moving over to systemd.
>
> Not sure if this is ‘wise’ – if anyone has technological arguments
> for/against then I’d be interested – but I wanted to investigate it anyway.
>
> I’ve modified local.conf (right or wrong) with
>
> DISTRO_FEATURES_append = " systemd"
> VIRTUAL-RUNTIME_init_manager = "systemd"
> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
> VIRTUAL-RUNTIME_initscripts = ""
> KERNEL_ENABLE_CGROUPS = "1"
>
> I also found a readme
>
(https://cgit.freedesktop.org/systemd/systemd/tree/README#n37)
about the
> kernel requirements for systemd, and it does at least now boot. >
> However although eth0 is coming up (‘ifconfig eth0’), there doesn’t seem to
> be any dhcp happening – no IP etc.
>
> Previously (under SysV) I had the busybox dhcp client; now it seems that is
> missing. There’s a symlink /etc/systemd/system/busybox-udhcpc.service to
> /dev/null
>
> I’m using
>
> Poky Jethro
> Kernel 4.4.0
> Busybox 1.23.2 (with ‘CONFIG_FEATURE_SYSTEMD=y’)
>
> I wondered if this is just a simple switch I’m missing somewhere, or is
> there a whole load more modifications I need to dig into and hand-craft?
> (Was hoping for something ‘out of the box’….)
Try:
VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
Enabling systemd is somewhat documented by the example in {meta-poky,openembedded-core/meta}/conf/local.conf.sample.extended, which is:
#
# Use systemd for system initialization
#
# DISTRO_FEATURES_append = " systemd"
# DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" # VIRTUAL-RUNTIME_init_manager = "systemd"
# VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
--
_______________________________________________
yocto mailing list
[email protected] <mailto:[email protected]>
https://lists.yoctoproject.org/listinfo/yocto

[email protected]

author

2017-01-20 14:12 UTC #8 lore raw

Thanks for all the pointers everyone. I've now got (in my distro conf):

DISTRO_FEATURES_append = " systemd"

DISTRO_FEATURES_remove = " sysvinit"

VIRTUAL-RUNTIME_init_manager = "systemd"

PREFERRED_PROVIDER_udev = "systemd"

PACKAGECONFIG_append_pn-systemd = " resolved networkd"

It's booting fine (if 'noisily'!) and starting up dhcp.

I suspect there's also some de-cluttering needed e.g. init.d scripts still being installed as well as a .service. On that subject, is there some clever syntax for a do_install() and/or recipe in order to control which type of file is installed into rootfs?

Leon Woestenberg

2017-01-21 13:09 UTC #9 lore raw

Hi Colin,

Quoted 5 lines · On Fri, Jan 20, 2017 at 2:59 PM, <[email protected]> wrote:

DISTRO_FEATURES_remove = " sysvinit"
I suspect there’s also some de-cluttering needed e.g. init.d scripts still being installed as well as a .service.

I wouldn't expect these to be installed. Which ones specifically?

Regards,

Leon.

[email protected]

author

2017-01-23 07:52 UTC #10 lore raw

Looking at it in more detail, it's perhaps more that not everything is taken up by systemd i.e. I have lots of symlinks to /dev/null in etc/systemd/system, with the corresponding/original SysV script still in /etc/init.d. Things like banner, sysfs, urandom, dmesg (to name just a few). Maybe these don't matter but, as I say, it just seems like a bit of 'clutter'

Looking at one which does seem to switch over cleanly - dropbear - I'm puzzled how the recipe [dropbear.inc, in poky/meta/recipes-core] appears to install both init.d script and .service in its do_install, yet only one or the other ultimately shows up in the rootfs..? (Relates to my other question about how to determine the init type in do_install)

-----Original Message-----
From: Leon Woestenberg [mailto:[email protected]]
Sent: 21 January 2017 13:09
To: [email protected]
Cc: Yocto discussion list <[email protected]>
Subject: Re: [yocto] Changing over to systemd (no dhcp)

Hi Colin,

Quoted 5 lines · On Fri, Jan 20, 2017 at 2:59 PM, <[email protected]> wrote:

DISTRO_FEATURES_remove = " sysvinit"
I suspect there’s also some de-cluttering needed e.g. init.d scripts still being installed as well as a .service.

I wouldn't expect these to be installed. Which ones specifically?

Regards,

Leon.

Mike Looijmans

2017-01-23 08:57 UTC #11 lore raw

Quoted 4 lines · On 23-01-17 08:47, [email protected] wrote:

Looking at it in more detail, it's perhaps more that not everything is taken up by systemd i.e. I have lots of symlinks to /dev/null in etc/systemd/system, with the corresponding/original SysV script still in /etc/init.d. Things like banner, sysfs, urandom, dmesg (to name just a few). Maybe these don't matter but, as I say, it just seems like a bit of 'clutter'
Looking at one which does seem to switch over cleanly - dropbear - I'm puzzled how the recipe [dropbear.inc, in poky/meta/recipes-core] appears to install both init.d script and .service in its do_install, yet only one or the other ultimately shows up in the rootfs..? (Relates to my other question about how to determine the init type in do_install)

I suspect that "inherit systemd" is taking care of that.

Quoted 2 lines

Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: [email protected]
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

-----Original Message-----

Quoted 20 lines

From: Leon Woestenberg [mailto:[email protected]]
Sent: 21 January 2017 13:09
To: [email protected]
Cc: Yocto discussion list <[email protected]>
Subject: Re: [yocto] Changing over to systemd (no dhcp)
Hi Colin,
Quoted 5 lines · On Fri, Jan 20, 2017 at 2:59 PM, <[email protected]> wrote:
DISTRO_FEATURES_remove = " sysvinit"
I suspect there’s also some de-cluttering needed e.g. init.d scripts still being installed as well as a .service.
I wouldn't expect these to be installed. Which ones specifically?
Regards,
Leon.

Patrick Ohly

2017-01-23 09:19 UTC #12 lore raw

In reply to [email protected]

Quoted 6 lines · On Mon, 2017-01-23 at 07:47 +0000, [email protected] wrote:

Looking at one which does seem to switch over cleanly - dropbear - I'm puzzled how the recipe [dropbear.inc, in poky/meta/recipes-core] appears to install both init.d script and .service in its do_install, yet only one or the other ultimately shows up in the rootfs..? (Relates to my other question about how to determine the init type in do_install)

systemd.bbclass has a rm_sysvinit_initddir postfunc for do_install which removes sysvinit config files if the DISTRO_FEATURES enable systemd and do not enable sysvinit.

rm_systemd_unitdir does the opposite when systemd is disabled and only sysvinit is enabled.

Signature · 6 lines

Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Mike Looijmans

2017-01-23 11:02 UTC #13 lore raw

In reply to [email protected]

Quoted 11 lines · On 20-01-17 14:59, [email protected] wrote:

Thanks for all the pointers everyone. I’ve now got (in my distro conf):
DISTRO_FEATURES_append = " systemd"
DISTRO_FEATURES_remove = " sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
PREFERRED_PROVIDER_udev = "systemd"
PACKAGECONFIG_append_pn-systemd = " resolved networkd"

Thanks for the tip, I was also wondering why network didn't work with systemd.

Is there a reason why this has been disabled by default? It's strange to have a system without network as the default setup.

I would at least have expected network support to be enabled for any machine that has some networking features.

Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: [email protected]
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Maciej Borzęcki

2017-01-23 11:19 UTC #14 lore raw

Quoted 15 lines · Mike Looijmans

Quoted 5 lines · On 20-01-17 14:59, [email protected] wrote:
Thanks for all the pointers everyone. I’ve now got (in my distro conf):
DISTRO_FEATURES_append = " systemd"
Quoted 7 lines
DISTRO_FEATURES_remove = " sysvinit"
VIRTUAL-RUNTIME_init_manager = "systemd"
PREFERRED_PROVIDER_udev = "systemd"
PACKAGECONFIG_append_pn-systemd = " resolved networkd"

Quoted 8 lines

Thanks for the tip, I was also wondering why network didn't work with systemd.
Is there a reason why this has been disabled by default? It's strange to have a system without network as the default setup.
I would at least have expected network support to be enabled for any machine that has some networking features.

Pick an choose, most features are opt-in to avoid bloating the final image.

Some people are not interested in networkd and prefer to use connman, NetworkManager or other tool.
Note that networkd is not wifi aware, but does observe interface state changes. For wifi you'll need wpa_supplicant to actually drive the process of joining networks, while networkd will handle DHCP part.

resolved is not enabled by default either. Even when enabled, it's not really useful without the nss-resolved piece. I've posted a patch to OE-core [1] that would set up /etc/nsswitch.conf properly but I wasn't merged.

[1]. http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126738.html

Signature · 2 lines

Maciej Borzecki
RnDity

Kristian Amlie

2017-01-19 07:20 UTC #15 lore raw

In reply to [email protected]

Quoted 5 lines · On 18/01/17 16:10, [email protected] wrote:

We have a configuration for our embedded system which is working via SysV, but we’re investigating moving over to systemd.
Not sure if this is ‘wise’ – if anyone has technological arguments for/against then I’d be interested – but I wanted to investigate it anyway.

Not really a technical argument, but I thought I'd just report that we are running with systemd just fine in Mender, and has been doing so for a good year now. The road hasn't been completely bump-free, but all issues so far have been resolved, and lately it's been quite stable for us. I should point out that since we are a software vendor we don't have devices in production though, only testing/integration.

Signature · 1 line

Kristian

Mike Looijmans

2017-01-19 09:40 UTC #16 lore raw

In reply to [email protected]

Quoted 5 lines · On 18-01-17 16:10, [email protected] wrote:

We have a configuration for our embedded system which is working via SysV, but we’re investigating moving over to systemd.
Not sure if this is ‘wise’ – if anyone has technological arguments for/against then I’d be interested – but I wanted to investigate it anyway.

Just one. systemd is a bit larger. So it will increase the boot time if your platform is I/O limited (many embedded systems are).

The good thing I noticed is that it shuts down a lot faster than initscripts. (I don't understand why I can boot my system in 2 seconds, but shutdown takes over 5 seconds...)

Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: [email protected]
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Michael Gloff

2017-01-20 06:16 UTC #17 lore raw

Mike,

Quoted 11 lines · Mike Looijmans

Quoted 8 lines · On 18-01-17 16:10, [email protected] wrote:
We have a configuration for our embedded system which is working via SysV, but
we’re investigating moving over to systemd.
Not sure if this is ‘wise’ – if anyone has technological arguments for/against
then I’d be interested – but I wanted to investigate it anyway.

Quoted 7 lines

Just one. systemd is a bit larger. So it will increase the boot time if your platform is I/O limited (many embedded systems are).
The good thing I noticed is that it shuts down a lot faster than initscripts. (I don't understand why I can boot my system in 2 seconds, but shutdown takes over 5 seconds...)

The 5+ seconds may be from sendsigs on shutdown or reboot:
echo "Sending all processes the TERM signal..." killall5 -15
sleep 5
echo "Sending all processes the KILL signal..." killall5 -9

Reducing to 1 or 2 seconds should be sufficient.

Michael Gloff

Quoted 26 lines

Kind regards,
Mike Looijmans
System Expert
TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: [email protected]
Website: www.topicproducts.com
Please consider the environment before printing this e-mail
--
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto

Mike Looijmans

2017-01-20 14:27 UTC #18 lore raw

Quoted 25 lines · Michael Gloff

Mike,
On Thu, Jan 19, 2017 at 3:18 AM, Mike Looijmans <[email protected] <mailto:[email protected]>> wrote:
On 18-01-17 16:10, [email protected] <mailto:[email protected]> wrote:
We have a configuration for our embedded system which is working via SysV, but
we’re investigating moving over to systemd.
Not sure if this is ‘wise’ – if anyone has technological arguments for/against
then I’d be interested – but I wanted to investigate it anyway.
Just one. systemd is a bit larger. So it will increase the boot time if your platform is I/O limited (many embedded systems are).
The good thing I noticed is that it shuts down a lot faster than initscripts. (I don't understand why I can boot my system in 2 seconds, but shutdown takes over 5 seconds...)

Quoted 6 lines

The 5+ seconds may be from sendsigs on shutdown or reboot:
echo "Sending all processes the TERM signal..." killall5 -15
sleep 5
echo "Sending all processes the KILL signal..." killall5 -9

OMG, indeed, this is utterly braindead!

An no one (except one of the systemd folks) has come up with a program that just waits for the the processes to finish (with a timeout) and only uses the "-9" double barrel shotgun to finish only the ones that didn't respond? (though doing that is rather pointless if the system power is about to be cut anyway...)

Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: [email protected]
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Leon Woestenberg

2017-01-21 12:41 UTC #19 lore raw

Hello Mike,

Quoted 8 lines · Mike Looijmans

An no one (except one of the systemd folks) has come up with a program that just waits for the the processes to finish (with a timeout) and only uses the "-9" double barrel shotgun to finish only the ones that didn't respond?
(though doing that is rather pointless if the system power is about to be cut anyway...)
What lesser-brain-dead "one of the systemd folks" solution is that?

Regards,

Leon.

Mike Looijmans

2017-01-23 09:04 UTC #20 lore raw

Quoted 5 lines · Leon Woestenberg

Hello Mike,
On Fri, Jan 20, 2017 at 3:27 PM, Mike Looijmans <[email protected] <mailto:[email protected]>> wrote:

Quoted 8 lines

An no one (except one of the systemd folks) has come up with a program that just waits for the the processes to finish (with a timeout) and only uses the "-9" double barrel shotgun to finish only the ones that didn't respond?
(though doing that is rather pointless if the system power is about to be cut anyway...)
What lesser-brain-dead "one of the systemd folks" solution is that?

Sorry if I wasn't clear. The systemd folk seems to have gotten it right.

The problem with the "sleep" is that 5 seconds is way too long, since most processes will finish in mere milliseconds. But 5 seconds is also way too short, because if a program needs to spin up a harddisk to write out its final state, it'll need about 7 seconds to do so on the average 3.5" disk...

Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: [email protected]
Website: www.topicproducts.com

Please consider the environment before printing this e-mail

Khem Raj

2017-01-20 06:34 UTC #21 lore raw

In reply to [email protected]

Quoted 39 lines · On Wed, Jan 18, 2017 at 7:10 AM, <[email protected]> wrote:

We have a configuration for our embedded system which is working via SysV, but we’re investigating moving over to systemd.
Not sure if this is ‘wise’ – if anyone has technological arguments for/against then I’d be interested – but I wanted to investigate it anyway.
I’ve modified local.conf (right or wrong) with
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = "systemd"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
VIRTUAL-RUNTIME_initscripts = ""
KERNEL_ENABLE_CGROUPS = "1"
I also found a readme
(https://cgit.freedesktop.org/systemd/systemd/tree/README#n37) about the kernel requirements for systemd, and it does at least now boot.
However although eth0 is coming up (‘ifconfig eth0’), there doesn’t seem to be any dhcp happening – no IP etc.
Previously (under SysV) I had the busybox dhcp client; now it seems that is missing. There’s a symlink /etc/systemd/system/busybox-udhcpc.service to /dev/null
I’m using
Poky Jethro
Kernel 4.4.0

Quoted 7 lines

Busybox 1.23.2 (with ‘CONFIG_FEATURE_SYSTEMD=y’)
I wondered if this is just a simple switch I’m missing somewhere, or is there a whole load more modifications I need to dig into and hand-craft? (Was hoping for something ‘out of the box’….)

you need to enable right packageconfigs for systemd e.g. see
https://github.com/kraj/meta-himvis/tree/master/recipes-core/systemd

Quoted 14 lines

Thanks
--
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto