[WARNING ] /usr/lib/python3.8/site-packages/salt/utils/files.py:396: RuntimeWarning: line buffering (buffering=1) isn’t supported in binary mode, the default buffer size will be used
f_handle = open(*args, **kwargs) # pylint: disable=resource-leakage
and then nothing else happen.
I checked firewall log, here what is there:
handle_execute_service: couldn’t invoke qrexec-policy-daemon, using qrexec-policy-exec
connect_daemon_socket: connection to socket failed: connection refused
qrexec-daemon.c:589:handle_cmdline_body_from_client: connection with ident not requested or already handled
ioall.c:75:read_all: EOF
qrexec-client.c: 318: negoriate_connection_params: read daemon success
sys-firewall → dom0: error while executing: qrexec-client failed [‘/usr/lib/qubes/qrexec-client’, ‘-d’, ‘dom0’, ‘-c’, ‘SOCKET12,sys-firewall,6’, ‘-E’, ‘QUBERPC qubes.WIndowIconUpdate+ sys-firewall keyword adminvs’]
qrexec-daemon.c: 695:reap-children: qrexec-policy-exec for connetion SOCKET12 exited with code 1, but the response (allow) was already sent
Did you perform an in-place upgrade from Qubes 4.0 to Qubes 4.1? Or do you have clean Qubes 4.1 installation?
Did you restore old Qubes 4.0 template from backup and use it for your sys-firewall?
This is normal if you have default updatevm for templates that is set here: cat /etc/qubes/policy.d/90-default.policy | grep UpdatesProxy
Policies in /etc/qubes-rpc/policy/ have higher priority than policies in /etc/qubes/policy.d/90-default.policy.
Do you have sys-firewall set as UpdatesProxy for @type:TemplateVM or is it sys-net?
But anyway it’s a setting that specify which netvm to use as updatevm for template updates and shouldn’t be related to your issue with dom0 updates as it’s using another setting to specify which netvm to use as updatevm for dom0 in global settings.
Maybe you’re missing qubes-updates-proxy service for sys-firewall. Try to add it in sys-firewall Qubes Settings.
If it won’t work then what if you create new qube sys-firewall2 with Provides network option enabled and try to set it as updatevm for dom0 in Qubes Global Settings?
Also add the qubes-updates-proxy service in the Qubes Settings for your sys-firewall2.
Will you have the same error?
Maybe your sys-firewall qube is broken for some reason.
I get this same warning, but it successfully updates after a minute or so, depending on how many updates are available. Does the CPU usage of your dom0 and updatevm rise and fluctuate after running the dom0 update command?
To @tzwcfq and others, do you not see the same warning when running the dom0 update command?
But after running this command: sudo qubesctl --show-output state.sls update.qubes-dom0
There should be some output at the end even if there are no updates.
Yes, it did show the log after the python warning, needed to wait a little bit longer. It says 39000ms. Not the 207ms from the post.
In the sys-firewall settings in the services tab I don’t have services listed.
Policies in /etc/qubes-rpc/policy/ have higher priority than policies in /etc/qubes/policy.d/90-default.policy .
The qubes.UpdatesProxy in qubes-rpc/policy is the one I posted. And the 90-default.policy looks like that:
Upgrade all TemplateVMs through sys-wnonix.
qubesUpdatesProxy * @type:TemplateVM @default allow target=sys-whonix
Upgrade all Whonix TemplateVMs through sys-wnonix.
qubesUpdatesProxy * @tag:whonix-updatevm @default allow target=sys-whonix
Deny Whonix TemplateVMs using UpdateProxy of any other VM.
qubesUpdatesProxy * @tag:whonix-updatevm @anyvm deny
Default rule for all TemplateVMs - direct the connection to sys-net
qubesUpdatesProxy * @type:TemplateVM @default allow target=sys-net
qubesUpdatesProxy * @anyvm@anyvm deny
Using:
sudo systemctl status qubes-updates-proxy.service
in firewall, besides shows it is inactive, it says:
systemd[1]: Condition check resulted in Qubes updates proxy (tinyproxy) being skipped.
It seems that you’ve removed # symbols before posting.
But if you didn’t change the file then you have sys-net as your updatevm for template updates: qubesUpdatesProxy * @type:TemplateVM @default allow target=sys-net
You can change it to sys-firewall if you need.
It seems that qubes-updates-proxy service is not enabled for sys-firewall.
Add qubes-updates-proxy service in sys-firewall Services tab in Qube Settings.
You can read more info about it here: How to install software | Qubes OS
sudo systemctl list-unit-files | grep qubes says it is, presumably.
In the services tab there is nothing in the drop-down menu, except (custom). Below is blank. No added services. Should there be something by default here?
There seems to be some peculiarities with disposable qubes and they don’t have default Qubes services listed in Services tab like other AppVMs based on TemplateVMs.
Just select (custom...) in Services tab, press Add and type qubes-updates-proxy there.
Not sure if this is related, but my 4.1 install (in-place upgrade, if that matters) started to act strange. I get every day update notification for dom0, even if there’s nothing to update. If I update from command line I get “System is already up-to-date”. If I update from GUI, I get this in the details section every day:
Thanks for that.
Unfortunately those who access the forum via email dont get updates, and
I guess that you updated your original post.
Can you just ping your “short description” in the thread?