How to enable the (new) GUI VM?

User Support General
21

I gave sys-gui-gpu a go. I first ran into into the dummy-psu-dom0 → dummy-psu-sender issue above, I guess that has not been release yet.

After patching sys-gui.sls, I ran into the qubes-input-trigger not found errno 2 reported above too.

I fixed that: Fix for no such file error starting sys-gui by face · Pull Request #415 · QubesOS/qubes-core-admin · GitHub. After applying my PR as a patch in dom0, you must restart the qubes manager api: sudo systemctl restart qubesd.service

I then had to disable the gui-vm with qubesctl, delete the VMs, and run the setup again with qubesctl as sys-gui-gpu was not configured properly from not booting during the salt scripts.

Made progress, but now I’m stuck.
sys-gui-gpu is working, and happy, except I cant see it. On sys-gui-gpu’s console, I see lightdm is running via my 2nd Nvidia GPU and nouveau drivers (I have a newer card and the proprietary drivers don’t work with xen but seem to be working with nouveau in sys-gui-gpu which is farther than I got in dom0 with this card).

dom0 still has my intel GPU and control of the monitors. I tried qubes-prefs default_guivm sys-gui-gpu…but dom0 still has the monitors. The setting seems to work for all other VMs and they send their screens to sys-gui-gpu. which I can not see. At one point in all this, I did get a lightdm login screen take over my KDE desktop…but could never reproduce that.

In another thread @fepitre says to log out and run a GuiVM session or run qvm-run -p --no-gui --service sys-gui-gpu qubes.GuiVMSession. The command returns Timed out waiting for Xorg display :1. If I log out , I can’t figure out how to “start a GuiVM session”. I’m running KDE, and sddm has no option. I stopped sddm and started lightdm, but still see no option for a GuiVM session. I don’t see a way or service to start a GuiVM session w/out lightdm or sddm running. Ref: Sys-gui in Qubes 4.1 - devel - #16 by fepitre

It actually makes no sense to me dom0 is still running a DM when lightdm is running on sys-gui-gpu, so I tried changing the runlevel of dom0 to multi-user.target…but dom0 still has the monitors, just a text console instead of a GUI. Note: If I try to give the intel GPU to sys-gui-gpu, insta hard boot of the entire laptop (xen crashes). Then, same crash on boot when sys-gui-gpu starts (I think because dom0 is using it, and xen doens’t like two VMs using the intel GPU at the same time). I can’t figure out how to tell dom0 to give up the GPU and let the sys-gui-gpu take over.

4 Likes
22

This is only for sys-gui not sys-gui-gpu.

23

Thanks. I see now I can hide cards from dom0 using qvm-pci and then kernel options similar to rd.qubes.hide_pci=0a:00.0,0a:00.1

I’ll give sys-gui-gpu another go when I have time now that I see I can hide the intel GPU from dom0 and pass it too.

I also found a bios option to bypass the intel and send all output from the nvidia…might be useful too.

24

the same question

1 Like
25

@face
Thanks for the fix!

Just a reminder to myself and others who might encounter the same:
After enabling and starting sys-gui-gpu my wireless mouse didn’t work anymore although it was recognized.
I ran the command for creating my sys-usb again, in my case
sudo qubesctl state.sls qvm.sys-usb
and there was a total of 9 states run with 2 changes.

After that I removed my USB receiver and plugged it in again and the mouse is working again.

1 Like
26

Thanks, while the qvm.sys-usb did some updates, still no input on sys-gui-gpu. However, I have a usb mouse and keyboard I passed and that works.

So I played some more, and setting the bios for my nvidia card to have the ports worked for my external monitors and sys-gui-gpu. dom0 holds the intel GPU and sys-gui-gpu has the nvidia passed to it. Lol, it really feals like I have two computers now (sys-gui-gpu on the external monitors and dom0 on the laptop screen which is hard wired to the intel GPU).

I’m using the noveau driver as the proprietary are blocking my card in a linux VM. Performance is around the same as with dom0 gui, maybe a little less with video. You can render video in sys-gui-gpu and get better preformance, but that defeats the security model.

I was able to install KDE on sys-gui-gpu (on the fedora-33-xfce template), and set qubes-prefs default_guivm sys-gui-gpu and all my VMs worked ok in sys-gui-gpu. The only issue I ran into was my usb device menu was not working (not sure if that broke with KDE or was always broke). Worked around this by using dom0 on the laptop screen.

I would love to plow ahead with a audio VM and run this way but can’t because dom0 still has the intel GPU and laptop monitor and keyboard. If I try and pass the intel GPU to sys-gui-gpu, xen crashes the computer as both dom0 and sys-gui-gpu are trying to use the GPU at the same time. I can block the intel GPU from dom0 to pass it, but then I can’t type my luks password and boot the computer. So till I can figure out how to get dom0 to give up the GPU when sys-gui-gpu boots…and then how to access dom0? Sys-gui-gpu doesn’t have things I need like qvm-usb.

So to summarize, sys-gui-gpu works great on my external monitors with my nvida GPU. But, I’m at a loss how to get dom0 to let go of the intel GPU after we boot so I can pass it to sys-gui-gpu and use the laptop monitor in sys-gui-gpu. Then, how do I access dom0?

27

20210823_155431_632947122
20210823_155431_6329471221040×780 84 KB

How long should I wait for the last command to end… (Motherboard : GA-970A-DS3P, FX 4300, GTX750Ti, Qubes 4.1 alpha)

28

A really long time, depending on your bandwidth. It is downloading the fedora-33-xfce template which depending on your bandwidth could take a while.

29

Isn’t that built on Fedora-34 ??? Anyway I have a pretty fast GPON connection of 30 Mbps up/down but it does not ends at 45 mins. dom0 does not gives any result about what is happening. Shall I give it a try again ?

30

I got error code 1. Please find the output of dom0 terminal.

[Anirban@dom0 ~]$ sudo qubesctl top.enable qvm.sys-gui
local:
----------
qvm.sys-gui.top:
----------
status:
enabled
[Anirban@dom0 ~]$ sudo qubesctl top.enable qvm.sys-gui pillar=True
local:
----------
qvm.sys-gui.top:
----------
status:
enabled
[Anirban@dom0 ~]$ sudo qubesctl --all state.highstate
[ERROR ] Command ‘systemd-run’ failed with return code: 1
[ERROR ] stdout: Running scope as unit: run-rc28f9fd9937b4a92af56de82f7460ead.scope
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time…
Running ‘/usr/lib/qubes/qubes-download-dom0-updates.sh --doit --nogui ‘–exclude=qubes-template-whonix-gw-15,qubes-template-debian-10,qubes-template-fedora-34,qubes-template-whonix-ws-15’ ‘-y’ ‘–best’ ‘–allowerasing’ ‘–clean’ ‘–action=install’ ‘qubes-template-fedora-34-xfce’’ on sys-firewall
sys-firewall: command failed with code: 1
[ERROR ] retcode: 1
[ERROR ] Error occurred installing package(s). Additional info follows:

errors:
- Running scope as unit: run-rc28f9fd9937b4a92af56de82f7460ead.scope
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time…
Running ‘/usr/lib/qubes/qubes-download-dom0-updates.sh --doit --nogui ‘–exclude=qubes-template-whonix-gw-15,qubes-template-debian-10,qubes-template-fedora-34,qubes-template-whonix-ws-15’ ‘-y’ ‘–best’ ‘–allowerasing’ ‘–clean’ ‘–action=install’ ‘qubes-template-fedora-34-xfce’’ on sys-firewall
sys-firewall: command failed with code: 1
[ERROR ] ====== [‘present’] ======
====== stderr ======
/usr/bin/qvm-create sys-gui --class=AppVM --template=fedora-34-xfce --label=black
app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details.

====== [‘prefs’] ======
Virtual Machine does not exist!

====== [‘service’] ======
[SKIP] Skipping due to previous failure!

====== [‘features’] ======
[SKIP] Skipping due to previous failure!
local:

      ID: topd-always-passes
Function: test.succeed_without_changes
    Name: foo
  Result: True
 Comment: Success!
 Started: 20:01:57.951700
Duration: 0.984 ms
 Changes:   

      ID: qubes-template-fedora-34-xfce
Function: pkg.installed
  Result: False
 Comment: Error occurred installing package(s). Additional info follows:
          
          errors:
              - Running scope as unit: run-rc28f9fd9937b4a92af56de82f7460ead.scope
                Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
                Running '/usr/lib/qubes/qubes-download-dom0-updates.sh --doit --nogui '--exclude=qubes-template-whonix-gw-15,qubes-template-debian-10,qubes-template-fedora-34,qubes-template-whonix-ws-15' '-y' '--best' '--allowerasing' '--clean' '--action=install' 'qubes-template-fedora-34-xfce'' on sys-firewall
                sys-firewall: command failed with code: 1
 Started: 20:02:02.712592
Duration: 292687.428 ms
 Changes:   

      ID: dummy-psu-sender
Function: pkg.installed
  Result: True
 Comment: The following packages were installed/updated: dummy-psu-sender
 Started: 20:06:55.400359
Duration: 26406.807 ms
 Changes:   
          ----------
          dummy-psu-sender:
              ----------
              new:
                  1.0.0-2.fc32
              old:

      ID: dummy-backlight-dom0
Function: pkg.installed
  Result: True
 Comment: 1 targeted package was installed/updated.
 Started: 20:07:21.849464
Duration: 24626.707 ms
 Changes:   
          ----------
          dummy-backlight-dom0:
              ----------
              new:
                  1.0.0-2
              old:

      ID: /usr/share/xsessions/sys-gui.desktop
Function: file.managed
  Result: True
 Comment: File /usr/share/xsessions/sys-gui.desktop updated
 Started: 20:07:46.507336
Duration: 82.714 ms
 Changes:   
          ----------
          diff:
              New file

      ID: sys-gui
Function: qvm.vm
  Result: False
 Comment: ====== ['present'] ======
          ====== stderr ======
          /usr/bin/qvm-create sys-gui --class=AppVM --template=fedora-34-xfce --label=black 
          app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details.
          
          ====== ['prefs'] ======
          Virtual Machine does not exist!
          
          ====== ['service'] ======
          [SKIP] Skipping due to previous failure!
          
          ====== ['features'] ======
          [SKIP] Skipping due to previous failure!
 Started: 20:07:46.603628
Duration: 818.917 ms
 Changes:   

      ID: sys-gui-rpc
Function: file.managed
    Name: /etc/qubes/policy.d/50-gui-sys-gui.policy
  Result: True
 Comment: File /etc/qubes/policy.d/50-gui-sys-gui.policy updated
 Started: 20:07:47.422933
Duration: 21.854 ms
 Changes:   
          ----------
          diff:
              New file

      ID: sys-gui-admin-local-rwx
Function: file.append
    Name: /etc/qubes/policy.d/include/admin-local-rwx
  Result: True
 Comment: Appended 2 lines
 Started: 20:07:47.445158
Duration: 21.312 ms
 Changes:   
          ----------
          diff:
              --- 
              
              +++ 
              
              @@ -8,3 +8,5 @@
              
               
               ## Add your entries here, make sure to append "target=dom0" to all allow/ask actions
               
              +sys-gui @tag:guivm-sys-gui allow target=dom0
              +sys-gui sys-gui allow target=dom0

      ID: sys-gui-admin-global-rwx
Function: file.append
    Name: /etc/qubes/policy.d/include/admin-global-rwx
  Result: True
 Comment: Appended 3 lines
 Started: 20:07:47.466618
Duration: 3.329 ms
 Changes:   
          ----------
          diff:
              --- 
              
              +++ 
              
              @@ -8,3 +8,6 @@
              
               
               ## Add your entries here, make sure to append "target=dom0" to all allow/ask actions
               
              +sys-gui @adminvm allow target=dom0
              +sys-gui @tag:guivm-sys-gui allow target=dom0
              +sys-gui sys-gui allow target=dom0

Summary for local

Succeeded: 7 (changed=6)
Failed: 2

Total states run: 9
Total run time: 344.670 s
DOM0 configuration failed, not continuing
[Anirban@dom0 ~]$

31

What kind of “passing mouse and keyboard” did you use ? I tried attaching my USB controllers to sys-gui-gpu, but that did not help.

I’m starting to see my AMD iGPU attached to sys-gui-gpu: after using no-strict-reset, I’m now getting a “registered successfully” message in guest-sys-gui-gpu-dm.log, and a lightdm displayed, but cannot interact with it.
OTOH guest-sys-gui-gpu.log shows failed to start issues for lightdm, and journalctl in dom0 shows another lightdm starting first. The Xorg.0.log.old I can look at afterwards in dom0 uses fbdev and not direct access to the GPU. There does not seem to be any persistent logfiles from sys-gui-gpu to look at in the fs image, though.

It does not seem necessarily wrong to have a Xorg server in dom0, it could be normal to have one to work with the GUI agent. But then, it does not seem to use any of the qubes drivers, and still having lightdm starting there seems definitely wrong: @fepitre what kind of mechanism is supposed to prevent that one from starting ? It also strikes me that the Xorg log does show both the iGPU and dGPU PCI devices (both are supposed to be “protected” from initialization/use in dom0, using pci-stub).

32

If I boot with video=efifb:off, I’m unsurprisingly left in the dark during the boot, and have to blindly enter my LUKS passphrase. But after this, if the Xorg/lightdm normally showing up was the one from sys-gui-gpu I’d have expected it to show here too – but no, nothing appeared, so I guess what I was seeing was still coming from dom0… which seems to confirm my above doubts.

33

if i understand it correctly, mamarek only added the info about the grub parameters to preemptively help, in case executing the salt commands break your system. you won’t need to edit the grub parameters if everything goes as planned.

34

@emmi, right!

35

I also gave sys-gui-gpu a try. I only have an iGPU, so when hiding it from dom0 I also have to type the LUKS passphrase blindly.
However, lightdm in the sys-gui-gpu qube doesn’t seem to start, I only have a black screen in the end. Is there any way to debug this? As mentioned by @yann it looks like there are no persistent logs.

36

What kind of iGPU do you have ?
With my AMD Renoir I have at times tried to completely disable the display, but usually I just avoid dom0 using it as a PCI device (through pci-stub.ids=...), on the premise that FB_EFI from dom0 should not prevent amdgpu from starting any more than its usage by the BIOS. I could be wrong, but at least I’m under the impression I’m indeed making progress, however small.

@ctr you don’t have persistent userspace logs, but there are still several saved logs if you manage to enter your LUKS key (for next boot if you had to do it in the dark or suffer other blocking issues):

  • guest kernel: /var/log/xen/console/guest-sys-gui-gpu.log
  • stubdom: /var/log/xen/console/guest-sys-gui-gpu-dm.log
  • libvirt: /var/log/libvirt/libxl/libxl-driver.log and /var/log/libvirt/libxl/sys-gui-gpu.log
  • dom0’s journal also sometimes shows valuable info

Aside from that, you can also setup a serial console if needed (managed to did that at one point, requires a bit of configuration).

1 Like
37

Hi, I am not an advance user by any means, but have been tolling around with Qubes for some years. Usually breaking it and trying to undo how I broke it. I decided to go straight to the sys-gui-gpu setup and after changing the dummy psu dom0 to sender and running the qubesctl --all state.highstate in root i received the following:

-------------
Succeeded: 11 (changed=3)
Failed:     0
-------------
Total states run:     11
Total run time:  140.123 s
debian-11: SKIP (nothing to do)
fedora-34: SKIP (nothing to do)
fedora-34-xfce: OK
Debian-dvm: SKIP (nothing to do)
default-mgmt-dvm: SKIP (nothing to do)
fedora-34-dvm: SKIP (nothing to do)
per-deb: SKIP (nothing to do)
per-fedora: SKIP (nothing to do)
per-work-34: SKIP (nothing to do)
sys-firewall: SKIP (nothing to do)
sys-net: SKIP (nothing to do)
sys-usb: SKIP (nothing to do)
vault: SKIP (nothing to do)
sys-gui-gpu: OK

Thought i’d share. thinkpad T480
now to see how this baby works.

1 Like
38

Baby grown up? Toddler?

39

I’ve been able to get sys-gui-gpu working with my T430 single intel igpu (Ivy Bridge HD 4000) but its not working properly, tho.

I did this booting with “module_blacklist=i915 video=efifb:off” kernel params, then typing my LUKS pass blindly, opening a new tty (Ctrl + Alt + F2), loging in with my dom0 user and pass and blindly typing qvm-start sys-gui-gpu (as for some reason, it wont auto start even when I believe its supposed to).
That gets me a black screen (no backlight) which after around 2-3 minutes turns into a green-ish screen with flicker and a weird aspect ratio(?), but nontheless I could see lightdm and made it to login to desktop.

In this state its pretty unusable and I dont know if its some problem with my gpu being unsupported, some broken sys-gui-gpu vm or maybe some bad drivers (maybe even a bad vbios? Im.not sure how GPU passthrough works in Xen). I checked and i915 kmod is loaded in sys-gui-gpu.

Im not too sure how could I debug this so if anyone is kind enough to get me in the right direction I’ll aport any logs or whatever needed, many thanks.

40

running a w530 with k2000m dGPU and experimenting with sys-gui-gpu:

i followed @neowutran 's guide here to modify grub, hide my dGPU from dom0 and set the hvm boot ram: Qubes OS article

seems like i am making progress, but i am now stuck.

when i attach just the iGPU to sys-gui-gpu, i am able to start it from Qubes Manager after signing in. screen goes blank immediately as pci is passed to the hvm, then once it boots i am at a login screen again… but this time i am unable to use my normal credentials… just “user” and then when i’m logged in all i see is dom0 and sys-gui-gpu. this is somehwat useless. selecting “sys-gui” instead of XFCE session at login returns me to the login page.

ideally i would like to attach the nvidia k2000m, but when i do so alongside iGPU the screen stays blank, and when i attach nvidia alone the screen freezes on the last dom0 state as soon as sys-gui-gpu finishes boot and never changes over to sys-gui-gpu rendering. i am able to exit this state with ctrl-alt-del and sys-gui-gpu shuts down and dom0 refreshes the screen.

is there a way i can attach the nvidia card to sys-gui-gpu without it trying to take over the screen? this way i could qvm-run --pass-io the NVIDIA install script, and i might finally have a use for this dGPU.