initramfs: Fix using local /etc when also replacing kernel

[jlebon]

Instead of basing our decision to use the local /etc on whether we're
using dracut --rebuild, base it directly on a boolean parameter.

This is relevant in the client-side when initramfs regeneration is
requested as well as a kernel override. In such cases, we do want to use
the local /etc, but we'd skip that path because we didn't also use
dracut --rebuild.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1806588

[jlebon]

This is split out from #1997 and is all that's technically needed to fix https://bugzilla.redhat.com/show_bug.cgi?id=1806588. Though I think we should do something like #1997 too.

Keeping as draft until I add tests here.

[jlebon]

To fix Prow: coreos/coreos-assembler#1154

[jlebon]

OK, added a test for this. Ready to review!

[cgwalters]

In such cases, we don't use dracut --rebuild because no longer have access to the original initramfs.

We do, it's in the base tree.

So my vague recollection here is that the current behavior was somewhat intentional - the concept is that e.g. override replace for kernel should just get you new kernel modules, but otherwise behave the same as a server side compose.

We do distinguish in the interface/code today between rpm-ostree initramfs --enable and rpm-ostree override replace.

Isn't this something more like we should look at the origin and see whether initramfs regeneration was requested and if so use the local /etc?

[jlebon]

We do, it's in the base tree.

OK, sure :), but it's not super handy. We'd have to re-check it out somewhere under the temp rootfs so dracut can access it. Actually, a first iteration of this patch was to keep the base initramfs under /usr/lib/sysimage and using that. But anyway, it's hard to talk about this without talking about #1997: my conclusion was that using --rebuild isn't what we really want.

So my vague recollection here is that the current behavior was somewhat intentional - the concept is that e.g. override replace for kernel should just get you new kernel modules, but otherwise behave the same as a server side compose.

We do distinguish in the interface/code today between rpm-ostree initramfs --enable and rpm-ostree override replace.

Isn't this something more like we should look at the origin and see whether initramfs regeneration was requested and if so use the local /etc?

Hmm yeah, I think that makes sense. Will tweak!

[cgwalters]

Yeah, I think I agree with #1997

[jlebon]

OK, updated! ⬆️

[cgwalters]

Nice, thanks!
/lgtm

[jlebon]

Had to push another commit here to work around https://pagure.io/releng/issue/9281. Though I also took the opportunity to drop a stale comment I had added.

[cgwalters]

/lgtm

[jlebon]

OK, had to add yet another commit here to fix testing. 😢 Hopefully this is the one!

[cgwalters]

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cgwalters, jlebon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [cgwalters,jlebon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[yanirq]

@jlebon I assume this should also work for initramfs --enable --arg=-I --arg="/etc/foo.conf /etc/bar.conf" right ?

[jlebon]

@yanirq Yup, I could've probably tweaked the config to use that. But note: https://bugzilla.redhat.com/show_bug.cgi?id=1806588#c6