Updating dom0 does not work on new 4.1 install

User Support General
#1

I follow the update Qubes article and using the first command:

sudo qubesctl --show-output state.sls update.qubes-dom0

I get:

[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

#2

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?

#3

No, fresh 4.1 install. Installed whonix at the beginning, but now is stopped (if that could potentially mess the settings)

Global settings update setting is set to sys-firewall.

Posting some results I made, following some posts from people with updates issue. I do not know how much they are connected.

My qubes.UpdatesProxy file shows only two lines:

$tag:whonix-updatevm $default allow, target=sys-whonix
$tag:whonix-updatevm $anyvm deny

Using:

sudo systemctl status qubes-updates-proxy.service

in sys-firewall shows inactive(dead).

qubes-prefs in dom0 shows updatevm to be sys-firewall.

#4

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.

#5

The QubesOS Documentation has a warning about how best to perform updates and recommends that you run two different commands, one after the other:

  • sudo qubesctl --show-output state.sls update.qubes-dom0 && sudo qubes-dom0-update --clean -y

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?

1 Like
#6

I have this warning as well:

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.

1 Like
#7

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.

#8

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

#9

The # are in the file, just didn’t wrote them.

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?

#10

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.

#11

That didn’t change anything.

But I continued with the other steps from the update guide.

Some things updated, I think.

Thanks, for your time. Again.

#12

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:

Updating dom0
local:
    ----------

dom0_update

#13

Please dont use screenshots without also SAYING what they contain.
What is it you get?

#14

This sounds like it could be #7503 or #7220.

#15

Uh, yes. Added short description.

#16

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?