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 proceeds. 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'? unman -- 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 https://groups.google.com/d/msgid/qubes-users/20190627114448.mlnylqqpnf727ni4%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
