I have been playing with my own builds, including customising busybox. I was concerned that I would be inflating the image size, so I removed some things from busybox. One thing was sed.
Unfortunately I broke sysupdate by doing this, leaving a router with no radio (overwrote the cal data). I managed to recover without going to serial port, but...
Is there any value in making sysupdate check for all the tools used before it does the update and give a warning? I was wondering about a putting in a series of tests on the underlying tools? Or is this such an edge case that there is no need for it?
The viability of an image has to be the responsibility of whoever is creating it. Beyond select metadata (to identify the device and the partition layout) sysupgrade does not, and realistically can not possibly check the sanity of its contents, let alone the presence of functions within a multi-call binary.
Fair enough. I'll just modify my own copy to protect against my own stupidity. This seems to work:
# check expected commands are present
check_command_exists() {
which $1 > /dev/nul
if [ $? != 0 ]; then
echo "$1 is NOT found $0 exiting"
exit 1
fi
}
for item in which sed grep find cat touch sort rm ; do
check_command_exists $item
done
The busybox configuration (as well as the kernel itself) is among the most crucial parts of an OpenWrt build, and the busybox config option are intentionally hidden from the enduser (behind the expert settings and taint flags). If you touch them, you really need to be aware of the consequence, as all safeguards are off.
Misspelling of /dev/null aside, this would check for the command's presence in the currently running system. How would that catch a missing command in a to-be-installed image binary, and what would it exit?
(Out of curiosity, what kind of incredibly restricted device are you running that you are, or feel, pinched to strip commands from BusyBox? Also, you must be aware that BusyBox contains more than those 8 commands, with most of them essential to a system that heavily relies on scripting.)
This is just stopping sysupgrade proceeding in an environment it is going to fail in. If the new image is truly damaged I would have to go back to a serial port again. I've not broken any that badly yet. Those commands are the ones I spotted sysupgrade needing to do the moving of flash content around during the update.
I was changing busybox setting because among other things I wanted a nc that listened too.
I was playing. I like the BT Homehub 5A because they are cheap. I've got two running as wifi repeaters. I've got another 5 or 6 for meshes. I'm trying different builds and firewall rules.
Fair enough. If it's not broken, fix it until it is. As a learning experience.
That being said, BusyBox is pretty much the very last place to look at for space saving measures, and only as a hail mary before the device becomes completely incapable to run OpenWrt in the very next iteration. If a device is truly so restricted that it requires BusyBox modifications, it's time to say γη²γζ§ and move on to a device produced in the current decade.
β¦and iirc, the bthub5a offers ~90 MB usable space (128 MB NAND flash) for OpenWrt.
Unless you really know what you're doing, it's usually more sensible to use dedicated (non-busybox) packages (GNU, BSD, etc.) in these cases - leaving busybox alone, but adding (bigger, but also more featureful) 'full' dedicated packages to fill this functionality.
If sed and other utilities are needed by base level packages, maybe they should be dependencies on something like base-files?
Rather than complicate sysupgrade, let package dependencies handle it.