On 1/23/20 4:13 PM, Alex Kiernan wrote:
On Thu, Jan 23, 2020 at 10:09 AM Andreas Müller <schnitzelt...@gmail.com> wrote:

On Thu, Jan 23, 2020 at 10:43 AM Alex Kiernan <alex.kier...@gmail.com> wrote:

On the offchance someone's tripped over this already/has pointers:

Around the time python2 dropped out, I'm now seeing boot failures with:

[  612.151548] systemd-journald[543]: Assertion
'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at
src/basic/time-util.c:55, function now(). Aborting.

I suspect it's unrelated to py2, but that's delayed me getting to the problem.

The board I'm targetting is AM335x based, but without an RTC (which I
suspect may be relevant).

Anyone seen anything similar?

--
Alex Kiernan
Hi Alex,

Have not seen that one yet. Will look for it once I can build images
in current environment (python2/Qt5.14 broke loads for me). What I
have seen were problems with timedatectl <-> ntp. Changing from local
time to ntp-sync did not work: Time remained un-synced on recent
images. Machine was Raspi so no RTC either.

Don't know if this is related to your finding...


Looks like it's related to the glibc bump - reverting that changeset
gets it booting again. I struggle to figure out which of the myriad
wrappers are actually being used from inspecting the glibc source, but
if it's the one I think it is, there's clearly
clock_gettime/clock_gettime64 changes there which I doubt my kernel
has (we're currently using the TI 4.19.y kernel).

Is it possible for you to try 5.x for tests ? I know there were 64bit time_t related errors I saw with 4.19/rpi3-32bit but it was with musl, since musl enabled 64bit time_t by default, that might be different issue too

Try applying [1] to glibc as well, currrently, its only applied to musl case, perhaps that might help.

[1] https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd/0022-Use-INT_MAX-instead-of-TIME_T_MAX-for-timerfd_settim.patch





--
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

Reply via email to