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.
Just tried enabling this for the first time, on a fresh 4.1 install. I updated dom0 and templates first. Went straight for sys-gui-gpu. After executing the commands, 1 out of 11 states failed. It concludes with DOM0 configuration failed, not continuing. It’s a desktop with Ivy Bridge cpu with integrated graphics and no other graphics card, so I was kind of expecting it to work, or at least for the setup to complete succesfully.
Full output below:
[user@dom0 ~]$ sudo qubesctl top.enable qvm.sys-gui-gpu
local:
----------
qvm.sys-gui-gpu.top:
----------
status:
enabled
[user@dom0 ~]$ sudo qubesctl top.enable qvm.sys-gui-gpu pillar=True
local:
----------
qvm.sys-gui-gpu.top:
----------
status:
enabled
[user@dom0 ~]$ sudo qubesctl --all state.highstate
[ERROR ] Command 'systemd-run' failed with return code: 1
[ERROR ] stdout: Running scope as unit: run-r217c3268c6454ebab5e84c25cc9a1336.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-*' '-y' '--best' '--allowerasing' '--clean' '--action=install' 'dummy-psu-dom0'' 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-r217c3268c6454ebab5e84c25cc9a1336.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-*' '-y' '--best' '--allowerasing' '--clean' '--action=install' 'dummy-psu-dom0'' on sys-firewall
sys-firewall: command failed with code: 1
local:
----------
ID: topd-always-passes
Function: test.succeed_without_changes
Name: foo
Result: True
Comment: Success!
Started: 13:02:14.657874
Duration: 1.18 ms
Changes:
----------
ID: sys-gui-gpu-template
Function: qvm.template_installed
Name: fedora-34-xfce
Result: True
Comment: ('Template fedora-34-xfce version 4.0.6 installed',)
Started: 13:02:14.665292
Duration: 601050.512 ms
Changes:
----------
details:
fedora-34-xfce: Importing data
Downloading 'qubes-template-fedora-34-xfce-0:4.0.6-202110020922'...
Installing template 'fedora-34-xfce'...
new:
----------
buildtime:
2021-10-02 12:14:09
description:
Qubes template for fedora-34-xfce
epoch:
0
installtime:
2022-06-01 17:12:14
license:
GPL
name:
fedora-34-xfce
release:
202110020922
reponame:
qubes-templates-itl
size:
5182737035
summary:
Qubes template for fedora-34-xfce
url:
http://www.qubes-os.org
version:
4.0.6
----------
ID: dummy-psu-dom0
Function: pkg.installed
Result: False
Comment: Error occurred installing package(s). Additional info follows:
errors:
- Running scope as unit: run-r217c3268c6454ebab5e84c25cc9a1336.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-*' '-y' '--best' '--allowerasing' '--clean' '--action=install' 'dummy-psu-dom0'' on sys-firewall
sys-firewall: command failed with code: 1
Started: 13:12:19.044609
Duration: 115035.856 ms
Changes:
----------
ID: qubes-input-proxy-sender
Function: pkg.installed
Result: True
Comment: All specified packages are already installed
Started: 13:14:14.080992
Duration: 30.279 ms
Changes:
----------
ID: /etc/qubes/input-proxy-target
Function: file.managed
Result: True
Comment: File /etc/qubes/input-proxy-target updated
Started: 13:14:14.134970
Duration: 13.468 ms
Changes:
----------
diff:
New file
----------
ID: sys-usb-previous-rpc
Function: file.line
Name: /etc/qubes-rpc/policy/qubes.InputMouse
Result: True
Comment: No changes needed to be made
Started: 13:14:14.150239
Duration: 7.5 ms
Changes:
----------
ID: sys-usb-input-proxy
Function: file.prepend
Name: /etc/qubes-rpc/policy/qubes.InputMouse
Result: True
Comment: Prepended 1 lines
Started: 13:14:14.158086
Duration: 8.256 ms
Changes:
----------
diff:
---
+++
@@ -1 +1,2 @@
+sys-usb dom0 ask,user=root,default_target=sys-gui-gpu
$anyvm $anyvm deny
----------
ID: sys-gui-gpu
Function: qvm.vm
Result: True
Comment: ====== ['present'] ======
/usr/bin/qvm-create sys-gui-gpu --class=AppVM --template=fedora-34-xfce --label=black
====== ['prefs'] ======
====== ['service'] ======
====== ['features'] ======
Started: 13:14:14.166678
Duration: 5357.571 ms
Changes:
----------
qvm.features:
----------
qvm.features:
----------
input-dom0-proxy:
----------
new:
True
old:
None
no-default-kernelopts:
----------
new:
1
old:
None
video-model:
----------
new:
none
old:
None
qvm.prefs:
----------
qvm.create:
----------
audiovm:
----------
new:
None
old:
*default*
autostart:
----------
new:
False
old:
*default*
guivm:
----------
new:
None
old:
*default*
kernelopts:
----------
new:
nopat iommu=soft swiotlb=8192 root=/dev/mapper/dmroot ro console=hvc0 xen_scrub_pages=0
old:
*default*
memory:
----------
new:
1000
old:
*default*
netvm:
----------
new:
None
old:
*default*
virt_mode:
----------
new:
hvm
old:
*default*
qvm.service:
----------
qvm.service:
----------
dummy-psu:
----------
new:
Enabled
old:
Missing
guivm:
----------
new:
Enabled
old:
Missing
lightdm:
----------
new:
Enabled
old:
Missing
----------
ID: sys-gui-gpu-rpc
Function: file.managed
Name: /etc/qubes/policy.d/50-gui-sys-gui-gpu.policy
Result: True
Comment: File /etc/qubes/policy.d/50-gui-sys-gui-gpu.policy updated
Started: 13:14:19.525311
Duration: 9.409 ms
Changes:
----------
diff:
New file
----------
ID: sys-gui-gpu-admin-local-rwx
Function: file.append
Name: /etc/qubes/policy.d/include/admin-local-rwx
Result: True
Comment: Appended 2 lines
Started: 13:14:19.534996
Duration: 7.503 ms
Changes:
----------
diff:
---
+++
@@ -8,3 +8,5 @@
## Add your entries here, make sure to append "target=dom0" to all allow/ask actions
+sys-gui-gpu @tag:guivm-sys-gui-gpu allow target=dom0
+sys-gui-gpu sys-gui-gpu allow target=dom0
----------
ID: sys-gui-gpu-admin-global-rwx
Function: file.append
Name: /etc/qubes/policy.d/include/admin-global-rwx
Result: True
Comment: Appended 3 lines
Started: 13:14:19.542786
Duration: 5.951 ms
Changes:
----------
diff:
---
+++
@@ -8,3 +8,6 @@
## Add your entries here, make sure to append "target=dom0" to all allow/ask actions
+sys-gui-gpu @adminvm allow target=dom0
+sys-gui-gpu @tag:guivm-sys-gui-gpu allow target=dom0
+sys-gui-gpu sys-gui-gpu allow target=dom0
Summary for local
-------------
Succeeded: 10 (changed=7)
Failed: 1
-------------
Total states run: 11
Total run time: 721.527 s
DOM0 configuration failed, not continuing
It did install the xfce-template succesfully. When running the setup again, it is also a lot faster because it doesn’t hace to install the xfc-template anymore, however when I run the setup again, it still fails at the same point. Also when I follow the steps to remove the GUIvm first, and then run the setup again. I see that the package it is failing to install “dummy-psu-dom0” doesn’t seem to be in the repository(Index of /repo/yum/r4.1/current/dom0/fc32/rpm/) and not in current-testing or unstable either.
EDIT: Seems to be a mistake in the setup file: sys-gui-gpu.sls still references dummy-psu-dom0 · Issue #7230 · QubesOS/qubes-issues · GitHub
When trying to setup sys-gui instead of sys-gui-gpu, it completes all states succesfully. I’ll make a separate post about my sys-gui experiences.
As I said in my previous post, unlike the sys-gui-gpu, the hybrid sys-gui setup completed succesfully. I am also able to log into sys-gui. As mentioned in the doc, there are no qubes entries in the application menu. Qube manager also only saw dom0 and sys-gui. And I was not able to start a qube through terminal, as if they did not exist. The application menu issue(Application menu lack VM entries in fresh GUI VM · Issue #5804 · QubesOS/qubes-issues · GitHub) mentions you also need to set sys-gui als the default guivm. This is not mentioned in the doc. After doing so I’m able to start my qubes and Qube manager now sees them as well. So now, using Qubes OS through sys-gui actually works. However, there is quite a bit of screen tearing, missing icons from systray such as wifi/ethernet and power, qube manager crashes after some actions, after shutting down a VM qube.WindowIcon.updater fails, and if I try to update a template through QubeS Update, it complains about command “qubesctl” not found. Running sudo qubes-dom0-update from terminal also complains about command not found. I see most of these issues are already reported on Github.
I gave sys-gui-gpu another try. That folder does not exist in my dom0. I did find sys-gui-gpu.sls in /srv/formulas/base/virtual-machines-formula/qvm/. After changing
dummy-psu-dom0 to dummy-psu-sender, the setup was able to succeed on all steps. Then I attached the gpu to sys-gui-gpu and rebooted, but could not login to the guivm session, only to dom0. I realized sys-gui-gpu was not running because autostart was not enabled for sys-gui-gpu. I enabled it and rebooted again. During boot it crashes and it restarts the computer. I used the qubes.skip_autostart line to get in again, and saw that dom0 was still the default guivm, and thought maybe that was the reason it crashed. I changed the default guivm to sys-gui-gpu and rebooted, but it still crashes during boot and reboots. This is with an Intel i5 3470 with integrated graphics, no external gpu installed.
At that point I gave up. I’m still thinking about apply for the testing team, but only for sys-gui-gpu because I need my machine for productive means also. I believe the sys-gui-gpu idea (and sys-audio) to minimise dom0-interaction is awesome.
To my understanding the qubes.skip_autostart flag reverts the gui to dom0.
$ sudo qubesctl --all state.highstate
local:
Data failed to compile:
----------
Detected conflicting IDs, SLS IDs need to be globally unique.
The conflicting ID is 'dummy-psu-sender' and is found in SLS 'base:qvm.sys-gui' and SLS 'base:qvm.sys-gui-gpu'
DOM0 configuration failed, not continuing
The error happens because two pieces of configuration (Salt top files) define the same state (called dummy-psu-sender) and names MUST be unique.
Since both those files seem to be maintained by the Qubes OS team, that might look like a bug, but I suspect it’s something else. My guess is that only one of those top files should be enabled at any given time (and the two states have the same name because they define the same element that’s used in both scenarios).
Are you supposed to have enabled both sys-gui and sys-gui-gpu at the same time? (I don’t think so, but I genuinely don’t know.)