Sys-gui in 2025?

sys-gui in 2025 is stable enough to use everyday seriously? I don’t see anyone talking about sys-gui since 2023. Very strange tbh. I used to use sys-gui in 2022, but it had a lot of bugs.

3 Likes

I just tried it on a Lenovo P52 which has an Intel + nvidia P1000 card hardwired in hybrid mode.
The result was an instant hard reboot as soon as the gui VM started with the assigned VGA devices. :frowning:

So it is heavily hardware dependent… one might have better luck with a ‘pure Intel’ setup.

1 Like
1 Like

I tried sys-gui (hybrid mode with Xephyr, to be able to access dom0) a month ago. It still has a lot of bugs.

For example, the menu is empty, despite that I’ve read here somewhere that that issue is already fixed. At one moment (don’t remember, when exactly) I saw that there was a ton of processes spawned in dom0, that were doing something related to the menu… probably one for each qube, in parallel. Yeah, but I have more than 100 qubes (many old/unused/need to be deleted), so these processes were probably oom-killed after a while. Still, not a single qube entry appeared in the menu after that.

Then I noticed, that many actions lead to 100% CPU usage by libvirtd and qubesd processes in dom0 for about a minute.

When using dom0 as a GUI domain, I can restart lightdm (and the desktop environment) at any time and loose only applications started in dom0. All qube windows will reappear after the relogin. But if I restart sys-gui, all windows from running qubes are lost, I need to restart these qubes. Moreover, the process of restarting sys-gui was somewhat convoluted: I needed to restart sys-gui and lightdm in specific subsequence.

There was also some problem with display refresh rate. In dom0 I can just run xrandr --rate 120, for example, but with sys-gui it is complicated.

You need to remember to set up a password and make it persistent in sys-gui, or the first screensaver lock (that has default timeouts, not what is configured in dom0) will literally lock you out. Which means, you need to restart sys-gui, and all running qubes, and loose all unsaved work.

gui-default-secure-copy-sequence and gui-default-secure-paste-sequence qvm-features for sys-gui didn’t accept F10–F12 keys (though, they accepted F1–F9 IIRC), I needed to find out and change that. Although for dom0 as a GUI domain the combinations with F11 and F12 work OK.

There is a bug, that for hvm qubes the window of emulated VGA output does not show up. It was extremely inconvenient, so I ended up setting guivm setting for these qubes to dom0 and starting a parallel desktop session in dom0 to use these qubes.

So, it turns out that

  1. I use many commands in dom0 (like xl sched-credit2 or cpupool-related),
  2. for many small bugs/unimplemented features in sys-gui I need to switch to dom0 tty for a workaround and
  3. for hvm qubes I start a separate dom0 desktop session.

So, in the end I thought “what’s the point” and returned back to using dom0 as a GUI domain.

(By the way, after returning back to dom0, the menu ends up also blank there, so beware.)

So, not usable enough. Sadly, it appears that the Qubes development team is too small to handle everything.

3 Likes

Exactly! When I used sys-gui, I had so many bugs, like Xscreensaver locking me out (I had to change the password each boot and sometimes I just forgot to edit the password), Qube in HVM (Windows, BSD, etc.) just didn’t pop up, and so on. Despite these two annoying bugs, everything else worked without issues. I thought these two bugs had been fixed, since my experience with sys-gui is from 3 years ago.

1 Like