Here we go again with sys-cacher

[SteveC]

Again, I try to rebuild a template–one that that I built a few days ago.

Only now I cannot “connect” trying to get to the repositories. Why? Who knows?

I find these random errors trying to install packages very frustrating. Particularly since the package I am trying to install doesn’t even “live” in these repositories, but apt install INSISTS that it won’t do anything until it downloads the entire effing list of what’s in the repositories. It might be two whole days out of date. Better to have no VM at all than that!

2025-11-01 17:19:29,033 output:      Comment: An error was encountered while installing package(s): E: Failed to fetch http://HTTPS///deb.debian.org/debian/dists/bookworm/InRelease  500  Unable to connect [IP: 127.0.0.1 8082]
2025-11-01 17:19:29,033 output:               E: Failed to fetch http://HTTPS///deb.debian.org/debian-security/dists/bookworm-security/InRelease  500  Unable to connect [IP: 127.0.0.1 8082]
2025-11-01 17:19:29,033 output:               E: Failed to fetch http://HTTPS///deb.debian.org/debian/dists/bookworm-backports/InRelease  500  Unable to connect [IP: 127.0.0.1 8082]
2025-11-01 17:19:29,033 output:               E: Failed to fetch http://HTTPS///deb.qubes-os.org/r4.2/vm/dists/bookworm/InRelease  500  Unable to connect [IP: 127.0.0.1 8082]
2025-11-01 17:19:29,033 output:               E: Some index files failed to download. They have been ignored, or old ones used instead.

If only that last line were true. Yes, please ignore.

[solene]

Your template does not seem to use sys-cacher to get the updates.

If this is too annoying for you because things break, do not use sys-cacher.

[SteveC]

Indeed, somehow my policy file got borked.

(There’s something squirrely about qubes-global-config…if that particular file doesn’t have an EXACT set of contents to it, it will complain about unsaved edits whenever you switch off that page. As it happens, I sometimes install personally-built libraries into dvm templates; that won’t work unless I add AppVM as an allowed user of the cacher to the policy file–but then qubes-global-config complains about it. I must have hit the wrong button a few days ago and wiped that out.

However, all attempts to fix it now fail, with the same error.

I even tried removing the cacher entirely. It’s going to https: (not HTTPS) now, and STILL failing. [EDIT: I need to set the proxy to sys-net, not sys-firewall; then it works. The cacher still won’t no matter how I set the policy file.]

I will take your advice, though: Once I get this template to build, I am going to burn the damn cacher. It has been more trouble than it is worth.

[andreasglashauser]

@SteveC

It has been more trouble than it is worth.

This was also my experience. When it worked, it was great - unfortunately it did not work consistently and debugging cost me way more time (and nerves) than without it.

[unman]

This was also my experience. When it worked, it was great - unfortunately it did not work consistently and debugging cost me way more time (and nerves) than without it.

Shame.
I find that apt-cacher-ng works flawlessly, (bar Fedora mirrors needing
regular updating), and have somewhere north of 150 users with it
installed.
Could you say how you installed it, and what issues you faced?

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

[andreasglashauser]

@unman

Could you say how you installed it, and what issues you faced?

Sys-apt-cacher-ng always fails on specific qubes

I compared the repo definitions but found nothing interesting. I even reinstalled debian-13-minimal but the error still occured. I already set the Debug level to the max level. I regret doing this now (because I would be very interested in why this error occured out of nowhere?) but I deleted sys-apt-cacher-ng out of frustration and set it up again with my saltstack states (so its 1:1 the same) and now it works again. The only error that still occurs and that I get quite often is when updati…

My last comment was that i post again if the error occurs again. I am not sure if i posted again, however this occurred again and again in different templates. I tried rebooting my cacher and sys-whonix and the error would still be there. Next day after rebooting and updating again it would work.

This was really annoying. Fast updates were awesome, but the inconsistency made it unusable for me.

Besides of the tutorials that are there on this forum I additionally tried lots of things but never made it work.

I setup everything via saltstack, so I should be able to reproduce this. The most interesting states to keep it clear:

file 50_user.conf:

binds+=( '/var/cache/apt-cacher-ng' )
binds+=( '/var/log/apt-cacher-ng' )
binds+=( '/etc/anacrontab' )

file acng.conf:

...
Port:8082
...
Remap-alxrep: file:archlx_mirrors file:archlx_mirrors_extra   /archlinux
Remap-blackarch: file:blackarch_mirror-list  /blackarch
Remap-debrep: file:deb_mirror*.gz file:debian_mirrors_extra /debian ; file:backends_debian # Debian Archives
Remap-fedrep: file:fedora_mirrors file:fedora_mirrors_extra ; https://mirrors.kernel.org/fedora/ https://ftp-stud.hs-esslingen.de/pub/fedora/linux/  # Fedora Linux
Remap-uburep: file:ubuntu_mirrors /ubuntu ; file:backends_ubuntu # Ubuntu Archives
Remap-Qubes: file:Qubes_mirrors
Remap-klxrep: file:kali_mirrors /kali ; file:backends_kali # Kali Linux Archives
Remap-cygwin: file:cygwin_mirrors /cygwin # ; file:backends_cygwin # incomplete, please create this file or specify preferred mirrors here
Remap-sfnet:  file:sfnet_mirrors # ; file:backends_sfnet # incomplete, please create this file or specify preferred mirrors here
Remap-epel:   file:epel_mirrors # Fedora EPEL
Remap-slrep:  file:sl_mirrors # Scientific Linux
Remap-gentoo: file:gentoo_mirrors.gz /gentoo ; file:backends_gentoo # Gentoo Archives
Remap-secdeb: https://security.debian.org https://security.debian.org/debian-security https://deb.debian.org/debian-security /debian-security cdn-fastly.deb.debian.org/debian-security #; deb.debian.org/debian-security security.debian.org cdn-fastly.deb.debian.org/debian-security
...
PassThroughPattern: ^dl\.flathub\.org:443$
PassThroughPattern: ^(extrepo-team\.pages\.debian\.net|salsa\.debian\.org):443$
PassThroughPattern: ^(codecs\.fedoraproject\.org):443$
Proxy: http://127.0.0.1:8118

file config.sls:

{% if grains['id'] == 'tpl-sys-apt-cacher-ng' %}

template-sys-apt-cacher-ng--mask:
  service.masked:
    - name: apt-cacher-ng

template-sys-apt-cacher-ng--mask-privoxy:
  service.masked:
    - name: privoxy

template-sys-apt-cacher-ng--configure:
  file.managed:
    - name: /etc/apt-cacher-ng/acng.conf
    - source: salt://sys-apt-cacher-ng/files/acng.conf
    - user: root
    - group: root
    - makedirs: True

template-sys-apt-cacher-ng-privoxy:
  file.append:
    - name: /etc/privoxy/config
    - text: forward-socks5t / 10.152.152.10:9153 .

'chown -R apt-cacher-ng:apt-cacher-ng /var/cache/apt-cacher-ng':
  cmd.run

'chmod -R a+rX,g+rw,u+rw /var/cache/apt-cacher-ng':
  cmd.run


{% endif %}

[SteveC]

Case in point: When I was ranting mad about the cacher earlier in this topic, I deactivated it on my laptop but left it on my desktop.

Today, I’m trying to rebuild some templates and appvms. I lost connectivity for about ten minutes (I think) and of course the cacher was unable to connect.

The problem is it CONTINUED to be “unable to connect” even after my connection came back up. I even restarted the cacher, sys-firewall, and sys-net (though I should not have had to). I tried multiple times, but it was “unable to connect” for absolutely no apparent reason.

As soon as I reconfigured that template to not use the cacher, it worked.

Time to burn it off my desktop too.

I’m done with this flaky piece of junk.

[unman]

@SteveC of course, if some software isnt working for you you should
stop using it. The same goes for Qubes itself. I dont think it warrants
announcements to the forum.

I would say that apt-cacher-ng is used by many folk without issue,
and just sits there doing its job. Many of these have used my packaged
version without a problem, and of course, I eat my own dog food. If it
didnt work I would not promote it.

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

[Euwiiwueir]

Another note of support and approval here- I built my^[1] apt-cacher-ng qube perhaps two years ago now and have never had any major^[2] issues with it. I’m expecting one day it will fill its volume and I’ll have to clear the .deb cache but that’s simple enough.

---

1. reverse engineered from inspection of unman’s cacher RPM ↩︎

2. I gave up on using it for Fedora templates but I understand the issue there is not really the fault of apt-cacher-ng. Anyway my templates are mostly apt/deb based so it’s but a small sacrifice for me. ↩︎

[SteveC]

I posted in part thinking that there might be a clue here…but at 1AM after repeated tries over the course of an hour, I simply didn’t have the time or patience to pursue it.

Apparently when the network went down the cacher got stuck in a state where it was convinced the network was down, even when it came back up. (And yes I could ping debian.org from the cacher qube, but apparently the cacher could not do anything anyway.) Unfortunately that state persisted across a restart of cacher.

For those (like @Euwiiwueir) who have no difficulty with it, good! I hope you continue to have success with it.

But this is not my first time dealing with apparently-arbitrary failures (including having it work on second attempts with no apparent reason for the first failure (at least that one’s easy to overcome!) and times when it will work for one VM but not for another…for no apparent reason, and no matter how often one re-tries it).

At least someone in my shoes might read this and feel that it’s OK to stop using it.

@Euwiiwueir you did a reverse engineering…successfully. I did one too, but apparently not with complete success. (It usually does work.) I am surprised you think it needs to be “emptied.” Does it not do so automatically? And if not, shouldn’t it? (I doubt this is my issue; I’ve often-enough re-created it from scratch.)

[Euwiiwueir]

@SteveC

I am surprised you think it needs to be “emptied.” Does it not do so automatically? And if not, shouldn’t it? (I doubt this is my issue; I’ve often-enough re-created it from scratch.)

I just checked my qube and it’s nowhere near full, so perhaps you’re right and it does itself do some kind of LRU cache clearing.