I recently reinstalled qubes and restored whonix-16 from backup and it seems to work fine. I assume simply downloading the template from qubes-templates-community and reassigning the associated whonix-15 AppVM also works.
itās great all the work, and yet, this has been a pattern with previous releases freezing with the master invokation,
I donāt mind waiting overnight, but would like a warning, ofc, if it freezes a PC with 32GB Ram, well maybe there werenāt enough testers to do any betterā¦
in my case, running the sys-whonix and the appVM ends up limiting how many other appVM sessions I can run, so ā¦
did you install via sudo qubes-dom0-update qubes-foo-template or run the monster script again ?
in the past when I used the whonix forum, despite the very low traffic, it was an unpleasant experience, YMMV
Yesterday, I cloned the whonix-gw-15 template, named the clone whonix-gw-16 and then upgraded inside the new template with
release-upgrade
changed sys-whonix to new template, so far workstations and gateway work flawlessly.
(thatās on Qubes 4.0.4 still)
I was successful in installing Whonix 16 on Qubes 4.1 but it seems there is a communication issue between anon-whonix and sys-whonix. I can see the deamon listening on port 9108 and 9150 on sys-whonix, but requests from anon-whonix donāt get there. The last time I see sth is on the anon-whonix iptables OUTPUT chain (hitting an ACCEPT rule) but then nothing comes into sys-whonix (no iptables hits, nothing to be seen using tcpdump). Obviously anon-whonix is using sys-whonix as NetVM.
Has anyone else seen this?
I donāt know if itās related but these days I always end up with systemd-socket-proxyd frying my CPU in the whonix-ws (100% cpu). It seems to be running on /lib/systemd/systemd-socket-proxyd 10.152.152.10:9150
Iāve not been able to find a solution.