Sys-gui in Qubes 4.1 - devel

fedora-32-Xfce is missing packages and they are not downloadable. After successful install of template, 4 packages can not be installed.
Those are

These package leads to constant update notification for template and when we update the template no package get installed and that notification doesn’t go away.
@adw I think it’s a qubes-issue. should it be opened on Github? or maybe I missing something here?

1 Like

First of all, there is no template called fedora-32-xfce (AFAIK), so this is a signal that something weird is going on.

  • What exactly are you trying to do? Be specific.
  • What exactly did you do? Provide exact steps and commands.
  • What behavior did you expect to see? Be specific.
  • What behavior did you actually see? Provide exact error messages, etc.

Ok, I am on qubes 4.1
I have installed this template as it is needed for sys-gui. I have followed this-

The commands followed were written in comment. After third step fedora-32-Xfce gets installed and sys-gui domain is created but fedora-32-Xfce does not contain mentioned packages.
There is another user seems to be affected by same issue I think.
1 Like

@adw you have said that there is no template fedora-32-xfce but it is there-

1 Like

Ah, yes, I forgot that this existed.

Ok, but did you see Marek’s follow-up comment immediately after that?

Ah, indeed I placed --all in the wrong position. I’ve updated the comment.

You still haven’t provided any exact commands or exact results like I requested, so it’s very difficult to help you. We can’t help you if we don’t know what’s happening on your end.

sudo qubesctl top.enable qvm.sys-gui
sudo qubesctl top.enable qvm.sys-gui pillar=True
sudo qubesctl --all state.highstate
sudo qubesctl top.disable qvm.sys-gui
1 Like

And the results…?

What do you mean by “can not be installed”? No package found? Error message?

Third step succeded with total 7 run states and after that all templates and appvm name appears with ok and lastly we can say result were success with only one fail. Fail was for fedora-32-xfce with exit code 20.
When I see the logs of /var/log/qubes/mgmt-fedora-32-xfce.log
there were 4 states run. Out of them 3 were succeeded and 1 failed.

ID: sys-gui-xfce
Function: pkg.installed
Result: False
Comment: Error occurred installing package (s). Additional info follows.

Failed to return clean data
   Request refused
exit code: 20

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]