tests: Add cross-consumer staging scenario to loader-entries-source - #2330
Draft
jmarrero wants to merge 1 commit into
Draft
tests: Add cross-consumer staging scenario to loader-entries-source#2330jmarrero wants to merge 1 commit into
jmarrero wants to merge 1 commit into
Conversation
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. Signed-off-by: Joseph Marrero Corchado <jmarrero@redhat.com>
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
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.