Feedback Qubes OS alpha with sys-gui

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 :wink:
@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 replace dummy-psu-dom0 with dummy-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 from fedora-32 to fedora-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 the qrexec_policy_exec exception persists

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 ?
1 Like