There are quite several threads mentionning those problems with sys-gui-gpu, but I can’t really find an “official statement” about what we should do to get it running. Here is my attempt to put everything in one place at the same time I’m doing the steps. Hopefully a dev in-the-know will tell if this is what we’re expected to do, and fill in the blanks
@fepitre or @marmarek maybe ?
I went directly to sys-gpu-gui without going the sys-gui path first, as that hybrid approach is not I’m after.
The steps go like:
-
official instructions, failing with failure to install
dummy-psu-dom0
qubesctl top.enable qvm.sys-gui-gpu qubesctl top.enable qvm.sys-gui-gpu pillar=True qubesctl --all state.highstate
-
fix the Salt recipe by editing
/srv/formulas/base/virtual-machines-formula/qvm/sys-gui-gpu.sls
to replacedummy-psu-dom0
withdummy-psu-sender
- rerun the 3
qubesctl
calls (though I guess the 3rd one could be sufficient):- the 10 Salt steps all pass this time
- sys-gui-gpu is reported as ERROR, mgmt logfile say “request refused”, qrexec-mgmt logfile show something I did not find in any other post:
WARNING:root:warning: !compat-4.0 directive in file /etc/qubes/policy.d/35-compat.policy line 16 is transitional and will be deprecated
INFO:policy:qrexec: qubes.VMRootShell+: disp-mgmt-sys-gui-gpu -> sys-gui-gpu: allowed to sys-gui-gpu
Traceback (most recent call last):
File "/usr/bin/qrexec-policy-exec", line 5, in <module>
sys.exit(main())
File "/usr/lib/python3.8/site-packages/qrexec/tools/qrexec_policy_exec.py", line 221, in main
return asyncio.run(handle_request(
File "/usr/lib64/python3.8/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/usr/lib64/python3.8/asyncio/base_events.py", line 616, in run_until_complete
return future.result()
File "/usr/lib/python3.8/site-packages/qrexec/tools/qrexec_policy_exec.py", line 274, in handle_request
await resolution.execute(caller_ident)
File "/usr/lib/python3.8/site-packages/qrexec/tools/qrexec_policy_exec.py", line 169, in execute
await super().execute(caller_ident)
File "/usr/lib/python3.8/site-packages/qrexec/tools/qrexec_policy_exec.py", line 133, in execute
await super().execute(caller_ident)
File "/usr/lib/python3.8/site-packages/qrexec/policy/parser.py", line 538, in execute
self.ensure_target_running()
File "/usr/lib/python3.8/site-packages/qrexec/policy/parser.py", line 579, in ensure_target_running
utils.qubesd_call(self.target, 'admin.vm.Start')
File "/usr/lib/python3.8/site-packages/qrexec/utils.py", line 95, in qubesd_call
raise AssertionError(
AssertionError: invalid qubesd response: b''
2021-07-30 13:57:01.566 qrexec-daemon[47761]: qrexec-daemon.c:1212:main: qrexec-agent has disconnected
domain dead
2021-07-30 13:57:01.567 qrexec-daemon[47761]: qrexec-daemon.c:1104:handle_agent_restart: cannot connect to qrexec agent: No such process
2021-07-30 13:57:01.567 qrexec-daemon[47761]: qrexec-daemon.c:1214:main: Failed to reconnect to qrexec-agent, terminating
That kinda looks like a protocol mismatch between qubesd and qrexec-agent ?
- fedora-33-xfce is reported as ERROR, logfile say as in this post
- I see complaints about
qubes-input-trigger
in popups (which Discourse Search strangely locates in no other post, but which Duckduckgo luckily confirms occurs in other posts) -
change the template for
default-mgmt-dvm
fromfedora-32
tofedora-33-xfce
- rerun the 3
qubesctl --all state.highstate
- fedora-33-xfce now OK
- sys-gui-gpu still reported in ERROR, with popup telling it still cannot
'/usr/bin/qubes-input-trigger --all --dom0'
.
- something obviously missing here
inconclusive attempts to tackle the input-trigger --all --dom0
issue
- applied this patch to
/usr/lib/python3.8/site-packages/qubes/ext/gui.py
as mentionned here -
systemctl restart qubesd.service
- now it’s
/usr/bin/qubes-input-trigger
not being found (though it is included in the template), and theqrexec_policy_exec
exception persists
- now it’s
USB mouse
At this point when I plug a USB mouse, Qubes tries to start sys-gui-gpu
, which fails because of qubes-input-trigger
, and my mouse is not usable. The following step probably has to be added somewhere in the recipe:
qubesctl state.sls qvm.sys-usb
operations to do later when that step has been fixed
qubesctl top.disable qvm.sys-gui-gpu
- attach AMD GPU to sys-gui-gpu since only Intel ones are handled today
-
qvm-prefs work guivm sys-gui-gpu
? - other ?