Qubes 4.2 -> 4.3 (Whonix 17 -> 18) - Denied sdwdate-gui.ConnectCheck from anon-whonix to sys-whonix

Qubes-Whonix
1

Rather than follow the qubes-dist-upgrade or release-upgrade approach to moving to Qubes 4.3 / Whonix 18 I decided to factory reset and rebulid my various qubes. Here are a couple Whonix-releated things I noticed during the process.

(1) Switching the template of an existing anon-vm qube from whonix-workstation-17 to whonix-workstation-18:

After starting the qube I saw looping notifications, Denied sdwdate-gui.ConnectCheck from <anon qube> to sys-whonix. Noted elsewhere on the forums, and expected. To ‘fix’ this I create a new anon qube and qvm-copy over the /home/user/.tb dir from the old qube. Seems to be working fine. I think there is nothing wrong in doing this? The browser session is intended to be persistent, not ephemeral/anonymous.

(2) Running update-torbrowser on a fresh whonix-workstation-18 template:

(See other post: `rm` errors when running `update-torbrowser` on a `fresh whonix-workstation-18` template)

Thanks!

2

It might be lacking a dom0 some qvm-tags. How to check and how to add them, documented just now:
Denied sdwdate-gui.ConnectCheck from anon-whonix to sys-whonix

Please let me know if that can fix the issue.

This shouldn’t be related at all. sdwdate-gui.ConnectCheck has no relationship with tb-updater / update-torbrowser whatsoever.

1 forum topic = 1 issue please.

1 Like
3

Yes, it’s as you said. Adding the sdwdate-gui-client tag to the anon vm fixes the issue. Thanks.

Something interesting I discovered:

[user@dom0 ~]$ qvm-tags anon-vm-originally-ws-17
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
[user@dom0 ~]$ qvm-clone anon-vm-originally-ws-17 anon-vm-clone
anon-vm-clone: Cloning private volume
[user@dom0 ~]$ qvm-tags anon-vm-clone
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
sdwdate-gui-client

Cloning or renaming the ws17-origin anon vm will automatically add the missing sdwdate-gui-client tag to to the new qube (but not to the original qube).

1 Like
4

You are running Qubes R4.3, right? (It sounds like you are, but I wanted to double-check.) qubes-core-admin-addon-whonix (which is preinstalled in R4.3) should automatically add the sdwdate-gui-client tag to any Whonix-Workstation VMs any time a domain-load event is triggered in qubes-core-admin. In concrete terms, this event gets triggered on every single VM when dom0 is restarted, or when the qubesd service is restarted.

If you run sudo systemctl restart qubes.service in dom0, does anon-vm-originally-ws-17 gain the sdwdate-gui-client tag? (Be warned that restarting qubesd can cause some odd behavior, for instance Qube Manager might crash, so make sure you aren’t doing any important work when you try this.)

2 Likes
5

It’s as you said. :+1:

[user@dom0 ~]$ qvm-tags anon-vm-originally-ws-17
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
[user@dom0 ~]$ qvm-tags anon-vm-originally-ws-17-other
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
[user@dom0 ~]$ sudo systemctl restart qubesd.service
[user@dom0 ~]$ qvm-tags anon-vm-originally-ws-17
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
sdwdate-gui-client
[user@dom0 ~]$ qvm-tags anon-vm-originally-ws-17-other
anon-vm
audiovm-dom0
created-by-dom0
guivm-dom0
sdwdate-gui-client
2 Likes
6

Perfect. I’ll see if I can find a good place to document that a qubesd restart is needed to “sync” tags in some instances.

1 Like
7

So it will work for all whonix based app qubes? Including sys-whonix? Will it work for kicksecure based app qubes?

And if I understand you correctly, a system restart will also do the job?

8

It should.

It should thanks to GitHub - QubesOS/qubes-core-admin-addon-kicksecure: Kicksecure core-admin plugin. For any Kicksecure specific issues, please use https://forums.kicksecure.com.

Yes. Restarting the system will also result in a restart of dom0 qubesd.service systemd unit.

1 Like
9

Updated just now.

1 Like