[barebox-state](https://git.pengutronix.de/cgit/tools/dt-utils/tree/src/barebox-state.c#n510) likes to create a file in `/var/lock`. `/var/lock` is a symlink to `../run/lock`, but that directory is non-existent. ``` root@some-host:~# ls -lha /var/lock lrwxrwxrwx 1 root root 11 Mar 9 2018 /var/lock -> ../run/lock root@some-host:~# ls -lha /run/lock ls: /run/lock: No such file or directory ``` I'm pretty sure the base-files recipe should be responsible for creating /run/lock.
base-files doesn't create that directory, no. With sysvinit, populate-volatiles creates that directory on boot. With systemd, systemd itself does it. I suspect that by switching to barebox you've removed a dependency on populate-volatiles?
thanks for your reply. AFAIK I don't use any sysvinit files. So, there's something in systemd missing? I can't find the "populate-volatiles" recipe anywhere. Neither in the poky, nor in the meta-oe repo. Can you give me a hint? Also, what should I look at to determine if systemd is missing something here? As a workaround I created a custom tmpfiles configuration, which creates the /run/lock directory.
/run/lock is created by /usr/lib/tmpfiles.d/legacy.conf which is in the main systemd package, so if you're using systemd then you can't avoid that. Are you using systemd?
I'm using systemd for sure. My tmpfiles.d does *not* contain a legacy.conf. However, I think this is because of: meta-distro/recipes-core/systemd/systemd_%.bbappend 19:RRECOMMENDS_${PN}_remove = "systemd-compat-units" Could this be the problem?
Yes the meta-distro is likely the problem. If you remove it does it fix the problem?
Interesting enough, it does *not*. Even with that option disabled, there is no legacy.conf. I'm using systemd 246.1. What can I do to examine this further? Could this be a regression somewhere?
Well, no one else has reported such a problem so it's most likely something unique to your environment. Can you tell us: 1. what commit is at the top of your poky tree 2. attach the files in your conf directory and explain what you manually added and why, 3. what your build distro is (shouldn't matter but who knows!) 4. are you able to start with a new build without sstate and still see the problem? Sorry to ask so many questions but this seems like an odd bug and as I said, we can't reproduce it. ../Randy
Any update on how to reproduce the issue.
Thanks for your ping. I have digged into the systemd source code and found this line (https://github.com/systemd/systemd/blob/78dff3f3d72c62357543fe1716da3886cff54a10/tmpfiles.d/meson.build#L14): ['legacy.conf', 'HAVE_SYSV_COMPAT'], Let's look, where `HAVE_SYSV_COMPAT` is defined (https://github.com/systemd/systemd/blob/78dff3f3d72c62357543fe1716da3886cff54a10/meson.build#L93-L96) sysvinit_path = get_option('sysvinit-path') sysvrcnd_path = get_option('sysvrcnd-path') conf.set10('HAVE_SYSV_COMPAT', sysvinit_path != '' and sysvrcnd_path != '', description : 'SysV init scripts and rcN.d links are supported') Now let's look where `sysvinit-path` and `sysvrcnd-path` is defined in poky: rg '(sysvinit|sysvrcnd)-path' meta/recipes-core/systemd/systemd_246.6.bb 172:PACKAGECONFIG[sysvinit] = "-Dsysvinit-path=${sysconfdir}/init.d -Dsysvrcnd-path=${sysconfdir},-Dsysvinit-path= -Dsysvrcnd-path=,,systemd-compat-units update-rc.d" Now let's take a look at https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#using-systemd-exclusively > You can also prevent the SysVinit distribution feature from being automatically enabled as follows: > > DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" So this line (which I have in my config) makes that the legacy.conf isn't enabled. There's your way to reproduce it ;) --- Should I file an upstream issue at dt-utils and let them fix their lock path? Or should I remove that offending line in my config and see what else might be back again?
Yes, please report upstream and if you can send a patch to oe-core so we have a local fix.
Hi, Is there any update on this bug? Are you stuck? Do you expect to have time to work on the bug?
I'm sorry, I totally forgot this one. There was a patch submitted to dt-utils (not by me) at https://www.mail-archive.com/oss-tools@pengutronix.de/msg00063.html Here's the upstream fix: https://git.pengutronix.de/cgit/tools/dt-utils/commit/?id=fd48fe4efb40f35b119958495d56b399bec73654
Mr CookieSoft! ;-) Thanks for the update. If you update dt-utils, you'll pick up that commit: $ git tag --contains fd48fe4efb40f35b119958495d56b399bec73654 v2021.03.0 I've only skimmed the comments here, with that package updated is there still a problem on master?
On dt-utils master this is fixed. If I see that correctly, dt-utils aren't directly supported by poky or oe-embedded. I'll file an upstream issue in the meta-rauc package so that they update their dependencies ;) Thank you very much for your time and help! I concider this as closed, won't fix or something like that ;)
For reference, I created https://github.com/rauc/meta-rauc/pull/209
The fix is to dt-utils rather than oe-core/bitbake.