On Mon, 2026-09-07 at 12:25 +0300, Michael Tokarev wrote: > After receiving several bug reports about busybox-static package and its > issues initrd, a bigger question come to mind -- Why do we need these > statically-linked utilities these days? > > Back in 1990s, it made some (little) sense, -- computers were different, > filesystems were different, crashes were often and so on. So, under some > circumstances, having statically-linked set of utilities which you can use > to repair a badly damaged filesystem, when your /bin is broken, - it was > good to have. > > So we have busybox-static, sash, e2fsck-static, bash-static, even zsh-static. > > Please note these utilities had to be installed before the recovery, and > the user should know about them to begin with. So even there, when they > made some sense, there were just a few people who actually used these. > > Now, systems has become much more reliable, rescue is usually (and better!) > done while booting from a separate rescue media, and there are many other > filesystems in use - value of this set of utils becomes very questionable. > > It is even more: almost no system these days works without initrd. And > initrd almost always includes (a regular build of) busybox. Which might > serve as a minimal rescue tool *outside* of the main system. So having > static versions of these utils on the main system becomes even more > questionable. > > I think there's no reason to keep building these static versions of > rescue utilities in 2026, finally. In particular, I'm thinking about > dropping busybox-static, keeping just the regular busybox binary. > Do we still need bash-static, e2fsck-static, even zsh-static?
Ubuntu is shipping busybox-static by default (the ubuntu-standard 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? -- Benjamin Drung Debian & Ubuntu Developer
