On Mon, 2026-09-07 at 10:48 +0300, Michael Tokarev wrote: > Control: tag -1 + moreinfo > Control: severity -1 wishlist > > On 9/7/26 00:35, Benjamin Drung wrote: > > Package: busybox-static > > Version: 1:1.38.0-3 > > Severity: normal > > X-Debbugs-Cc: [email protected] > > > > Dear Maintainer, > > > > The Dracut 72-nbd autopkgtest fails with busybox-static. This can also > > be reproduced with the upstream dracut project: > ... > > 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. > > 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.
You are right. This is a XY problem and I failed to describe the 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. -- Benjamin Drung Debian & Ubuntu Developer
