Yesterdays update is incompatible with concourse

[jforand]

The new docker images published yesterday, August 18th 2021, do not work with the concourse orchestrator.

More specifically, concourse attempts to mount directories to docker containers to share results from previous steps. The new docker images are unable to access these mounts/they seem to be corrupted.

Currently, the workaround is to specify a tagged version prior to this change (for instance python3.8.10 works, but python 3.8.11 does not)

[jrobison-sb]

+1. And specifically here's how it's failing when I fly intercept (which is basically docker exec) into a container:

root@f2addba9-ecde-4d94-6486-780cdbaa4948:/# pwd
/
root@f2addba9-ecde-4d94-6486-780cdbaa4948:/# ls
bin  boot  dev	etc  home  lib	lib64  media  mnt  opt	proc  root  run  sbin  scratch	srv  sys  tmp  usr  var
root@f2addba9-ecde-4d94-6486-780cdbaa4948:/# ls -d
ls: cannot access '.': Operation not permitted

Anything which attempts to stat a directory gets blocked.

FWIW I don't know if the coreutils package for Debian shares any code with the coreutils package of RHEL/Centos/Fedora, but if it does, then it sounds a lot like this bug.

[tianon]

You'll need a newer version of Docker, runc, and/or libseccomp to fix this one.

[yosifkit]

This should be limited to the now released Debian Bullseye based images (the new default). So you can try using python:3.8.11-buster to keep using the Debian Buster based images. Until the OS or Pytohn version is end of life, we keep building Python images on two concurrent Debian releases.

If Buster works but the new Bullseye based images do not, then, as Tianon mentioned, the OS running Docker will need a newer version of Docker, runc, and/or libseccomp to fix it.

Similar issues: docker-library/ruby#351 docker-library/php#1192 docker-library/php#1177