tests: Add cross-consumer staging scenario to loader-entries-source - #2330
Draft
jmarrero wants to merge 2 commits into
Draft
tests: Add cross-consumer staging scenario to loader-entries-source#2330jmarrero wants to merge 2 commits into
jmarrero wants to merge 2 commits into
Conversation
jmarrero
added a commit
to jmarrero/ostree
that referenced
this pull request
Aug 5, 2026
Multi-reboot TMT test that exercises the previously-staged fallback path in ostree_sysroot_stage_tree_with_options(). Verifies that x-options-source-* keys set by bootc survive when rpm-ostree re-stages on the same boot. This is the ostree-side test for the scenario covered by bootc-dev/bootc#2330. Related: ostreedev#3611
jmarrero
added a commit
to jmarrero/ostree
that referenced
this pull request
Aug 5, 2026
Multi-reboot TMT test that exercises the previously-staged fallback path in ostree_sysroot_stage_tree_with_options(). Verifies that x-options-source-* keys set by bootc survive when rpm-ostree re-stages on the same boot. This is the ostree-side test for the scenario covered by bootc-dev/bootc#2330. Related: ostreedev#3611
jmarrero
added a commit
to jmarrero/ostree
that referenced
this pull request
Aug 5, 2026
Multi-reboot TMT test that exercises the previously-staged fallback path in ostree_sysroot_stage_tree_with_options(). Verifies that x-options-source-* keys set by bootc survive when rpm-ostree re-stages on the same boot. This is the ostree-side test for the scenario covered by bootc-dev/bootc#2330. Related: ostreedev#3611
jmarrero
added a commit
to jmarrero/ostree
that referenced
this pull request
Aug 5, 2026
Reapply the bootconfig-extra previously-staged fallback (reverted in PR ostreedev#3610) with a corrected all-or-nothing fallback chain that fixes the regression reported in ostreedev#3609. The original 3-way additive merge gave previously-staged data higher priority than the merge deployment, which broke bootc's loader-entries set-options-for-source when called multiple times on the same boot. The fix uses a 2-tier fallback: 1. Merge deployment's bootconfig (caller may have updated in-memory) 2. Previously staged deployment's bootconfig-extra (cross-consumer fallback for unaware consumers like rpm-ostree) If tier 1 has any extension keys, those are authoritative and previously-staged data is ignored. This prevents stale keys from overriding fresh updates when the same consumer stages repeatedly. Also adds a multi-reboot TMT integration test covering: - Cross-consumer staging (bootc then rpm-ostree) - Triple coexistence (two bootc sources + rpm-ostree local kargs) - Source replacement while rpm-ostree kargs are active Closes: ostreedev#3609 Related: bootc-dev/bootc#2330
jmarrero
added a commit
to jmarrero/ostree
that referenced
this pull request
Aug 5, 2026
Reapply the bootconfig-extra previously-staged fallback (reverted in PR ostreedev#3610) with a corrected all-or-nothing fallback chain that fixes the regression reported in ostreedev#3609. The original 3-way additive merge gave previously-staged data higher priority than the merge deployment, which broke bootc's loader-entries set-options-for-source when called multiple times on the same boot. The fix uses a 2-tier fallback: 1. Merge deployment's bootconfig (caller may have updated in-memory) 2. Previously staged deployment's bootconfig-extra (cross-consumer fallback for unaware consumers like rpm-ostree) If tier 1 has any extension keys, those are authoritative and previously-staged data is ignored. This prevents stale keys from overriding fresh updates when the same consumer stages repeatedly. Also adds a multi-reboot TMT integration test covering: - Cross-consumer staging (bootc then rpm-ostree) - Triple coexistence (two bootc sources + rpm-ostree local kargs) - Source replacement while rpm-ostree kargs are active Closes: ostreedev#3609 Related: bootc-dev/bootc#2330
jmarrero
added a commit
to jmarrero/ostree
that referenced
this pull request
Aug 5, 2026
Reapply the bootconfig-extra previously-staged fallback (reverted in PR ostreedev#3610) with a corrected all-or-nothing fallback chain that fixes the regression reported in ostreedev#3609. The original 3-way additive merge gave previously-staged data higher priority than the merge deployment, which broke bootc's loader-entries set-options-for-source when called multiple times on the same boot. The fix uses a 2-tier fallback: 1. Merge deployment's bootconfig (caller may have updated in-memory) 2. Previously staged deployment's bootconfig-extra (cross-consumer fallback for unaware consumers like rpm-ostree) If tier 1 has any extension keys, those are authoritative and previously-staged data is ignored. This prevents stale keys from overriding fresh updates when the same consumer stages repeatedly. Also adds a multi-reboot TMT integration test covering: - Cross-consumer staging (bootc then rpm-ostree) - Triple coexistence (two bootc sources + rpm-ostree local kargs) - Source replacement while rpm-ostree kargs are active Closes: ostreedev#3609 Related: bootc-dev/bootc#2330
jmarrero
force-pushed
the
test-cross-consumer-staging
branch
from
September 13, 2026 21:01
acaab26 to
7eb2029
Compare
Re-applying a source whose options had not changed still staged a new deployment whenever anything followed them on the options line: compute_merged_options removed the old options and appended the new ones at the end, so the line changed and the idempotency check failed. That happens as soon as a second source is added or another tool such as rpm-ostree appends a karg, which is exactly the situation TuneD re-applying its profile runs into. Replace the source's options at the position of the first old one instead. That also keeps the relative order of kernel arguments stable, which matters for parameters where the last occurrence wins. Generated-by: AI I am knowledgeable in this problem domain and reviewed it carefully.
Cover the case where bootc stages source-tracked kargs and then rpm-ostree re-stages on the same boot (e.g. `rpm-ostree kargs --append`). The replacement staged deployment must inherit the x-options-source-* keys from the previously staged one, which is the fallback path fixed in ostreedev/ostree#3611; without it the keys are dropped and the source can no longer be diffed or removed. Two fixes to the test along the way: read the source keys from the entry whose options line carries the booted ostree= karg rather than whichever entry sorts last, and expect a removed source to leave an empty tombstone key behind, since set-options-for-source never deletes keys. Generated-by: AI I am knowledgeable in this problem domain and reviewed it carefully.
jmarrero
force-pushed
the
test-cross-consumer-staging
branch
from
September 13, 2026 22:09
7eb2029 to
868dec4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Extend the loader-entries set-options-for-source test to cover the case where bootc stages source-tracked kargs and then rpm-ostree re-stages on the same boot (e.g. via 'rpm-ostree kargs --append'). The replacement staged deployment must inherit the x-options-source-* keys from the previously-staged deployment.
This exercises the 'previously-staged fallback' path in ostree's ostree_sysroot_stage_tree_with_options(), fixed by ostreedev/ostree#3611. Without that fix, this test fails because rpm-ostree's re-staging drops the source keys that bootc set.
Done with AI. Draft while ostree PR closes.