> Getting a signed kernel update for an EOL kernel for an EOL machine is
> close to impossible from Google, so we're just trying to work around these

If these are machines you're in control of, you may be able to load a
module to patch it. If this is something you're deploying to users
stuck on that kernel who don't want to fix their systems, then of
course that's not a practical option.

Deploying kernel modules to EOL machines is probably not worth doing at 
this point. One might argue this is just a pointless exercise in preserving legacy technology!


> issues in userspace to maintain some functionality for any users who may
> still be using the device.
>
> The simplest workaround possible would be ideal.

If you're shipping binaries specifically for these devices, the
simplest fix is just to emulate the failure that should happen in the
kernel in userspace, using the attached patch. DO NOT deploy this
patch in binaries meant to be used on modern systems, since they will
break when Y2038 rolls around. (Your old Chromebooks will break then
too.)

I'll let the next generation of preservationists worry about the Y2038 issues. Thanks for the patch. I'll build that now with the  https://git.musl-libc.org/cgit/musl/patch/?id=c2feda4e2ea61f4da73f2f38b2be5e327a7d1a91 reversal patch for the i686 machines, and see if that fixes the issue. If so, we can consider the matter closed, unless you want to suggest a modification of the syscall patch to handle older working kernels which might avoid the need for the patch when used with older systems.


> It is interesting though
> that the sample program works fine when built against near-stock glibc
> 2.23, no?

No. If your kernel has a bug that makes something behave wildly wrong,
whether you do or don't see that as visible breakage with a particular
piece of software is not particularly interesting.

I'm pretty sure, however, that you just haven't tested enough to see
any failures. glibc 2.23 is from 2016, so any functionality in it
using syscalls added after 2011 (3.8 kernel) is going to blow up
badly, thinking the syscall succeeded and returned some positive value
when actually the kernel lacks it.

In the particular case of clock_gettime, it's just that your glibc
2.23 has a hard Y2038 EOL and does not use/support the missing time64
syscalls.


Duly noted.
 
Thanks so much for being patient while I got you enough information to fix this!

On behalf of the entire Chromebrew community, thank you!

Satadru