I just erased my Whonix 13 templates/VMs in Qubes 4, and replaced with Whonix 14 as per the upgrade docs.
Post-install I ran sudo qubesctl state.sls qvm.whonix-ws-dvm, as I use Whonix DispVMs.
This created the whonix-ws-14-dvm as expected.
However, when I launch a Whonix DispVM’s TorBrowser, I get an error ‘Do not run Tor Browser in Qubes DVM Template!’
This is a surprise because I’m not intending on running it in a template - I’m launching a new DispVM from the Qubes ‘start’ menu (Disposable: whonix-ws-14-dvm -> Tor Browser), which previously always created a new DispVM.
So in fact, it seems that starting a DispVM is not actually starting a DispVM, it’s instead booting the whonix-ws-14-dvm TemplateBasedVM. I verified by checking in the Qube Manager that it’s actually booting the templatebased VM instead of starting a dispXXXX.
What is weird is I started/stopped it several times and I kept getting the DVM rather than the DispVM.
I started and stopped the DVM both deliberately (via Qube Manager) and accidentally (via the start menu → Disposable → whonix-ws-14-dvm), each several times, but I kept getting DVM.
If I get time I will uninstall all my Whonix 14 appVMs/templates and see if I reproduce it.
I definitely think it’s awkward UX if, after creating a DVM template, clicking Start → Disposable → (DVM) doesn’t actually create a Disposable VM, but it doesn’t sound Whonix-specific indeed.
I get similar behavior on fedora-26-dvm even after running qvm-features fedora-26-dvm appmenus-dispvm 1. That is, choosing a menu entry launches the dvm template instead of dispXXX.
Dragging and dropping the menu entry to the desktop creates a .desktop file that correctly invokes a disposable VM instance, rather than the dvm template itself.
It seems like choosing from the menu uses an older, cached .desktop file that runs the dvm template.
Logging out and logging in, appears to fix the issue (refreshes the cache?).
I’m currently documenting wiki Qubes-Whonix DispVM first startup vs subsequent startup. I followed your suggestions and uninstalled/renamed all my current Whonix 14 appVMs/templates and see if I reproduce it.
After reinstall I used salt to configure a new whonix-14-dvm
sudo qubesctl state.sls qvm.whonix-ws-dvm
I was not able to reproduce your results starting the DispVM from the appmenu or command line.
qvm-run --dispvm=whonix-ws-14-dvm torbrowser
The only way i was able to reproduce that behavior (dvm start not Dispvm) was to manually create and customize the dvm template (whonix-ws-14-vm) to allow Tor Browser to be started within the dvm.
Manually create:
qvm-create -t whonix-ws-14 -l red whonix-ws-14-dvm
The dvm is started instead of the DispVM and prompts to download Tor Browser.
Around the same time this thread was started there was another discussion about DispVM customization. Do you recall if you made any changes to Whonix TemplateVM?
Its not the custom configuration that does it. If a dvm is created and a default_dispvm is not set, the first start and n subsiquent starts (need to figure that out) will be the dvm instead of a DispVM.
Example:
1. Create a dvm template (with default_dvm set for the dvm)
qvm-create -t whonix-ws-14 -l red whonix-ws-14-dvm
Hi @0brand, it’s been a while, all I can reliably say is that I followed verbatim the steps at Release Upgrade - Whonix as they stood at the time.
I would’ve been copying commands straight from that doc, I can’t think of a reason I would’ve done anything extra or different, other than like you, I did run sudo qubesctl state.sls qvm.whonix-ws-dvm yet still ran into the issue.
One thing in that doc is the step sudo qubesctl state.sls qvm.anon-whonix which has a footnote saying ‘This applies all salt settings’. I presumably ran that command (since as per my original post above, I ran other state.sls commands) but couldn’t say for sure.
I don’t recall doing any other customisation of the DVM - though it’s certainly possible, as around the same time I was probably keen on getting some Tor Browser customisations into the DVM.
Its not the custom configuration that does it. If a dvm is created and a default_dispvm is not set, the first start and n subsiquent starts (need to figure that out) will be the dvm instead of a DispVM.
It’s only the first time in my experience. And it is a bug imo since
expected behavior is different from actual behavior. Would be very
helpful if you could report a Qubes bug!
If a dvm is created and a default_dispvm is not set
This sounds like a very surprising condition. An unrelated setting
having this effect. Speak: a bug.
This issue was previously reported but closed because they were unable to reproduce the behavior. Don’t think it matter if its a custom dvm (or 4RC3?). Behavior should be the same. Didn’t think duplicate issue was necessary? I added a comment and would imagine it will be reopened.