Repository navigation
playbooks/depencies-fedora-coreos: add a fallback to the updates-testing repo - #1847
Rolv-Apneseth wants to merge 2 commits into
Conversation
2773b57 to
51c1a42
Compare
51c1a42 to
9cc2e16
Compare
There was a problem hiding this comment.
Thanks for putting this together, @Rolv-Apneseth ! I don't think I understand the details of Fedora CoreOS Next, so let me ask what might be a stupid question. Does CoreOS have different updates and updates-testing repositories than the usual Fedora ones? If not, then I am a bit confused about what's going on.
First, we have these:
$ rpm-ostree override replace --experimental --from repo=updates glibc ...
...
error: No matches for 'glibc' in repo 'updates'
$ rpm-ostree override replace --experimental --from repo=updates shadow-utils
...
error: No matches for 'shadow-utils' in repo 'updates'From what you wrote, it seems that this is related to Fedora 45 being in Final Freeze from the 6th of October, which has caused some package updates to be stuck in the updates-testing repository. That makes sense, and explains the above based on what I can see in Bodhi and Koji.
These errors aren't fatal, because we are using ignore_errors: yes for those in the Ansible playbook.
Second, we have:
$ rpm-ostree install --allow-inactive --apply-live --assumeyes --idempotent gcc
...
error: Could not depsolve transaction; 1 problem detected:
Problem: libgcc-16.2.1-2.fc45.1.i686 from fedora does not belong to a distupgrade repository
- package gcc-16.2.1-2.fc45.1.x86_64 from fedora requires libgcc >= 16.2.1-2.fc45.1, but none of the providers can be installed
- cannot install both libgcc-16.2.1-2.fc45.1.x86_64 from fedora and libgcc-16.2.1-2.fc45.x86_64 from @System
- conflicting requestsThis is the part I don't understand, and this error is fatal because we don't use ignore_errors: yes for it.
The gcc-16.2.1-2.fc45.1 build was pushed to stable five days ago, and both the gcc and libgcc binary packages are built from the same gcc source. So, how can gcc and libgcc have a broken dependency chain between them? :)
Anyway, if the CI passes, then that's the final word. :)
|
So, I'm picking this up as I go, but my understanding is:
They are the same.
So for the install step, any package already installed on the system can't be updated automatically due to how rpm-ostree works, which is why we have the override steps. And we ignore the errors in case there are no updates. But you're right to ask, I missed the fact it's |
|
I think coreos/rpm-ostree#4708 would make things a lot easier here |
Thanks for explaining that detail about
Yes, if Take a step back from this specific problem, I am wondering if there's ever a valid reason for the |
9cc2e16 to
4d86f14
Compare
|
Trying something different, we'll see how CI goes.
I'm afraid I don't know. I don't have enough knowledge on the topics of Fedora package repos. |
|
Ok, seems like the fallbacks are working as expected in https://gateway-cloud-softwarefactory.apps.ocp.cloud.ci.centos.org/zuul/t/local/build/91b9e465a1264a79bff668732ab506af/log/job-output.txt: outputHowever, looks like there's another issue in the |
debarshiray
left a comment
debarshiray
left a comment
There was a problem hiding this comment.
If libgcc is in the Fedora CoreOS host image, and it breaks rpm-ostree install ... gcc because it's older than the version in the repositories, then wouldn't it be enough to just do:
diff --git a/playbooks/dependencies-fedora-coreos.yaml b/playbooks/dependencies-fedora-coreos.yaml
index d676cb9f4175..27e7f5862134 100644
--- a/playbooks/dependencies-fedora-coreos.yaml
+++ b/playbooks/dependencies-fedora-coreos.yaml
@@ -22,6 +22,7 @@
glibc-common
glibc-minimal-langpack
glibc-gconv-extra
+ libgcc
ignore_errors: yes
- name: Synchronize shadow-utils to repo version for shadow-utils-subid-devel compatibility
Completely untested, because I didn't want to step on your toes.
Looks like this is coreos/fedora-coreos-tracker#2238 - can maybe be fixed in systemd, but likely will be a change needed on our side. If you want to move forward here, I think
We want them separate because a lack of an update in one package will fail the whole command, so we can only really group packages that are from the same SRPM. The current changes seem to pass that stage without issues, if you're happy with them? |
Sounds good to me, yes. Do you want to throw a patch in here?
Aha, I didn't know that. |
Sure yes, I'm working on understanding the upstream issue |
…ng and fedora repos When trying to replace the existing versions of some base Fedora CoreOS packages, we had repo=updates hard-coded. However, while the `next` stream is pointing at a pre-release version, updates are either in repo=updates-testing or repo=fedora. Let's add some fallback logic to avoid failures when this is the case. Signed-off-by: Rolv Apneseth <rolv.apneseth@gmail.com>
As of systemd v261, bare `systemd-tmpfiles --create` calls now attempt to set permissions on / on systems which are not set to 0o555. This currently fails on Fedora CoreOS systems due to them having the incorrect permissions set while also having a read-only root filesystem. This leads to the following error: fchmod() of / failed: Read-only file system Since both entries in data/tmpfiles.d/toolbox.conf are under /run, it's safe for us to restrict these calls to this directory with --prefix=/run in order to avoid that issue on FCOS. See: coreos/fedora-coreos-tracker#2238 Signed-off-by: Rolv Apneseth <rolv.apneseth@gmail.com>
4d86f14 to
23a2a2b
Compare
|
Rebased and pushed a commit for that @debarshiray. Hopefully that lets the CI here avoid the issue. |
This branch has not been deployed
2 participants
When trying to replace the existing versions of some base Fedora CoreOS packages, we had repo=updates hard-coded. However, during branching, the
nextstream will only have updates from repo=updates-testing, so let's add a fallback to avoid failures when this is the case.Testing if this resolves the issues seen in #1846. Note that we need that merged first, then I'll rebase this.