Please report this to qubes-issues.
Please report this to qubes-issues separately.
After upgrading to 14.0.0.6.8-testers-only following the instruction: Release Upgrade - Whonix
It turns out the Whonix onion service is not enabled by default. Specifically:
user@host:/etc/apt$ cat /etc/apt/sources.list.d/whonix.list
## This file is part of Whonix.
## Copyright (C) 2012 - 2014 Patrick Schleizer <adrelanos@riseup.net>
## See the file COPYING for copying conditions.
## Whonix /etc/apt/sources.list.d/whonix.list
## This file has been automatically created by /usr/bin/whonix_repository.
## If you make manual changes to it, your changes get lost next time you run
## the whonix_repository tool.
## You can conveniently manage this file, using the whonix_repository tool.
## For any modifications (delete this file, use stable version, use testers
## version or use developers version), please use the whonix_repository tool.
## Run:
## sudo whonix_repository
deb http://deb.whonix.org stretch main
## Leaving source line disabled by default to safe some time, it's not useful
## anyway, since it's better to get the source code from the git repository.
#deb-src http://deb.whonix.org stretch main
## End of /etc/apt/sources.list.d/whonix.list
The onino service is used after running sudo whonix_repository sudo whonix_repository --enable --codename stretch:
user@host:/etc/apt$ cat /etc/apt/sources.list.d/whonix.list
## Copyright (C) 2012 - 2018 ENCRYPTED SUPPORT LP <adrelanos@riseup.net>
## See the file COPYING for copying conditions.
## Whonix /etc/apt/sources.list.d/whonix.list
## This file has been automatically created by /usr/bin/whonix_repository.
## If you make manual changes to it, your changes get lost next time you run
## the whonix_repository tool.
## You can conveniently manage this file, using the whonix_repository tool.
## For any modifications (delete this file, use stable version, use testers
## version or use developers version), please use the whonix_repository tool.
## Run:
## sudo whonix_repository
deb tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion stretch main
#deb-src tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion stretch main
deb http://deb.whonix.org stretch main
#deb-src http://deb.whonix.org stretch main
## Leaving source line disabled by default to safe some time, it's not useful
## anyway, since it's better to get the source code from the git repository.
## End of /etc/apt/sources.list.d/whonix.list
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-gw qubes-template-whonix-ws
Shouldn’t this be qubes-template-whonix-gw-14, qubes-template-whonix-ws-14?
The resulting templates are named whonix-ws-14, whonix-gw-14. Since neither the template name nor the package names conflict with the old version, why is it necessary to rename/remove VMs/packages?
sudo qubesctl state.sls qvm.anon-whonix
This appears to be hardwired to use qubes-template-whonix-{ws,gw} and not qubes-template-whonix-{ws,gw}-14. It’ll start downloading the former, even after you’ve installed the latter.
To get the tor service to start, I had to chown -R debian:tor /var/lib/tor to get rid of permission errors. In sys-whonix (which I cloned from the jessie version) this was a bind-dir with wierd perms (sdwdate something).
torbrowser works but the gui around the tabs is messed up.
Tor fails to start if %include (#24303) · Issues · Legacy / Trac · GitLab
If %include is present in torrc then tor service will fail to start.
The directive I aded to torrc was
%include /etc/torrc.d/Folder exist and perms are valid, but tor service will not start and tor will not write the reason why to log.
[…]
Changed 4 months ago by nickm
Are you running Tor inside Apparmor, or something else that might restrict which files it’s allowed to read?
[…]
Four months are passed and no new info. The apparmor guess is a plausible one – meaning that whoever writes the apparmor rules for whatever Tor package this was is going to have to think about how the %include directive works. I think it’s getting to be time to close this one as user-disappeared though.
Investigation
Since Whonix now does the same i.e. %include line, I thought that maybe one of the Whonix AppArmor profiles is probably blocking Tor user config changes, hence Tor is not starting when you try to edit this file with it enabled.
But:
sudo cat /var/log/audit/audit.log | grep -i DENIED
does not show anything in sys-whonix.
So I disabled apparmor and tried to edit the config file again.
Same problem occurs - PID, “Tor cannot connect” errors. Remove the offending lines - Tor connects again.
So, it does not relate to AppArmor. Had a hunt around in various log files - couldn’t identify anything in particular.
Something is wrong there with the change in the default path in Whonix 14 away from the standard torrc file, since connection padding and Tor sandbox work fine in Whonix 13.
1 Like
Correct.
The templates would be named whonix-gw-14 and whonix-ws-14. However, the new templates have to be named whonix-ws and whonix-gw for the instructions to have the desired outcome. That way salt will only create sys-whonix and anon-whonix VMs based on the new templates (unstable). Not download whonix stable templates etc.
The instructions work as intended if they are followed.
Edit: My bad - Versioned Whonix template names were introduced in the last build. It is correct to use qubes-template-whonix-gw-14 qubes-template-whonix-ws-14 arguments. This would indeed cause whonix-13 (stable) VMs to be downloaded and new sys-whonix, anon-whonix (stable) VMs to be created.
Thanks for reporting this!
I have used Whonix 14 in Qubes 4 for a while now.
Just installed it in Qubes 3.2.
After completing the installation, anon-connection-wizard does not start. Running it from command line does not help, it stops after clicking Connect as mentioned.
The reason is most likely (or certainly) that the newly installed image is not up to date, it was created some time ago, in the mean time all the repositories (stretch, whonix) were updated.
The problem was fixed after running
sudo apt-get update && sudo apt-get dist-upgrade
in whonix-gw, stopping it and restarting sys-whonix. Then anon-connection-wizard runs as intended, torrc is written, tor control and socks are created.
This should be a standard procedure after installing an image (not only in Qubes, happened to me in VirtualBox too).
@0brand It might be helpful to update the thread introduction.
Edit: Agreed that it’s not intended for newbies.
1 Like
Done!
Thanks for pointing that out troubadour!
1 Like
Done!
I managed to read through your post without it registering that I have to make changes to the instructions. Sorry about that. 
1 Like
Thank you for your investigation, @torjunkie !
Do you mean you removed the line %include /etc/torrc.d in /etc/tor/torrc and everything works fine then?
I will try to reproduce the problem with anon-connection-wizard by doing another fresh upgrade to Whonix 14.
Again, thank you for reporting and helping to solve the problem, @torjunkie !
→ Done.
I mean, try adding Sandbox 1 and ConnectionPadding 1 to the new Tor config file /usr/local/etc/torrc.d/50_user.conf in sys-whonix with the GUI or with nano. Tor won’t start.
Error is:
ERROR: Tor Pid Check Result:
Tor not running. (tor_pid_message: Pid file /var/run/tor/tor.pid does not exist.)
You have to fix this error, before you can use Tor.
Please restart Tor after fixing this error.
dom0 → Start Menu → ServiceVM: sys-whonix → Restart Tor
or in Terminal:
sudo service tor@default restart
Restart whonixcheck after fixing this error.
dom0 → Start Menu → ServiceVM: sys-whonix → Whonix Check
or in Terminal:
whonixcheck
But these options do work with Whonix 13, when editing the /etc/tor/torrc file (which we are told not to touch in Whonix 14).
So, something in the coding of trying to grab those options and apply it to the Tor process in Whonix 14 is screwing up.
Removing those config changes in Whonix 14, Tor connects again.
I note Arm in Whonix 14 also says something about “Unneeded torrc entries found. They’ve been highlighted in blue on the torrc page.”
And torrc page shows: %include /etc/torrc.d/95_whonix.conf ()
With the () in blue. So I presume that is problematic somehow (?)
__
Anyhow, based on progress to date, it seems the main blockers have been rectified i.e.
1) v3 onion fixed
2) anon-connection-wizard actually works following updates being applied.
However, given the user can’t connect to Tor to start with to do the updates, @0brand, we should probably add to the updating step something like:
Note: As the templates are based on older Whonix packages, users will probably be unable to use anon-connection-wizard or the Whonixsetup GUI to connect to Tor in the first instance. Therefore it is recommended to connect to Tor on the first run with the following command in sys-whonix, before attempting to upgrade the TemplateVMs:
sudo whonixsetup
3) The remaining main problem is tor config changes.
Can anybody else get Sandbox 1 and ConnectionPadding 1 to work in Whonix 14 and have Tor connect?
1 Like
Just now reported.
Tor startup crash with Sandbox 1 in torrc.d - sandbox_intern_string(): Bug: No interned sandbox parameter found
1 Like
Thank you for the clarification!
I agree. 
This thread with 52 posts is getting unmanageable.
To make this workable, please add something like:
1 issue = 1 ticket at https://phabricator.whonix.org
Add the Whonix_14 tag.
iry:
After upgrading to
14.0.0.6.8-testers-onlyfollowing the instruction: Release UpgradeIt turns out the Whonix onion service is not enabled by default.
Fixed.
2 Likes
0brand:
[quote=“no1, post:43, topic:4988”]
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-gw qubes-template-whonix-wsShouldn’t this be qubes-template-whonix-gw-14, qubes-template-whonix-ws-14?
Yes, very much so.
Without the -14 suffix you are getting an outdated template version.
https://yum.qubes-os.org/r4.0/unstable/dom0/fc25/rpm/
Everyone here is basically testing a version that I didn’t intent to ask
for testing since it had known bugs (that I fixed and forgotten about
since).
This might explain some bugs reported here.
Versioned Whonix template names were only introduced in the last build.
Whonix versioned template names vs salt is an issue indeed.
Meanwhile I asked to have the outdated versions removed.
2 Likes
torjunkie:
I note Arm in Whonix 14 also says something about “Unneeded torrc entries found. They’ve been highlighted in blue on the torrc page.”
And torrc page shows: %include /etc/torrc.d/95_whonix.conf ()
With the () in blue. So I presume that is problematic somehow (?)
After reading Control and Monitor Tor with
all the false positives, it’s safe to ignore arm. It’s much more likely
it just doesn’t know how to parse these lines. Feel free to report a bug
upstream. It may even be fixed at some point.
1 Like
I will correct the instructions a little later today. This is just a basic outline of purposed changes dependent on successful testing. I will make sure to test instructions from start to finish to make sure they are sound.
- install whonix-gw-14, whonix-ws-14 templates.
- clone whonix-14 templates and name → whonix-ws , whonix-gw.
- since clones are named whonix-ws and whonix-gw, use salt to create sys-whonix ,anon-whonix VMs.
Step 5: New templates are initially being updated through sys-whonix or sys-firewall (stable) updateVM.
1 Like
Instead of cloning the templates and then using salt, why not just reuse the existing anon-whonix and sys-whonix, by changing their templateVM?
So the full procedure is like this:
- Download new templates whonix-ws-14 and whonix-gw-14:
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable qubes-template-whonix-{ws,gw}-14
(note this won’t overwrite the existing whonix-ws and whonix-gw). - shutdown anon-whonix and change its template from whonix-ws to whonix-ws-14.
- shutdown sys-whonix and change its template from whonix-gw to whonix-gw-14.
To get tor to connect, I also had to fix permissions in sys-whonix’s /var/lib/tor: chown -R debian-tor:debian-tor /var/lib/tor
A procedure similar to the above gives me a working set of whonix-14 based VMs, and leaves my existing whonix-13 templates available in case I need to revert or do regression testing.
Updated instructions to use the newest Whonix 14 builds (suffix -14)
Instructions were tested x2 from start to finish with no issues.
If you want to look over the edits:
Step 4 : changed arguments to qubes-template-whonix-gw-14 , qubes-template-whonix-ws-14.
Step 4 : removed note referencing Whonix v2 and v3 .onions being down.
Step 5 : total re-write.
Step 6 : re-write.
Step 7 : added step to update template VMs. (Just a reminder.)
Whonix-14 install and configure note:
After instructions were corrected to use the newest builds. No problems were encountered with Anon Connection Wizard. Everything went smooth when connecting to Tor.
1 Like
Its great to see that your contributing to the instruction. They are a little complicated.
Since we are testing Whonix 14, we want to create Whonix 14 sys-whonix and anon-whonix VMs from scratch. Instead of changing VM templates.