bootloader: Simplify tuning of rpm-ostree kargs

[zacikpa]

This PR aims to simplify the tuning of kernel parameters in rpm-ostree systems, which has some major flaws:

1. It does not respect the claim that existing kernel parameters are left untouched.
2. It does not append new kernel parameters in the order specified in the profile.

The new implementation is much simpler, but it also restricts the user more, since it disallows replacing existing kernel parameters.

Setting to WIP, since I'm still doing testing on Fedora CoreOS virtual machines.

[yarda]

The new implementation is much simpler, but it also restricts the user more, since it disallows replacing existing kernel parameters.

There is an older grub convention that TuneD cannot change/delete any karg it didn't add itself, so I think this restriction is OK.

One question, what happen if there is running deployment or the rpm-ostree is busy. IMHO previously, it waited until it's idle. Is the request processed later or is there failure in such case?

[zacikpa]

One question, what happen if there is running deployment or the rpm-ostree is busy. IMHO previously, it waited until it's idle. Is the request processed later or is there failure in such case?

I will re-check that, can't remember if I tested such cases or not, thanks.

[yarda]

One question, what happen if there is running deployment or the rpm-ostree is busy. IMHO previously, it waited until it's idle. Is the request processed later or is there failure in such case?

I will re-check that, can't remember if I tested such cases or not, thanks.

Is the behaviour the same?

[zacikpa]

One question, what happen if there is running deployment or the rpm-ostree is busy. IMHO previously, it waited until it's idle. Is the request processed later or is there failure in such case?

I will re-check that, can't remember if I tested such cases or not, thanks.

Is the behaviour the same?

Looking at it now, I likely factored out that code by accident. I will add it back. Edit: Or I rather misunderstood what the code did. If there is a new active deployment, it's ok to proceed, but if there is a transaction in progress (like creating new deployment), then we should wait.

[zacikpa]

Updated the code to handle errors better and re-added the wait until rpm-ostree becomes idle.

[jmencak]

I've tested this PR on RHEL AI 1.4 and apart from very long times (cca 1 minute) to add/remove kernel parameters I did not find any issues. The very long times seem to be an rpm-ostree issue.

Edit: this seems to lower the long delays in rpm-ostree by roughly 6x for me (from 1 minute to 10s).

[zacikpa]

I adjusted the handling of kargs in no-daemon mode: before appending kargs from a profile, TuneD removes any kargs that may be present from previous profiles. This should be consistent with how TuneD behaves on traditional package-based systems, where the entire grub configuration file is overwritten.

[zacikpa]

Closed this on accident, reopening.

[cgwalters]

One thing I would note here is that with bootc we are also now supporting modifying kargs at container build time via https://docs.fedoraproject.org/en-US/bootc/kernel-args/#_via_usrlibbootckargs_d

This is a totally new capability vs what came before with (rpm-)ostree.

So in a world where we're running tuned at build time to execute on a profile, it could write out e.g. /usr/lib/bootc/kargs.d/20-tuned.toml or so. The key benefit of this is that tuned doesn't need to reconcile anything - bootc takes care of that.

[richm]

One thing I would note here is that with bootc we are also now supporting modifying kargs at container build time via https://docs.fedoraproject.org/en-US/bootc/kernel-args/#_via_usrlibbootckargs_d

This is a totally new capability vs what came before with (rpm-)ostree.

So in a world where we're running tuned at build time to execute on a profile, it could write out e.g. /usr/lib/bootc/kargs.d/20-tuned.toml or so. The key benefit of this is that tuned doesn't need to reconcile anything - bootc takes care of that.

Thanks - @martinpitt this is good to know when you get to converting the bootloader system role to work at container build time - also note that for TOML formatting we implemented an Ansible filter plugin for the podman role to convert data types to their TOML representation - https://github.com/linux-system-roles/podman/tree/main/filter_plugins

[zacikpa]

Thank you for the comments, @cgwalters, much appreciated.

One thing I would note here is that with bootc we are also now supporting modifying kargs at container build time via https://docs.fedoraproject.org/en-US/bootc/kernel-args/#_via_usrlibbootckargs_d

This is a totally new capability vs what came before with (rpm-)ostree.

So in a world where we're running tuned at build time to execute on a profile, it could write out e.g. /usr/lib/bootc/kargs.d/20-tuned.toml or so. The key benefit of this is that tuned doesn't need to reconcile anything - bootc takes care of that.

Is there a way to reliably detect that we are in this scenario, i.e., in a bootc container being built?

[cgwalters]

Is there a way to reliably detect that we are in this scenario, i.e., in a bootc container being built?

systemd-detect-virt -c is easiest

[yarda]

IMHO in TuneD we use virt-what tool a lot, maybe it can also detect it (I didn't try).

[cgwalters]

xref https://github.com/bootc-dev/bootc/issues/899

[yarda]

So in a world where we're running tuned at build time to execute on a profile, it could write out e.g. /usr/lib/bootc/kargs.d/20-tuned.toml or so. The key benefit of this is that tuned doesn't need to reconcile anything - bootc takes care of that.

This can be handled in future PRs.