On Thu, Jan 31, 2019 at 5:33 PM Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > > On Thu, 2019-01-31 at 14:19 +0100, Jonas Bonn wrote: > [...] > > So with that: > > > > a) Does buildbot use connman, systemd-networkd, both, or something > > else? How do I find this out? > > We're building standard poky so there are no non-standard settings, > other than for those images, enabling systemd. You can see the > configuration and revisions used in the logs. > > On the host side, the autobuilders are configured with static tap > devices which the user running the build has permissions for. > > > b) I'll poke at the patch series again once I get a working > > origin/master build so that I have sane state to work from. The > > systemd patches work fine on Thud... I suspect the problem lies > > elsewhere. > > > > c) Are others seeing similar errors with connman? > > Our builds work fine with current master, as soon as we add the patches > they break. They break even with just the machineid changes. I haven't > looked into why, I just know our regression tests go red with your > patches :(. >
Okay, I know what's going on... the issue is there's new services enabled which weren't enabled previously, including systemd-time-wait-sync.service which fails to activate because systemd-timesyncd can never get time as we've no DNS server. systemd-time-wait-sync.service then gets caught by the test for "systemctl --state=activating" returning an empy list of units and our test in settle() fails The reason the machine-id change trips is because "systemctl --preset-all" is now being run, which enables these services: $ diff pass fail 0a1 > /etc/systemd/system/getty.target.wants/getty@tty1.service 2a4 > /etc/systemd/system/graphical.target.wants/console-kit-daemon.service 11a14 > /etc/systemd/system/multi-user.target.wants/machines.target 14a18,21 > /etc/systemd/system/multi-user.target.wants/remote-fs.target > /etc/systemd/system/multi-user.target.wants/systemd-networkd.service > /etc/systemd/system/multi-user.target.wants/systemd-resolved.service > /etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service 18a26,28 > /etc/systemd/system/sockets.target.wants/systemd-networkd.socket > /etc/systemd/system/sysinit.target.wants/systemd-time-wait-sync.service > /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service Which shows the problem where I came into this - images using systemd currently don't get systemd-networkd, which is unfortunate if you you were using that for your networking. If I compare the list of services with the systemd 242 changeset reverted, the list is rather more reasonable: $ diff pass.241 fail 3a4 > /etc/systemd/system/graphical.target.wants/console-kit-daemon.service 25a27 > /etc/systemd/system/sysinit.target.wants/systemd-time-wait-sync.service If I disable just systemd-timesyncd.service with a hack in systemd: $ git diff diff --git a/presets/90-systemd.preset b/presets/90-systemd.preset index 11960e54236a..75636134c835 100644 --- a/presets/90-systemd.preset +++ b/presets/90-systemd.preset @@ -18,6 +18,7 @@ enable getty@.service enable systemd-timesyncd.service enable systemd-networkd.service enable systemd-resolved.service +disable systemd-time-wait-sync.service disable console-getty.service disable debug-shell.service Then the tests work fine with systemd 242 and this (rebased) changeset. What I've so far failed to figure out is why systemd-time-wait-sync.service gets enabled since I can't find a preset for it, and as far as I can tell it has to be coming from systemd. There's https://github.com/systemd/systemd/issues/10253 (which is closed) in this space where there's a reference to systemd-time-wait-sync.service in there getting enabled, so I think this has to be coming from systemd. I could post the rebased changeset with the above hack (which would fix images expecting systemd-networkd), or wait whilst I dig into systemd to figure out what's enabling systemd-time-wait-sync.service? -- Alex Kiernan -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
