Comment 1 for bug 2051118

In the ubuntu armhf DEP8 infrastructure, this is what /proc/self/status looks like when that failing test starts (I added a "cat /proc/self/status" to debug):

Name: cat
Umask: 0002
State: R (running)
Tgid: 1105
Ngid: 0
Pid: 1105
PPid: 1102
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 64
Groups: 4 24 27 30 115 1000
NStgid: 1105
NSpid: 1105
NSpgid: 1092
NSsid: 1092
VmPeak: 4164 kB
VmSize: 4164 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 644 kB
VmRSS: 644 kB
RssAnon: 64 kB
RssFile: 580 kB
RssShmem: 0 kB
VmData: 328 kB
VmStk: 132 kB
VmExe: 24 kB
VmLib: 1188 kB
VmPTE: 36 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
CoreDumping: 0
THP_enabled: 1
Threads: 1
SigQ: 0/63405
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp: 0
Speculation_Store_Bypass: unknown
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 0
nonvoluntary_ctxt_switches: 0
Seccomp: 0

Specifically, "Seccomp: 0" tells us that there is no seccomp filtering applied. Therefore, the test runs.

When I launch an armhf container on my pi4, even a privileged one, I get "Seccomp: 2" and "Seccomp_filters: 1", so there is some filtering applied and the test is skipped.

In the debian armhf DEP8 infrastructure, "Seccomp: 0" is not present in /proc/self/status (I don't know the full contents) when the test starts, so the "grep" check makes it exit with status 77 and the test is skipped.

I don't know how to further troubleshoot this, since it only happens in the ubuntu DEP8 infrastructure, and using it for step by step debugging will take a long time.