What about xterm or gnome-terminal?
Of course, I tried xterm, firefox etc. and the error is identical.
Off-topic:
I wasnât sure anymore if I had t run xfce4-terminal, gnome-terminal or just terminal. âqvm-run terminalâ isnât supposed to work, is it? (results in a âcommand failed with code 127â in dom0)
Edit: I tried that with debian and fedora VM (not that I knew if that would matter)
and I also tried on a fresh install of the latest build - with the same result.
Unfortunately, I donât know much about the inner workings of most stuff in Qubes and how it really should work when something doesnât work. I mostly search for solutions in qubes-issues.
No itâs not. You qvm-run something which exists in PATH of the target VM. Unless you install some program named terminal and put it in your PATH like in /usr/bin/ this will not work.
Thanks for the clarification! I was asking because it looked like it was starting a terminal and didnât result in an error.
Although I do work with CLI in Qubes regularly I usually do not use commands to start a terminal. Typing âterminalâ in âRun Programâ would have helped already (in distinguishing between gnome-terminal and xfce4-terminal).
Ok, so I tried it again (hmm). And yes this worked for me. Firefox started in test VM. I kind of think that my machine was little slow when I was using it. And can we call this command off once our VM starts.
qvm-run -p --no-gui --service sys-gui qubes.GuiVMSession
Thanks for reporting back!
So it looks likely that I am doing something the wrong way.
If you do have the time could you briefly tell me the steps you are taking in order to get this to work?
I guess, I must be doing something differently.
Edit:
I found my mistake (?), Iâve been running the command from within sys-gui (doesnât work) and from dom0 it does work.
Ok, I get excited early. It worked for one test vm (and yeah it worked for that absolutely fine) and now I am testing it with qubes-prefs. Only one VM that I am running successfully is whonix ws VM. What I faced is xss lock and Qubes- Manager crashed and message about VM shell like you faced which I am trying to figure out. And yeah I think I had user policy file to deny calls to VMshell etc so removing them. I will report back if I will be able to run other VM properly. Btw in Guivm session I am not having VM and their application entries in Q drop down menu. Then I used Alt +space tricks and ongoing testingâŚ
I noticed that as well.
I could have tried dom0 earlier (I thought I did). It looks like itâs working well so far from dom0 with selected VM. I will probably try setting this as global on another test install (I donât want to mess up the one I am using right now).
OK, It works from dom0. You cannot exit command till session ends. All VM can start and can be shut down. I removed my 30-user.policy file for my custom qrexec calls (I now think it was not needed or maybe).(I will retest it with my policy file)
Tray icon which are shown in sys-gui are Network manager of sys-net, sys-whonix icon, power line and audio with no audio output sign.
Tray icon which are shown in dom0 are Disk, Qubes-dom0 icon, Power line, clipboard and device widget.
One weird behaviour which I noticed is that I have two VPN VM, out of which one showed Notification in dom0 tray and one showed it in GUIVM tray, as I believe they should have been shown notification in sys-gui tray only.
Dom0 drop down menu shows all VM and entries like a normal Qubes installation is expected to show.
sys-gui drop menu only shows Run program, Terminal emulator, System tools, Qubes-tools and Logout.
xss-lock crash was related to me changing between sys-gui and dom0 interfaces with logout and login without shutdown.
I did have weird behavior concerning notifications in 4.1 before. For me, suspend did only work in 4.1 and the pop-up notification disappeared and only appeared again after resuming from suspend. When starting my VPN I lately did not get the pop-up window âLink is upâ.
Suspend is broken at the moment after updating Xen to 4.14. I havenât found the cause for the problem with the notification pop up yet. At least for you it is still working.
Btw, I do have the two selected gui-test-vm in the drop down menu in sys-gui.
As expected Reason was qubes-prefs was not able to set guivm of 3 VM to sys-gui. I manually set it for those three to sys-gui. (It should not have happened in first place.Is qubes-prefs broken in 4.1 for anyone.)
Suspend is not working for anyone, I think.
My Qubes Manager in sys-gui is showing all VM and I can start all VM with qvm-start from sys-gui terminal but no entry in drop down menu. I donât even know how to troubleshoot it further. Any Ideas?
Yes, I know.
I was referring to the notification for your VPN connection. I am having a little trouble with this at the moment. But that is something else.
Wait for some documentation in the future and maybe some help from @fepitre 
sys-gui drop down menu now have all VM listed. I went to settings of Almost each qube from Qubes-Manager of sys-gui and Refreshed applications and then entry appeared in sys-gui drop down Q-menu.
@Raphael_Balthazar I think you should give it a try.
Now the most important issue is that I donât know how to write my new user policy file when sys-gui has come into play as I have written it according to new format but without sys-gui in consideration.
@deeplow I am not able to rename the post. But I think this post should be renamed to-
sys-gui in Qubes 4.1 - devel support
1 Like
Whatâs the performance impact of using sys-gui? Youâd be adding yet another framebuffer to the mix, playing YouTube Videos for example wouldnât be a great experience.
The âcompromiseâ method seems a little too hacky for what it gives you, just my 2c. 2D/3D Accel is super important to a nice browsing experience, indeed it also makes it easier to side channel/inter-VM exploitation.
For that reason Iâm planning on waiting for Qubes/Xen to support proper GPU Pass-through of iGPUs via Intelâs GVT-g or SR-IOV.
I can only give you a first impression since I can hardly say to have either been using this long enough or really know how it should work at this level.
Youtube videos are running smooth even in 1080p full-screen (which is totally unnecessary on my old laptop). No complaints here at all so far. I didnât notice any difference and Iâve been running only selected VM on sys-gui. I guess, running only a GUIVM session shouldnât have an impact on the performance, should it?
2 Likes
Itâs almost perfect when you are running your session from dom0. All glitches mentioned in discussion here are mostly limited to the scenaerio when you are running session from sys-gui VM itself.
I am running sys-gui as default for all qubes but obviously from dom0 session.
Can you explain it in detail in case of sys-gui-
Donât we already have all GUI code in dom0?
One glitch is disposable VM are not shutting down by themselves. Even manual shutdown is not working properly. This is also occuring when you are operating via dom0. Can you give it a try @Raphael_Balthazar by setting sys-gui as guivm for disposable VM like fedora-32-dvm, if issue is reproducible?
Yes, the dispvm is not shutting down when closing for example firefox. I must admit that I have the same problem in Thunderbird, where I set the policy for hyperlinks to dispvm (and I am not sure if everything was 100% correct).
It is shutting down when stopping via Qubes Manager but there are a bunch of pop-up warnings. I guess, you meant those.
I think this might answer your question:
1 Like
Not only that, if it gets shut down, if should not be available in Qubes-Manager of sys-gui but you can see them in Manager even when they are halted. Is it same on your end?