Add ability to render our own kargs in container

[jeckersb]

Right now in the composefs build test/example flow, we are hardcoding the kargs that are injected into the UKI. However we need to properly render the kargs given the context of the contents of the container image, and also let users supply additional kargs and merge them the same way one would do with the bootc install flow. This is a prerequisite to generating the full UKI since we need to know this ahead of time, the same that we need to know the composefs fsverity hash.

This should be something like (naming bikesheddable):

bootc container render-kargs --additional-kargs "foo bar=baz"

This will print the kargs to stdout the same way it would be added to the cmdline in the normal bootc install. So this would also take into account things like installconfig, kargs.d, etc.

One outstanding question is what to do about the "root filesystem" kargs from the install flow? I guess we just ignore that in this case, since we're running in an arbitrary container and don't have the final root filesystem available for introspection. Will that cause any problems down the line?

[cgwalters]

What would the output format be? Plain text whitespace separated? Should probably have --json as a general rule.

This also relates a bit to #1820 (that use case actually wants this instead really).

Maybe we add bootc container inspect which is generalized to outputting more information, like say the detected kernel version and whether it's UKI or not? I've wanted that elsewhere.

--additional-kargs "foo bar=baz"

What would be the use case for that versus writing them as kargs.d files?

[jeckersb]

What would the output format be? Plain text whitespace separated? Should probably have --json as a general rule.

Both, probably plain text by default (basically Cmdline::to_string() on the final computed value). Primarily we want to just feed this into ukify.

This also relates a bit to #1820 (that use case actually wants this instead really).

Maybe we add bootc container inspect which is generalized to outputting more information, like say the detected kernel version and whether it's UKI or not? I've wanted that elsewhere.

Yeah that seems generally useful. That kinda goes against what I wrote above re: making the kargs plaintext though. I guess we should make the fields and formatting user-selectable, mostly so I can be lazy and do something like bootc container inspect --fields=kargs --format=plain or whatnot and not have to pipe the output into things like grep and jq just to reformat it to send it to ukify.

--additional-kargs "foo bar=baz"

What would be the use case for that versus writing them as kargs.d files?

Not strictly required, but this would take the place of the current flow where one does bootc install to-disk --karg foo --karg bar=baz. In the UKI case this is the only place where one could inject arbitrary kargs since we can't do it at install time. Maybe we intentionally do not allow that in the sealed/UKI case (although the end user could still modify the generated cmdline between rendering it and passing to ukify...).

[cgwalters]

Maybe we intentionally do not allow that in the sealed/UKI case

Yes,

bootc/crates/lib/src/bootc_composefs/boot.rs

Line 1041 in a4bda72

state.require_no_kargs_for_uki()?;

mostly so I can be lazy and do something like bootc container inspect --fields=kargs --format=plain

Yeah, something analogous podman inspect --format might make sense for both bootc status and this.

Though I dunno, what did you think about having bootc container ukify anyways?

I hope anyways that tooling here ends up in not-shell-script so parsing JSON isn't onerous.

[jeckersb]

Yeah it was my intention to have bootc container ukify as well. I guess internally we just call the same thing that bootc container inspect calls to render the kargs and consume it directly. For some reason I was thinking it would be like:

bootc container ukify -- --cmdline $(bootc container inspect --kargs)

But really we can just do all of that internally.

[cgwalters]

Yes exactly, us taking care of --cmdline is an important part of this.

BTW a really big thing in this when we clean up our image builds to fix containers/composefs-rs#132 (by switching to an updated layer-split/chunked format) then we can compute the composefs digest from inside the container image build process, which would dramatically cleanup the build process.

It's such a big cleanup actually that I am tempted to try to entirely rework the sealed build path to always work that way.

[jeckersb]

Yeah that would be a giant win and it probably makes sense to just get it sorted out ASAP as part of this.

Rereading that issue reminds me that we really should pursue a fix in overlayfs to be able to mark directories as "structual-only" and to read metadata from the next lowerdir in the stack. Doesn't seem like a very difficult change (famous last words...)