[spec2x] Backport: Add ignition-subsequent.target for non-Ignition boots#132
[spec2x] Backport: Add ignition-subsequent.target for non-Ignition boots#132cgwalters merged 2 commits intocoreos:spec2xfrom darkmuggle:rootflagless
ignition-subsequent.target for non-Ignition boots#132Conversation
|
/cc @cgwalters Testing this now. |
|
Can you update the description? It currently doesn't make sense since this branch isn't used by fcos. |
This is needed for Red Hat CoreOS work for encrypted disks. With the CoreOS Assembler commit 8bcd5608c473a959dae240a6488ce3451ddcdc69, the `root=` and `rootflags` kargs are removed. Red Hat CoreOS is also using b29bf79c5bd27d683519cf2e236f6f9088f6d127 from Fedora CoreOS that uses a service to mount and locate the root filesystem on first boot via `ignition-ostree-mount-sysroot.service`. The problem, however, is that there are different dependencies/ordering if we're doing the "Ignition boot" versus a "subsequent" boot. Add a new target that's queued up if we detect we're doing a "subsequent" boot.
|
So...trying this out, a problem I'm seeing is that we really need the |
|
OK, trying to add |
This helps RHCOS rebase on the latest fedora-coreos-config changes. - Add a stub ignition-mount.service for ordering purposes - Don't change the dependencies of all of the units just yet to minimize churn
|
OK, pushed another commit to this PR which adds Tested in concert with:
|
dustymabe
changed the title
ignition-subsequent.target for non-Ignition bootsignition-subsequent.target for non-Ignition boots
dustymabe
left a comment
dustymabe
left a comment
There was a problem hiding this comment.
I haven't been following all the changes in this space, but LGTM from a trivial review.
|
OK yep, this is all working in my testing. |
4 participants
Backport: Add
ignition-subsequent.targetfor non-Ignition bootsThis is needed for Red Hat CoreOS work for encrypted disks. With the CoreOS Assembler commit 8bcd5608c473a959dae240a6488ce3451ddcdc69, the
root=androotflagskargs are removed. Red Hat CoreOS is also using b29bf79c5bd27d683519cf2e236f6f9088f6d127 from Fedora CoreOS that uses a service to mount and locate the root filesystem on first boot viaignition-ostree-mount-sysroot.service. The problem, however, is that there are different dependencies/ordering if we're doing the "Ignition boot" versus a "subsequent" boot.Add a new target that's queued up if we detect we're doing a "subsequent" boot.