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
4 times, most recently
from
September 14, 2026 00:35
0756a65 to
9adbe03
Compare
Re-applying an unchanged source staged a new deployment whenever other kargs followed its own on the options line: the old options were removed and the new ones appended at the end, so the line changed. That happens as soon as a second source or e.g. `rpm-ostree kargs` adds something after it, which is TuneD re-applying its profile. Replace the options where the old ones were. This also keeps kernel argument order stable, which matters where the last occurrence wins. Generated-by: AI I am knowledgeable in this problem domain and reviewed it carefully. Signed-off-by: Joseph Marrero Corchado <jmarrero@redhat.com>
Upgrade and switch computed kargs from the booted deployment, so a change that was only staged (`loader-entries set-options-for-source`, `rpm-ostree kargs`) was silently dropped when the staged deployment was replaced -- e.g. TuneD applying a profile and an automatic `bootc upgrade` running before the reboot. rpm-ostree deliberately builds on the pending deployment so operations chain; do the same. Image-provided kargs are unaffected, since the kargs.d diff is applied relative to whichever deployment we build on. Generated-by: AI I am knowledgeable in this problem domain and reviewed it carefully. Signed-off-by: Joseph Marrero Corchado <jmarrero@redhat.com>
Cover bootc staging source-tracked kargs and rpm-ostree re-staging on the same boot: the x-options-source-* keys must survive, which is the fallback fixed in ostreedev/ostree#3611. Also cover the two bootc fixes before this: re-applying an unchanged source is a no-op, and a `bootc switch` on top of a staged source removal keeps the removal. Along the way, find the booted BLS entry by its ostree= karg instead of taking the last one, and expect a removed source to leave an empty tombstone key, since set-options-for-source never deletes keys. Generated-by: AI I am knowledgeable in this problem domain and reviewed it carefully. Signed-off-by: Joseph Marrero Corchado <jmarrero@redhat.com>
kernel-arguments.md still said bootc has no API for per-machine kernel arguments. Describe `loader-entries set-options-for-source`: the ownership keys, how a call is processed, how upgrade/switch and rpm-ostree interact with it, and what TuneD does with it, with a link to the ostree documentation for how the keys survive staging. Generated-by: AI I am knowledgeable in this problem domain and reviewed it carefully. Signed-off-by: Joseph Marrero Corchado <jmarrero@redhat.com>
jmarrero
force-pushed
the
test-cross-consumer-staging
branch
from
September 14, 2026 01:46
143c3bc to
2d9edec
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.