How to enable the (new) GUI VM?

Is there a way to copy over the templates used in the previous monolithic dom0?

Please read this and the other topics regarding the gui-domain.
You don’t need to copy anything.

You either set the default guivm to sys-gui via

qubes-prefs default_guivm sys-gui

in dom0.

Or, if you want to test single apps then run

qvm-prefs work guivm sys-gui

In order to go back to how things were you have to set default_guivm to dom0 or the single appVM to dom0 respectively.

Please take your time reading the posts in this and the other threads.

2 Likes

Is there any particular reason that a Whonix workstation wouldn’t work with the sys-gui as the default GUI-VM?

After having made it the default, the Whonix workstation apps will not launch properly.

What worked for me was to have the desired AppVM apps launched while in the xfce account and then
log in to the sys-gui account and then run the command you mentioned:

qvm-prefs work guivm sys-gui

But the app needs to be running in the xfce account already

The command is for the specific app called “work”. Of course, you have to replace it with the names of your apps.

I did not use Whonix in sys-gui but it should work if not only the workstation is set to sys-gui but also gateway and sys-whonix.

Good luck!

The command requires the VMNAME value, which is the name of the appVM

Currently DispVMs do not appear to crossover from xfce into sys-gui.

In the Xfce user account the AppVMs and TemplateVMs and their related applications are listed in the “Q”
GUI dropdown menu in the upper left corner, is this possible in the sys-gui account?

Overall the sys-gui looks pretty promising, there are a few kinks to iron out.

Maybe my experience can add some value for those having dGPUs.

Yeah anybody have experience with using iGPUs like Intel HD?

qvm-run -p --no-gui --service sys-gui-gpu qubes.GuiVMSession

this command returns:

Timed out waiting for Xorg display:1

does the lightdm service have to be disabled?

Also, with the sys-gui-gpu saltstack state, the usb-keyboard/mouse no longer attach to dom0.

Date: 29/12/2023
Test System: clean install of R4.2 with all the updates applied on a T480 with 32Gb of RAM.

Result:
Following the instructions for sys-gui at https://www.qubes-os.org/doc/gui-domain/ results in a perfectly unusable sys-gui.

After running:

qubes-prefs default_guivm sys-gui

as suggested by @Raphael_Balthazar in an earlier post, the system is still pretty much unusable as no apps can be run in any other DomU than sys-gui, and Dom0 is only reachable through text console (Ctrl-Alt-F2). Bonus: US keyboard hard-coded and (seemingly) immutable in sys-gui.

My current attempt is using the sys-gui-gpu Salstack forumula. My USB devices are no longer working in dom0 and when I try to switch to the sys-gui-gpu VM using:

qvm-run -p --no-gui --service sys-gui-gpu qubes.GuiVMSession

it returns:

Timed out waiting for Xorg display: 1

I am sorry that I don’t understand, but isn’t that the point of sys-gui(-xxx) at all? Not to have any domU out of it? Just dom0? Isn’t sys-gui supposed to be new “dom0”, that is AdminVM? In which you’d have to recreate all new set up - templates, appVM and all other qubes?

Ref:

1 Like

Exactly! (I know these were rhetorical questions)
For me this is working with the limitations I described above.

@janglingquo_575
The command is only for sys-gui, I think this has been explained already somewhere in this thread.

1 Like

I can run apps just fine in sys-gui, I have access to the same VMs and apps as I do in dom0.

@tempmail no, that isn’t the point of sys-gui, you don’t have to recreate anything you can use the VMs you already have.

Of course I can use the VMs I already have. I posted a link few posts above that I actually already deploy it as practically having 2 Qubes OS’ on a single machine. Having templates both in dom0 and inside sys-gui (in the latter with proper tags). It’s clearly stated there.

Date: 10/01/2024
Test System: clean install of R4.2 with all the updates applied on a T480 with 32Gb of RAM. [same as before]

Result: following the instructions for creating a sys-gui-gpu qube results in the system crashing and rebooting as soon as sys-gui-gpu starts up.

Conclusion: this whole sys-gui stuff is utterly experimental and dangerous; should be clearly marked as such, something like “Think 10 times before trying this on a production machine”.

I may try and write a walkthrough on how to enable it “my way”, despite certain things not being yet implemented for practical usage - though might take a look and implement some, when having lots of free time.

The crashing thing may be related to the fact that the graphics drivers gets loaded by dom0, rather than sys-gui-gpu and it has to be denylisted first (module_blacklist=i915).

I’ll paste what I wrote some time ago on the public chat:

The upgrade to 4.2 went smoothly! Furthermore, sys-gui-gpu works on my trusty T480!

Though I’m kinda confused - how do I do anything from sys-gui-gpu in the context of dom0? I’m primarily thinking about simple things like shutting down my laptop, but simply using a poweroff command results in a black screen. Or tweaking anything in dom0 without having to use qubes.skip_autostart and removing module_blacklist=i915?

and later, after some more experiments:

The bad news

  • Audio doesn’t work out-of-the-box, may be related due to the fact I haven’t touched anything related to audiovm
  • Tray icons do not show up by default, need to manually recreate the application entries in templates, disposable templates and AppVMs
  • 4.2-exclusive administrative graphical tools crash before they are fully loaded
  • Only dom0 and sys-gui-gpu are visible, other qubes are not - need to manually run $ qubes-prefs --set default_guivm sys-gui-gpu
  • On the XFCE4 taskbar in the “Windows Buttons” widget only “cute qube” icons showed up, that is no incoming-sanitized-colorized X11 application icons
  • Some anomalies related to power management:
    • brightness options are not persistent, the default “very dim” level is used
    • selecting the Power Manager Plugin setting “Show label: Percentage” does nothing

The good news

  • When from dom0 the policy qubes.InputMouse * sys-usb sys-gui-gpu ask is written, then input proxying works
  • Mirroring and extending displays works with HDMI
  • Emulated hardware acceleration with llvmpipe should work inside qubes
4 Likes

Thanks @aronowski!
After adding module_blacklist=i915 the system does not crash on boot anymore.
But… the system is not usable either, because I ran into all the troubles that you mentioned :laughing: … dim display (to the minimum, not adjustable), the menu is crashing on startup, only sys-gui-gpu is visible, system crashes instead of powering off or rebooting.
All in all… the sys-gui-gpu setup is still unusable.

1 Like