You can try this.
These issues happen particularly with “updates” repositories. I think this is
because you are hitting issues with poor mirroring.
They are reported by users not using apt-cacher-ng.
I find in many cases that simply retrying at a later time will work - my
guess is that this is because the mirrors have synced and no other
updates have been pushed in the mean time.
Let me know how you get on.
E.g., Fedora-35-minimal and Fedora-36 updates failed this morning.
Tried again now, and all good.
Ok, thanks. I’ll try on different intervals.
On another note, would it just be easier to run a squid proxy at my firewall? Then I could leverage that for updating other non-qubes systems I have.
Also, just a few minutes later, some started working. Some still fail. So I’ll keep trying the others.
I see that worked for you.
I’m sure this is because of mirror syncing in fedora.
You could get round this by pointing all the Fedora repo calls to a
single server - you do this in the Remap definition. I don’t recommend
that.
Of course, in the associated GitHub discussion,
there are many options, including squid.
I find squid over baked for the purpose, and apt-cacher-ng works well
with minimal overhead. YMMV
Thanks for the github discussion link!
I’ll check it out, as I’ve got one qubes system so far (laptop), but am going to repurpose a server to be my new workstation. Plus I’ve got multiple VMs that would benefit from the rpm/deb caching.
I used to run local repos, but that ended up being even more traffic as I was caching packages I’m not using.
I had to make this change to get Fedora 38 templates to update. Without the change, I always had to manually boot the template to run dnf clean all.
I’m not using shaker but I got to the point where I did copy over the shaker acng.conf and I manually replicated the
update_template salt steps.
For me, it randomly succeeds, regardless of False is set to zchunk or not.
So I totally gave up of not to clean all first…