There’s some mismatch between Linux kernel 3.10 and #KDE that wants to use clone3 to create a process thread.
Do I know anyone from @kde@lemmy.kde.social @kde@floss.social who is able to assist with debugging it further?
The system call clone3 has been added to linux 5.3 but it seems that KDE does not do any fallback in case the system call is rejected with EPERM.
@zygoon @carlschwan @kde@lemmy.kde.social @kde@floss.social It’s likely coming from some usage of libseccomp somewhere. This also afflicts the container stack and such, which is why RHEL 9 containers on RHEL 7 are not supported.
Container/sandbox runtimes using libseccomp need to explicitly always allow clone3() through, or otherwise it will not fail correctly on RHEL 7.
@Conan_Kudo @carlschwan @kde@lemmy.kde.social @kde@floss.social yeah, I strongly suspect seccomp. I’m debugging this now and I will share updates when I get to the bottom of the problem.
@zygoon @carlschwan @kde@lemmy.kde.social @kde@floss.social The clone3() call is done implicitly and automatically by glibc. It started with glibc 2.34. This is most likely a problem in the Ubuntu Core 22 runtime that KDE snaps are built on.
The fix is to patch out the logic that uses it for clone() in Ubuntu’s glibc.
@zygoon @carlschwan @kde@lemmy.kde.social @kde@floss.social The clone3() call is done implicitly and automatically by glibc. It started witih glibc 2.34. This is most likely a problem in the Ubuntu Core runtime that KDE snaps are built on.