busybox
busybox copied to clipboard
docker-library
The latest busybox becomes compiled dynamic?
606487dc92ff318103b5b5482# ldd /tmp/registry/docker/registry/v2/blobs/sha256/97/97dc7d325bed4fb89cd8ce42bbf8084403bf3aa342f422736f056a2ab2902451/bin/cp
/tmp/registry/docker/registry/v2/blobs/sha256/97/97dc7d325bed4fb89cd8ce42bbf8084403bf3aa342f422736f056a2ab2902451/bin/cp: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/registry/docker/registry/v2/blobs/sha256/97/97dc7d325bed4fb89cd8ce42bbf8084403bf3aa342f422736f056a2ab2902451/bin/cp)
/tmp/registry/docker/registry/v2/blobs/sha256/97/97dc7d325bed4fb89cd8ce42bbf8084403bf3aa342f422736f056a2ab2902451/bin/cp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/registry/docker/registry/v2/blobs/sha256/97/97dc7d325bed4fb89cd8ce42bbf8084403bf3aa342f422736f056a2ab2902451/bin/cp)
linux-vdso.so.1 (0x00007fff050bc000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbfdadfe000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fbfdabe4000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbfda7f3000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbfdb19c000)
Hi!
This libc change broke my container build. The supplied dynamic libraries are incompatible with the ones I tried to copy into the image earlier. dmesg showed a segfault in sh, and the container build failed.
See https://github.com/docker-library/busybox/pull/154 and especially https://github.com/buildroot/buildroot/commit/4057e36ca9665edd5248512e4edba2c243b8f4be.
For the quick escape hatch, switch to the -uclibc variant of the image explicitly instead of relying on the default.
The uclibc variant works, thanks. But please note, that the libc.so in the glibc variant does not seem to be compatible with ubuntu 22.04 compiled files. This may cause problems for others...
The libc packaged within this image is intended to support BusyBox (which cannot be compiled without a suitable libc implementation, and whose behavior differs slightly based on the libc implementation), and is not explicitly intended for external use (anything like that which "works" is incidental). I would expect more incompatibilities in the future.
(Our current build of glibc itself comes from Debian Bullseye, but will not necessarily continue to come from Debian or even Debian Bullseye specifically.)
I use the busybox image to build minimal containers on it by copying only the necessary .so files into a new image. This does not work anymore with the glibc variant of busybox. Maybe it's only my use-case, so others may not notice it. Anyway, I'm back to the uclibc variant.
Yep, the uclibc variant is (and should remain) fully statically compiled, so it's your safest bet for that use case.
Just to add that I have several container builds, copying in my own app and corresponding glibc, that used the :latest container not realizing that it was going to change...
This also broke our container image builds; making a change like this is definitely a breaking change that should be widely advertised at least. Changed to using the musl static version and not using latest, but this was a real head scratcher.
This is how I did it, works with latest too.
https://github.com/anzevalher/dnsmasq
This also breaks mounting busybox' /bin directory into FROM scratch images during build (to access tools). And it does so with a very confusing error message.
For example:
FROM scratch
RUN --mount=from=busybox:1.33,src=/bin,dst=/bin mkdir -p /some/path
RUN --mount=from=busybox:1.34,src=/bin,dst=/bin mkdir -p /some/path
The command on the second line works while the one on the last fails with:
> [stage-0 2/2] RUN --mount=from=busybox:1.34,src=/bin,dst=/bin mkdir -p /some/path:
#6 0.260 exec /bin/sh: no such file or directory
------
executor failed running [/bin/sh -c mkdir -p /some/path]: exit code: 1
IMO this is a very significant change that can't simply be introduced in a minor version bump...
The version number in the tags of this image represent the version number of BusyBox itself, not the version number of the image.
If you want an image that is fully static (and likely to stay that way), switch to -uclibc explicitly.
If you want an image that will not ever change, use a content-addressable digest (busybox:xxx@sha256:yyyy).