Tool: Simple Set-up of New Qubes and Software

@unman

Its interesting that I do not have this error at each update attempt, and it makes me wonder if, for my own use case, it would make sense to have cacher being a disposable qube to resolve the pool always increased usage problem, to get rid of that particular error that randomly hits me, considering that I barely ever install templates updates in different boot sessions of Qubes OS and that I use mainly cacher to economize bandwidth downloading the same packages across specialized templates.

Let me try to update Fedora now:
[user@fedora-36-current ~]$ sudo dnf update

Fedora 36 openh264 (From Cisco) - x86_64        0.0  B/s |   0  B     00:01    
Errors during downloading metadata for repository 'fedora-cisco-openh264':
  - Curl error (56): Failure when receiving data from the peer for https://codecs.fedoraproject.org/openh264/36/x86_64/os/repodata/repomd.xml [Received HTTP code 403 from proxy after CONNECT]
Error: Failed to download metadata for repo 'fedora-cisco-openh264': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Fedora 36 - x86_64 - Updates                     52 kB/s | 7.6 kB     00:00    
Qubes OS Repository for VM (updates)            959  B/s | 833  B     00:00    
Ignoring repositories: fedora-cisco-openh264
Dependencies resolved.
Nothing to do.
Complete!

Mental note to come back here when I get the error again in the future. From network speed above, I can tell that the package list was downloaded from upstream servers, not cacher’s cache. So the error didn’t happen. The zchunk errors happens where there is a discrepency between the cache content, downloaded from cacher as opposed to what is locally kept under Fedora’s template.

From memory:

  • Doing a sudo dnf clean all in template sometimes helps.
  • Purging cacher’s unreferenced files (you have to tick option in webui) normally resolves the issue if combined with previous step.

But doing so removes what was cached, unless you tick each zchunk file individually. I’m not sure as of today, even after having read apt-cacher-ng documentation, why there would be a discrepency between Fedora’s template cache (clean all wipes it), cacher’s cache and upstream repositories. My hypothesis here is that a different mirror, containing different files is being hit and apt-cache-ng just provides that cache to Template which doesn’t match. Why? No clue!