There's no real useful purpose in having static version of
busybox in 2020s.  Maybe it was a good idea back in 1990s,
when systems were very different, filesystems were much less
reliable, and so on.  But even at that time, keeping extra
rescue tools always installed on the system was very uncommon.

Busybox is used in initrd.  Static build of busybox conflicts
with regular build, because both provides the same binary
([/usr]/bin/busybox).  Now, when static build is installed,
this static build will be used in initrd too.  So initrd,
which is supposed to be small, now includes one more copy of
glibc - the one built into busybox-static.  This is absurd.

Instead of trying to fix busybox & busybox-static co-existance,
at this point it is more useful to drop busybox-static
entirely.

This is my use case:

deboostrap ... /mnt/
cd /
busybox ash
  mkdir OLD
  mv * OLD/
  mv OLD/mnt/* .

So I do need busybox-static.

On 9/7/26 12:36, Marco d'Itri wrote:
...
But it's definitely "not supported" by debian :)  That to say: I
don't consider this to be a valid use case - enough to keep the
package.

I remember using busybox-static to perform /usr-merge manually -
dunno why already but somehow usr-merge package was doing something
wrongly, I think...  ah, it was it's copying of / stuff to /usr,
instead of moving it.  So I used busybox-static to do a rename
instead of copy+remove.

So it does have its uses.  But these are very niche.  Even for my
use case, I downloaded busybox-static.deb, extracted it to /tmp/bb,
and used it directly from /var/tmp/bb/bin/busybox, without
installing it.

Thanks,

/mjt

I find busybox-static incredibly useful for debugging running
containers:

	$ podman cp /usr/bin/busybox misbehaving-container:/bin/busybox
	$ podman exec -ti misbehaving-container bash
	# or if even bash isn't available, busybox sh

and now I can use busybox to investigate the runtime state of the
container, without needing to know anything about what available libc
version (or even vendor) is inside, etc.