Have a few smaller edits to complete then I’ll start on this. 
Two wiki contribs.
Uploaded the last screenshot https://whonix.org/wiki/File:Screenshot-clone-vm-qubes.png
Added Screenshot Qubes-r4-create_sys-whonix.png to Template: Qubes Create Gateway ProxyVMs including content. (Using Admin privileges). Also, I failed to add a comment for the edits…again.
I’ve created a bit mess under Post-installation Security Advice. All the different cases are documented now.
suspend / hibernate in dom0: Generally ok in Qubes.
There is a difference in Qubes between suspend / hibernate in dom0 and pause / resume using Qubes VM Manager. The later is problematic usability wise.
suspend / hibernate / safe / restore / pause / resume in Non-Qubes-Whonix:
Generally problematic usability wise.
So maybe all of that documentation could be moved to an advanced place or hidden under an expand button? The simplified documentation could be:
I’ll have a look.
Excellent. Thanks for doing this, it was a real priority (I’ll also have a look at your recent edits soon, but they look great).
Your advice to mig5 re: DispVM customization is suitable to be cut and pasted straight into a relevant section in your update BTW.
I think based on Whonix 14 being imminent and Qubes R3.2 being phased out in a little over 6 months, I agree focusing on Whonix 14 & R4 is best.
I’ll keep fixing links and minor edits, and then come back to backlog of larger things.
I made a bit of a mistake in the instructions.
Its not prefs templates_for_dispvms true that prevents Tor Browser from starting.
Its the dvm tag in the VM name anon-whonix-dvm that prevents Tor Browser start.
User would have to create an AppVM without dvm appended to the name. Customize Tor Browser (Noscript, Tor Browser security slider, etc). Then clone the AppVM with dvm appended to the name of the new VM. Then continue with the instructions using the new VM.
Instructions have been updated
However, to start Tor Browser in a dvm, the instructions Patrick provided makes more sense IMO:
https://whonix.org/wiki/Tor_Browser#From_the_Command_Line_or_Debugging_Mode
Done!
Removed “Install Software in TemplatebasedVM” from #Software
https://whonix.org/w/index.php?title=Software&oldid=35007&diff=cur
Migrated to #Install Software
https://whonix.org/w/index.php?title=Install_Software&oldid=35195&diff=cur
0brand:
I made a bit of a mistake in the instructions.
Its not prefs
templates_for_dispvms truethat prevents Tor Browser from starting.
Unfortunately not. I consider this an unclean implementation but for now
it’s the only possible way.
Its the dvm tag in the VM name
anon-whonix-dvm that prevents Tor Browser start.
Nitpick: Let’s please not call it a tag to avoid confusion with Qubes
tags. It’s the VM name ending -dvm.
User would have to create an AppVM without dvm appended to the name.
That’s cheating. 
I don’t like that at all because in future we won’t
check for -dvm in VM name but use a proper check.
To avoid invalidating the instructions in future, I would prefer:
A)
/etc/torbrowser.d/50_user.conf
tb_qubes_dvm_template() {
true
}
or B)
Manually starting Tor Browser while circumventing tb-starter
(/usr/bin/torbrowser).
or C)
I could easily implement a command line option --dvm-start or so to
allow running torbrowser --dvm-start and starting Tor Browser in DVM
Tempalte.
However, to start Tor Browser in a dvm, the instructions Patrick provided makes more sense IMO:
https://whonix.org/wiki/Tor_Browser#From_the_Command_Line_or_Debugging_Mode
The path is different. So Tor Browser Essentials
won’t work.
Just now documented here:
Tor Browser Advanced Topics
Could you please add somewhere advice on how to increase the quality of entropy pool? That would be advisable before sensitive cryptographic operations such as generating a gpg private key or crypto currency wallet / mnemonic seed etc. As I understand the linux kernel developers, the kernel entropy can never get worse even if users manage to produce no entropy at all.
Write random keyboard glibberish to a text file.
cat random-file > /dev/randomNo problem.
I can fix this as it just so happens I’ve gotten up to the Passwords section re: fixing links.
The goal is for connecting without enabling networking in TemplateVMs? Correct?
Haven’t given up. Still researching.
Migrating from Github GUI to .git CLI
Taking a little longer than I had hoped (learning syntax).
Whonix 14 Release forum post nits:
Other than that - congrats on the release! Lets see how everyone goes upgrading/re-installing…
Please check my edits to upgrade instructions. One of those Qubes packages is now in the stable repo, not the testing one (I fixed that). But could be other minor errors.
Could be good to double check since Whonix 14 has been announced.
torjunkie:
Whonix 14 Release forum post nits:
- VirtualBox .ova and libvirt qcow2 raw images were reduced by 35% correct? (it says just .ova at the minute)
Yes. Could you please edit the post (given moderation power)?
- Remove that “prefers onion sources line”, since that is no longer true.
It’s true. You might be misinterpreting some commit or forum message by me.
Other than that - congrats on the release! Lets see how everyone goes upgrading/re-installing…
OK, I’ll fix that.
http://phabricator.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/T812 ?
I see. Ticket description improved.
I was contemplating to drop support for Qubes R3.2. Makes development a
lot harder / time consuming to keep compatibility with both in mind.
Suffering from sunken cost fallacy.
0brand:
[quote=“Patrick, post:743, topic:3477”]
This very chapter: https://www.whonix.org/wiki/Dev/Qubes#Connection_through_Qubes_Updates_Proxy
Could you please test? And document a bit better?Also the following…
Qubes R3.2
http_proxy=http://10.137.255.254:8082 gpg.anondist-orig --recv-keys ...
Please forget about doing this in a TempalteVM for a second for testing
purposes. Does the gpg --recv-keys key work for you?
This is what is happening for me in a Debian VM.
gpg --recv-keys “916B 8D99 C38E AF5E 8ADC 7A2A 8D66 066A 2EEA CCDA”
gpg: keyserver receive failed: Server indicated a failure
http_proxy=http://10.137.255.254:8082 curl.anondist-orig check.torproject.org works for me in Qubes-Whonix 14 Qubes R3.2. Does
that work for you?
Qubes R4
http_proxy=http://127.0.0.1:8082 gpg.anondist-orig --recv-keys ...Would then be possible. What would be a good place to document this?
[/quote]
Does http_proxy=http://127.0.0.1:8082 gpg.anondist-orig check.torproject.org work for you in Qubes-Whonix 14 Qubes R4?
The goal is for connecting without enabling networking in TemplateVMs? Correct?
Correct.
Sounds reasonable with only 6 months left on that anyway.
PS Whonix 14 upgrade seems ok. However:
torjunkie:
Sounds reasonable with only 6 months left on that anyway.
PS Whonix 14 upgrade seems ok. However:
- Steps for install qubes-whonix-workstation (and gateway) are not necessary. They are already installed before that step.
Confirmed. Should be kept anyhow. This is only a safeguard to make sure Whonix distribution defaults as far as default package selection are enforced. Will only matter for users who previously uninstalled a Whonix meta package.
- Ditto the dom0 qubes-whonix-add-on (or whatever it’s called) - it’s already installed somewhere before that step.
Right, it is now a dependency of qubes-mgmt-salt-dom0-virtual-machines. Therefore can be removed.
- The qubes salt stuff to create the anon-whonix didn’t work for me (similar to mig5 from memory). Had to manually create one from Qubes Manager.
Error message? Was any TemplateVM / sys-whonix / anon-whonix already
existing? You mean iry / No error information when salt failed to create a VM due to name collision · Issue #4177 · QubesOS/qubes-issues · GitHub ?
I trust that is safe with anon-vm tags now (?)
Don’t. TODO: add missing Whonix tags anon-vm / anon-gateway to user created Whonix based VMs · Issue #4155 · QubesOS/qubes-issues · GitHub - But also don’t worry much about it for now as per Dev/Qubes - Whonix (just now written).
If not, how to check for tags etc?
Just now documented all of that:
Dev/Qubes - Whonix
It would certainly benefit Qube-Whonix development. Easier for everyone: devs., mantainers, etc
Same result
Yes both work
Neither one works
http_proxy=https://127.0.0.1:8082 curl.anondist-orig https://check.torproject.org curl: (6) Could not resolve host: check.torproject.org
http_proxy=http://127.0.0.1:8082 gpg.anondist-orig --recv-keys 0x427F11FD0FAA4B080123F01CDDFA1A3E36879494 gpg: keyserver receive failed: No keyserver available