#1147074 drop static build of busybox

Package:
busybox
Source:
busybox
Description:
Tiny utilities for small and embedded systems
Submitter:
Michael Tokarev
Date:
2026-09-17 09:53:02 UTC
Severity:
normal
#1147074#5
Date:
2026-09-07 09:04:18 UTC
From:
To:
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.
#1147074#10
Date:
2026-09-07 09:36:42 UTC
From:
To:
This is my use case:

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

So I do need busybox-static.
#1147074#15
Date:
2026-09-07 11:27:45 UTC
From:
To:
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
#1147074#20
Date:
2026-09-07 13:05:46 UTC
From:
To:
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.
#1147074#25
Date:
2026-09-08 23:15:08 UTC
From:
To:
Instead of removing busybox-static, keep the package, but rename the
binary to busybox-static and drop the initramfs-tool hook. That way
busybox and busybox-static will become co-installable. There are a few
package that need to change their Depends/Recommends from
"busybox | busybox-static" to just "busybox".
#1147074#30
Date:
2026-09-09 11:32:26 UTC
From:
To:
I fully support this proposal.
#1147074#35
Date:
2026-09-09 12:45:38 UTC
From:
To:
depends on it). Archaeology found the reason for it:
https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/505887

Summary from the bug: If e.g. libc is broken a stock ubuntu system can
currently not be booted. With busybox-static installed on the system,
users could boot with "init=/bin/busybox sh" to be able do recovery.

But for this, wouldn't it be better to boot with rd.break to stop at the
end of the initrd? Then users have full access to their system (they
could chroot into it), but still be able to use all the working tools
inside the initrd?
#1147074#40
Date:
2026-09-10 10:07:36 UTC
From:
To:
Personally I don't see value of having busybox-static in initrd at all.
And yes, when initrd contains busybox binary, that one can be used to
explore the system in case of some problem.  Again, even there, it is
much, much more common to use some live media to boot and do stuff from
there, having all tools available.

I'd switch back to regular busybox in this case.

And I never liked that busybox-static in ubuntu initrd.

BTW, in order to do that others are proposing (renaming binary to
busybox-static and dropping the initrd hook), we should switch to
regular busybox in ubuntu first :)

Thanks,

/mjt
#1147074#45
Date:
2026-09-10 10:09:34 UTC
From:
To:
Yes, this is what I plan to do.

Before this can be done, I've #1147076 against virtme-ng.

And - as stated above - switch all other Depends/Recommends to just
busybox.

Thanks,

/mjt
#1147074#50
Date:
2026-09-11 12:16:51 UTC
From:
To:
I plan to do the same in Ubuntu and assembled a list of affected
packages in https://launchpad.net/bugs/2167087 that needs their
Depends/Recommends adjusted.

In case you have the busybox change prepared, could you share it so that
I can use it in Ubuntu to not diverge here.
#1147074#55
Date:
2026-09-11 12:29:56 UTC
From:
To:
I agree. busybox-static makes no sense in the initrd since we already
have glibc in the initrd anyway. I'll drop recommending busybox-static
as alternative from dracut in the next upload.

This hasn't been the case up until recently. Up to 26.04 Ubuntu installs
busybox-static by default but provides busybox-initramfs to be used by
initramfs-tools. Since you were against adding a busybox-initrd to
Debian (see https://bugs.debian.org/1135987) I dropped busybox-initramfs
from Ubuntu (see https://launchpad.net/bugs/2157328).

Yes, I created those bugs for that:

[FFe] Please drop busybox-static from lubuntu-desktop-minimal and
ubuntu-standard
https://launchpad.net/bugs/2167086

[FFe] Make busybox and busybox-static co-installable (dropping
initramfs-tools support from busybox-static)
https://launchpad.net/bugs/2167087

I am fine with Ubuntu applying the change in advance, but I want to
prevent the busybox package to diverge from Debian. In case you have the
busybox change prepared, could you share it so that
I can use it in Ubuntu? If not, should I create a MP on salsa with this
change?
#1147074#60
Date:
2026-09-16 07:40:00 UTC
From:
To:
On 9/11/26 15:29, Benjamin Drung wrote:
...>> I'd switch back to regular busybox in this case.

uh.

Thank you!  Let's do it on debian too.
I created a branch in debian busybox repository, with two commits - one
to rename the binary and drop the hooks, and another is a changelog entry.
See https://salsa.debian.org/installer-team/busybox/-/commits/busybox-static-rename
for it.

I don't have it in main branch for now, since before applying that, we should
drop the |busybox-static alternatives in dependencies.  I'll file bug reports
about this.

Thanks,

/mjt
#1147074#93
Date:
2026-09-16 20:53:42 UTC
From:
To:
Thanks. I found them before you wrote the email and used the first
commit for the Ubuntu upload. I added several Breaks entries to
busybox-static to avoid upgrading busybox-static and loosing busybox
inside the initrd.

Thanks for doing the paperwork here. The change in Ubuntu is nearly done
(I haven't uploaded virtme-ng because I wanted to wait for the outcome
of the discussion in bug #1147076) and I haven't forwarded the patches
since I assume that your bug reports should be enough to get the same
changes in Debian.
#1147074#98
Date:
2026-09-17 09:51:40 UTC
From:
To:
There's nothing to do in virtme-ng, and #1147076 is now closed.
virtme-ng already checks for /usr/bin/busybox-static binary first, and
if not found, checks for /usr/bin/busybox (roughly - see refs in the
bug report).

There's lxc-templates though, which apparently might need some more work
(#1148021).

Thanks,

/mjt