Qubes 4: Unable to get any DVM app to ever launch

77 views
Skip to first unread message

Otto Kratik

unread,
Oct 30, 2018, 10:28:03 PM10/30/18
to qubes-users
Qubes 4.0


Whenever attempting to launch an app in a DVM, the result is always the same. The popup message comes up saying "Disp1234 has started", and then nothing happens. Then about two minutes later, another popup says "Disp1234 has halted". No app ever launches.

It doesn't matter what app I try.. xterm, konsole, firefox, dolphin, thunar, tor browser, gedit, kwrite etc. Always the same behavior. Also doesn't matter if I try from Q Menu shortcuts, command line in dom0, command line in another AppVM.. no difference. Just the same type of message in the terminal, says it's launching, then shuts down two minutes later with no output.

Doesn't make a difference either if I try to open a file in a DVM or just straight launching an app. Nothing ever opens. Launching apps regularly from normal AppVM's works perfectly all the time, just not DVM's.

Slight correction: About 1 in 10 times, launching Firefox from a Fedora-template-based DVM succeeds. The other 9 times it fails. All other apps fail 10 out of 10 times. And launching any app (including Firefox) from a Whonix-ws-14-template-based DVM also fails 100% of the time as described above.

How is this issue best investigated and resolved?

awokd

unread,
Oct 31, 2018, 7:49:43 AM10/31/18
to qubes...@googlegroups.com
Otto Kratik wrote on 10/31/18 2:28 AM:
Have you upgraded to Whonix 14 or customized the DVM? Try removing it
completely (you might have to temporarily change DVM defaults to a
different template), then recreating it with `sudo qubesctl state.sls
qvm.whonix-ws-14-dvm`. If that doesn't work, see
https://www.whonix.org/wiki/Qubes/Uninstall and
https://www.whonix.org/wiki/Qubes/Install to completely uninstall and
reinstall the workstation template and DVM. You can skip the gateway
steps if you've already upgraded it to 14 since it sounds like that's
still working.

Otto Kratik

unread,
Oct 31, 2018, 3:27:06 PM10/31/18
to qubes-users

It's a fresh install of Qubes 4 with freshly downloaded/installed Whonix 14/DVM templates using the salt/qubesctl command mentioned above and in the documentation. No customisations. So I doubt reinstalling would have any effect.

Whonix-ws-14 template works perfectly fine for running apps the normal way, from AppVMs based upon it. No issue whatsoever. Only running them from whonix-ws-14-dvm causes trouble.

However as I said, even trying to run apps from Fedora-26-dvm also fails the majority of the time, so I'm not even convinced it's a whonix specific issue. Rather a DVM one in general.

Any other things to try?

awokd

unread,
Oct 31, 2018, 5:56:03 PM10/31/18
to qubes...@googlegroups.com
Otto Kratik wrote on 10/31/18 7:27 PM:
I missed that; you did mention Fedora too. Strange. You can try
"qvm-prefs fedora-26-dvm qrexec_timeout 120" (and for whonix-ws-14-dvm)
to raise the timeout from 60, but even 60 should be plenty of time to
start a DVM. Have you updated dom0 & templates?


unman

unread,
Nov 1, 2018, 10:13:36 AM11/1/18
to qubes-users
I would try this:
Install all updates in dom0 and qubes.
Create a new Fedora based qube.
Confirm you can run programs as expected.
Make it a template for dispvms, using qvm-prefs.
Close all unnecessary qubes.
Then , at command line, start to test running programs in dispvms based
on the qube.

Generally , the command should be:
qvm-run --dispvm <qube> <command>

That's the most basic form.
Anything you can run using qvm-run <qube> <command> should work in
disposableVM based on qube (except gnome-terminal)

That will test the basic infrastructure.

If all is good, start testing a more complex form:
qvm-run -a --service --dispvm=<qube> --qubes.StartApp+<command>

<command> here should have an associated desktop file.
Again, anything you can run using qvm-run --service <qube> <command> should work in
disposableVM based on the qube (except gnome-terminal)

That will test the more complex infrastructure.

If all's good, you can start testing different template based qubes,
including Whonix. If it's not good there's something fundamentally
broken.

qvm-run *does* have -v option, but it doesn't generate verbose output.

Check back when you have some results from testing.

unman



Otto Kratik

unread,
Nov 3, 2018, 6:14:01 PM11/3/18
to qubes-users


Hi, thanks for your detailed reply and suggestions. Here is what I have found:

I created a new qube/AppVM based on the fedora26 template, and called it 'fedoratest'. I also enabled it as a DVM template using qvm=prefs. Running all of the following commands from dom0 worked perfectly:

qvm-run fedoratest firefox
qvm-run fedoratest nautilus
qvm-run fedoratest gedit
qvm-run --dispvm fedoratest firefox
qvm-run --dispvm fedoratest nautilus
qvm-run --dispvm fedoratest gedit

However, as soon as I introduced the '--service' argument into the picture, everything stopped working. All of the following commands fail silently:

qvm-run -a --service fedoratest firefox
qvm-run -a --service fedoratest nautilus
qvm-run -a --service fedoratest gedit
qvm-run -a --dispvm --service fedoratest firefox
qvm-run -a --dispvm --service fedoratest nautilus
qvm-run -a --dispvm --service fedoratest gedit
qvm-run -a --service -- fedoratest qubes.StartApp+firefox
qvm-run -a --service -- fedoratest qubes.StartApp+nautilus
qvm-run -a --service -- fedoratest qubes.StartApp+gedit
qvm-run -a --service -- fedoratest qubes.StartApp+firefox
qvm-run -a --dispvm=fedoratest --service qubes.StartApp+firefox

In all cases above, the relevant AppVM (or dispvm) starts running if it wasn't already, but nothing EVER launches. The situation is exactly the same with Debian and Whonix based AppVM/DVM/templates. Any command that doesn't involve using '--service' works fine. Any that do use it fail silently, without exception.

What is likely causing this issue and how is it fixed?

unman

unread,
Nov 4, 2018, 8:22:33 AM11/4/18
to qubes-users
Thanks for the extensive troubleshooting.

It looks as if there's a problem *either* with the service *or* with the
desktop files on fedoratest.
Can you check the contents of /etc/qubes/rpc/policy/qubes.StartApp to
make sure that you dont have a "deny" statement at the top of that file?
You could temporarily insert a line at the top:
dom0 $anyvm allow
$anyvm $anyvm allow

Just concentrate on using:
qvm-run -a --service --dispvm=fedoratest -- qubes.StartApp+firefox (or
gedit)
Check the log file in /var/log/qubes : you should see a log created for
whatever dispVM is atrted and qubes.log updated.

unman

Otto Kratik

unread,
Nov 5, 2018, 4:56:00 PM11/5/18
to qubes-users


So during testing, even though I'd stopped all other VMs from running, I started noticing some odd slowdowns and other memory-related issues, wondered if RAM shortage was affecting my attempts, and decided to reboot and try again from scratch with no autostart VMs enabled.

After that, I am now able to run pretty much any app in a Debian or Whonix based DispVM without issue. In Fedora based DVMs, some apps like Firefox, Filezilla, Calculator etc all run fine from the DVM menu, while other apps such as Gedit and Nautilus/Files simply don't seem to want to act as the "launch leaders" for DispvM's.

Meaning, the DispVM gets launched, but those apps don't open, and then the DVM halts again a minute or so later, as previously described. If I launch Firefox instead first in a Fedora DVM, and then from the widget select "Run terminal" for that very same already-open DVM, I can then launch Gedit or Nautilus or any other app from the command line without any problem. But those apps won't open as the initial "launch-apps" for Fedora DVMs.

By contrast, in Debian DVM's I can launch KWrite or Dolphin or whatever other equivalents easily, a well as Firefox or Tor Browser, and so far haven't found one that refuses to launch.

Thus it seems like a bit of an interoperability quirk between Fedora26 and the DVM system, so far as I can tell. Results are the same whether trying from gui menu or dom0 command line, though admittedly with some apps like Gedit, I am unsure which of the following I should be typing:

qvm-run -a --service --dispvm=fedoratest -- qubes.StartApp+gedit
qvm-run -a --service --dispvm=fedoratest -- qubes.StartApp+org.gnome.gedit
qvm-run -a --service --dispvm=fedoratest -- "qubes.StartApp+Text Editor"

All of them fail in the same way, however.. so I'm not sure it makes much difference.

Out of curiosity for comparison, are you able to launch Gedit or Nautilus/Files in a Fedora based DVM without issue, as the initial launch-app either from the menu or command line?

unman

unread,
Nov 6, 2018, 10:29:49 AM11/6/18
to qubes-users
I'm glad that some progress is being made.
I wonder if there's some issue with the desktop files in Fedora which
are preventing those applications from running? Those symptoms are
exactly those that fit with problems with the desktop files.
I dont have Fedora here to test, I'm afraid: Debian and BSD only.

If you open a Fedora based qube, do the applications work if you try to
open files that would use them? I mean create text file, and then double
click on it in nautilus, etc etc

unman

Otto Kratik

unread,
Nov 9, 2018, 5:09:30 PM11/9/18
to qubes-users


If I run a fedora based qube normally, all of those applications open and run completely fine, whether I launch them on their own or open files that would naturally use them as their default handlers. Gedit and Nautilus etc are perfectly willing to act at launch-starters for a fedora based qube, as long as that qube is a regular AppVM and not a DVM-template.

It is *only* when trying to open those apps as launch-starters from DVM templates (such as fedora-26-DVM) that they refuse to open. Other apps like Firefox/Calculator open fine as launch-starters for fedora DVM's, and once open, I can run-terminal from the widget for that Disp8375 or whatever, and from that terminal launch Gedit or Nautilus or whatever, no problem.

Only trying to start a new fedora based DVM with some specific apps (gedit, nautilus) fails, with the Disp7473 halting a minute or so after it initially launches, without ever opening the requested app. Debian/Whonix DVM's seem to have no such issue with any apps, at least that I've noticed. Only fedora.

Honestly, it's a tiny bit of an inconvenience but at this point it's far more of an odd minor quirk than a major show-stopping issue, and thus I'm not sure I want to take up more of your or anyone else's troubleshooting time on something so relatively inconsequential. At the beginning I couldn't launch any DVM of any type no matter what, but I think that was more an available-memory issue than anything else.

I appreciate all your assistance, as well as that of awokd.

Reply all
Reply to author
Forward
0 new messages