That would work for the dnf command. However, this system is an ostree based system which has configuration files in /etc/ostree/remotes.d/. See the man page for ostree.repo-config by running man ostree.repo-config.
There seems to be only that one download site at the moment, but someone actually involved in maintaining the ostree infrastructure may have the actual information on how this works.
Found a workaround that seems to be working so far: rebase to the equivalent ublue image.
The issue is that youâd need to first install their ublue-os-signing package.
To do so, I used the command I found somewhere, but I couldnât find it again to link here:
podman pull ghcr.io/ublue-os/config && rpm-ostree install --assumeyes \
--apply-live --force-replacefiles \
$(find ~/.local/share/containers -name ublue-os-signing.noarch.rpm 2>/dev/null) \
&& rpm-ostree rebase --uninstall $(rpm -q ublue-os-signing-* --queryformat \
'%{NAME}-%{VERSION}-%{RELEASE}.%{Arch}') \
ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:stable
Replace the last bit bluefin-dx-nvidia:stable with the image you want to use from Packages ¡ Universal Blue ¡ GitHub
EDIT: trying to adjust the command to work on copy and paste. If it doesnât, try removing the \ and the line breaks to make it one-liner.
uhm, what about refreshing the metadata?
rpm-ostree refresh-md
if that does not work use
rpm-ostree refresh-md --force
This method is easier, it is the old one
I had the same problem for several days. The following steps worked for me:
Somehow the problem got solved during the preview
The issue seems to be solved now
Unfortunately Iâm still getting the same error here.
error: While pulling fedora/41/x86_64/kinoite: While fetching https://d2uk5hbyrobdzx.cloudfront.net/objects/be/35ee772cffa28a93724aeba57535d8eb026546120860fb5389ca4118197645.filez: Server returned HTTP 502
Iâm still having the issue as well.
Maybe itâs a coincidence, but it worked for me too.
rpm-ostree upgrade --preview
rpm-ostree rebase fedora:fedora/41/x86_64/sericea
Neither of those worked for me.
I know itâs the weekend, but this was a problem before then. Have we had any confirmation that this is being addressed by someone âofficialâ?
I think the official is still trying to triage the issue.
The 404 I mention is on the local side. The file doesnât exist there at all. So, it tells cloudfront â404â and cloudfront tells the client â502â.
Itâs not a matter of load, it just simply doesnât have the file, so it canât serve it.
Why itâs telling clients to fetch that file I donât know, will need to get folks that know ostree to look.
In case you want to follow along:
With the information from Issue #12427: Server returns HTTP 502 when trying to rollback Fedora Silverblue - fedora-infrastructure - Pagure.io I came up with a workaround that seems to work better.
Edit /etc/ostree/remotes.d/fedora.conf (make a backup copy first, just in case)
Change the line that starts with url= to
url=https://kojipkgs.fedoraproject.org/ostree/repo/
Just in case, comment the line with content=mirrolist... by adding a #in the beginning of that line.
It worked for me on a test environment I created for Kinoite 41.
For me, in Poland, Silverblue 41 is working normally with no need for this workaround.
Whatâs the difference between whatâs hosted on ostree.fedoraproject.org and kojipkgs.fedoraproject.org? Iâm affected by this bug and havenât been able to update my system since last Wednesday. Iâm interested in trying out this workaround, but would like to know what the possible implications are from changing the remote url.
Does that server have the capacity if everyone did that?
Not really, and itâs only in one location in the US, unlike the normal
cloudfront nodes that are all over the world.
Itâs seeming like switching, doing an update and then switching back is
working for people, but I donât understand why. ;(
Thank you. This workaround works for me.
I understand the impact on the servers and have switched back to the CloudFront URL.
Before I made the change to /etc/ostree/remotes.d/fedora.conf, rpm-ostree update on Silverblue and Kinoite give:
error: While pulling fedora/41/x86_64/silverblue: While fetching https://d2uk5hbyrobdzx.cloudfront.net/delta-indexes/DC/0O6lDAFVM33LALWc2WOU+yfAr9e7PcbiAWtiSRHGM.index: Server returned HTTP 502
error: While pulling fedora/41/x86_64/kinoite: While fetching https://d2uk5hbyrobdzx.cloudfront.net/delta-indexes/hX/074AAUg00U9XS0UpcduOj_YOdyy3UcHwts1Ki9fmc.index
https://kojipkgs.fedoraproject.org/ostree/repo/delta-indexes/DC/0O6lDAFVM33LALWc2WOU+yfAr9e7PcbiAWtiSRHGM.index and https://kojipkgs.fedoraproject.org/ostree/repo/delta-indexes/hX/074AAUg00U9XS0UpcduOj_YOdyy3UcHwts1Ki9fmc.index also return 404 error.
After updating and switching back to the default/Cloudfront, I can install packages but cannot update again (if I remove the deployment with rpm-ostree cleanup -p && rpm-ostree update, I get the same 502 error).
I dont think it would have. We should make this change only for testing and temporarily. They might even block public access to that Kojipkgs url if they feel like there is too many people using.
Btw, at least to me, the workaround isnât needed anymore. Both my systems (one with Silberblue 41 and another with Kinoite 41 are working fine without that.