problem with TurbVNC and Ubuntu 24

[Andrea Farina]

Dear users,

I'm been using TurboVNC installed on LINUX since 2020 without problems. Now I've upgraded to UBUNU 24 and I've installed the last version 3.1.3.

Wgen i start the server on the limux machine all goes smoothly but, when I try to connect from my MacBook both using VNCConnect and the embedded Screen sharing, after inserting the password I get the error:

"Oh No! Something has gone wrong!" and no way to connect.

If, instead of TurboVNC I use RealVNC or the standard vncserver the connection is accepted but with a very poor graphics. I would like to continue using TurboVNC because, I can manage multiple vnc displays for many users with an init script.

Do you know how to manage this problem? Are there some security limits on the connection?

Thanks a lot!

Andrea

[DRC]

Which window manager are you attempting to use?  I have tested GNOME,
MATE, and Xfce under Ubuntu 24.04 with no issues.  There is a known
issue with the GNOME Classic window manager on Ubuntu 24.04, however. 
In order to use GNOME Classic/Ubuntu 24.04 with TurboVNC, you have to
set TVNC_USERDBUS=1 in the environment, which limits you to one
simultaneous session.

DRC

[Andrea Farina]

Dear DRC,

thank you very much. I've tried to set the variable using the command 

export TVNC_USERDBUS=1 before creating the display with 

/opt/TurboVNC/bin/vncserver :2 -geometry 1440x900

but the problem still remains.

I could solve it discarding the option -geometry 1440x900. Don't know why, but in the last versions I could set geometry without problems.

Thanks again

Regards

Andrea

[DRC]

That shouldn’t happen. Please answer my question regarding which window manager you are using.

On Dec 21, 2024, at 5:59 PM, Andrea Farina <andreaf...@gmail.com> wrote:

Dear DRC,

--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/c38c9db9-c7d7-44e4-a9c2-0fd418275033n%40googlegroups.com.

[Andrea Farina]

Dear DRC, sorry I'm not so expert in those things!

On the physical machine each user has the standard desktop is GNOME. If I successfully connect without the -geometry options, the result of the command 

wmctrl - m is GNOME Shell, so I guess GNOME is what I try to use with TurboVNC.

I use the standard xstartup.turbovnc file in the folder /opt/TurboVNC/bin that is the same you can download from Github https://github.com/TurboVNC/turbovnc/blob/main/unix/xstartup.turbovnc.

I've tried to put in the second line TVNC_USERDBUS=1 and connect with -geometry but without success.

If you can explain me more in details which commands I have to use I can debug the problem.

Thanks a lot!

Andrea

[DRC]

I mentioned TVNC_USERDBUS in case you were using GNOME Classic, but that environment variable should not be necessary with plain (non-classic) GNOME. I will try to reproduce the issue, but I may not be able to. (This sort of issue tends to be system-specific and may not even be related to TurboVNC.) The best thing you can do to debug it is to try prior versions of TurboVNC. Try 3.1, then try 3.0.3, then 3.0, then 2.2.7. Stop as soon as you find a version that behaves either better or worse than the current version— that is, a version that either doesn’t exhibit the bug or exhibits a worse bug. (The version of GNOME in Ubuntu 24.04 may not work with TurboVNC 2.2.x, for instance.) What I’m looking for is some way to narrow down a specific version of TurboVNC that might have introduced the issue, which may give me a clue as to the feature that introduced it, which may give me a clue as to how to reproduce and fix it.

On Dec 22, 2024, at 3:27 AM, Andrea Farina <andreaf...@gmail.com> wrote:

Dear DRC, sorry I'm not so expert in those things!

To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/fbb360c7-7778-4844-84cf-d9790b47c926n%40googlegroups.com.

[Andrea Farina]

Dear DRC,

here are the exact steps.

In September I’ve upgraded from 20 to 22. I had TurboVNC 2.x and after the upgrade I’ve also update to the last version that was 3.03. No problem and all started to work smoothly.

On Friday I had to further upgrade because I’ve received a vulnerability report from my ICT admin because of the OpenSSH version 8.9. So I had to update to 9.3 that is supported by UBUNTU 24. After the upgrade I had the TurboVNC version 3.03 already installed and I’ve received the same error, this is because I update to 3.1. So, at my knowledge, at least TurboVNC 3.03 has the issue.

Actually, I cannot try the older versions because the machine is shared.

What I guess is that it might be a problem due to the fact that I don’t have a fresh installation but a 2 times updated version of Ubuntu… 

Thanks a lot 

Andrea Farina

 

Il giorno 22 dic 2024, alle ore 17:35, 'DRC' via TurboVNC User Discussion/Support <turbovn...@googlegroups.com> ha scritto:



To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/125177A4-46A9-4C50-9F35-5FCD5A1A75A1%40virtualgl.org.

[DRC]

Can you check the TurboVNC session log under ~/.vnc on the server. It occurs to me that the TurboVNC Server may be trying to execute xinitrc because the GNOME session desktop file isn’t available (due to a missing package.)

To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/FDC0649F-3191-4E32-883B-8EF9D14A1E96%40gmail.com.

[Andrea Farina]

Dear DRC,

Here attached the two log files obtained with and without -geometry option. They look pretty the same except a part with warnings related to XKEYBOARD keymap compiler (xkbcomp) that is present two times in the working log and one time in the not_working log.

Hope this can help finding the issue, which is probably related only to my installation…

Best regards

Andrea

To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/DBDA2518-C456-4C6C-8B42-E02E4190D3A1%40virtualgl.org.

[DRC]

The TurboVNC Server isn’t invoking xinitrc, so my previous suspicion was incorrect. At this point, I will have to try reproducing the issue. What VNC viewer are you using, and what client O/S? I ask because the session log indicates that the TurboVNC Server is enabling the outdated and slow ZRLE encoding, which would never happen if you were connecting with the TurboVNC Viewer.

To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/A6ECA3FF-63B7-456A-A940-F31FC3BA9F67%40gmail.com.

<log_without_geometry_working.log>

--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/A6ECA3FF-63B7-456A-A940-F31FC3BA9F67%40gmail.com.

<log_with_geometry_not_working.log>

--
You received this message because you are subscribed to the Google Groups "TurboVNC User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turbovnc-user...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/A6ECA3FF-63B7-456A-A940-F31FC3BA9F67%40gmail.com.

[Andrea Farina]

Dear DRC,

My client is on a MacBookPro M1. I’ve installed TurboVNC viewer, RealVNC and the embedded screen Sharing.

All of them present the same error when I try to connect using the -geometry 1440x900 option. I tried another things: using the -geometry with many resolutions; here is the report:

1200x900 working!

1300x900 working!

1400x900 working!

1440x900 not working (waht I’ve always used before)

1920x1080 not working

1200x1080 working!

1728x1117 working! (my halved 16inches resolution monitor)

So I honestly think that the problem is in some strange combination of resolutions. Hope this can help!

Best regards!

Andrea

To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/C7663621-67D6-4D52-AEDD-8C94812E7C30%40virtualgl.org.

[DRC]

OK. It sounds like a window manager issue, then. The “Oh no! Something has gone wrong!” screen comes from GNOME, not TurboVNC. It means that you have successfully connected to the TurboVNC Server, but the window manager crashed. I have never seen such a crash that was resolution-specific, however.

To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/208507FE-4B86-4B4E-8665-85A6C09FAF73%40gmail.com.

[DRC]

Reproduced.  In my case, specifying -geometry (or $geometry in turbovncserver.conf) never works.  It fails with the "Oh No! Something has gone wrong!" screen if I specify 1440x900, but it fails with a black screen otherwise.  The same happens with TigerVNC, and TigerVNC's startup mechanism is so different from TurboVNC's that that strongly suggests a GNOME bug.  Other window managers, such as MATE or Xfce, work fine.  As a workaround, you can start the TurboVNC Server with no arguments and then pass '-desktopsize 1440x900' to the TurboVNC Viewer when connecting (or enter 1440x900 into the "Remote desktop size" field of the Connection tab in the TurboVNC Viewer Options dialog.)

I am investigating whether a more automatic workaround might be possible.

To view this discussion visit https://groups.google.com/d/msgid/turbovnc-users/208507FE-4B86-4B4E-8665-85A6C09FAF73%40gmail.com.

[DRC]

Disregard my previous remark about a black screen.  That was user error.  I can now reproduce exactly the issue you report.  In fact, specifying any resolution that is in the default list of resolutions reported by X RandR causes the failure.  If I remove 1440x900 and 1920x1080 from that list, then those resolutions can then be selected with -geometry/$geometry.  Same goes for the TigerVNC Server.  I am still investigating.

[DRC]

Unfortunately I am clueless at this point.  Given that the issue also occurs with TigerVNC and doesn't occur with any other WM or any other O/S distribution, there isn't much I can do to isolate it.  I googled around and didn't find any other reports of it.  There unfortunately isn't anything else I can do barring further information.

[DRC]

It does in fact appear that I can work around this by changing our X RandR logic.  Stand by.  I will look into it more early next week.

[DRC]

Never mind.  The workaround was a red herring.  I discovered that I could work around the immediate problem, whereby GNOME crashes if one of the default X RandR resolutions is initially specified in the TurboVNC session (by using -geometry/$geometry), but then if I change the resolution with 'xrandr -s', the crash still occurs.  Both the O/S-provided TigerVNC 1.13.1 package and the project-provided TigerVNC 1.14.1 package demonstrate some variation of the same issue.  The O/S-provided package behaves similarly to TurboVNC.  The project-provided package behaves similarly to the workaround I tried, in that it allows a default X RandR resolution to be initially selected with -geometry/$geometry but subsequently fails if a default X RandR resolution is selected with 'xrandr -s'.  (If a default X RandR resolution was initially selected, then attempting to select another default resolution with 'xrandr -s' causes the resolution to briefly change but immediately revert to the previous resolution.  If a non-default X RandR resolution was initially selected, then attempting to select a default resolution with 'xrandr -s' causes GNOME to stop displaying the desktop or responding to input, so it has effectively crashed.)

Note that I can also reproduce the failure with recent versions of GNOME on Fedora.  Based on the fact that GNOME 44 in Fedora 38 fails but GNOME 42 in Ubuntu 22.04 doesn't, the issue must have been introduced in GNOME 43 or 44.

I could unfortunately write a book about how GNOME has become increasingly hostile to remote display environments.  I could write another book about how Wayland has complicated the remote display picture to the point that Linux remote display developers basically can't figure out where to go from here.  For me personally, I'm trying to maintain TurboVNC as best I can, but with no R&D budget or staff or salary, I have no ability to be proactive or forward-looking.  That's why, when I observe issues like this with a recent platform, I look at TigerVNC to see if they have fixed or worked around it.  (Development of TigerVNC is primarily funded through sales of a commercial/semi-proprietary product built around it, so they have a lot more flexibility than I do.)  If they have fixed or worked around it, then I can adopt their fix.  Otherwise, however, I unfortunately can't devote the weeks of labor that would likely be required to track this down, since no one is paying for that labor.  My standard rant on this is that Linux graphics stack developers are acting as if remote display has no relevance, when I would argue that the potential relevance of Linux as a remote display platform is much higher than the potential relevance of Linux as a desktop platform.

tl;dr: Use the workaround I mentioned earlier, i.e. changing the resolution remotely, or use another window manager.

[DRC]

I did finally find some issues that suggest general X RandR problems with GNOME 44+/X11:

https://www.reddit.com/r/gnome/comments/1cimcu0/no_background_after_xrandr_in_gnome_46/

https://www.reddit.com/r/Fedora/comments/14f9u5c/gnome_44_and_xrandr/

The writing is on the wall that GNOME may not support X11 for much longer.  You can read about the general problems with creating a Wayland VNC server here (and by following the links in the thread):

https://github.com/TurboVNC/turbovnc/issues/18

Essentially the problem is that, in Wayland, the compositor and window manager are integrated, so each window manager implementation (GNOME, KDE, etc.) has its own specific implementation of Wayland.  There doesn't seem to be any kind of convergence around a common set of Wayland extensions for remote display, so it wouldn't be possible (at least at the moment) to develop a TurboVNC-like solution for Wayland.  The more I dug into that problem, the more I also realized that the RFB protocol is very much a product of the limitations of X11 and 1980s displays.  To really leverage the capabilities of Wayland, it would be much better to develop a new remote display solution from the ground up, a solution that is essentially a standalone Wayland compositor with remote window management built in.  (Thus, you wouldn't run GNOME or KDE or whatnot in the compositor.  The compositor would simply transmit the contents of application windows on the server to local windows on the client and take advantage of the client's window manager.)  However, such a solution would be a herculean task-- probably requiring an industry consortium to come up with an open protocol and multiple developers working full-time for at least a year to come up with a prototype.  I don't see that happening in the open source community.  The more likely scenario is that a company comes up with a proprietary solution for it, doesn't share their research, and makes open source remote display solutions increasingly irrelevant.  As long as window managers like Xfce exist that will run on X11, then people will still be able to use TurboVNC, but applications and frameworks (GTK, Qt, etc.) will probably start defocusing from X11, if they haven't already.  I am certainly very open to conversations regarding how to mitigate that situation, which may mean collaborating with other players in the open source remote display field.

[DRC]

Because I don't give up as easily as I say I do, I spent another day with the issue and was able to find an automatic workaround.  Basically GNOME 44+ doesn't like it if the current X RandR mode is not the first in the list, so the TurboVNC Server now ensures that it is.  Changing the resolution using 'xrandr -s {mode}' still behaves erratically with recent GNOME releases (and only with recent GNOME releases), in that sometimes 'xrandr -s {mode}' doesn't change the resolution, and other times it disables the X RandR output, which causes the desktop to disappear.  That can also be worked around by changing the resolution using 'xrandr --output VNC-0 --mode {mode}'.  In my testing with GNOME Ubuntu 24.04 and Fedora, TurboVNC now behaves as expected, except for the aforementioned issues with 'xrandr -s'.  I also verified that there are no behavior regressions when using GNOME on Ubuntu 22.04 and Rocky Linux 8, and when using MATE on Ubuntu 24.04.