Docker 20.10 on ARM/V7 Buster is… bust
So, you have a RPI, happily running fully patched Docker 20.10.8.
Then…
Maybe you tried todocker run -ti debian:bullseye apt-get update and all hell broke loose with apt telling you the debian repo cannot be trusted:
At least one invalid signature was encountered— while the same command works just fine if using the :buster tag
Or maybe a valid Golang binary seemingly refuses to start with some confusing mumbo jumbo about your (armhf) CPU lacking… hf...
runtime: this CPU has no floating point hardware, so it cannot run
this GOARM=7 binary. Recompile using GOARM=5.… or any other mind-boggling, very hard-to-reason-about issue
Be not afraid, for you are not alone
Before you dive into the rabbit hole trying to figure out what’s wrong with setcap, or apt, or your network, or your cpu, or the internet, and spend countless hours deep down into a very dark rabbit hole…
Try this one magic trick:
docker run -ti --security-opt seccomp=unconfined debian:bullseye apt-get updateIf things now work, congrats, as you have fallen victim of the great seccomp dumpster fire of twenty-twen^H errrr, sometime ago.
Now, try this too:
dpkg -l | grep seccompVersion says anything smaller than 2.4.2? That’s it.
seccomp in buster is broken in a (not so) subtle way.
“Solutions”
Pretty much, either:
- embrace the wild side and upgrade your RPIs to bullseye
- just install libseccomp from bullseye while holding the rest of your system back
- run all your containers with --security-opt seccomp=unconfined
- run dockerd with a tweaked seccomp profile (passing to dockerd something in the line of: --seccomp-profile=default.json) — you can get the original from here, then sed /”defaultAction”: “SCMP_ACT_ERRNO”/”defaultAction”: “SCMP_ACT_TRACE”/
There is no good solution. It’s pretty much about either downgrading your security, rushing a system upgrade to an unreleased Debian version, or mangling your system with a newer version of a critical package.
References
Prior art on this:
