unman:
I also had this experience on Qubes upgrade - both in 3.2 and 4.
As stated, systemctl status whonix-firewall
shows it is masked.
Removing the mask and enabling the service in the template allows sys-whonix to start as expected.
It whonix-firewall.service shouldn’t be masked to begin with. That might
be the root cause. I wonder what I masking it.
There was a migration from package whonix-gw-firewall /
whonix-ws-firewall to whonix-firewall package:
https://github.com/Whonix/whonix-firewall/blob/master/lib/systemd/system/whonix-firewall.service
(Question - is this the right thing to do?
Maybe an ok workaround for testing but not the right fix.
Or is there service that will run in sys-whonix that will unmask and enable?)
No such services in Debian. Not a usual way to do things in Debian.
N.B Because the service is initially masked,
whonixcheck takes a loooong time to produce any output.
There is code to wait up to 30 seconds to avoid race conditions.
https://github.com/Whonix/whonixcheck/blob/master/usr/lib/whonixcheck/check_services.bsh#L93
Once this is fixed, sys-whonix started with firewall enabled and running.
I found that in 4.0rc5 whonixcheck in sys-whonix reports that Tor is disabled, although systemctl status
shows it is running.
Not related to systemctl status.
This check:
https://github.com/Whonix/whonixcheck/blob/master/usr/lib/whonixcheck/check_tor_enabled.bsh
Backend:
https://github.com/Whonix/anon-shared-helper-scripts/blob/master/usr/lib/anon-shared-helper-scripts/tor_enabled_check
Trying to enable using whonixsetup results in error 0 unable to add "DisableNetwork 0" to /usr/local/etc/torrc.d/40_anon_connection_wizard.conf
.
really whonixsetup?
whonixsetup refers to https://github.com/Whonix/whonixsetup CLI tool.
There is a bug in
indeed.
If /usr/local/etc/torrc.d/40_anon_connection_wizard.conf exists but does
not include #DisableNetwork 0
, then ed -s /usr/local/etc/torrc.d/40_anon_connection_wizard.conf [...]
will fail.
Please fix.
Indeed that file does not exist, although 95_whonix.conf does in same location.
So it must be yet another bug. Running with bash -x
might help to find
out why it’s not created by whonixsetup
?