Teamviewer 13 GUI is not shown in QubesOS 3.2

[thardeck]

Qubes OS version:

3.2 and 4.0

Affected component(s):

Window Manager/Handling

---

Steps to reproduce the behavior:

1. Install https://download.teamviewer.com/download/linux/teamviewer.x86_64.rpm
2. Run teamviewer in console

Expected behavior:

Teamviewer gui is shown.

Actual behavior:

Teamviewer tries to start and then just returns to console without error messages.

General notes:

The old Teamviewer 12 which bases on wine does work fine on QubesOS 3.2 and 4.
The new native Teamviewer 13 which bases on QT does not show any interface on both QubesOS releases.

I have tested the rpm in Fedora 26 in another VM environment to check if it is a Fedora issue but there it just worked fine.

Let me know if you need any additional details.

[thardeck]

Can I provide any additional information? The error message posted in the duplicate looks like this:

Mar  8 14:49:54 localhost qubes-gui[640]: XGetWindowAttributes for 0x2200006 failed in handle_create, ret=0x0

[thardeck]

Can I provide any additional information? The error message posted in the duplicate looks like this:

Mar  8 14:49:54 localhost qubes-gui[640]: XGetWindowAttributes for 0x2200006 failed in handle_create, ret=0x0

[marmarek]

The above message looks to be an effect of failed startup, not about the reason. More interesting messages can be found in /home/user/.local/share/teamviewer13/logfiles/TeamViewer13_Logfile.log:

2018/04/16 18:45:24.094  4404 126118275423552 G!! MonitorInfo: WorkingArea: Property error 14 (0)
2018/04/16 18:45:24.126  4404 126118275423552 G   Loaded language 'en', using locale 'en'
2018/04/16 18:45:24.127  4404 126118275423552 G   InterProcessBase::SecureNetwork created
2018/04/16 18:45:24.200  4404 126118275423552 G   AutoLogin::Login: enabled: 1
2018/04/16 18:45:24.200  4404 126118275423552 G   WindowsSessionStateManager(0x3254560) state 0
2018/04/16 18:45:24.220  4404 126118275423552 G!!!Own session could not be resolved, unable to startup
2018/04/16 18:45:24.222  4404 126118275423552 G   Chat::Stop: Stopping chat
2018/04/16 18:45:24.223  4404 126118275423552 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 9 failed with error 2, Errorcode=11
2018/04/16 18:45:24.224  4404 126118275423552 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 5 failed with error 2, Errorcode=11
2018/04/16 18:45:24.226  4404 126118275423552 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 6 failed with error 2, Errorcode=11
2018/04/16 18:45:24.227  4404 126118275423552 G!! WorkingProxy::Listener::WorkingProxyResultHandler failed: 2, Errorcode=11
2018/04/16 18:45:24.227  4404 126118275423552 G!  WorkingProxy::Listener::WorkingProxyResultHandler: setting default value ProxyType::Undefined
2018/04/16 18:45:24.228  4404 126118275423552 G!! WorkingProxy::Listener::WorkingProxyResultHandler failed: 2, Errorcode=11
2018/04/16 18:45:24.228  4404 126118275423552 G!  WorkingProxy::Listener::WorkingProxyResultHandler: setting default value ProxyType::Undefined
2018/04/16 18:45:24.228  4404 126118275423552 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 10 failed with error 2, Errorcode=11
2018/04/16 18:45:24.230  4404 126118275423552 G   interprocessbase::SecureNetwork destroyed
2018/04/16 18:45:24.231  4404 126118114297600 G!  MainThreadCall::Post: The instance is already gone.
2018/04/16 18:45:24.258  4404 126118275423552 G   Shutting down System DBus

Not sure yet why it happens.

[marmarek]

The above message looks to be an effect of failed startup, not about the reason. More interesting messages can be found in /home/user/.local/share/teamviewer13/logfiles/TeamViewer13_Logfile.log:

2018/04/16 18:45:24.094  4404 126118275423552 G!! MonitorInfo: WorkingArea: Property error 14 (0)
2018/04/16 18:45:24.126  4404 126118275423552 G   Loaded language 'en', using locale 'en'
2018/04/16 18:45:24.127  4404 126118275423552 G   InterProcessBase::SecureNetwork created
2018/04/16 18:45:24.200  4404 126118275423552 G   AutoLogin::Login: enabled: 1
2018/04/16 18:45:24.200  4404 126118275423552 G   WindowsSessionStateManager(0x3254560) state 0
2018/04/16 18:45:24.220  4404 126118275423552 G!!!Own session could not be resolved, unable to startup
2018/04/16 18:45:24.222  4404 126118275423552 G   Chat::Stop: Stopping chat
2018/04/16 18:45:24.223  4404 126118275423552 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 9 failed with error 2, Errorcode=11
2018/04/16 18:45:24.224  4404 126118275423552 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 5 failed with error 2, Errorcode=11
2018/04/16 18:45:24.226  4404 126118275423552 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 6 failed with error 2, Errorcode=11
2018/04/16 18:45:24.227  4404 126118275423552 G!! WorkingProxy::Listener::WorkingProxyResultHandler failed: 2, Errorcode=11
2018/04/16 18:45:24.227  4404 126118275423552 G!  WorkingProxy::Listener::WorkingProxyResultHandler: setting default value ProxyType::Undefined
2018/04/16 18:45:24.228  4404 126118275423552 G!! WorkingProxy::Listener::WorkingProxyResultHandler failed: 2, Errorcode=11
2018/04/16 18:45:24.228  4404 126118275423552 G!  WorkingProxy::Listener::WorkingProxyResultHandler: setting default value ProxyType::Undefined
2018/04/16 18:45:24.228  4404 126118275423552 G!! ConfigurationHub::HandleRegistrationResponse(): registering for feature 10 failed with error 2, Errorcode=11
2018/04/16 18:45:24.230  4404 126118275423552 G   interprocessbase::SecureNetwork destroyed
2018/04/16 18:45:24.231  4404 126118114297600 G!  MainThreadCall::Post: The instance is already gone.
2018/04/16 18:45:24.258  4404 126118275423552 G   Shutting down System DBus

Not sure yet why it happens.

[marmarek]

This may be related to https://community.teamviewer.com/t5/Linux/Teamviewer-13-amp-Debian-Stable-9-2-no-GUI/td-p/24817 (similar problem for Fedora: https://community.teamviewer.com/t5/Linux/Teammviewer-13-0-6634-not-working-on-fedora-26-64-bit/td-p/26905, but the Debian one has more details):

TeamViewer relies on session info to be made available to the daemon. The desktop manager (lightdm) is involved in this. TeamViewer needs this information to allow connecting to the login screen (lightdm) and then transfer to the actual user session.

We focus on that ability in our development. However, your scenario is also valid of course. Once we get the (non-installed) TAR package fixed, you might prefer it however. You should be able to just start it when needed and it should also work if no desktop manager exists.

Indeed there is no lightdm running in Qubes VM. Qubes GUI Agent service provide simiar functionality, but apparently not everything needed for TeamViewer.

[marmarek]

This may be related to https://community.teamviewer.com/t5/Linux/Teamviewer-13-amp-Debian-Stable-9-2-no-GUI/td-p/24817 (similar problem for Fedora: https://community.teamviewer.com/t5/Linux/Teammviewer-13-0-6634-not-working-on-fedora-26-64-bit/td-p/26905, but the Debian one has more details):

TeamViewer relies on session info to be made available to the daemon. The desktop manager (lightdm) is involved in this. TeamViewer needs this information to allow connecting to the login screen (lightdm) and then transfer to the actual user session.

We focus on that ability in our development. However, your scenario is also valid of course. Once we get the (non-installed) TAR package fixed, you might prefer it however. You should be able to just start it when needed and it should also work if no desktop manager exists.

Indeed there is no lightdm running in Qubes VM. Qubes GUI Agent service provide simiar functionality, but apparently not everything needed for TeamViewer.

[marmarek]

Ok, I've managed to launch it, but it still isn't clear to me what is the best actual solution.
Steps I've done:

• modify /usr/bin/qubes-run-xorg.sh to launch su -l user -c "/usr/bin/xinit ... with stdin connected to /dev/tty7 (</dev/tty7), and in new session (setsid -c) - this made the user session connected to some tty according to logind
• add "master-of-seat" udev tag to some device (I had pcspkr handy, which apparently is an input device ¯_(ツ)_/¯ ), then attach it to seat0; this made seat0 CanGraphical=yes; this is really weird in logind...
• modified /usr/bin/su binary to call pam_set_item(pamh, PAM_XDISPLAY, ":0") - this propagated into logind' user session "Display=:0" property.

The last step definitely was needed, without it still didn't worked. But not sure about others.

[marmarek]

Ok, I've managed to launch it, but it still isn't clear to me what is the best actual solution.
Steps I've done:

• modify /usr/bin/qubes-run-xorg.sh to launch su -l user -c "/usr/bin/xinit ... with stdin connected to /dev/tty7 (</dev/tty7), and in new session (setsid -c) - this made the user session connected to some tty according to logind
• add "master-of-seat" udev tag to some device (I had pcspkr handy, which apparently is an input device ¯_(ツ)_/¯ ), then attach it to seat0; this made seat0 CanGraphical=yes; this is really weird in logind...
• modified /usr/bin/su binary to call pam_set_item(pamh, PAM_XDISPLAY, ":0") - this propagated into logind' user session "Display=:0" property.

The last step definitely was needed, without it still didn't worked. But not sure about others.

[qubesissues]

@marmarek Can you please re explain your solution? It is not clear to me what exactly you changed. If you can please paste the full and exact lines you added to /usr/bin/qubes-run-xorg.sh

Also where/how did you add "master-of-seat" and "CanGraphical"?

How did you "modified /usr/bin/su binary to call pam_set_item(pamh, PAM_XDISPLAY, ":0")"? Please paste your exact code and explain how to made a binary change.

[qubesissues]

@marmarek Can you please re explain your solution? It is not clear to me what exactly you changed. If you can please paste the full and exact lines you added to /usr/bin/qubes-run-xorg.sh

Also where/how did you add "master-of-seat" and "CanGraphical"?

How did you "modified /usr/bin/su binary to call pam_set_item(pamh, PAM_XDISPLAY, ":0")"? Please paste your exact code and explain how to made a binary change.

[marmarek]

I don't have that VM anymore, but something like:

Also where/how did you add "master-of-seat" and "CanGraphical"?

/etc/udev/rules.d/80-something.rules:

ENV{ID_PATH}=="platform-pcspkr", TAG+="master-of-seat"

How did you "modified /usr/bin/su binary to call pam_set_item(pamh, PAM_XDISPLAY, ":0")"? Please paste your exact code and explain how to made a binary change.

Not directly binary, I've downloaded util-linux package source (dnf download --source util-linux), extracted it (rpmdev-extract ...src.rpm), extracted util-linux tarball there, modified login-utils/su-common.c to add pam_set_item(pamh, PAM_XDISPLAY, ":0"); at the beginning ot modify_environment function. Then rebuild the thing (./configure; make) and replace su binary with the new one. I was reluctant to use sudo make install, as I haven't applied any Fedora specific patches nor its configuration.

Anyway, modification of util-linux package is something really hacky and proper solution should handle it better.

[marmarek]

I don't have that VM anymore, but something like:

Also where/how did you add "master-of-seat" and "CanGraphical"?

/etc/udev/rules.d/80-something.rules:

ENV{ID_PATH}=="platform-pcspkr", TAG+="master-of-seat"

How did you "modified /usr/bin/su binary to call pam_set_item(pamh, PAM_XDISPLAY, ":0")"? Please paste your exact code and explain how to made a binary change.

Not directly binary, I've downloaded util-linux package source (dnf download --source util-linux), extracted it (rpmdev-extract ...src.rpm), extracted util-linux tarball there, modified login-utils/su-common.c to add pam_set_item(pamh, PAM_XDISPLAY, ":0"); at the beginning ot modify_environment function. Then rebuild the thing (./configure; make) and replace su binary with the new one. I was reluctant to use sudo make install, as I haven't applied any Fedora specific patches nor its configuration.

Anyway, modification of util-linux package is something really hacky and proper solution should handle it better.