Sys-gui in Qubes 4.1 - devel

When I tried to update the xfce template via Qubes updater, no error message appears and it looks like update happened and Updater still says that updates available for fedora-32-xfce.
Then I tried to update via Qubes Manager and there I got this message that those mentioned packages are not available. Main reason was qubes-artwork was not provided by anything and rest three depends on it, I think according to message.

Problem: package xfwm4-1000:4.14.2-1.fc32.x86-64 requires qubes-desktop-linux-common, but none of the providers can be installed.
- package qubes-desktop-linux-common-4.1.2-1.fc32.noarch requires qubes-manager, but none of the providers can be installed.
- cannot install best update candidate for package xfwm4-4.14.5-1.fc32.x86_64
- nothing provides qubes-artwork needed by qubes-manager-4.1.9-1.fc32.noarch 
(try to add '--skip-broken' to skip uninstallable packages)
Press Enter to shutdown.

Ok, looks like two separate issues should be filed in qubes-issues: one for each of these last two posts. (Please search first to avoid duplicates.) Both are beyond my knowledge to provide any immediate help here in this forum.

I can imagine that this might be the cause:

Note this is still highly experimental feature.

Ok, these packages are available in current-testing which I enabled by editing in fedora-32-xfce-
sudo gedit /etc/yum.repos.d/qubes-r4.repo
So then main issue is that when we follow command 3, fedora-32-xfce get downloaded if not already installed and it contain same file unedited and so process although seems to complete, actually isn’t completed. This edit solves both problems mentioned here.
Yet it is an testing feature I think this I will report in same issue already present.
Although I was unable to start any vm with sys-gui as guivm as although my vm starts but no firefox launched. :sweat:
Edit: On second thought, Can you link back this discussion if you consider it appropriate in issue #5662. (as I don’t have a github account and github registration doesn’t work in tor browser I think)

No problem. Done.

@adw It is worth to highlight somewhere that when installing a devel Qubes version, like R4.1, to not rely on a working feature (especially very experimental) without current-testing repos. Side effect: very critical updates occur like recent Xen upgrade. Still, it’s a devel version and from my humble point of view, I would not set it as “User support” but mostly “Testing/Devel support”. That would help to separate threads.

1 Like

You need to either logout of lightdm and change session to select GuiVM one or in dom0, run qvm-run -p --no-gui --service sys-gui qubes.GuiVMSession. It’s not yet documented…


I think this is a very good proposition!

Impressive! I didn’t know that sys-gui has been developed this far. I’ve read about it in the news and was reminded of it again here just a few days ago.
I am looking very much forward to sys-gui being implemented & to reading some documentation in the future!

I only tested this briefly and it looks like it is working like you described either by choosing GuiVM during login or running the above mentioned command in dom0.

I’ve added a test-vm by running
qvm-prefs test-vm guivm sys-gui
which adds the test-vm to the menu & manager in sys-gui. Do I have to add applications as well and/or some policy somewhere? When trying to run a terminal in the test-vm I am getting a BrokenPipeError and a pop-up notification “Denied.qubes.VMShell from sys-gui to test-vm”. So, I guess this is expected behavior and I have to set some policy rule? I am lost here.

Thanks for your great work on Qubes! 4.1 looks very promising already.

Starting app in sys-gui of test-vm normally works out of the box but it reminds me some issue I had already. I would need to check that.

Probably not easy to show a fingerprint of the work done on R4.1 but the release changelog promises to be kind of huge.

This is the error message:

[user@sys-gui ~]$ qvm-run test-vm terminal
Running 'terminal' on test-vm
Traceback (most recent call last):
  File "/usr/bin/qvm-run", line 5, in <module>
  File "/usr/lib/python3.8/site-packages/qubesadmin/tools/", line 308, in main
    proc, copy_proc, local_proc = run_command_single(args, vm)
  File "/usr/lib/python3.8/site-packages/qubesadmin/tools/", line 205, in run_command_single
BrokenPipeError: [Errno 32] Broken pipe

In addition to that a pop-up tells me that

qubes-core-admin-client quit unexpectedly [version: 4.1.9-1.fc32.noarch]

What about xterm or gnome-terminal?

Of course, I tried xterm, firefox etc. and the error is identical.

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.

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.