Unfortunately at me not to receive the thin client to the x2go server...
On the thin client I see the console localhost login text: Sometimes it is very quickly visible some blue screen and again the console.
I have a computer about Linux and x2go the client. From it I am well connected to the server. I took from it the work file sessions and copied it as x2go-tce-sessions on http the server. The file from the server is downloaded normally. At line with APPEND in the end added fetch= http://10.3.1.117/x2go-tce/x2go-tce-filesystem.squashfs sessionsurl= http://10.3.1.117/x2go-tce/x2go-tce-sessions session=tsu to the file of a configuration
In the sessions name=tsu file (I tried to write session=0123456 as at the beginning of the session [0123456] file)
Nothing is impossible. On the thin client I see the console localhost login text: Sometimes it is very quickly visible some blue screen and again the console.
What can be made? Can as that it is possible to look at log on the thin client? added debug to APPEND. But how to look at it I do not know.
I seem to me close to the purpose
С Уважением Строганов Роман
Am 16.01.19 um 13:56 schrieb Stroganov Roman:
On the thin client I see the console localhost login text: Sometimes it is very quickly visible some blue screen and again the console.
This is an indication that your X session is starting up, but crashing. I suggest you log in as root@yourthinclientip via SSH using a public key provided via a pubkey= boot parameter and file.
As root, you can run:
service nodm stop
to stop the flashing.
Then, look for the files
/home/user/.xsession-errors
and
/var/log/Xorg.0.log
Their content might provide hints as to what is going on, so feel free to post them here.
At line with APPEND in the end added fetch= http://10.3.1.117/x2go-tce/x2go-tce-filesystem.squashfs sessionsurl= http://10.3.1.117/x2go-tce/x2go-tce-sessions session=tsu to the file of a configuration
Looks good ...
In the sessions name=tsu file (I tried to write session=0123456 as at the beginning of the session [0123456] file)
No, it's the session name, not the session id, so "tsu" is correct, assuming you have a session named "tsu".
What can be made? Can as that it is possible to look at log on the thin client? added debug to APPEND. But how to look at it I do not know.
The debug parameter probably won't help you. It will generate lots of output regarding the startup phase, but that's not where your problem lies. Startup is OK, it's the X Server that is acting up - for reasons currently unknown.
You might want to try passing boot parameter
xorg-resolution=1024x768 (or a lower resolution)
and/or boot parameters
nomodeset vga=normal
and/or boot parameter
xorg-driver=fbdev or xorg-driver=vesa
and see if the X Server will stay up with one of these.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Hi guys, Like a fool I upgraded my Fedora 28 workstation, and now my connection to my x2go session running on a CentOS 7.6.x server is acting really strangely.
It will connect and show the windows, but then the display starts flashing and the screen stops refreshing windows unless I'm actually using a specific window. Then it will work. For example, I'm typing this email in an xterm on system, which I'm using to SSH home to write this email.
I had to refresh the terminal before it would update, but now that I'm typing, it's working just fine. But the rest of the windows in my x2go session are NOT refreshing, and the screen isn't updating properly either. If I move the mouse, the screen *tries* to update things, but it's really screwey. While typing this in an xterm, if I move the mouse, I have to refresh my mail client (emacs & viewmail) by hand to get the display working again.
And it's very hard to get screen captures or cut'n'paste to show the info. But here goes...
Client: Fedora 28 x86_64 system. Updated as of Jan 16, 2019, which broke the setup.
x2goserver-common-4.1.0.3-1.fc28.noarch
x2goserver-xsession-4.1.0.3-1.fc28.noarch
x2goserver-4.1.0.3-1.fc28.x86_64
x2goclient-4.1.1.1-1.fc28.x86_64
x2goagent-4.1.0.3-1.fc28.x86_64Server: Redhat CentOS 7.6.1810 (Core)
x2goserver-common-4.1.0.3-1.el7.noarch
perl-X2Go-Log-4.1.0.3-1.el7.noarch
x2goagent-4.1.0.3-1.el7.x86_64
x2goserver-4.1.0.3-1.el7.x86_64
perl-X2Go-Server-DB-4.1.0.3-1.el7.x86_64
perl-X2Go-Server-4.1.0.3-1.el7.noarch
x2goserver-xsession-4.1.0.3-1.el7.noarchSession: XFCE
I'm loathe to reboot the server, because I've got work in various windows I need to keep going.
What's the trick to force the x2goclient to start a NEW session on the same host? For some reason, it's just automatically resuming, and not giving me the option to select between different sessions.
I strongly suspect it's a problem with Fedora, since the update on there of some libraries. Here's the dnf log from that upgrade:
2019-01-15T19:06:35Z DEBUG --> Starting dependency resolution 2019-01-15T19:06:35Z DEBUG ---> Package kernel-core.x86_64 4.19.14-200.fc28 will be installed 2019-01-15T19:06:35Z DEBUG ---> Package kernel.x86_64 4.19.14-200.fc28 will be installed 2019-01-15T19:06:35Z DEBUG ---> Package kernel-devel.x86_64 4.19.14-200.fc28 will be installed 2019-01-15T19:06:35Z DEBUG ---> Package kernel-modules-extra.x86_64 4.19.14-200.fc28 will be installed 2019-01-15T19:06:35Z DEBUG ---> Package kernel-modules.x86_64 4.19.14-200.fc28 will be installed 2019-01-15T19:06:35Z DEBUG ---> Package efivar.x86_64 35-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package efivar.x86_64 37-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package efivar-libs.x86_64 35-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package efivar-libs.x86_64 37-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package gnutls.x86_64 3.6.4-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package gnutls.x86_64 3.6.5-2.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package ibus-typing-booster.noarch 2.4.0-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package ibus-typing-booster.noarch 2.4.1-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package kernel-headers.x86_64 4.19.13-200.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package kernel-headers.x86_64 4.19.14-200.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package kernel-tools-libs.x86_64 4.19.10-200.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package kernel-tools-libs.x86_64 4.19.14-200.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package krb5-libs.x86_64 1.16.1-21.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package krb5-libs.x86_64 1.16.1-24.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libcdr.x86_64 0.1.4-4.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libcdr.x86_64 0.1.5-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libetonyek.x86_64 0.1.8-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libetonyek.x86_64 0.1.9-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libqxp.x86_64 0.0.1-2.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libqxp.x86_64 0.0.2-1.fc28 nwill be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package librados2.x86_64 1:12.2.9-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package librados2.x86_64 1:12.2.10-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libreport.x86_64 2.9.5-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libreport.x86_64 2.9.5-3.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libreport-filesystem.x86_64 2.9.5-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libreport-filesystem.x86_64 2.9.5-3.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package python3-libreport.x86_64 2.9.5-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package python3-libreport.x86_64 2.9.5-3.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libreport-web.x86_64 2.9.5-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libreport-web.x86_64 2.9.5-3.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libreport-plugin-reportuploader.x86_64 2.9.5-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libreport-plugin-reportuploader.x86_64 2.9.5-3.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libreport-plugin-bugzilla.x86_64 2.9.5-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libreport-plugin-bugzilla.x86_64 2.9.5-3.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libreport-gtk.x86_64 2.9.5-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libreport-gtk.x86_64 2.9.5-3.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libreport-gtk.x86_64 2.9.5-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libreport-gtk.x86_64 2.9.5-3.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libreport-cli.x86_64 2.9.5-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libreport-cli.x86_64 2.9.5-3.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libreport-anaconda.x86_64 2.9.5-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libreport-anaconda.x86_64 2.9.5-3.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libwpd.x86_64 0.10.2-4.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libwpd.x86_64 0.10.3-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libwpg.x86_64 0.3.2-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libwpg.x86_64 0.3.3-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package libzstd.x86_64 1.3.6-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package libzstd.x86_64 1.3.8-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package lm_sensors-libs.x86_64 3.4.0-17.20180522git70f7e08.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package lm_sensors-libs.x86_64 3.5.0-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package perl-DateTime-TimeZone.noarch 2.21-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package perl-DateTime-TimeZone.noarch 2.23-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package setroubleshoot.x86_64 3.3.19-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package setroubleshoot.x86_64 3.3.19-2.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package setroubleshoot-server.x86_64 3.3.19-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package setroubleshoot-server.x86_64 3.3.19-2.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package wget.x86_64 1.19.5-5.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package wget.x86_64 1.20.1-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package wvdial.x86_64 1.61-19.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package wvdial.x86_64 1.61-21.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package xscreensaver-base.x86_64 1:5.40-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package xscreensaver-base.x86_64 1:5.42-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package xscreensaver-extras.x86_64 1:5.40-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package xscreensaver-extras.x86_64 1:5.42-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package xscreensaver-extras-base.x86_64 1:5.40-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package xscreensaver-extras-base.x86_64 1:5.42-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package zstd.x86_64 1.3.6-1.fc28 will be upgraded 2019-01-15T19:06:35Z DEBUG ---> Package zstd.x86_64 1.3.8-1.fc28 will be an upgrade 2019-01-15T19:06:35Z DEBUG ---> Package kernel.x86_64 4.19.10-200.fc28 will be erased 2019-01-15T19:06:35Z DEBUG ---> Package kernel-core.x86_64 4.19.10-200.fc28 will be erased 2019-01-15T19:06:35Z DEBUG ---> Package kernel-devel.x86_64 4.19.7-200.fc28 will be erased 2019-01-15T19:06:35Z DEBUG ---> Package kernel-modules.x86_64 4.19.10-200.fc28 will be erased 2019-01-15T19:06:35Z DEBUG ---> Package kernel-modules-extra.x86_64 4.19.10-200.fc28 will be erased 2019-01-15T19:06:35Z DEBUG --> Finished dependency resolution
Dammit, it looks like it's really a server problem, because using the latest window client also shows the problem. Dang... Time to start a new session on the server and see how that works.
Am 16.01.19 um 16:39 schrieb John Stoffel:
What's the trick to force the x2goclient to start a NEW session on the same host? For some reason, it's just automatically resuming, and not giving me the option to select between different sessions.
If you have only one suspended session, and it has the same connection options as the one you requested during reconnect, the default is to auto-reconnect. The only exception to this rule is Published Application mode, where you will always see the tile with the various options.
Your options to avoid automatic session resuming are:
- run x2goclient with parameter --no-autoresume
- Create a session with slightly different settings, and use that to connect (say, windowed instead of fullscreen)
- force-terminate the session on the server, using a regular SSH session and the commands x2golistsessions (to find out the session ID) and x2goterminate-session SESSIONIDHERE. The session ID is the second column in the pipe-separated output by x2golistsessions.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
"Stefan" == Stefan Baur <X2Go-ML-1@baur-itcs.de> writes:
Stefan> Am 16.01.19 um 16:39 schrieb John Stoffel:
What's the trick to force the x2goclient to start a NEW session on the same host? For some reason, it's just automatically resuming, and not giving me the option to select between different sessions.
Stefan> If you have only one suspended session, and it has the same connection Stefan> options as the one you requested during reconnect, the default is to Stefan> auto-reconnect. The only exception to this rule is Published Application Stefan> mode, where you will always see the tile with the various options.
Stefan> Your options to avoid automatic session resuming are:
Stefan> - run x2goclient with parameter --no-autoresume Stefan> - Create a session with slightly different settings, and use that to Stefan> connect (say, windowed instead of fullscreen) Stefan> - force-terminate the session on the server, using a regular SSH session Stefan> and the commands x2golistsessions (to find out the session ID) and Stefan> x2goterminate-session SESSIONIDHERE. The session ID is the second Stefan> column in the pipe-separated output by x2golistsessions.
Stefan, THanks for the quick and helpful reply, I appreciate it! As for my problem, I ended up killing off and restarting my session on the CentOS system. I didn't have the time to debug, but if it happens again, I'll do the --no-autoresume and see if it's a per-session problem, or a system level problem.
Looking at the debug logs for x2goclient, I didn't really see anything major. Nor did I see anything in the logs on the server side which really helped. But something was messed up with the mouse and screen refreshes for sure.
John
Am 16.01.19 um 16:10 schrieb Stefan Baur:
Am 16.01.19 um 13:56 schrieb Stroganov Roman:
On the thin client I see the console localhost login text: Sometimes it is very quickly visible some blue screen and again the console. I just encountered a similar issue on a test build. I'm not sure if it is a coincidence, but it might be the current version in git is broken. I'll do a few test runs and will let you know.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Am 16.01.19 um 18:35 schrieb Stefan Baur:
Am 16.01.19 um 16:10 schrieb Stefan Baur:
Am 16.01.19 um 13:56 schrieb Stroganov Roman:
On the thin client I see the console localhost login text: Sometimes it is very quickly visible some blue screen and again the console. I just encountered a similar issue on a test build. I'm not sure if it is a coincidence, but it might be the current version in git is broken. I'll do a few test runs and will let you know.
Hi Roman,
just start a new build with
./x2gousbpatch && ./x2gobuild2 2>&1 | tee logfile
and afterwards, pick the files starting with x2go-tce-* from the directory with the newer timestamp.
We had a bug in the TCE version on github that only triggered if no local screensaver is used. In our current test setup, we're using one, so we didn't catch that issue right away. Once we started using the image the same way as you, we were affected by the bug as well, and it was easy to track down.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
-
John Stoffel -
Stefan Baur -
Stroganov Roman