Add ignition-subsequent.target for non-Ignition boots#131
Add ignition-subsequent.target for non-Ignition boots#131jlebon merged 1 commit intocoreos:masterfrom
ignition-subsequent.target for non-Ignition boots#131Conversation
This is needed for Fedora CoreOS work on reprovisioning the rootfs. We tried to split out a systemd unit to handle mounting the root in this commit: coreos/fedora-coreos-config@a6fe374 with `ignition-ostree-mount-sysroot.service` but the problem is that needs to have 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.
The unit to mount sysroot only worked the *first* boot because it was integrated with Ignition. We need to have separate units with different dependencies (but that execute the same code) for the "Ignition boot" compared with "subsequent" boots. Depends coreos/ignition-dracut#131
|
Required by coreos/fedora-coreos-config#210 |
The unit to mount sysroot only worked the *first* boot because it was integrated with Ignition. We need to have separate units with different dependencies (but that execute the same code) for the "Ignition boot" compared with "subsequent" boots. Depends coreos/ignition-dracut#131
darkmuggle
left a comment
darkmuggle
left a comment
There was a problem hiding this comment.
LGTM. I was working out a separate PR, but your landed first
|
Hmm, though coreos/fedora-coreos-config#210 already has |
|
OK I see, the firstboot unit also ties into |
jlebon
left a comment
jlebon
left a comment
There was a problem hiding this comment.
LGTM! I'm a little wary of shipping a unit here which isn't actually needed by Ignition itself. Though it's definitely useful to have those semantics handy.
|
I'm playing a bit of catch up here so I probably missed something, why couldn't the sysroot mount service just have the same deps/ordering as the old sysroot.mount unit? |
What we had before is what The systemd generated We're taking over that role. |
Well it will always be at
Right, why not do that with the service as well? |
I think that works today yeah. That said, requirements may drive us to later do something like ensure we've "bound" our config to something more like "the label root on the disk whose UUID=(uuid we generated at Ignition time)".
|
I thought we'd decided that the interface was "root is by label and you can only have one label with root". We don't need to design around non-problems, especially when it introduces more complexity. We should keep it simple unless we have a concrete reason to make it more complex.
Gotcha. |
The unit to mount sysroot only worked the *first* boot because it was integrated with Ignition. We need to have separate units with different dependencies (but that execute the same code) for the "Ignition boot" compared with "subsequent" boots. Depends coreos/ignition-dracut#131
The unit to mount sysroot only worked the *first* boot because it was integrated with Ignition. We need to have separate units with different dependencies (but that execute the same code) for the "Ignition boot" compared with "subsequent" boots. Depends coreos/ignition-dracut#131
The unit to mount sysroot only worked the *first* boot because it was integrated with Ignition. We need to have separate units with different dependencies (but that execute the same code) for the "Ignition boot" compared with "subsequent" boots. Depends coreos/ignition-dracut#131
4 participants
This is needed for Fedora CoreOS work on reprovisioning
the rootfs. We tried to split out a systemd unit to handle
mounting the root in this commit:
coreos/fedora-coreos-config@a6fe374
with
ignition-ostree-mount-sysroot.servicebut the problemis that needs to have 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.