I installed chromium browser in a debian-8 based standalone VM called 'work'. If I run, from dom0:
```
qvm-run work chromium
```
it outputs:
```
Running command on VM: 'work'...
```
but nothing happens. It is the same if I use shortcut desktop menu (which I guess executes the same command).
If, instead, I run `chromium` from within a terminal in 'work' it works fine.
I thought maybe it was a permissions problem with folder `~/.config/chromium`, but I granted everything to everybody just to check it and nothing changes.
I'm quite lost because, as there is nothing in dom0 stderr, I don't know how I could debug it.
I would be thankful for any help.
Thanks!
Thanks for your answer Andrew.
Thanks to a private reply I got, I have been seen that the problem is related with my `PATH`. I have installed chromium via nix package manager, and for this reason it is not in the `PATH` that dom0 is able to see. Answering your question, it happens with any other package I installed with nix.
It doesn't happen in my VM because there I have the `PATH` configured with zsh when I log in.
So, now, the question comes down to: how could I change my VM `PATH` seen from dom0? I tried with my VM `~/.profile` and `~/.bashrc` but without success. I suspect this may be related with another topic I open some time ago:
https://groups.google.com/forum/#!topic/qubes-users/G9F3EHpeU2Q
Thank you very much
Thanks for your answer Unman. The issue is that I installed it with nix package manager and then it ends up in another path. Please, see my previous reply for details.
Thanks for your answer haaber. Yes, I run that... now I see it is related with the application PATH. Please, see previous replies for details.
Hey Unman. The issue is that neither `~/.bashrc` nor `/etc/bash.bashrc` from my VM are used when I do `qvm-run` from dom0. Your workaround works but I think it is quite cumbersome. I wonder if there is any way to change the VM PATH seen from dom0 for every command.
Thanks
Yeah, you are right, this works. Thank you very much. But I don't quite understand. I guess that I'm opening an interactive non-login shell, but ~/.zprofile is sourced while ~/.zshrc isn't, while, from http://zsh.sourceforge.net/Intro/intro_3.html:
> `.zshrc' is sourced in interactive shells
> [...]
> `.zlogin' is sourced in login shells. [...] `.zprofile' is similar to `.zlogin', except that it is sourced before `.zshrc'
It returns `bash`
> and:
> qvm-run -a -p qube "ps aux"
It includes a `/bin/bash /usr/bin/qubes-session`
> You may be surprised.
Also, `echo $SHELL` returns `/bin/bash`.
I thought that maybe that `bash` process was in fact a subprocess of the actual `zsh` shell, but `ps aux|grep zsh` returns nothing.
So, yes, I'm very surprised, and now I understand even less why `~/.zprofile` is sourced... :)
Right
> That's su starting a shell as a login shell: as you have zsh as default
> shell, .zprofile is read to set env variables, including path.
>
> And I think you should have seen the output from qvm-run ps aux
> included something like "sh -c ps aux".
Right
> That call to sh is coming from qrexec-fork-server, I think.
>
> I hope that makes it a little clearer.
Not too much, but I guess I lack some background in qubes internals :)
> It would be interesting to see what happened if you were to relink sh
> to zsh in the template. I'm looking at a number of issues arising using
> some non default user shells(tcsh, fish)
Doing so:
$ qvm-run -a -p qube "echo $0"
# => sh
$ qvm-run -a -p qube "ps aux"
# Inclues
# => /bin/bash /usr/bin/qubes-session
# => su -l user -c /usr/bin/xinit
# => ps aux (without `sh -c` before)
$ qvm-run -a -p qube 'echo $SHELL'
# => /bin/zsh