> > > > 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