I think I have an issue similar to this, but I updated dom0 and rebooted everything multiple times to no avail. Shouldn’t it be fixed at this point or the root cause is different in my case?
Overall symptoms are very similar: app qubes and disposables have the internet connection while the templates do not. One difference is that debian templates also have no internet connection.
The error in fedoras:
ID: notify-updates
Function: cmd.run
Name: /usr/lib/qubes/upgrades-status-notify
Result: False
Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
Started: 17:59:28.917228
Duration: 2185.83 ms
Changes:
----------
pid:
1205
retcode:
1
stderr:
Error: Failed to download metadata for repo 'updates': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f38&arch=x86_64 [Proxy CONNECT aborted]
The error in debians:
ID: update
Function: pkg.uptodate
Result: False
Comment: E: Failed to fetch https://deb.debian.org/debian/dists/bookworm/InRelease Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]
E: Failed to fetch https://deb.debian.org/debian-security/dists/bookworm-security/InRelease Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]
E: Failed to fetch https://deb.qubes-os.org/r4.2/vm/dists/bookworm/InRelease Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]
E: Some index files failed to download. They have been ignored, or old ones used instead.
Started: 04:22:43.661335
Duration: 8491.459 ms
Changes:
I haven’t tried the workarounds from the related github issue yet.
I observed the same behavior for my Fedora-39 template under R4.2.1, as long as sys-net is based on Fedora-39. If sys-net is based on Debian-12, the update works.
As suggested in the earlier problem, I have added the line Allow ::1 to etc/tinyproxy/tinyproxy-updates.conf , but this does not affect the current error.
Have that problem also. I have found, that the qubes-update-proxy service in sys-net does not start timely.
Current workaround: Open a terminal on sys-net.
sudo systemctl status qubes-update-proxy (to check, if the service is started correctly, if not, go to next command)
sudo systemctl restart qubes-update-proxy
sudo systemctl status qubes-update-proxy (to check, if the service is started correctly)
Then you can close the terminal and the update should work.
I have no clue currently, why the qubes-update-proxy service does not start during start of the sys-net qube, nevertheless, the service is marked in the settings - service tab as selected.
B.t.w, i have that problem in fedora- and debian based sys-net service qubes.
Looks like I have the same problem, but I still stucked with it. If I try your workaround to restart the update proxy, I’m getting the following message:
Failed to restart qubes-update-proxy.service: Unit qubes-update-proxy.service not found. What sounds creepy!
Indeed! Now I was able to restart it, it’s status is running, but the problem still persists, I have the same error when I attempt updating my templates.
Here it is (I redacted parts what I though might be too specific information about my VM - however, maybe I redacted the ones I actually shouldn’t, just let me know if that is the case):
However, I realised one more thing: in my global settings / updates, Dom0’s update proxy is set up to sys-firewall. If I remember correctly, it was originally sys-net and I modified this to the firewall when I was a newbie because I thought that would be a good idea. Is this might be part of the problem?