Instead of manually doing this, enable the updates-proxy-setup service.
2 Likes
How to do so please? A google search did not yield any answer. Thanks!
Template Settings > Services
Thank you, I tried it, does not fix the issue. Must manually do it to fix the UpdateProxy issue.
getting same issue, I’d really like to fix it instead of full reinstall.
1 Like
I experienced similar issues on a recent Kali install that was based on a Debian template. I lost a TemplateVM due to issues others encounter with the Qubes packages and dependencies and the availability (or lack thereof) of the Debian testing branch in Qubes repos (since Kali uses testing).
The tinyproxy service does not appear to be running which causes it to fail; perhaps this could explain why using sys-net address worked for others.
This is not completely definitive but if the system still has the Qubes packages installed (i.e. packages held or in the middle of a new install) and the VM is still able to successfully start (without qrexec timeouts – which may be recoverable but is another endeavor). If the packages are still installed (or you can acquire and install them manually – yet another process) then it may simply be a matter of ensuring Qubes systemd services are enabled/starting.
(Disclaimer: I’m not 100% certain on the exact services)
As @unman noted, enabling the updates-proxy-setup service does seem to resolve the issue. However in my particular instance, this did not resolve the issue of apt failing and ignoring when I’d manually issue an apt update at a root shell on the TemplateVM.
After examining the systemd services were not starting since /var/run/qubes-services and the condition paths did not exist. More digging revealed /usr/lib/qubes/init/qubes-sysinit.sh which has a service.
Enabling appears to configure the system including any update proxy.
systemctl start qubes-sysinit.service
systemctl enable qubes-sysinit.service
This may or may not be relevant here, but during my recent “playing” with minimal templates, I’d often run a script to clone a prior template, then add software to it with apt install.
If I had both sys-net and sys-firewall running, things would go fine. If they weren’t running, it would start sys-net but not sys-firewall. It would then attempt to get the files for the install, and fail. Apparently sys-firewall is vital to the process but it’s not automatically started if it’s not already running.
Not sure if that was something I did or whether that’s a glitch in the way apt installs are handled normally. But seeing all those messages upthread about failed file gets reminded me of what I was seeing a couple of weeks ago.