Hi. I’m having exactly the same problem. Running rpm-ostree cleanup --repomd and rpm-ostree refresh-md does nothing – I just get the same Curl error (23) as the op.
this is a relatively new install of silverblue (though the iso was maybe a touch stale). I did manage to install some packages but for some reason any further actions fail with the exact same error:
error: Updating rpm-md repo 'fedora': cannot update repo 'fedora': Yum repo downloading error: Downloading error(s): repodata/bb982fe525c17f348b8f9b8fe7c5a07b38baca7718ac1d790d341ee6b21343b3-comps-Everything.x86_64.xml.zck - Download failed: Curl error (23): Failed writing received data to disk/application for http://creeperhost.mm.fcix.net/fedora/linux/releases/37/Everything/x86_64/os/repodata/bb982fe525c17f348b8f9b8fe7c5a07b38baca7718ac1d790d341ee6b21343b3-comps-Everything.x86_64.xml.zck [Failure writing output to destination]; Last error: Curl error (23): Failed writing received data to disk/application for http://creeperhost.mm.fcix.net/fedora/linux/releases/37/Everything/x86_64/os/repodata/bb982fe525c17f348b8f9b8fe7c5a07b38baca7718ac1d790d341ee6b21343b3-comps-Everything.x86_64.xml.zck [Failure writing output to destination]
I’ve tried hard-coding a different repo with the same result. I’m at a loss. It could be a bug with the local packages but obviously I can’t update them.
This is the second install of silverblue and the second time I’ve hit exactly the same problem.
I’ve tried rpm-ostree upgrade even rpm-ostree rebase all to no avail. Restarting has no effect either.
Curl-ing the URL that causes the problem gives a 200 OK so it’s not that the file is missing.
journalctl -xe shows the same error, so I can’t give you any more info. Any help greatly appreciated.
(oh and df -h shows a lot of free space) – like I say it’s new install that hasn’t had a chance to accumulate cruft)
Ok. So I’ve figured out the problem. My mobile broadband provider provides a content block to prevent access to 18+ sites by default.
Seems this content block is extremely bad at its job. e.g. I tried to access the documentation for distrobox at https://distrobox.privatedns.org/ and it blocked the site.
So turning this block off has fixed my problems. The weird thing was that just directly curling the problematic urls from the terminal worked fine (and the received files matched their expected SHAs). so something extremely non-obvious was going on.
Reminds me of the days I spent trying to debug network problems on a freebsd box only to realise that all the issues were due to a dodgy ethernet cable.
Some of the mirrors have extremely weird hostnames, e.g. http://creeperhost.something.something to the point where I freaked out and checked what was going on myself by looking at the list of mirrors. This may have contributed, but as I say, I was able to manually curl the files, so actually no idea.
Still, I think rpm-ostree could have done a better job of letting me know what was happening. “curl error (23)” isn’t particularly productive.
Non-encrypted protocols are known to be vulnerable to traffic spoofing, specifically plain DNS and HTTP, and even encrypted protocols can suffer from DPI and IP based content filtering.
It’s good practice to try an alternative ISP or better VPN to isolate network-related issues.
Hi Garry, Thanks for posting about this. I think this is the only post online to have identified this issue.
I have been having almost the same error as OP for some time on my Silverblue 36 machine. I am also using a mobile data connection.
Are you able to post some detail on how you fixed your system with manual curl? For example, did you need to identify and download all of your layered packages or just the fedora one?
Searching the disk, I think it is trying to write to /var/cache/rpm-ostree/repomd/updates-36-x86_64/repodata/ but it’s hard to be certain because the error doesn’t provide that information.
Error:
error: Updating rpm-md repo 'fedora': cannot update repo 'fedora': Yum repo downloading error: Downloading error(s): repodata/cd4101d88f0f384899265e0677fb70a7d9e5bdf9f3da89b36bf39b6ade52c93f-comps-Everything.x86_64.xml.zck - Download failed: Curl error (23): Failed writing received data to disk/application for http://creeperhost.mm.fcix.net/fedora/linux/releases/36/Everything/x86_64/os/repodata/cd4101d88f0f384899265e0677fb70a7d9e5bdf9f3da89b36bf39b6ade52c93f-comps-Everything.x86_64.xml.zck [Failure writing output to destination]; Last error: Curl error (23): Failed writing received data to disk/application for http://creeperhost.mm.fcix.net/fedora/linux/releases/36/Everything/x86_64/os/repodata/cd4101d88f0f384899265e0677fb70a7d9e5bdf9f3da89b36bf39b6ade52c93f-comps-Everything.x86_64.xml.zck [Failure writing output to destination]
Are you able to post some detail on how you fixed your system with manual curl?
I wasn’t able to fix the problem with curl. I just did some investigation of the URL in question manually using curl, to see if there was some problem with the URL or host.
The weird thing was that downloading manually worked perfectly…
The fix that let me update the system was to turn off the adult content filter on my mobile broadband plan.
I was able to verify that the problem was with this filter by turning on a vpn to verify that the update worked once I passed all my traffic through the VPN, avoiding any filtering by the broadband provider.
So if you have a vpn I’d suggest turning that on or disabling any content blockers on your broadband.
If you could force HTTPS connections to the repos that would work too I think (unless your provider blocks the host at the DNS level) but I have no idea how to do that.
I have tested on a connection without content filtering and found no improvement. Although, it was a virtual mobile provider, using the same network as my main connection, so whatever trickery they’re using on their NAT is probably the same regardless of content filtering.
That “creeperhost” mirror name really is unfortunate. I will explore the VPN or force HTTPS ideas.
FYI the problem started re-occurring for me even though i’d been updating without problem for a while.
I found a workaround I think by selecting for https mirrors.
The trick is to append &protocol=https to the metalink url in the .repo file of the repo that’s failing. so for me the fix was to edit /etc/yum.repos.d/fedora.repo and set the metalink line to: