If you have gnome-flashback installed, it works with gnome3 now.-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_- Eskimo North Linux Friendly Internet Access, Shell Accounts, and Hosting. Knowledgeable human assistance, not telephone trees or script readers. See our web site: http://www.eskimo.com/ (206) 812-0051 or (800) 246-6874.
On Mon, 7 May 2018, Heinz Wrobel wrote:
Date: Mon, 7 May 2018 16:12:49 +0000 From: Heinz Wrobel <heinz.wrobel@nxp.com> To: "x2go-user@lists.x2go.org" <x2go-user@lists.x2go.org> Subject: [X2Go-User] installing x2go server on a mostly headless RHEL 7, solving black screen on Windows client
Hi,
I found a few interesting things when trying to install the x2go server on a somewhat customized and mostly headless RHEL 7 VM in the cloud, specifically in this case on a RHEL 7.2. These findings might help others, so I thought I'd post the details with some side notes.
Following the instructions on https://wiki.x2go.org/doku.php/doc:installation:x2goserver for RHEL 7 was not quite enough to install a working server on this specific RHEL 7 VM. Due to the various documented issues with Gnome 3, I had switched the VM to "Server with GUI" with Xfce, but it still didn't help. On installing Xfce I even had to skip a broken dependency regarding sound support to make it install, but that is a side note only in case you also see something like that. I don't care about sound, so that single thing was easy to ignore for me.
In any case, when trying to connect with a Windows x2go client, not even the X desktop window on the client showed up initially.
Some investigation and log searching revealed that /usr/bin/x2goruncommand relies on dbus-run-session. This RHEL 7 machine only had dbus-launch because its dbus libs are older, and therefore it completely failed to even invoke the Xsession properly. So I hacked x2goruncommand to do the following fallback:
typeset dbus_wrapper="$(type -P "dbus-run-session")" typeset dbus_wrapper_args="" if [ -z "${dbus_wrapper}" ]; then typeset dbus_wrapper="$(type -P "dbus-launch")" typeset dbus_wrapper_args="--exit-with-session" fi[...] XSESSION_EXEC="$cmd" STARTUP="/usr/bin/env LD_LIBRARY_PATH=${LD_LIBRARY_PATH} ${STARTUP}" ${dbus_wrapper} ${dbus_wrapper_args} /etc/x2go/Xsession >> "$MESSAGE_FILE" 2>&1
This little hack was good enough to make the client show the server window, but I got a black window only. No remote desktop in sight still. Using htop on the server, I saw that while the x2goagent was running, there was no xfce4 session of any kind or anything else that looked like a process related to any desktop session.
After a long set of weird and clueless debug steps I found a problem because I manually invoked "dbus-launch --exit-with-session /etc/x2go/Xsession". It complained about elements in bash-completion.d not being valid identifiers, starting with "_itweb-settings()". Anything bad that can be fixed should be fixed while debugging along, so I started fixing those to see what might happen next. Iteratively I went through the following files in /etc/bash_completion.d to remove the "-" from the function name identifiers only(!) that it was complaining about:
- rhn-migrate-classic-to-rhsm
- rhsm-debug
- rhsm-icon
After the manual invocation of the Xsession no longer complained about bash-completion, I tried the client and ... Ta Da! ... the session came up and seems to work well now. I am sure there are other things that may need fixing and your mileage may vary, but all that is for another day.
The moral of the story: It's not always just older dbus libs or similar things. Even seemingly unrelated bash completion quirks can make the x2go Xsession script fail to start up ... and not show anything in any obvious log file.
BR,
Heinz
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user