Repository navigation
playbooks/depencies-fedora-coreos: add a fallback to the updates-testing repo #1847
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -14,19 +14,45 @@ | |
| # limitations under the License. | ||
| # | ||
|
|
||
| # These package overrides get a little complicated due to the | ||
| # `next` stream pointing at pre-release repos during branching. | ||
| # With the below loop, we try and use the default `updates` repo, | ||
| # and fallback to `updates-testing` and `fedora` in turn so that we | ||
| # can update base packages on the system. | ||
|
|
||
| - name: Synchronize base packages to repo versions | ||
| become: yes | ||
| shell: | | ||
| for repo in updates updates-testing fedora; do | ||
|
Member
There was a problem hiding this comment. I am not fully sure about the ... to match the ascending order of builds - Train of thought follows below. |
||
| output=$(rpm-ostree override replace --experimental --from repo="$repo" {{ item.packages }} 2>&1) | ||
| rc=$? | ||
|
|
||
| if [ $rc -eq 0 ]; then | ||
| echo "$output" | ||
| exit 0 | ||
| fi | ||
| echo "$output" >&2 | ||
|
|
||
| # Already at the latest version, nothing to do. | ||
| if echo "$output" | grep -qi 'reinstall exact'; then | ||
| exit 0 | ||
| fi | ||
|
|
||
| # Package not found in this repo, try the next one. | ||
| if echo "$output" | grep -qi 'no matches'; then | ||
| continue | ||
| fi | ||
|
Member
There was a problem hiding this comment. Train of thought follows from above. Error handling, loops, and standard error/output stream handling in shell scripts stress me out under the best of conditions, and this is an Ansible playbook that's difficult to test locally. :) So, I am wondering if something like this will actually work: It can be slower because it will always run The problem is, I don't know if
Contributor
Author
There was a problem hiding this comment. I think it does work like that yes. I'm not entirely sure how to confirm. It does seem to behave well for the series of overrides we're doing there though. I'll make that change and we'll see what CI says.
Contributor
Author
There was a problem hiding this comment. OK, that's annoying. Doesn't look like it does the right thing: [core@cosa-devsh ~]$ sudo rpm-ostree override replace --experimental --from="repo=fedora" libgcc
Checking out tree 2c45d70... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora updates-archive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2026-03-24T10:37:04Z solvables: 3
rpm-md repo 'updates' (cached); generated: 2026-10-13T01:05:00Z solvables: 30441
rpm-md repo 'fedora' (cached); generated: 2026-04-22T13:34:32Z solvables: 76354
rpm-md repo 'updates-archive' (cached); generated: 2026-10-12T03:51:56Z solvables: 47351
Resolving dependencies... done
Will download: 1 package (129.3 kB)
Downloading from 'fedora'... done
Importing packages... done
Applying 1 override
Processing packages... done
Running systemd-sysusers... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Downgraded:
libgcc 16.2.1-2.fc44 -> 16.0.1-0.10.fc44
Run "systemctl reboot" to start a reboot
[core@cosa-devsh ~]$ sudo rpm-ostree override replace --experimental --from="repo=updates" libgcc
Checking out tree 2c45d70... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora updates-archive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2026-03-24T10:37:04Z solvables: 3
rpm-md repo 'updates' (cached); generated: 2026-10-13T01:05:00Z solvables: 30441
rpm-md repo 'fedora' (cached); generated: 2026-04-22T13:34:32Z solvables: 76354
rpm-md repo 'updates-archive' (cached); generated: 2026-10-12T03:51:56Z solvables: 47351
Resolving dependencies... done
Applying 1 override
Processing packages... done
Running systemd-sysusers... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Freed: 29.2 MB (pkgcache branches: 0)
Downgraded:
libgcc 16.2.1-2.fc44 -> 16.0.1-0.10.fc44
Run "systemctl reboot" to start a reboot
[core@cosa-devsh ~]$ sudo rpm-ostree override replace --experimental --from="repo=updates-testing" libgcc
Checking out tree 2c45d70... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora updates-archive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2026-03-24T10:37:04Z solvables: 3
rpm-md repo 'updates' (cached); generated: 2026-10-13T01:05:00Z solvables: 30441
rpm-md repo 'fedora' (cached); generated: 2026-04-22T13:34:32Z solvables: 76354
rpm-md repo 'updates-archive' (cached); generated: 2026-10-12T03:51:56Z solvables: 47351
Resolving dependencies... done
Applying 1 override
Processing packages... done
Running systemd-sysusers... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Freed: 29.2 MB (pkgcache branches: 0)
Downgraded:
libgcc 16.2.1-2.fc44 -> 16.0.1-0.10.fc44
Run "systemctl reboot" to start a rebootThat's on an F44 node |
||
|
|
||
| # Other error, bail out. | ||
| exit $rc | ||
| done | ||
| exit $rc | ||
| loop: | ||
| - { name: glibc, packages: "glibc glibc-common glibc-minimal-langpack glibc-gconv-extra" } | ||
| - { name: shadow-utils, packages: "shadow-utils" } | ||
| - { name: libgcc, packages: "libgcc" } | ||
|
Member
There was a problem hiding this comment. Nitpick. Since we are grouping things by the same source package, we should probably use
Contributor
Author
There was a problem hiding this comment. I just thought it might be confusing since we're installing |
||
| loop_control: | ||
| label: "{{ item.name }}" | ||
|
Member
There was a problem hiding this comment. Is it doing anything? :) The documentation says: However, it doesn't seem to make any difference to the console output.
Contributor
Author
There was a problem hiding this comment. Just seemed correct to include, but we can drop it I guess |
||
| ignore_errors: yes | ||
|
|
||
| - name: Apply base package overrides | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't the
updates-testingaspect turn out to be a red herring? In this case the problem is that the Fedora CoreOS host image has an olderlibgccfrom an oldergccbuild and thefedorarepository has a newer one, and this trips up therpm install ... gcclater.It seems worth it to include
fedora, because during freezes and right after a release, the ISOs and images might have older builds thanfedora. The problem might go away once a release gets older and newer builds make their way toupdates.More importantly, I don't know if
updates-testingis enabled during therpm-ostree install ...later on Fedora CoreOS Next? Is it? I am guessing that it's not in Stable? If it's not enabled, then there will be a difference between the builds seen byrpm-ostree override replace ...andrpm-ostree install ..., and the problem will be back.I suppose we could find a way to conditionally use
updates-testingdepending on the Fedora CoreOS stream, but my rudimentary Ansible skills are preventing me from conjuring up a quick solution for that. :)So, if you want to fix the current problem with the minimum amount of fuss, and I am fine with that, then we should drop
updates-testing.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But some updates were in
updates-testing(glibc) and some were infedora(libgcc). See the below:output
As for the install step, no
updates-testingisn't instable, but do the repos here not mean thatupdates-testingis being used innext?Could you explain where the difference would come from on
stableeven? Theupdates-testingrepo just fails:Apologies if I'm misunderstanding anything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this also shows we still need
updates-testing:output
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A quick reply to one of your questions, because I am running short on time.
As far as I can make out, the
glibcbuilds inupdates-testingaren't causing problems here. Those are missing updates and the CI will run with what's infedoraandupdates-testing.The problem here is that the
libgccin the Fedora CoreOS Next image is older than thegccin thefedorarepositories, and an attempt torpm-ostree install gccfails due to this mismatch. Probably, because the image was created from an older snapshot of builds, and just this gets it going:$ rpm-ostree override replace --experimental --from repo=fedora libgccSee #1851 for a full CI run with logs. Of course, we can't literally do what's in that throwaway PR. It's just a demo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not entirely sure why the CI ends up behaving differently than #1847 (comment) (maybe different
nextimage) but I think the output in that comment shows that it can be an issue if we don't take updates fromupdates-testing