4.2.1: sys-gui-vnc is not working

[rapenne-s]

How to file a helpful issue

Qubes OS release

4.2.1 with testing updates enabled

Brief summary

I deployed sys-gui-vnc per the documentation but there are no VNC service running in the qube.

Steps to reproduce

I followed the instructions in https://www.qubes-os.org/doc/gui-domain/ , so

sudo qubesctl top.enable qvm.sys-gui-vnc
sudo qubesctl top.enable qvm.sys-gui-vnc pillar=True
sudo qubesctl --all state.highstate
sudo qubesctl top.disable qvm.sys-gui-vnc
sudo reboot

From there, sys-gui-vnc (it's using fedora-39-xfce template, this was by default) starts fine but the service lightdm fails to start in it.

So far, I found 2 issues in sys-gui-vnc:

First, qubes-run-x11vnc is not working as it calls qsvc guivm-vnc but the service is named qsvc guivm-gui-vnc, so it doesn't create a valid /etc/X11/xorg.conf for vnc.

Second, once the xorg.conf for vnc was generated, X fails to start due to a dummyqbs X driver error

In /var/log/Xorg.log I have the error:

(EE) Failed to load Loading /usr/lib64/xorg/modules/drivers/dummyqbs_drv.so: /usr/lib64/xorg/modules/drivers/dummyqbs_drv.so: undefined symbol: glamor_egl_create_textured_pixmap_from_gbm_bo
(EE) Failed to load module "dummyqbs" (loader failed, 0)
(EE) No drivers available.

I had to type the error message because I can only get into the sys-gui-vnc qube using the serial access, which doesn't seem to allow copy text from it.

Expected behavior

Not sure how it should look once it's working, at least lightdm should run in sys-gui-vnc and something should answer on port 5900.

From the documentation, it's not clear what to expect on the physical display, is there a login option to choose like for sys-gui ?

Actual behavior

No VNC

[rapenne-s]

The X driver error also happens in fedora 37, I don't know when it started failing.

[rapenne-s]

In the logs there is a systemd-coredump entry about Xorg core dump.

As I can't copy/paste and qvm-run does not work with sys-gui-vnc :/ I can't share it...

It looks like this (taken from the internet) it is not MY LOG

Oct 02 10:18:38 fedora systemd-coredump[1326]: Process 1310 (Xorg) of user 0 dumped core.
                                               
                                               Module linux-vdso.so.1 with build-id c26808872d57ea78c1437acf55d97b0d9840149f
                                               Module libuuid.so.1 with build-id a5009041f85b1ec5b58f06105aeb0319524ef526
                                               Metadata for module libuuid.so.1 owned by FDO found: {
                                                       "type" : "rpm",
                                                       "name" : "util-linux",
                                                       "version" : "2.38-1.fc36",
                                                       "architecture" : "x86_64",
                                                       "osCpe" : "cpe:/o:fedoraproject:fedora:36"
                                               }
                                               
                                               Module libxcb-util.so.1 with build-id 523c7e4d96f31a695088db2678bc09ed5e02cc6e
                                               Metadata for module libxcb-util.so.1 owned by FDO found: {
                                                       "type" : "rpm",
                                                       "name" : "xcb-util",
                                                       "version" : "0.4.0-19.fc36",
                                                       "architecture" : "x86_64",
                                                       "osCpe" : "cpe:/o:fedoraproject:fedora:36"
                                               }
                                               [..split so it's not too long...]
                                               Stack trace of thread

[marmarek]

Ok, I added a (partial for now) openQA job that tests this, so when it gets fixes, hopefully we will notice regression earlier.

As for the issue itself: first is that QubesOS/qubes-gui-agent-linux@eab7854 got vnc config based on slightly older xorg config template (the glamor dependency was added about the same time).
With that fixed, it fails on a write access to /run/qubes/shm.id.0 due to SELinux. And finally, with SELinux disabled it appears to start. But, still quite a few things are broken:

• several qrexec policy denial messages (listing devices, checking "updates-available" feature and some more)
• a lot of error messages in sys-gui-vnc logs

[rapenne-s]

Thanks @marmarek , tell me if I can test anything to help.

[marmarek]

SELinux errors:

[  994.880747] audit: type=1400 audit(1718197097.033:332): avc:  denied  { create } for  pid=20318 comm="Xorg" name="shm.id.0" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:qubes_var_run_t:s0 tclass=file permissive=0
[  994.898636] audit: type=1400 audit(1718197097.041:333): avc:  denied  { write } for  pid=20318 comm="Xorg" name="mtrr" dev="proc" ino=4026532077 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mtrr_device_t:s0 tclass=file permissive=0     
[  994.898904] audit: type=1400 audit(1718197097.041:334): avc:  denied  { write } for  pid=20318 comm="Xorg" name="mtrr" dev="proc" ino=4026532077 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:mtrr_device_t:s0 tclass=file permissive=0
[ 1563.440636] audit: type=1400 audit(1718197665.592:431): avc:  denied  { unix_read unix_write } for  pid=22519 comm="Xorg" ipc_key=0  scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm permissive=10-s0:c0.c1023 tcontext=system_u:object_r:mtrr_device_t:s0 tclass=fil
[ 1563.440828] audit: type=1400 audit(1718197665.592:431): avc:  denied  { read write } for  pid=22519 comm="Xorg" ipc_key=0  scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm permissive=1
[ 1563.448370] audit: type=1400 audit(1718197665.592:432): avc:  denied  { getattr associate } for  pid=22519 comm="Xorg" ipc_key=0  scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm permissive=1
[ 1930.109457] audit: type=1400 audit(1718198032.261:438): avc:  denied  { unlink } for  pid=22519 comm="Xorg" name="shm.id.0" dev="tmpfs" ino=953 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:qubes_var_run_t:s0 tclass=file permissive=1
[ 1930.550184] audit: type=1400 audit(1718198032.702:440): avc:  denied  { create } for  pid=32691 comm="Xorg" name="shm.id.0" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:qubes_var_run_t:s0 tclass=file permissive=1
[ 1930.551993] audit: type=1400 audit(1718198032.702:440): avc:  denied  { read write open } for  pid=32691 comm="Xorg" path="/run/qubes/shm.id.0" dev="tmpfs" ino=1083 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:qubes_var_run_t:s0 tclass=file permissive=1
[ 2183.477591] audit: type=1400 audit(1718198285.629:492): avc:  denied  { unix_read unix_write } for  pid=32691 comm="Xorg" ipc_key=0  scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm permissive=1[ 2183.477679] audit: type=1400 audit(1718198285.629:492): avc:  denied  { read write } for  pid=32691 comm="Xorg" ipc_key=0  scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm permissive=1 
[ 2183.477964] audit: type=1400 audit(1718198285.629:493): avc:  denied  { getattr associate } for  pid=32691 comm="Xorg" ipc_key=0  scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=shm permissive=1

[marmarek]

Oh, and there is a confusion guivm-gui-vnc vs guivm-vnc qvm-service.

[marmarek]

The above two PRs (easily applicable manually in the installed system) + disabling selinux should get you some approximation of working version. At least I was able to open a terminal window from another VM.

[rapenne-s]

I'm able to connect indeed 👍

If I set a qube guivm field to sys-gui-vnc I can start it from VNC and use the qube. There is a lot of rpc policy errors in dom0 when using qubes manager.

[rapenne-s]

Everything seems to work quite fine so far, except that I can't type accents characters in qubes from sys-gui-vnc, although I can type them in sys-gui-vnc itself. Any idea?

I'm using tigervnc as a client but I doubt it's a client issue as it works in the vnc server itself.

this is a real blocker :/

[rapenne-s]

Interestingly as I use an azerty layout I just tried to run setxkbmap fr in a qube and this resulted in a very weird layout when typing from vnc like a qwerty one but where many signs are placed randomly

[rapenne-s]

Here is xev output when typing eacute in a qube, I can't share the result when typing in sys-gui-vnc as I can't use the clipboard sharing feature, but it appears as a "eacute" keysym.

KeyPress event, serial 32, synthetic NO, window 0x2000001,
    root 0x40e, subw 0x0, time 3711473, (314,43), root:(1185,519),
    state 0x0, keycode 93 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 32, synthetic NO, window 0x2000001,
    root 0x40e, subw 0x0, time 3711522, (314,43), root:(1185,519),
    state 0x0, keycode 93 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

[rapenne-s]

Using setxkbmap fr in sys-gui-vnc solves the entire problem, not sure how to fix it properly out of the box for everyone.

[marmarek]

Using setxkbmap fr in sys-gui-vnc solves the entire problem, not sure how to fix it properly out of the box for everyone.

This looks like you didn't set fr layout before at all... It is expected to require setting keyboard layout in desktop environment (regardless if that's Xfce running in dom0 or the one running in sys-gui-vnc) to be able to use it.

[rapenne-s]

Using setxkbmap fr in sys-gui-vnc solves the entire problem, not sure how to fix it properly out of the box for everyone.

This looks like you didn't set fr layout before at all... It is expected to require setting keyboard layout in desktop environment (regardless if that's Xfce running in dom0 or the one running in sys-gui-vnc) to be able to use it.

How could I figure I had to do it? The keymap seemed fine for me in sys-gui-vnc, and I only configured it in dom0 at installation time, I was under the impression that the setting was carried over sys-gui-vnc through automation. I guess a sentence about it in the sys-gui-vnc setup would be useful for next users.

[qubesos-bot]

Automated announcement from builder-github

The package gui-agent-linux has been pushed to the r4.2 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package gui-agent-linux has been pushed to the r4.2 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component gui-agent-linux (including package gui-agent-linux) has been pushed to the r4.2 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo dnf update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component gui-agent-linux (including package gui-agent-linux) has been pushed to the r4.2 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo dnf update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component gui-agent-linux (including package gui-agent-linux) has been pushed to the r4.2 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo dnf update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component gui-agent-linux (including package gui-agent-linux) has been pushed to the r4.2 stable repository for the Fedora template.
To install this update, please use the standard update command:

sudo dnf update

Changes included in this update