Update:
No more testing required! (New testers-only release coming soon!)
Original post:
Let’s test the following recently rebuild Whonix TemplateVM packages.
2 Likes
well i cant make GW to connect:
Whonix Check
ACW
Logs
user@host:~$ systemctl status tor@default.service
● tor@default.service - Anonymizing overlay network for TCP
Loaded: loaded (/lib/systemd/system/tor@default.service; static; vendor preset: enabled)
Drop-In: /lib/systemd/system/tor@default.service.d
└─30_qubes.conf, 40_obfs4proxy-workaround.conf, 40_qubes.conf, 50_controlsocket-workaround.conf
Active: failed (Result: exit-code) since Sat 2018-11-03 16:08:02 UTC; 1min 12s ago
Process: 2305 ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config (code=exited, s
Process: 2302 ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor (code=exited, status=0/SUCCESS)
Nov 03 16:08:01 host systemd[1]: tor@default.service: Control process exited, code=exited status=1
Nov 03 16:08:01 host systemd[1]: Failed to start Anonymizing overlay network for TCP.
Nov 03 16:08:01 host systemd[1]: tor@default.service: Unit entered failed state.
Nov 03 16:08:01 host systemd[1]: tor@default.service: Failed with result 'exit-code'.
Nov 03 16:08:02 host systemd[1]: tor@default.service: Service hold-off time over, scheduling restart.
Nov 03 16:08:02 host systemd[1]: Stopped Anonymizing overlay network for TCP.
Nov 03 16:08:02 host systemd[1]: tor@default.service: Start request repeated too quickly.
Nov 03 16:08:02 host systemd[1]: Failed to start Anonymizing overlay network for TCP.
Nov 03 16:08:02 host systemd[1]: tor@default.service: Unit entered failed state.
Nov 03 16:08:02 host systemd[1]: tor@default.service: Failed with result 'exit-code'.
user@host:~$ journalctl -xe
-- Support: https://www.debian.org/support
--
-- Unit tor@default.service has failed.
--
-- The result is failed.
Nov 03 16:08:02 host systemd[1]: tor@default.service: Unit entered failed state.
Nov 03 16:08:02 host systemd[1]: tor@default.service: Failed with result 'exit-code'.
Nov 03 16:08:02 host audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor@default comm="systemd" exe="/lib/systemd/systemd" hostname=? add
Nov 03 16:08:02 host audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=tor@default comm="systemd" exe="/lib/systemd/systemd" hostname=? addr
Nov 03 16:08:27 host audit[2381]: USER_AUTH pid=2381 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="user" exe="/bin/su" hostname=? addr=? termi
Nov 03 16:08:27 host audit[2381]: USER_ACCT pid=2381 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="user" exe="/bin/su" hostname=? addr=? terminal=
Nov 03 16:08:27 host su[2381]: Successful su for user by root
Nov 03 16:08:27 host su[2381]: + ??? root:user
Nov 03 16:08:27 host audit[2381]: CRED_ACQ pid=2381 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="user" exe="/bin/su" hostname=? addr=? terminal=???
Nov 03 16:08:27 host su[2381]: pam_unix(su:session): session opened for user user by (uid=0)
Nov 03 16:08:27 host systemd[1]: Started Session c4 of user user.
-- Subject: Unit session-c4.scope has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit session-c4.scope has finished starting up.
--
-- The start-up result is done.
Nov 03 16:08:27 host systemd-logind[523]: New session c4 of user user.
-- Subject: A new session c4 has been created for user user
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- Documentation: http://www.freedesktop.org/wiki/Software/systemd/multiseat
--
-- A new session with the ID c4 has been created for the user user.
--
-- The leading process of the session is 2381.
Nov 03 16:08:27 host audit[2381]: USER_START pid=2381 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open acct="user" exe="/bin/su" hostname=? addr=? termin
Nov 03 16:08:27 host su[2381]: pam_unix(su:session): session closed for user user
Nov 03 16:08:27 host audit[2381]: USER_END pid=2381 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close acct="user" exe="/bin/su" hostname=? addr=? termina
Nov 03 16:08:27 host audit[2381]: CRED_DISP pid=2381 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="user" exe="/bin/su" hostname=? addr=? terminal=???
Nov 03 16:08:27 host qrexec-agent[584]: eintr
Nov 03 16:08:27 host systemd-logind[523]: Removed session c4.
-- Subject: Session c4 has been terminated
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- Documentation: http://www.freedesktop.org/wiki/Software/systemd/multiseat
--
-- A session with the ID c4 has been terminated.
Nov 03 16:09:17 host mate-notificati[2520]: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provi
user@host:~$
Is that a fresh sys-whonix, or it used whonix-gw (13) template before? I’ve seen similar problem when migrating from whonix 13.
On fresh install it works for me.
fresh install
i figured it out , the graphical uninstallation of previous sys-whonix didnt really happen so well from Qubes manager.
what happened is:
- sys-whonix removed graphically from Qubes manager.
- Qubes thought it has been deleted
- i installed new whonix , the old sys-whonix just popped-up (tricked me as i thought it is the new one)
- Qubes thought as well it did the command purpose of installing sys-- whonix based on new Whonix-gw-template (the fact its still based on the old whonix-gw-template)
- errors happened as above
Issues/Solutions:
- Graphical uninstall should give the same effect of manual uninstallation.(qvm-remove …)
-
sudo qubesctl state.sls qvm.whonix-ws-14-dvm, should be have some sanity about the existed templates/vms from old builds or new builds.
…
i dunno if these are the ideal solutions , but thats what happened with me.
Solution to my problem above:
in dom0 terminal:
qvm-remove sys-whonix
then repeat whonix installation command
sudo qubesctl state.sls qvm.whonix-ws-14-dvm
Other issues:
-
whonix-gw-appvm which are based on the old whonix 14, will not be able to be connect to the internet due to the same issue that i mentioned above. (so you need to delete every old gw-14 appvms and create new one based on the current testing whonix-14-gw appvms)
-
previous whonixes , when you create new whonix-apppvm there was a service in the settings of the appvm called “meminfo-writer”. this one seems to be disappeared with the current testing builds.(i need to write it manually then it will pop-up then i press on
sign to add it back) -
Old based vms on whonix-14 , will not save their data.true the whonix-ws-xxx.appvm which is based on the stable/old whonix will still in the qubes manager, but it will not keep containing the same data (emails,chat , texts …etc all will be erased).
Edit: only emails/mails + plugins (torbirdy+enigmail) with Thunderbird will be lost.
- Qubes Manager/Whonix Bug:
pressing on “Refresh application” inside whonix-ws-appvm which is taking its connection from whonix-gw-appvm NOT sys-whonix, it will ignore that and open sys-whonix EVEN though whonix-ws network isnt based on sys-whonix appvm.
Related:
Feature Request:
- Every Whonix-ws-appvm created from whonix-ws-template the firewall should be set on limit outgoing connection (or if there is prevent outgoing connection better) as we dont need connection within the WS at all. but only from GW-appvm.
No more testing required! (New testers-only release coming soon!)
1 Like
1 Like
6 posts were split to a new topic: cannot change Qubes keyboard layout
better to close this topic , as now no one can install this testing version (only the new upgraded one)
1 Like