Created attachment 4627 [details] base-files subprocess error The recipe for base-files errors in the do_package step due to the subprocess command dying from a received SIGSYS signal. See the attached log for more information. The error was discussed here https://patchwork.openembedded.org/patch/165913/, but the accepted patch did not fix the bug on my system. However the run-time solution given by Richard Purdie solved the issue, by disabling sand-boxing when running the file command. diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py index b8585d4253..0c22307c46 100644 --- a/meta/lib/oe/package.py +++ b/meta/lib/oe/package.py @@ -71,7 +71,7 @@ def is_kernel_module_signed(path): # 16 - kernel module def is_elf(path): exec_type = 0 - result = subprocess.check_output(["file", "-b", path], stderr=subprocess.STDOUT).decode("utf-8") + result = subprocess.check_output(["file", "-S", "-b", path], stderr=subprocess.STDOUT).decode("utf-8") if "ELF" in result: exec_type |= 1
A proper fix would detect this problem then use a wrapper script but only if seccomp is present.
Hey Randy, So I am not an expert by any means on seccomp, but it seems that detecting that the file program is compiled with this feature is difficult. I could read the audit log to determine that SIGSYS was indeed produced by an un-allowed system call like seen below [ 3613.158929] audit: type=1326 audit(1581812421.392:103): auid=1000 uid=1000 gid=1000 ses=2 subj==unconfined pid=6379 comm="file" exe="/usr/bin/file" sig=31 arch=c000003e syscall=39 compat=0 ip=0x7ff59f04a76b code=0x0 Through my research, it seems that I could check /proc/PID/status for the Seccomp flag, but this also doesn't seem viable. The file command also states for the "-S" option that "On systems where sandboxing is not available, this option has no effect" It seems like we can safely use this option.
Christopher/Jordan, We think this is fixed for most users. What is you host system?
Let us know if there's still a problem.