Void-packages: Several issues with busybox-1.30

[kehak]

I'm migrating my userland from GNU Coreutils to Busybox and have noticed several issues with the Void package.

• CONFIG_FEATURE_USERNAME_COMPLETION not set in .config.
  That means the autocompletion will not work for $HOME, which is annoying when using busybox as a login shell. There is no apparent reason why this flag shouldn't be set.

• If /bin/ash doesn't exist, the package should create a symlink /bin/ash -> /bin/busybox and add it to /etc/shells. This needs to be done manually so far.

• "ping" applet doesn't work
  Since adding a suid flag on /bin/busybox is out of question, the following should be done instead:

setcap cap_net_raw=ep /bin/busybox  # set capability for raw sockets on the binary
sysctl -w net.ipv4.ping_group_range=1 4  # allow GIDs 1 to 4 (wheel) to ping (should be added to /etc/sysctl.conf)

• "less" only show the first line of the file. I couldn't figure this one. Building from the upstream sources provides a working applet so this seems specific to the package.

• The static build will most likely be used in the initramfs as a rescue shell, or as the login shell for root (same use case). Setting CONFIG_FEATURE_SH_STANDALONE for the static package would probably make sense, so the shell will first use its builtin commands.

• package:
  busybox-1.30.1_1

[CameronNemo]

• [X] username completion
• [X] ash symlink and registering the shell
• [ ] unprivileged ping usage: I would rather not set cap_net_raw on the entire busybox binary. Is there some other privilege escalation mechanism that can be used, such as sudo, doas, or a wrapper?
• [X] less more than one line
• [ ] static shell builtin preference: could be useful for an emergency shell, but could be confusing in more general usage. Need to think on this request.

11358

[kehak]

• Regarding unprivileged ping usage, sudo works (doas probably does too) but isn't very convenient compared to the traditional iputils ping. However a suid bit might be an option after all: https://bugs.archlinux.org/task/25999
  It would require supplying a configuration file in /etc/busybox.conf.

• Also, apparently the busybox package doesn't properly support UTF-8. This can be showed with busybox vi where any special char will be displayed ".." instead.
  The following option should not be set for it to work:

# CONFIG_LOCALE_SUPPORT is not set

• A last thing, there is no PS1 parsing by default, those who have something like "PS1="w$ " in their .ashrc will just see the literal "w$" for their prompt. This can be enabled with

I see no adverse effect setting this option. Sorry for noticing those two minor issues later.

[CameronNemo]

Anything else of interest? Working on this now, hoping to have a PR later.

[the-wrench99]

I would love to have a package which bootstraps void with busybox as a base.

[santicalcagno]

Just dumping this here in case that it is useful to someone. I was planning to do it myself but I'm not finding the time lately.

• Maybe checking the diff with Alpine's busybox config would give more insights. Unfortunately there are ~300 different lines: https://www.diffchecker.com/5mTEjCos
• @the-wrench99 that would be base-system-busybox, see #9191. Personally I'm interested in having it listed too, with alternatives instead of conflicts as @CameronNemo commented there.

[the-wrench99]

@santicalcagno We could realize it as a package option, so anyone who wants can build it himself.

[kehak]

@the-wrench99, so I have successfully replaced GNU Coreutils with busybox, for both the system and initramfs. I am very pleased with the result.

So far I only noticed three minor issues:

• The busybox hwclock lacks an option required at boot so I didn't build it. The regular hwclock should be used.
• Same for psutils, however it's not part of Coreutils so it's no big deal.
• The full console font path should be provided in either rc.conf or ideally in the busybox build options: CONFIG_DEFAULT_SETFONT_DIR="/usr/share/kbd/consolefonts/".

I still have an issue with PAM_SCRIPT but it's probably out of scope since it doesn't ship with the system, and I can work around it.

For those interested in trying this migration, compile busybox with the standalone option (CONFIG_FEATURE_SH_STANDALONE) so it will use its builtin commands instead of the system commands. Then symlink /bin/sh to the newly built busybox, reboot, and test.

If everything works, you can build more applets to check how much of base-system is replaceable with busybox. Alpine has a full busybox base-system so I suspect everything in base-system can eventually be replaced with it.

So I cast my vote to revive the base-system-busybox package. After musl and runit, proposing a busybox base system brings some value to Void for those who favor minimalism and technical simplicity in a distribution.

[SirMetathyst]

Is bringing back the busybox base system still being considered? As @kehak said, I also favour void Linux because of its minimalism and a busybox system would be awesome. Is there a guide or something to help me do this?

[CameronNemo]

would love to do it, but #15836 and https://github.com/void-linux/xbps/pull/185 are blockers

[jsxof]

I really hope that this feature will be eventually implemented. It'd be amazing to have libressl, runit and busybox working on one system.