Add support for using u-root

[rminnich]

u-root builds its busybox'ed binaries into one binary, rewriting all commands into packages and compiling them all at once. This process takes about 30s, end to end.

The construction is performed by the u-root command itself. The commands need not be all u-root commands, e.g. GO111MODULE=off GOOS=plan9 GOOS=386 u-root plan9 github.com/nsf/godit will add the godit editor, for 386, using the plan9 template for u-root (which only adds commands known to work on Plan 9).

In fact, u-root is happy to build images with zero u-root commands. It's not picky.

On Plan 9, for each command, u-root creates a #! file, e.g. for date:

This will run /bbin/bb with one argument, #!date. The form of the second argument is carefully chosen not to break the various shells and kernels in use.

This style of #! is tested and works across all Unix and Plan 9 versions. For now, we continue to use the /bbin/bb path. This requires two binds, which is less than ideal, but I'd rather not change u-root itself just yet.

To incorporate a u-root image into harvey, for, e.g., 386: GO111MODULE=off GOOS=plan9 GOARCH=386 u-root plan9 cd 386 cpio -iv < /tmp/initramfs.plan9_386.cpio

Will unpack the u-root commands into the harvey image, in bbin/

This change includes a small tweak to .gitignore to ignore bbin directories and hence u-root binaries.

This is tested and working on my x230.

For some comparison on size: There are, today, 40 u-root commands that run on Plan 9. Some of them are not available on Plan9, e.g. sshd and gpt. If we just consider the commands that are common, Plan 9 binaries are 1.134M, u-root combine into 5M.

So u-root is bigger, but at the same time, it will be bringing in commands Plan 9 does not have. Further, there is a steep initial size to u-root, but it grows slowly even as the number of commands doubles.

Signed-off-by: Ronald G. Minnich rminnich@gmail.com

[paul-lalonde]

I'm guessing u-root doesn't respect go modules? Might that explain some of the grief pulling in edwood (among other things we're fixing)?

[rminnich]

from github

⚠️ Go Modules are Broken ⚠️ u-root itself builds fine with modules. When adding commands to your busybox which are outside u-root, make sure to export GO111MODULE=off both when geting the command (so that the command is found under $GOPATH/src and when running the u-root command (so that you can run the u-root command from any directory).

another case of Go working for a much more limited use case than it used to: go modules are fine until you do something not in their world. It's like the mess with internal/

Go has gotten less flexible over the years. I still like it but I miss that flexibility. It's what finally killed source mode once and for all.

[paul-lalonde]

Ron - can you update with the current state of u-root and modules? Then I think this is good?