Fedora template update (over Tor) error in 4.2

Hello, I’m using Qubes 4.2 with template updates over Tor enabled. I received the error message below while doing the updates. I’ve never heard of that website and it doesn’t show up on search engines but looks like it’s legitimate. The links are http and not https and when I tried accessing those two links using a VPN I got 404s but there are other files in their repodata directory. Do you think this might be the Tor exit node doing a MITM trying to send me a fake xml file but it was unsuccessful because the update tool didn’t accept it?

Updating fedora-38-xfce

Error: Failed to download metadata for repo 'updates': Yum repo downloading error: Downloading error(s): repodata/aec97418cb2a92e94c512675a8c4267ce305163f814f8fe000b8c6dcaaf91ff4-primary.xml.zck - Download failed: Curl error (23): Failed writing received data to disk/application for http://fedora.ip-connect.info/linux/updates/38/Everything/x86_64/repodata/aec97418cb2a92e94c512675a8c4267ce305163f814f8fe000b8c6dcaaf91ff4-primary.xml.zck [Failure writing output to destination]; repodata/4254414dffd192e25a9441265c7452101ef4a1ecb8a4b1031a32b4539a9f606b-filelists.xml.zck - Download failed: Curl error (23): Failed writing received data to disk/application for http://fedora.ip-connect.info/linux/updates/38/Everything/x86_64/repodata/4254414dffd192e25a9441265c7452101ef4a1ecb8a4b1031a32b4539a9f606b-filelists.xml.zck [Failure writing output to destination]

1 Like

This becomes more and more annoying and raises conspiracy theories against majors. I just can’t update basically no fedora>= v40 over tor with this esact error, for months now… And we are talknig about privacy and anonymity here…

No need for a a conspiracy theory.

Fedora mirrors are always in a poor state in my experience.
But Fedora 38 was eol 2024-05-21, and the repo contents moved to
archive
If you must insist on using Fedora 38 then you will have to update
your repo definitions accordingly.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

Thanks. You probably missed the part “>=v40”. No one persistentnly, actually, answers if they can update fedora over tor… Which raises conspiracy even more… Especially, stock fedora and the first update… I cannot manage to do that.

If that helps you: I have no issues with updating Fedora over tor.

Ah, finally. So where to look for this error, any idea? I’m using apt-cacher-ng too, obviously… And it works for all other distros, including dom0 (well that one is not relevant regarding cacher, I know)…

Also, it would help if you could confirm that you are able to update stock fedora over tor when first update is.

You’re right. I answered specifically to your first complaint.

On this general question, I can update Fedora templates over Tor on
first update, using apt-cacher-ng or tinyproxy.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

Then you must be an asset, hahaha. Just kidding, do I have to emphasize that at all? I’m just lost where to look for…

At the bidding of my deep state overlords I have opened a case file on
you.
Can you tell me how your updates are configured for the Fedora
templates.
What update server are you using?
What is the content of the qrexec policy files?
Do you have any other policy files that impact updates?

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

2 Likes

Please ask the overlords to let me prepare my response properly, and to bring it then only! Should I bring my tin foil hat with it?

Here’s output, first:

Summary

Updating and loading repositories:
Qubes OS Contrib Repository for VM (updates-testing) 100% | 1.4 KiB/s | 1.5 KiB | 00m01s
Qubes OS Contrib Repository for VM (updates) 100% | 4.2 KiB/s | 1.5 KiB | 00m00s
RPM Fusion for Fedora 41 - Free tainted 100% | 3.0 KiB/s | 4.0 KiB | 00m01s
RPM Fusion for Fedora 41 - Free 100% | 4.9 KiB/s | 4.3 KiB | 00m01s
RPM Fusion for Fedora 41 - Free - Test Updates 100% | 3.3 KiB/s | 3.7 KiB | 00m01s
RPM Fusion for Fedora 41 - Free - Updates 100% | 8.9 KiB/s | 3.7 KiB | 00m00s
RPM Fusion for Fedora 41 - Nonfree tainted 100% | 8.3 KiB/s | 3.0 KiB | 00m00s
RPM Fusion for Fedora 41 - Nonfree - Updates 100% | 9.7 KiB/s | 3.7 KiB | 00m00s
RPM Fusion for Fedora 41 - Nonfree - Test Updates 100% | 9.8 KiB/s | 3.7 KiB | 00m00s
Fedora 41 - x86_64 - Updates 100% | 140.8 KiB/s | 814.3 KiB | 00m06s

At least one of the zchunk checksums doesn’t match in http://mirror.accum.se/mirror/fedora/linux/updat
At least one of the zchunk checksums doesn’t match in http://mirror.accum.se/mirror/fedora/linux/updat
Fedora 41 openh264 (From Cisco) - x86_64 100% | 2.4 KiB/s | 6.0 KiB | 00m02s
RPM Fusion for Fedora 41 - Free tainted 100% | 4.0 KiB/s | 9.0 KiB | 00m02s
Qubes OS Repository for VM (updates) 100% | 2.3 KiB/s | 2.8 KiB | 00m01s
Librepo error: repomd.xml GPG signature verification error: Signing key not found
RPM Fusion for Fedora 41 - Free - Test Updates 100% | 7.4 KiB/s | 13.5 KiB | 00m02s
Qubes OS Repository for VM (updates-testing) 100% | 4.3 KiB/s | 2.8 KiB | 00m01s
Librepo error: repomd.xml GPG signature verification error: Signing key not found
Qubes OS Repository for VM (unstable) 100% | 2.2 KiB/s | 1.8 KiB | 00m01s
Status code: 404 for http://HTTPS///yum.qubes-os.org/r4.2/unstable/vm/fc41/repodata/repomd.xml (IP: 12
Status code: 404 for http://HTTPS///yum.qubes-os.org/r4.2/unstable/vm/fc41/repodata/repomd.xml (IP: 12
Status code: 404 for http://HTTPS///yum.qubes-os.org/r4.2/unstable/vm/fc41/repodata/repomd.xml (IP: 12
Status code: 404 for http://HTTPS///yum.qubes-os.org/r4.2/unstable/vm/fc41/repodata/repomd.xml (IP: 12
Librepo error: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
RPM Fusion for Fedora 41 - Free - Updates 100% | 68.8 KiB/s | 83.6 KiB | 00m01s
RPM Fusion for Fedora 41 - Nonfree tainted 100% | 8.4 KiB/s | 5.0 KiB | 00m01s
Fedora 41 - x86_64 100% | 127.7 KiB/s | 460.6 KiB | 00m04s
At least one of the zchunk checksums doesn’t match in http://mirror.bahnhof.net/pub/fedora/linux/relea
Error loading local metadata for repository “fedora”
Librepo error: Checksum error /var/cache/libdnf5/fedora-12130a5465b649ea/repodata/3973367e3877b70900ae12d5074f025c99015ab5bc829d2cfbf6fa5d7a0cd0e2-primary.xml.zck: Unable to validate zchunk checksums

repos:

Summary

[fedora]
name=Fedora $releasever - $basearch
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
metalink=http://HTTPS///mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch&protocol=http
#metalink=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch&protocol=http
enabled=1
countme=1
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

[fedora-debuginfo]
name=Fedora $releasever - $basearch - Debug
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Everything/$basearch/debug/tree/
metalink=http://HTTPS///mirrors.fedoraproject.org/metalink?repo=fedora-debug-$releasever&arch=$basearch&protocol=http
enabled=0
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

[fedora-source]
name=Fedora $releasever - Source
#baseurl=http://download.example/pub/fedora/linux/releases/$releasever/Everything/source/tree/
metalink=http://HTTPS///mirrors.fedoraproject.org/metalink?repo=fedora-source-$releasever&arch=$basearch&protocol=http
enabled=0
metadata_expire=7d
repo_gpgcheck=0
type=rpm
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
skip_if_unavailable=False

policies are ok, they work for all other wubes, nothig should impact f41. It’s basically “set it and forget it”…
No cleaning helps. No service restarting helps. No cacher qubes restarting helps. I just can’t update fedora for the first time over tor.

I thought you would already have it on.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

There’s a few things going on here.
You can address the repeated zchunk errors, by adding this to
/etc/dnf/dnf.conf in the templates:
zchunk=False

I’ve made this a default in the cacher package for a while.

The 404 errors are because Qubes “unstable” does not have a vm
section. You should not use that.

Yep, I put it there for the future, set it and forget it for the times when it will be available and set “skip if unavailable”…

[quote=“unman, post:14, topic:24248”]
You can address the repeated zchunk errors, by adding this to
/etc/dnf/dnf.conf in the templates:
zchunk=
[/quote!
Well, it was too much “set it and forget it”-s, because I forgot that one completely too! That was it, thanks @unman!