On Thu, 11 Feb 2021 at 21:14, Trevor Woerner <twoerner@...> wrote:

RP: there’s been a lot of churn in the versions (glibc, kernel, etc). if
anyone sees anything please raise a flag
Ross: yes, I’ve seen some issues, not always 100% reproducible
RP: x86 host?
Ross: not always
TimO: ubuntu host?
Ross: 20.04
RP: glibc-2.33 does have some interesting things, so i’m not surprised there
are issues
Randy: what are you seeing?
Ross: issues building the kernel (“dangerous relocations”)
RP: for dunfell we did a glibc-2.32 update but we’ll hold off on glibc-2.33
(thanks Michael!)
Ross: turning off uninative makes it go away
TimO: is that a Xen kernel?
Ross: no, just defconfig

I solved this issue: when running inside a container that uses seccomp
to filter the syscalls available, with glibc 2.33 inside (uninative,
for example), applications might end up calling faccessat2() (glibc
does this itself) which as a relatively new syscall is rejected by the
syscall filter. The rejection is EPERM but glibc only handles ENOSYS
so weird things happen.

I sent a workaround to oe-core, systemd 247 and Docker 20.10 are
fixed, but glibc appear to consider this a bug in other software and
not something it should handle.

Ross