Rethinking u-root's command line interface

[synackd]

From #1919 arose a discussion about the expected behavior of u-root's command line options. This issue aims at following that discussion, aiming to improve the design of u-root's command line interface to make it more intuitive and for it to follow expected behavior.

A notable example arises when adding files to an initramfs.

u-root provides the -base option which aims to build on top of an existing cpio. However, u-root does not include device files such as /dev/console or create /etc when -base is specified. Currently, there is no way to tell u-root via its CLI to include these files or not when specifying a base cpio.

u-root also provides the -files option which includes extra files/directories in the initramfs along with their ldd dependencies. u-root does include the device files when specifying the -files option; however, if the BusyBox binary was built outside of u-root (say, with gobusybox), -files will try to include the ldd dependencies of the BusyBox binary and will include it twice in some cases (see #1919).

[synackd]

The CLIs of other initramfs generators out there such as dracut, Arch Linux's mkinitcpio, Gentoo's genkernel, and SUSE's mkinitrd are being examined for reference on expected behavior.

One idea follows the following dracut options in the Injecting custom Files section of its manual page:

• --include src dst, which includes src on the filesystem at dst in the initramfs. This does not include ldd dependencies and can only be used once.
• --install 'file1 ...', which "installs" one or more files onto the initramfs, including their ldd dependencies.

Analogous options in u-root as a replacement of -files could be:

• -include src[:dst] which would include src in the initramfs (optionally at dst, like how -files currently does it) without including ldd dependencies. Up to the implementers if it can be included more than once.
• -install src[:dst] which would behave as -files does, installing ldd dependencies.

[synackd]

It seems that many initramfs generators are tied to their respective distributions and so don't offer much flexibility in including arbitrary files.

• genkernel provides flags for functionality that one wants included in the initramfs (e.g. --lvm, --ssh, etc.), but has no options for specific files/binaries.
• mkinitrd provides the -m flag for specifying which kernel modules to include, but the manual page notifies the reader to call dracut for more fine-grained functionality.
• mkinitcpio provides more flexibility in including files/modules/binaries, but does so from a config file, using variables:
  • MODULES
    • An array of additional modules which should be added to the image
    • Dependencies (including other modules and necessary firmware) also added
    • These will be explicitly loaded at initramfs runtime
  • FILES
    • An array of additional files which should be added to the image
    • Files are added as is, and parent directories will be added if needed
    • Overrides any existing files by the same path
  • BINARIES
    • An array of additional binaries which should be added to the image, assumed to be dynamic ELF binaries
    • Shared library dependencies will automatically be added
    • Not considered an error to specify a non-ELF binary in this variable
    • Parent directories will be added if needed
    • Overrides any existing files by the same path

I must say, the dracut method seems straightforward and understandable for including files on the command line. Using a config file seems more supplementary and not strictly necessary, at least right now, but the mkinitcpio and dracut ways of handling this seem succinct enough.

Interestingly, these tools don't offer a way of building off of a base cpio. Is there a reason that u-root doesn't add the device files when building off of a base cpio?

[synackd]

I've created a working example here of replacing -files with -install and -include (analogous to dracut) as described above which doesn't modify much code.

@rminnich and @orangecms, what do you think of this? I didn't make a PR yet because I got the impression that you may want more "remodeling" of u-root's CLI besides file inclusion, and to spark more discussion before any changes were made.

[orangecms]

A thought on -install and -include from my side: I find those a little unintuitive in terms of why which of them would imply ldd. I can imagine to keep -files and add a switch -ldd off to turn off the auto-ldd behavior.
Maybe it even makes sense to have ldd behavior control for each -files, close to your proposal.

However, I'm not sure I understood all of the issues, and that would only solve one of them. What is probably less desirable is a thousand options, like openssl or ffmpeg, which is why I wanted to consider a CLI redesign. :)
I'll give in another thought, would love to hear additional thoughts.

[synackd]

@orangecms Thanks for your thoughts!

Perhaps -install and -include are inherently unintuitive, but my thought was to keep the options similar to another widely-used tool like dracut, which people may already be familiar with. In my eyes, having two separate flags would be simpler to implement (and specify on the command line) than following every -files with an -ldd off/on flag. Perhaps the names could be something like, e.g., -files and -lddfiles to differentiate non-ldd behavior from ldd behavior, respectively?

I don't know about other issues, but the issue I had was primarily with u-root's file inclusion mechanism. What did you have in mind for a CLI redesign?

[rminnich]

above all: make sure that a simple
u-root

continues to do all the right basic things, and that adding files and such continues to be convenient.

[rminnich]

Note that -files now allows one to include directories, and does an ldd on tall binaries in the tree. This has proven to be very useful. Further, I'm not that big a fan of single-use -include; I've used the ability to add multiple files a lot.

BUT:
what if we could easily build a pipeline? Than a lot of my whining ends.

u-root whatver | u-root more stuff | u-root still more stuff

and so on.

This would be really nice.

[synackd]

a simple u-root continues to do all the right basic things

I couldn't agree more.

adding files and such continues to be convenient

That is what I am mainly focusing on: both convenience and following expected behavior.
I think having a way to differentiate including binaries with their ldd dependencies and including files without checking for ldd dependencies would provide more granularity over file inclusion, especially for the use case of building BusyBox outside of u-root with Gobusybox. Also, I see no reason for not being able to specify -include more than once.

[synackd]

Being able to build a pipeline is also essential I think, especially for any tool working with cpio archives.

[orangecms]

The -files and -lddfiles sound good to me, let's go for it :)

I just wasn't sure if I missed a bit somewhere after reading the whole problem statement, because it was a litfle late for me, that's all, sorry if that was confusing. 😅

[rjoleary]

I am going to try converting this to a discussion -- brace yourselves.

[jlowellwofford]

I posted this shell script in slack a while back that I use to build initramfs. It uses gobusybox without the u-root command. It's definitely not the answer here (for one, it's a bash script), but might provide some helpful pointers to some of the current build issues (and possible solutions?). I would love to abandon this script and go back to an appropriately reimagined u-root command.

https://github.com/kraken-hpc/kraken-layercake/blob/main/utils/layer0/build-layer0-base.sh