On Wed, Jun 26, 2019 at 10:12:40PM -0700, Sphere wrote:
> @unman: thanks for that
> I also noticed that qubes-updates-proxy.service fails by default on startup 
> and I'm unsure if that is a minimal template-only problem but I was able to 
> fix it thanks to it indicating that the problem is a missing folder: 
> /var/run/qubes-service/qubes-updates-proxy
> Pretty much the same problem that I get with clocksync service thankfully so 
> I was able to confirm that this service was running as intended
> systemctl status qubes-updates-proxy:
> qubes-updates-proxy.service - Qubes updates proxy (tinyproxy)
>    Loaded: loaded (/usr/lib/systemd/system/qubes-updates-proxy.service; 
> enabled;
>  vendor preset: enabled)
>    Active: active (running) since Thu 2019-06-27 12:06:14 +08; 2s ago
>   Process: 1603 ExecStartPre=/usr/lib/qubes/iptables-updates-proxy start 
> (code=e
> xited, status=0/SUCCESS)
>  Main PID: 1608 (tinyproxy)
>     Tasks: 3 (limit: 414)
>    Memory: 4.1M
>    CGroup: /system.slice/qubes-updates-proxy.service
>            ??????1608 /usr/bin/tinyproxy -d -c 
> /etc/tinyproxy/tinyproxy-updates.conf
>            ??????1609 /usr/bin/tinyproxy -d -c 
> /etc/tinyproxy/tinyproxy-updates.conf
>            ??????1610 /usr/bin/tinyproxy -d -c 
> /etc/tinyproxy/tinyproxy-updates.conf
> Jun 27 12:06:14 redacted systemd[1]: Starting Qubes updates proxy 
> (tinyproxy)...
> Jun 27 12:06:14 redacted systemd[1]: Started Qubes updates proxy (tinyproxy).
> Jun 27 12:06:14 redacted tinyproxy-wrapper[1608]: Found tinyproxy at 
> /usr/bin/tinyproxy
> Despite this however, the problem still persists and still behaves the same 
> even after trying dnf update for 5 times
> I think is right about the fact that there is a bug about this
> @Chris I think you may be right about the fact that this is a bug and I guess 
> it's time to escalate it into an issue in github. I'm willing to lend a 
> helping hand in making the issue as needed.
> My setup is all fully dependent on variations of fedora-30-minimal template 
> that I have tailored depending on use-case of the AppVM that would be using 
> it.

Like Chris, I use a separate qube for updates.
Unlike you and Chris I don't see the behaviour you report.

Let's try to dig in before raising a bug report.

I've tested this with 30-minimal template 201905071541 and 201906241949,
from stable and testing.
I've tested against dom0 stable and dom0 testing: both fully updated.
Test boxes are an old x230 and a custom rig with X-series CPU and 32G RAM.

In all cases, the proxy is started as appropriate, and the update
process (from fedora 29 and 30-minimal) waits until proxy is up and then

What hardware are you, Sphere and Chris, running?

Sphere - if you create a dedicated update qube using the 30-minimal with
qubes-core-agent-networking installed,
enable the qubes-updates-proxy service, route it through
sys-firewall, and edit the policy file appropriately, do you see the
same behaviour? (Almost instant fail)
What if you start the new update proxy before attempting a 'dnf update'?


You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to