u-root growth: different purposes

[hugelgupf]

Here's another conversation I would like to start. u-root is growing for different projects with different use cases at this point. We're gaining bootloader features (cmds/pxeboot, cmds/boot), as well as possibly two different init systems (uinit for firmware init, other init for NiChrome init).

One of the issues with this is that the default u-root initramfs will keep growing in size and complexity. NERF builds will include random NiChrome tools, like WiFi-related stuff. NiChrome builds will include random NERF tools, like pxeboot and boot.

I think we need to figure out how to separate the different purposes from the base build of u-root. The vague repos I have in my head:

• base u-root (u-root/u-root repo): basic busybox-like utilities / GNU coreutils-like utilities.
• NERF u-root (u-root/NERF): pxeboot, disk boot tools, etc.
• NiChrome u-root (u-root/NiChrome): WiFi tools, the fancier init system, etc.

The idea would be that any shared code could be in the main u-root repo as packages, but any cmds covering the NiChrome or NERF use case specifically should be in a separate repo.

cc @GanShun @rminnich @thienhoang23

[rminnich]

we need to plan for personalities I guess, and provide a default personality, and let users override it?

[pwFoo]

Maybe a custom builds need cmds of both? So all the features should be available. What so you think about pre-defined cmd lists or cmd "groups" to use?

[hugelgupf]

I'm thinking that the default set of commands should be the lowest common denominator - the original u-root with just the busybox-like tools.

Some NiChrome things are already in their own repo, (e.g. install), whereas stuff like the wifi command is in u-root.

All NERF-specific commands are currently in the u-root repo. I'm thinking that we may want to create a repo like u-root/boot that contains all the booting tools.

In the other hand, this somewhat hinders discoverability of features we've implemented. We'd need (well, we still need) better documentation of what's where and how it can be used.

[insomniacslk]

I entirely agree on the minimal subset and the additional repos to add feature sets instead of single commands/features, and we would benefit from this approach too. It would be also good to keep init as a candidate to become an easily replaceable component for all the build modes. We already discussed this on Slack and I know this is coming, just keeping track of it here too :)

[rck]

I totally agree with what Chris wrote about "hindering discoverability" and that we need more documentation. Just from my perspective: It was (and for some parts still is) pretty confusing what all the components are and how they play together. Really, try to imagine that you are new to that stuff, I still have this fresh memory. By now the u-root documentation got some nice improvements, but IMO we lack most of the "bigger picture" docu. For example generating my first initramfs and booting it with a kernel was a matter of 10mins, so we do a good job on that. But then I had this "what now?" moment. WTF is NERF? WTF is NiChrome? Do I need that? Do I want that? What is it anyways? What is the part of u-root in them?

I think what we really should have a) a "bigger picture" section and b) more complete "user stories"/howtos. You want to run it on your Chromebook? Read this. You want to run it on your apu2 board? Read this. You want to boot Alpine Linux with it, read that.

So if splitting repos makes sense, sure, that should be done, but we have to be careful, the situation is already confusing (or I'm exceptionally stupid, which is as likely ;-)).

So to make this productive, I have two things where I'm happy to contribute:

• I got hold of an APU2 board which we already mention in the README.md and where Ron told me it is a nice board to start with. So I assume @rminnich has something u-root related running on it. All hints are welcome, I would "reproduce" it and write it up. Ron, any hints to what you actually got running and how would be great!
• Currently I'm toying around with a script that takes an Alpine initramfs and replaces busybox binaries with ours. While that is not a particularly useful end-product it has two nice properties: a) it is easy, because they use busybox and we are close enough to that (e.g., single letter cmd arguments) and b) it nicely shows where we have "unexpected" behavior, missing behavior, or where we miss commands at all. This is in a state where this Frankenstein-initramfs then boots to an Alpine cli prompt (for a very limited hand-selected replacement of busybox commands). The goal is obviously to replace all of them in the end/develop the missing parts. If anyone is interested in that I'm happy to share it. I don't know if we have a place for these "example scripts" anywhere or if that should even be there, it is a quite exotic use case, but really fun to see commands you contributed /sent patches actually boot a system. That is a lot more satisfying than just landing in a qemu booted initramfs ;-)

[pwFoo]

u-root is awesome, but it lacks documentation of many features? How to use packages like wifi and much more?

[rjoleary]

I feel this has been mostly solved by the sub-directories under cmds/ as well as the templates file https://github.com/u-root/u-root/blob/master/templates.go.