/etc/bootc/kargs.d

[kfox1111]

It would be useful to have /etc/bootc/kargs.d in addition to /usr/lib/bootc/kargs.d get merged in.

Example use case: If you have a mixed hardware cluster, you often will have a different set of console args related to the serial console, but otherwise all the nodes are the same. You could make custom images for each hardware class, but if there was an /etc/bootc/kargs.d, you could just drop that arg in there and the same image would work everywhere.

[cgwalters]

Example use case: If you have a mixed hardware cluster,

We support conditionalizing kargs on architecture right now https://containers.github.io/bootc/building/kernel-arguments.html#usrlibbootckargsd

But yes per our discussion sometimes there are kargs that are dependent on (platform, arch) where "platform" is like "gcp", "aws", "metal" etc.

[kfox1111]

Yeah, where I usually have been seeing it though, the arch is x86_64. Just different serial ports. So, not too much to conditional on.

[plnordquist]

I will say that when using Anaconda to kickstart and install a bootc image, I was surprised it did not preserve the console argument from Anaconda automatically. pyanaconda parses the kernel arguments passed in through PXE boot and preserves the console argument when writing the bootloader configuration for a normal kickstart. I'm able to add the console argument manually with the ostreecontainer install by using the bootloader command and the --append argument.

[champtar]

Currently tuned can set kargs on classic and rpm-ostree systems, so bootc really need a supported way to change kargs 'at runtime' instead of being forced to build another image, /etc/bootc/kargs.d would definitely be great

[cgwalters]

so bootc really need a supported way to change kargs 'at runtime'

We have the same one we've always had to be clear:
https://bootc-dev.github.io/bootc//building/kernel-arguments.html#kernel-arguments-injected-at-installation-time

Should we have some sugar for it? Perhaps...

[kfox1111]

@cgwalters can you change it after install time without a bootc image update though?

[champtar]

This is at install time only, no ? I need to change it after install, and ideally have tuned integration at some point.
I know I can just edit config in loader/entries, but would prefer a bit of sugar to do it :)

My use case is a software appliance video encoder deployed on baremetal, I want 1 ISO installer, not 2 or 3. Some "workflow" require strict(er) latency, so we put some extra kargs for that, but those kargs reduce performance a bit and or increase power consumption, so we can't just always put them.

[cgwalters]

@cgwalters can you change it after install time without a bootc image update though?

Yes. The boot loader reads the arguments from that file.

This is at install time only, no ? I need to change it after install, and ideally have tuned integration at some point.
I know I can just edit config in loader/entries, but would prefer a bit of sugar to do it :)

Your two statements contradict. Yes there is tuned integration (which has at least one bug we're fixing redhat-performance/tuned#690 ).

That said bigger picture there's definitely work to do here. The thing that's not exciting about /etc/bootc/kargs.d is I was already not totally happy with introducing the /usr/lib version.

The problem tuned has right now is that it was designed for a yum system with only one bootable root, and there it's usually expected to mutate the kargs live.

But I think what we often really want is to only mutate the kargs for the next boot. Doing that would require generalized "pre-upgrade" support (a bit related to #640 ) so we fetch the tuned config from the new image, and have it basically "generate" something like /run/bootc/kargs.d during the update which we then apply. This would mean tuned wouldn't need to "reconcile" kargs itself.

Also, it would fix the problem that today the first install necessarily implies a reconciliation.

[champtar]

I was thinking for a future without rpm-ostree on the target, but if tuned can still use rpm-ostree kargs today that's a good news !

But I think what we often really want is to only mutate the kargs for the next boot. Doing that would require generalized "pre-upgrade" support (a bit related to #640 ) so we fetch the tuned config from the new image, and have it basically "generate" something like /run/bootc/kargs.d during the update which we then apply. This would mean tuned wouldn't need to "reconcile" kargs itself.

Also need to know which profile to use from the current /etc, but I like the idea very much

[cgwalters]

#1363 also relates to this