Qubes 4.2 rc3 sys-gui-gpu: communicating with dom0

[Raphael_Balthazar]

Hi,

I am wondering how to execute dom0 commands while being logged in sys-gui-gpu?
For example, if you want to create a new VM or forget to set the guivm from dom0 to sys-gui-gpu what do you do?
Shutting down sys-gui-gpu leads to a black screen and I don’t know if the desired behavior would be the gpu being attached to dom0 or if this was possible?

So, if anyone has some input/experiences I’d appreciate it. Removing sys-gui-gpu in order to execute a few dom0 commands seems a bit excessive.

4.2 rc3 is really great so far, a lot of things are working out of the box that did not work in 4.1! Great work!

[Raphael_Balthazar]

Sorry, this was a hasty post, the qubes-prefs command (qubes-prefs default_guivm sys-gui-gpu) does work in the GuiVM terminal, so all qubes are displayed in sys-gui-gpu after executing.

[Raphael_Balthazar]

A few observations:

There are some problems in connection with Qubes Update, the update tool is showing available updates but is failing to launch due to a “PermissionError” Errno 13 Permission Denied

I tried copying the full error message but I also get a “request refused” so maybe there are some policy changes needed.

Updating via CLI and the usual specific commands like qubes-dom0-update did not work for me, so the question on how to communicate with dom0 within sys-gui-gpu remains.

Installing software in templates does work but, for example, when trying to get u2f to work I do not know how to execute a command like

sudo qubes-dom0-update qubes-u2f-dom0

which is needed.

Another thing I noticed at once, was, that the keyboard layout had changed to that of the US. When trying to log in as ‘user’ in sys-gui-gpu it took me a while to find the right keys after my password had been rejected.

Maybe someone has encountered similar problems and can help me with how to update from within sys-gui-gpu.

[tempmail]

This is what I did, but it needs specific environment.

[Workaround] How to use external monitor in NVidia Optimus mode

For dual Intel/Nvidia GPU notebooks, as I understand it’s not possible to use external monitor/TV while in Nvidia Optimus mode because HDMI/DP ports are directly tied to Nvidia card. So we are doomed to Discrete mode, meanning using only Nvidia card which is very bad for the battery, or… Here I discovered that I can create sys-gui(-gpu) and attach only Nvidia card to it in Optimus mode even without hiding it from the dom0 and sys-gui-gpu is passed to external monitor, while using iGPU on the la…

[Raphael_Balthazar]

Thanks for the link and your setup! I tried something similar on another laptop but couldn’t quite get it to work. At the moment I use an old laptop without a 2nd GPU.

Since I am not sure how this is all supposed to work in the first place it’s hard to test and so I am trying to experiment further with a little annoying workaround.

I simply uncheck the “start qube automatically on boot” option in the sys-gui-gpu settings, reboot, log in to dom0 and bring back sys-net/sys-firewall to guivm dom0 via qvm-prefs in order to have a network access for the updates. I do all things dom0 like updating and installing u2f etc.

Before rebooting I tick the box for starting sys-gui-gpu on boot automatically again, set sys-net/sys-firewall back to guivm sys-gui-gpu.

Isolating as much from dom0 as possible is the desired goal, if I am correct. So I guess this means sys-gui-gpu is to be preferred over sys-gui security-wise, isn’t it?

Hopefully there will be a few more instructions in the future on how to deal with this. Any input is welcome!

At the moment I will set my system up with guivm dom0 and try using it with guivm sys-gui-gpu and see how it works.

[tempmail]

You are welcome.
In general, this should indicate the catch, as I see it:

@Raphael_Balthazar

For example, if you want to create a new VM or forget to set the guivm from dom0 to sys-gui-gpu what do you do?

@Raphael_Balthazar

Isolating as much from dom0 as possible is the desired goal,

Basically, you gave the answer yourself.

In case of sys-gui(-gpu), no VM should exist of it, all should exist in it’s envornment. Setting guiVM to sys-gui(-gpu) should be done prior to creating it and on a default guiVM level.

What you and are are doing is circumventing security goals advised when sys-gui(-gpu) is in the matter.

[Raphael_Balthazar]

You can add missing VM within sys-gui*, updating is crashing.

@tempmail

What you and are are doing is circumventing security goals advised when sys-gui(-gpu) is in the matter.

Of course, that’s why it’s called a workaround and the whole reason of my thread was asking how to do it better.

It’s been a while since I tried sys-gui* and it looks like it has improved very much but seeing what is missing, what is working and first of all getting to know, how this is all supposed to work is something that this testing versions are for, aren’t they?

At least in sys-gui-gpu the screensaver/password problem is gone. I also tried sys-gui and unfortunately starting the updater is leading to the same misbehavior I’ve mentioned before. Furthermore, I would have to disable the screensaver because I cannot login anymore from there, authentication with my password is failing (although taking the change in keyboard layout into account).

Regarding the setup I’d have to do without creating any VM during installation. Doing all this manually seems to me more error-prone than changing the default guivm. I doubt that anyone is going through the hassle least of all at the current state of sys-gui*.