Got it figured out, Seems that the default values from meta/recipes-core/systemd/systemd-serialgetty.bb for SERIAL_CONSOLES in are being processed instead of the expansion in our layer. Even though SE

#systemd #yocto

We have a build using warrior it boots up well but has a very long boot time of around 95 sec. Using systemd-analyze I notice that we the boot takes a long time before getting to multi-user.target. As

#systemd #yocto

what is SERIAL_CONSOLES variable set to ? this should be machine setting.

#systemd #yocto

Thank you for the quick reply, in our machin confif only SERIAL_CONSOLE is set, it is: But yocto then uses that to set SERIAL_CONSOLES In bitbake -e I see SERIAL_CONSOLE and SERIAL_CONSOLES set to :

#systemd #yocto

Hi, Make the systemd dependency for target only, e.g. DEPENDS_class-target += "systemd" etc. There may be relevant use cases to build some of systemd components or tools to native or nativesdk targets

#sdk #systemd

> DEPENDS_class-target += "systemd" You surely meant DEPENDS_append_class-target = " systemd" here

#sdk #systemd

Hi, (lets keep this on the list too) You can add _class-[target|native|nativesdk] to all variables to override defaults. Verify with "bitbake -e". Hope this helps, -Mikko

#sdk #systemd

Yes, quite likely. Tough reason why += doesn't work is a mystery to me :) I hack things until "bitbake -e" shows the right things for the recipes. -Mikko

#sdk #systemd

I agree it's a bit confusing at first (I was doing the same long time ago, before bitbake -e was even showing the history of evaluation), but everybody who uses bitbake often should learn this simple

#sdk #systemd

<eliranl=amazon.com@...> wrote: Which of the meta-tegra branches is it? thud-l4t-r32.3.1? [...] There was an issue with NVIDIA's eqos driver in older BSPs. I know it affected the TX

#yocto #systemd

Hi, (since this is a long post, i divided it to sections) TL;DR I have a networking issue in my Yocto dist; Somehow, my ethernet device won't work with systemd-networkd, but will work with /etc/networ

#yocto #systemd

Thanks Matt!! This solved it. And yes, the branch is thud-l4t-r32.3.1.

#yocto #systemd

I am trying to build an image with the following command line utilities built in: ntpq, timedatectl, and ntpstat. Note : ntp is builtinto my image and working correctly. I performed a simple test usin

#systemd #yocto #linux

Please, try this: https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-dunfell/local.conf This is the systemd addendum in my BBB Dunfell local.conf : ## Add systemd service DIS

#systemd #yocto #linux

I currently have "ntpq" building and installing correctly... Can someone tell me what it takes to get the "timedatectl" command utility built into Yocto kernel image ? I see it referenced in both : op

#systemd #yocto #linux

Currently not using system as our default init system (investigating why but this might not be an option). Is there any other utility I might use under Yocto to get similar data as that produced by ti

#systemd #yocto #linux

Hi Steve, It comes with systemd. Use it as your init system and then you'll have the command. Quentin

#systemd #yocto #linux

Is there documentation on how to set this up ?

#systemd #yocto #linux

what all functionality are you looking for. E.g. there is date utility and hwclock utility which can help you manipulate system time. you could also look into ntpd and/or chrony for Network time setti

#systemd #yocto #linux

Thanks... Yesterday I decided to go with ntpq/ntpdate/and a ntpstat script which does some basic stats through ntpd/ntpq/ntpdate and Chrony. We will see how it goes might be enough... Steve

#systemd #yocto #linux