Ignition Kernel Argument Support

[arithx]

Overview

Ignition is planning to add kernel argument support (coreos/ignition#1168) which expects that the distribution is both providing a binary which can perform the kernel argument modification as well as enabling the new stage at the desired ordering.

Binary

Ignition expects the following constraints from the binary:

1. Adds should be done in an append if missing manner
2. Deletes should NOT fail if they are not present
3. Rebooting the system if necessary

Currently Fedora CoreOS is using rdcore to set some kernel arguments inside of the initrd, however I believe that 1 & 2 might be slightly different than the current rdcore functionality so we might need to make slight modifications there. Additionally we'll need to implement the detection of kernel arguments in the Ignition spec & perform the reboot.

New Ignition Stage Ordering

The Ignition recommendation is to order the new stage some time after the fetch stage and before the disks stage. We'll also likely want to run before ignition-ostree-transposefs-detect/ignition-ostree-transposefs-save to avoid potentially copying the root disk in memory before a reboot when kernel arguments are set.

[cgwalters]

This is somewhat tangential but we debated ostree kargs over in ostreedev/ostree#2217 but one thing I think we may need to try harder to handle is the "reset to default" case, perhaps in a CoreOS specific way. One idea here is
that when we boot, we e.g. write the exact kargs from the BLS config we used to e.g. /boot/loader/.coreos-orig.conf or something.

Or (and this gets somewhat ostree-specific) we generalize some support for retaining the pristine booted deployment, which would also help for the #399 case.

Anyways, either or both of these can be separate stages in rdcore. But it would also greatly help the MCO code because then the day 2 kargs support could always be "start from CoreOS defaults and add shouldExist kargs, validate shouldNotExist doesn't".

[bgilbert]

Resetting the kernel arguments seems inherently risky, since any user-specified kargs may be necessary for the machine to boot successfully. (And in particular, we'd need to account for rootfs kargs added by rootmap.) Other than #399 and extending the MCO's kargs support, are there other use cases where that functionality is important?

[cgwalters]

Resetting the kernel arguments seems inherently risky, since any user-specified kargs may be necessary for the machine to boot successfully.

If the user does a factory reset and doesn't provide those kargs again, that's their problem?

(And in particular, we'd need to account for rootfs kargs added by rootmap.)

Right; rootmap-generated kargs blur this. I think if we capture the kargs after that's done but before Ignition that's what's desired.

Other than #399 and extending the MCO's kargs support, are there other use cases where that functionality is important?

I can't think of any, but the factory reset problem is fairly general.

[bgilbert]

Ah, I hadn't understood that you meant "reset to default" only in the context of a full system reset. I think it could make sense for the helper program to save the original kargs somewhere if it's easy, but we could probably also defer that functionality until #399 is implemented.

I think if we capture the kargs after that's done but before Ignition that's what's desired.

Ignition kargs will run before rootmap — on an earlier boot, in fact.

[jlebon]

This is done now in coreos/ignition#1178 and coreos/fedora-coreos-config#938.

[arithx]

Closed in coreos/fedora-coreos-config#938

[dustymabe]

The fix for this went into testing stream release 34.20210529.2.0. Please try out the new release and report issues.

[dustymabe]

The fix for this went into stable stream release 34.20210529.3.0.