My test machine is a lenovo t580 with intel udh620 as a graphics card. I installed sys-gui-gpu according to the documentation and got it to start properly once and it even worked moderately. Now when I try to restart it, the machine either ends up with a black screen or alternatively it restarts, I don’t even see the login screen. I have reinstalled r4.3, no effect. I would assume that sys-gui-gpu cannot remove the graphics card dom0 and crashes because of it. Has anyone gotten sys-gui-gpu to work and if so how. Damn sys-gui works great without gpu passthrough
While I also interested about this, for a very long time, I still see it as a very experimental - and optimistic - ‘feature’.
PCI Passtrough the only single GPU to a VM… 
sounds cool if it is working. But in practice, it will surely not for the first try. Might be not after many-many trial and error ‘session’
And it is a pain in the *ss to debug, especially as it is 90% depending in your actual hardware, BIOS, UEFI
What I can suggest as a starting point to ‘browse’ the related issues:
Just to be sure there are not extra expectations, sys-gui-gpu is absolutely not related to performance within qubes. It’s only an extra security feature that removes the GPU from Dom0 to reduce its attack surface.
As for the issue, I don’t really understand if things work or not after the reinstall?
I tried in on 4.3RC3. It sorta worked . . . lots of gui errors.
Hide the pcie of the display like for normal passthrough. Persisent attach the display pcie to sysgui. Make sure sysgui is set to autostart. After the grub screen you have to type in the luks password blind.
Things don’t work after reinstallation. I got sys-gui-gpu to start once exactly with the installation process guided by the documentation, but now it doesn’t work and always freezes on a black screen or resets the machine when starting up. I’m mainly wondering about the GPU passthrough that sys-gui-gpu uses, it seems to work sometimes and sometimes not. The only difference from other attempts is that on the first installation I rebooted the machine after installing sys-gui-gpu, which allowed me to get to the login screen and qubes os started, if I shut down the machine with the shutdown -h now command and restart I end up with a black screen, it seems very much like a GPU passthrough problem
Hmm, have you tried the no strict reset option?
No, what does that option do and where can I configure it? Do I install it in grub like I traditionally do in Linux? How do I get there? I’ve never adjusted grub on the fly.
uhd620 is the only GPU on the machine, no external graphics card, e.g. nvidia or amd, is available, apparently sys-gui-gpu should work whether the graphics card is integrated or not
Awesome, sys-gui-gpu starts correctly when I disable the thunderbolt controller in the t580 bios, apparently it interfered with the gpu passthrough. Now sys-gui-gpu doesn’t seem to have any kind of sound interface, no sound cards connected with the aplay-l command, how do I get the sounds to work on the machine, do I need to install sys-audio vm, i.e. a newer sound architecture
There are various options:
- keep audio in dom0 (the default) - while theoretically it may be made to work, currently there are two issues with this:
- since dom0 don’t have GUI anymore, you can’t control volume (volumeicon doesn’t have any display to show on)
- normally pulseaudio/pipewire is started as part of the user session - since that isn’t present in dom0 anymore, nothing starts it; same applies to qvm-start-daemon (the thing responsible for starting qubes audio proxy - pacat-simple-vchan)
- Make sys-gui-gpu an audiovm too - this is probably the easiest option, should be as easy as attaching audio device to your sys-gui-gpu and switching global
default_audiovmproperty to sys-gui-gpu. - Create separate sys-audio - follow the guide, should be the same with sys-gui-gpu as with dom0 (but you need dom0 access to set it up…).
FWIW, we have a CI test for sys-gui-gpu, but it checks only very basic stuff (especially, audio is not involved). You can watch video at Qubes OS openQA: Video
Great, is there any documentation for sys-audio on how to configure it. On the other hand, the default setting default audiovm and attaching the sound card to sys-gui would be a viable option. Qubes-template-manager doesn’t seem to be able to load the template list, so downloading new templates of debian fedora via sys-gui-gpu doesn’t work. Is this due to the sys-firewall settings or should sys-gui-gpu be allowed to use dom0 interfaces via the qrexec daemon. The qubes-update graphical tool also doesn’t open, although I see a notification that updates are available.
See Audio qube
Do you get some specific error? Theoretically it should work…
This unfortunately is a known limitation for now - Unable to use Qubes Updates on `sys-gui`: [Errno 13] Permission denied · Issue #8934 · QubesOS/qubes-issues · GitHub
Error when opening template manager is failed to fetch template list error sys-firewall. It seems to be related to sys-firewall and its rules, as if the template manager does not have permission to access the network. In Qubes-manager, besides sys-gui-gpu, there are no other virtual machines or templates from which they could be created. Only dom0 and sys-gui-gpu. Is this a known issue, when I tested just sys-gui, the templates were visible. Additionally, the qubes global config graphical configuration program seems to crash immediately upon startup, there is no more informative hint, just an error something went wrong. Would it be more sensible to use sys-gui and wait for the sys-gui-gpu problems to be resolved with updates?
Hm, have you changed the global “default_guivm” property to sys-gui-gpu? You should see all the qubes there…
Default_guivm is still the default, so apparently dom0, I assumed that the sys-gui-gpu installation would do this automatically. Can I do this from the sys-gui-gpu command line with the qubes prefs default_guivm sys-gui-gpu command, or does it require access to dom0 which I can’t log in to directly because sys-gui-gpu is installed
You can try from sys-gui-gpu, depending on other settings (especially if this part got applied) it may work.
Thanks for this, is the admin vm the management machine where updates and other dom0 management operations are done, in this case sys-gui-gpu. Is it the intention in future versions of qubes to completely separate dom0, so dom0 would only be left with a very minimal architecture xen etc
Yes, this is the long term goal, but there is a lot of things to do before we’re there…
1 Like
sys-gui-gpu seems to crash and end up with a black screen when connecting a usb sound card to the machine. So I do this via dom0 qubes global configuration device assignment by adding a new rule that automatically connects the usb sound card to this qube.
edit
Apparently the problem is not with usb passthrough but with the option
qubes-prefs default_guivm sys-gui-gpu. Without setting this option dom0 sys-gui-gpu boots, when I set the option I end up with a black screen. I am trying to solve the problem with this option where other vms or templates are not visible in the sys-gui-gpu qube manager, especially dom0 and sys-gui-gpu.