"Error: failed to synchronize cache for repo ..." when using Fedora-26 as sys-net

[Joeviocoe]

Qubes OS version:

R4.0 (RC4)

Affected TemplateVMs:

fedora-26

---

Steps to reproduce the behavior:

Install fedora-26 template new, and update to latest build.
Configure sys-net to use this template

For any VM:
dnf clean all
qubes.InstallUpdatesGUI or sudo dnf update

Expected behavior:

Update checks repos for new updates without error

Actual behavior:

Error: failed to synchronize cache for repo

General notes:

When using fedora-26 as the sys-net template... it seems to block the ability to perform updates. I get "Error: failed to synchronize cache for repo" whenever I try after clearing cache.

---

Related issues:

#3556

[taradiddles]

You may be encountering issue #3135

What happens after running systemctl restart qubes-updates-proxy in sys-net ?

[taradiddles]

You may be encountering issue #3135

What happens after running systemctl restart qubes-updates-proxy in sys-net ?

[Joeviocoe]

Yes, thank you taradiddles.

Indeed related to issue #3135
When changing TO fedora-26, the qubes-updates-proxy service fails to start on boot. A manual start of the service fixes the issue. A reboot seems needed to have it start on boot. Not a problem since sys-net changing templates is rare. I just didn't assume a reboot or manual service start would be needed.
No problem going FROM fedora-26 to another template, as the service starts properly on first run.

[Joeviocoe]

Yes, thank you taradiddles.

Indeed related to issue #3135
When changing TO fedora-26, the qubes-updates-proxy service fails to start on boot. A manual start of the service fixes the issue. A reboot seems needed to have it start on boot. Not a problem since sys-net changing templates is rare. I just didn't assume a reboot or manual service start would be needed.
No problem going FROM fedora-26 to another template, as the service starts properly on first run.

[taradiddles]

That's indeed strange; if you can consistently reproduce the problem it'll be interesting to see the output of sudo systemctl status qubes-updates-proxy.service and sudo journalctl --boot | grep qubes-updates-proxy

[taradiddles]

That's indeed strange; if you can consistently reproduce the problem it'll be interesting to see the output of sudo systemctl status qubes-updates-proxy.service and sudo journalctl --boot | grep qubes-updates-proxy

[Joeviocoe]

● qubes-updates-proxy.service - Qubes updates proxy (tinyproxy) Loaded: loaded (/usr/lib/systemd/system/qubes-updates-proxy.service; enabled; vendor preset: enabled) Active: failed (Result: start-limit-hit) since Fri 2018-02-09 11:45:14 EST; 49s ago Process: 2167 ExecStopPost=/usr/lib/qubes/iptables-updates-proxy stop (code=exited, status=0/SUCCESS) Process: 2149 ExecStart=/usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf (code=exited, status=0/SUCCESS) Process: 2145 ExecStartPre=/usr/lib/qubes/iptables-updates-proxy start (code=exited, status=0/SUCCESS) Main PID: 2149 (code=exited, status=0/SUCCESS)

[Joeviocoe]

● qubes-updates-proxy.service - Qubes updates proxy (tinyproxy) Loaded: loaded (/usr/lib/systemd/system/qubes-updates-proxy.service; enabled; vendor preset: enabled) Active: failed (Result: start-limit-hit) since Fri 2018-02-09 11:45:14 EST; 49s ago Process: 2167 ExecStopPost=/usr/lib/qubes/iptables-updates-proxy stop (code=exited, status=0/SUCCESS) Process: 2149 ExecStart=/usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf (code=exited, status=0/SUCCESS) Process: 2145 ExecStartPre=/usr/lib/qubes/iptables-updates-proxy start (code=exited, status=0/SUCCESS) Main PID: 2149 (code=exited, status=0/SUCCESS)

[marmarek]

In this case, I believe it is a duplicate of #3135.

[marmarek]

In this case, I believe it is a duplicate of #3135.