Then the issue must lie in this commit: https://salsa.debian.org/docker-team/docker/-/commit/ad52cffa31359262a8e9d44daddf896c3e063dd2
The docker.io package didn't build anymore, due to runc `1.0.0~rc92` which landed in debian unstable. Shengjing Zhu came up with the patch to fix that, but it was not a straightforward patch. The issue could be in this patch. Or maybe there's more work required to make docker.io 19.03.x work with latest runc (ie. more patching is needed, not less, sorry :/). Let me say it another way: when you install docker-ce from Docker's repo, you also get the containerd.io package, that ships the runc binary. All of these components are basically provided altogether by docker, and they are at versions that were tested together. While in Debian, these separate components (containerd, runc) are packaged independently, and these are not the same versions as the ones shipped by Docker. So sometimes we hit this kind of issues with the Debian package. And to be more correct: in Debian we actually bundle containerd within the docker.io package, because nobody has the bandwidth to try to make docker 19.03.x build-against / work-with containerd 1.4.x. So we build the version of containerd that is vendored in the docker source tree, and ship it in the docker.io package. But runc is NOT bundled in, it is provided independently by the runc package, ie. version `1.0.0~rc92`. I hope that this clarifies a bit what is the issue here. I CC Shengjing in case he knows more about this issue. I will also try to have a look on my side as well. In the meantime I guess you can downgrade to docker.io version 19.03.12+dfsg1-3 and maybe use `apt-mark hold` to prevent any further upgrade. Cheers, Arnaud On Tue, Sep 22, 2020 at 6:35 AM Tianon Gravi <tia...@debian.org> wrote: > On Mon, 21 Sep 2020 at 13:48, <ano...@users.sourceforge.net> wrote: > > On Sun, Sep 20, 2020 at 09:58:45AM +0700, El boulangero wrote: > > > Do you know what's special with the `tianon/true` image? On what > OS/release > > > is it based? > > > > It's an image that contains only a single binary that returns 0. That > > binary uses no libraries, not even libc. > > > > It's intended as an extremely light-weight image for purposes that don't > > need a whole OS. See, for example, > > > https://stackoverflow.com/questions/37120260/configure-docker-compose-override-to-ignore-hide-some-containers > > > > It seems that something changed between 19.03.12+dfsg1-3 and > > 19.03.12+dfsg1-4 that is somehow or other assuming the container > > contains more infrastructure. If you determine that the bug is upstream, > > feel free to forward it to them (and, ideally, revert whatever patch was > > added to 19.03.12+dfsg1-4 that caused the problem in the mean time to > > avoid breaking other software on the system). > > I don't think this is an upstream bug -- I'm using their "docker-ce" > package (version "5:19.03.12~3-0~debian-buster") on a host I've got, > and here's the result of some tests there: > > $ docker run --rm tianon/true && echo ok > ok > > $ docker run --rm --user 0:0 tianon/true && echo ok > ok > > $ docker run --rm --user 1000:1000 tianon/true && echo ok > ok > > ♥, > - Tianon > 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 >
