On 6/28/19 3:03 AM, Sphere wrote:
On Thursday, June 27, 2019 at 11:44:51 AM UTC, unman wrote:
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
Big update: I was able to solve the problem
What I essentially did:
1. Ensure to run the Update Qube first
2. Confirm and ensure that the qubes-updates-proxy is already running after the
qube is started. qubes-updates-proxy was listed and set as checked in the
services tab of Qubes Settings GUI before starting the update qube.
checking was done through the `systemctl status qubes-updates-proxy` command.
3. Ensure that qubes.UpdatesProxy policy file is configured correctly before
starting the templateVM
4. Ensure that DNS queries are resolving in the update qube
5. Start the templateVM and try to do a dnf update
One big thing to note here is that I encountered the problem after step 4 and
was able to solve it by ensuring that my update qube is able to properly
resolve DNS queries but I have to say that what's unique in my situation is
that I use DNSCrypt for resolving DNS queries.
So basically, the problem was solved after I ran DNSCrypt on the update qube.
Admittedly that was kinda dumb on my part to not realize that the f30 template
definitely needs to have DNS resolutions to do updating along with that fact
that I have already blocked all plaintext DNS from going out.
However, I can't quite remember whether or not I had DNSCrypt running on the
update qube last time I tested it so there's a possibility that strictly doing
the first 2 steps that I did contributed greatly in solving the problem.
For the purpose of troubleshooting this problem however, the qube that I used
to update and the qube that I used for VPN is one and the same. I guess I'll
try to use separate ones next week to see how it goes (I have none to very
minimal online activity throughout the weekend).
@Chris: Maybe you could try what I did and see how it goes?
Unfortunately its not helping. I can successfully update my Debian
templates usually on the first try, but it always takes 3 or more tries
to update fedora-30.
I may try changing my update vm to debian-10 to see if that helps. The
problem started when I switched the update vm from fedora-28 to fedora-30.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
--
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/b0254302-085c-7b5e-59a4-3835a504db62%40posteo.net.
For more options, visit https://groups.google.com/d/optout.
