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).
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.
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.
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.
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):
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.
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.
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.
I am having zero luck trying to get this working on a ThinkPad T15g Gen 1.
So far I’ve:
Fixed the whole dummy-psu issue
Disabled the i915 module
Attached only the NVIDIA card
Attached only the INTEL (i915) card
Every time I either get nothing at all on boot or if I run the qubesctl --all state.highstate command the list of tasks seems to complete and then the screen goes black, next thing I know I’m at the BIOS splash again.
Annoyingly there’s no last_kmsg in /proc in the default qubes kernel so that’s really unhelpful here. I’m pretty stuck on what to try next really.
A short status report from trying sys-gui and sys-gui-gpu on a qubes-os v4.1 install and the following hardware: ThinkPad T480, i7, 32GB RAM, 2TB SSD.
following the instructions under GuiVM Configuration | Qubes OS I got sys-gui to work easily, but running that setup I figured the desktop environment ist missing. The [sys-gui] Qube Manager doesn’t know about my qubes either. For the future I assume the qubes-team is going to mount a filesystem containing the environment in which-ever VM (dom0, sys-gui, sys-gui-gpu, sys-gui-vnc) is handling the graphical interaction with the user.
after changing dummy-psu-dom0 to dummy-psu-sender in dom0’s /srv/formulas/base/virtual-machines-formula/qvm/default/sys-gui-gpu.sls and attaching the intel iGPU to sys-gui-gpu with sudo qubesctl state.sls qvm.sys-gui-gpu-attach-gpu (this can also be done with the graphical Qube Manager by selecting the 00:02.0 VGA compatible controller: Intel [..]) I rebooted the machine. As it didn’t work on the first few tries I stopped crashing the machine. At the moment this is just to hacky for a productive system. On the long run I’m in favour of this solution.
Worthwhile to note sys-gui-gpu is a HVM based on fedora-34-xfce with interesting kernel-options while sys-gui is a PVH based on that same fedora-34-xfce template. When doing the first install the download of the this template takes a while since it is about 1.7GB in size (5GB decompressed).
To sum things up I can confirm sys-gui and sys-gui-gpu are experimental.
I appear to be having problems with this. After running “sudo qubesctl --all state.highstate” 7 steps succeeded but 2 failed. When checking the journalctl it appears to fail on "permission denied for call b’admin.vm.Create.AppVM’+b’ fedora-34-xfce’ "
I’m guessing its because I don’t have the fedora-34-xfce installed as I am on Qubes 4.1 and have fedora 35 template installed. If I try to run “sudo qubes-dom0-update qubes-template-34-xfce” I get the error “cannot open /etc/qubes-rpc/qubes.TemplateSearch: No such file”
doesn’t give you visual (or any kind of) feedback while downloading the template. However sudo qubes-dom0-update qubes-template-34-xfce worked for me. Maybe you need to update dom0 first?
Dom0 is up to date. It appears my issue revolves around the fact that /etc/qubes-rpc/qubes.TemplateSearch is missing. Why it is missing, I am not sure.
The qubes.TemplateSearch exists in the sys-firewall qube but not in dom0. So not sure how dom0 is supposed to call this. Plus I have no fedora-34-xfce tempalte. Only a Fedora-35 template and I had upgraded it due to EOL coming soon for Fedora 34.
