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, colin.helliwell@ln-systems.com
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:raltherr@google.com]
Sent: 19 January 2017 00:22
To: Andre McCurdy <armccurdy@gmail.com>
Cc: colin.helliwell@ln-systems.com;
Yocto discussion list <yocto@yoctoproject.org>
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.
On Wed, Jan 18, 2017 at 1:35 PM,
Andre McCurdy <armccurdy@gmail.com>
wrote:
On Wed, Jan 18, 2017 at 7:10 AM,
<colin.helliwell@ln-systems.com>
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"