Dear Maintainer,

The Dracut 72-nbd autopkgtest fails with busybox-static. This can also
be reproduced with the upstream dracut project:

```
$ TEST_CONTAINER_COMMAND="apt update && apt install --yes busybox-static" test/test.sh ubuntu:devel 72
[...]
[    1.345256] dracut-initqueue[634]: nbd-client: unrecognized option '-check'
[    1.346137] dracut-initqueue[634]: BusyBox v1.38.0 (Ubuntu 1:1.38.0-3ubuntu1) multi-call binary.
[    1.346719] dracut-initqueue[634]: Usage: nbd-client { [-b BLKSIZE] [-N NAME] [-t SEC] [-p] HOST [PORT] | -d } BLOCKDEV
[    1.347399] dracut-initqueue[634]: Connect to HOST and provide network block device on BLOCKDEV
[    1.348014] dracut-initqueue[635]: nbd-client: unrecognized option '-systemd-mark'
[    1.348493] dracut-initqueue[635]: BusyBox v1.38.0 (Ubuntu 1:1.38.0-3ubuntu1) multi-call binary.
[    1.349055] dracut-initqueue[635]: Usage: nbd-client { [-b BLKSIZE] [-N NAME] [-t SEC] [-p] HOST [PORT] | -d } BLOCKDEV
[    1.349710] dracut-initqueue[635]: Connect to HOST and provide network block device on BLOCKDEV
```

The nbd-client busybox applet lacks the options -check and
-systemd-mark. I reported that upstream at
https://github.com/vda-linux/busybox_mirror/issues/35

The dracut busybox module skips intstalling the nbd-client applet. This
has no effect when using busybox-static because busybox-static is built
with CONFIG_FEATURE_PREFER_APPLETS enabled. Busybox sh will prefer the
incompatible nbd-client applet instead of using the real nbd-client
binary.

The blkid applet had the same issue and was disabled for busybox-static.
Please consider doing the same for nbd-client.

Control: tag -1 + moreinfo
Control: severity -1 wishlist
...

What's your intended usage scenario for busybox-static to begin with?
Why are you trying to use it in context of dracut?

IIRC, initially, when busybox-static package has been created, the
intention was to have a single utility for some system rescue operation,
so no matter how damaged the host system is, you drop a single self-
contained binary there  and will be able to do maximum possible.

This is why it has PREFER_APPLETS enabled - so there's no need to look
into $PATH at all, because /bin might be damaged already.

For initrd, please use regular, non-static, busybox build.  Since many
other binaries in initrd already require libc, there's no need to keep
*another* copy of libc within busybox binary.  And the regular busybox
is build without PREFER_APPLETS option, so you can use a more advanced
version of some utility.

Arguable one might ask why one needs nbd-client for rescue purposes, but
it's a different question.

No.  blkid applet has been disabled before (or hasn't been implemented,
I don't remember already and am too lazy to check), and it broke existing
usages when I enabled it - exactly because of this PREFER_APPLETS knob.
At the time, we needed a quick fix for a new breakage.  Yes, the usage
was - also iirc - the same, I wouldn't use bb-static in initrd since it
is not supposed to be used there.  But we broke other stuff and we had
to fix it.  Here, we aren't breaking anything.

Please stop trying to use bb-static for initrd.

Thanks,

/mjt

Control: tag -1 + moreinfo
Control: severity -1 wishlist
...

What's your intended usage scenario for busybox-static to begin with?
Why are you trying to use it in context of dracut?

IIRC, initially, when busybox-static package has been created, the
intention was to have a single utility for some system rescue operation,
so no matter how damaged the host system is, you drop a single self-
contained binary there  and will be able to do maximum possible.

This is why it has PREFER_APPLETS enabled - so there's no need to look
into $PATH at all, because /bin might be damaged already.

For initrd, please use regular, non-static, busybox build.  Since many
other binaries in initrd already require libc, there's no need to keep
*another* copy of libc within busybox binary.  And the regular busybox
is build without PREFER_APPLETS option, so you can use a more advanced
version of some utility.

Arguable one might ask why one needs nbd-client for rescue purposes, but
it's a different question.

No.  blkid applet has been disabled before (or hasn't been implemented,
I don't remember already and am too lazy to check), and it broke existing
usages when I enabled it - exactly because of this PREFER_APPLETS knob.
At the time, we needed a quick fix for a new breakage.  Yes, the usage
was - also iirc - the same, I wouldn't use bb-static in initrd since it
is not supposed to be used there.  But we broke other stuff and we had
to fix it.  Here, we aren't breaking anything.

Please stop trying to use bb-static for initrd.

Thanks,

/mjt

underlying problem.

For an initrd it makes sense to use the busybox package that is linked
against libc, because the libc will be included in the initrd anyway. So
the static busybox would make the initrd bigger without a benefit.

The real problem I am facing is: The busybox and busybox-static packages
conflict with each other. So in case users wants to install busybox-
static they have to remove busybox and would loose using busybox inside
the initrd. That was the pure reason for me to try to support busybox-
static.

Would it be possible to rename busybox to busybox-static in the busybox-
static package to make both packages co-installable?

One more question: You say that busybox-static should not be used in the
initrd, but why does busybox-static ship an initramfs-tools hook to use
it in the initrd? I assume that initramfs-tools might have similar
issues when using with busybox-static.

On 9/7/26 11:12, Benjamin Drung wrote:
...

Aha.  This all makes perfect sense now.  And this is a very good topic
you bought up, something I failed to think about for years if not
decades.

We've quite a few tools like this in debian aimed for rescue purposes, -
sash, ef2fsc-static, bash-static, even zsh-static (!).  Some of them
made sense back in 1990s, but I think all of them makes no sense now
in 2020s.

Yes, that would be one of the solutions.  But a better solution, it looks
like, is to just drop busybox-static package entirely.  It serves no real
purpose these days.

I think it was just for symmetry and/or due to inertia.  And due to lack
of real attention to this matter for decades.  We should've thought about
the relation between busybox and busybox-static packages long, long time
ago.  Instead, we just marked the two to conflict with each other, in
order to fix some immediate issue, and that's it.

I looked at reverse dependencies of busybox-static, - most dependencies
are written as alternative --

  Depends|Recommends: busyox | busybox-static

this is because both provides similar set of applets in a same-named
binary (so reaming the binary is a bit more complicated).  Some do it
in reverse order:

  Depends|Recommends: busyox-static | busybox

so preferring the static build, but still accepting regular.  These are
Ok too.  But some actually depends on the static build, for example:

lxc-templates: Recommends: busybox-static

and especially:

virtme-ng: Depends: busybox-static

This one needs to be fixed.

This is a more general question, -- I'll bring it up on debian-devel@.

Thank you for the input!

/mjt

As long as nobody complains about removing busybox-static I am fine with
removing it as well. I had never the use case of needing busybox-static.

What I found in debian/README.Maintainer:

* static: For use in initramfs

Yes, let's widen this discussion. One more thing (The W in the XY
problem): I initially stumbled over this issue with busybox-static by
running the dracut autopkgtest on Ubuntu infrastructure. On those
ubuntu-standard were installed and ubuntu-standard depends on busybox-
static. So we need to figure out why it was included there.