Description of problem: I have freenx-server installed and configured in Fedora 19. I tried to access the desktop using a nxclient from a Fedora 18 machine. I see "Oh no! something has gone wrong. A problem has occurred and the system can't recover, please logout and try again" At-least with Fedora 18/17 it used to go back to the fallback mode. Version-Release number of selected component (if applicable): [saga@eatbetween-dl ~]$ rpm -q freenx-server freenx-server-0.7.3-31.fc19.x86_64 [saga@eatbetween-dl ~]$ rpm -q gnome-shell gnome-shell-3.8.1-1.fc19.x86_64 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Setup nxserver using, $ sudo nxsetup --install --setup-nomachine-key
I confirm that an upgraded Fedora 18 x86_64 to 19 beta breaks ns functionality. It always shows the "sad" screen and semms there is no fallback mode I tried useing both remmina-nx and nomachine client. It doesn't work even using F 19 on both sides (client ad server) Any advice about how it is supposed to have it working? Do we need to install a differente Desktop Environment like XFCE or KDE? This is a really annoyng bug that shuold be fixed Best regards
Experiencing the same issue after an upgrade from F18 to F19. Thank you, Nathan
Okay, so this appears to at least be a problem with forwarding a gnome-session over ssh. Trying a Windows nomachine client, Windows XMing server, or a Mac X11 server, I am unable to execute "gnome-session --session gnome-classic" through an ssh session with X forwarding enabled and verified working through the execution of other X apps. How reproducible: With Gnome3 installed and X11 forwarding enabled in the local sshd, login via a remote ssh client session with X forwarding enabled, and attempt to execute "gnome-session --session gnome-classic". Steps to Reproduce: 1. Perform default install of F18 with Gnome3. 2. Upgrade to F19 following the fedora-upgrade process. 3. Login remotely via ssh with X forwarding enabled (on MAC, "ssh -X ip.add.re.ss") 4. In the ssh client session, execute "gnome-session --session gnome-classic" Actual results: X server produces a target window for gnome-session, which displays an error message. I could attach a screenshot if desired. Expected results: X server produces a target window for gnome-session, which then displays a typical gnome-classic desktop. Additional info:
Okay, so this appears to at least be a problem with forwarding a gnome-session over ssh. Trying a Windows nomachine client, Windows XMing server, or a Mac X11 server, I am unable to execute "gnome-session --session gnome-classic" through an ssh session with X forwarding enabled and verified working through the execution of other X apps. How reproducible: With Gnome3 installed and X11 forwarding enabled in the local sshd, login via a remote ssh client session with X forwarding enabled, and attempt to execute "gnome-session --session gnome-classic". Steps to Reproduce: 1. Perform default install of F18 with Gnome3. 2. Upgrade to F19 following the fedora-upgrade process. 3. Login remotely via ssh with X forwarding enabled (on MAC, "ssh -X ip.add.re.ss") 4. In the ssh client session, execute "gnome-session --session gnome-classic" Actual results: X server produces a target window for gnome-session, which displays an error message. I could attach a screenshot if desired. Expected results: X server produces a target window for gnome-session, which then displays a typical gnome-classic desktop. Additional info: I apologize for my lack of clarity or brevity. If you would like further details, advise me on how to get them and I will. Thank you, Nathan
Same problem here accessing a F 19 x86_64 desktop server from a F 19 x89_64 client. I suppose we should "force" gnome shell in gnome-classic-session and it MAY have something to do with nxserver configuration file I tried setting COMMAND_START_GNOME=gnome-session --session=gnome-classic.session with no luck Does anyone has a workourund? This is a very annoyng bug .. Best regards Alex
I have also encountered this bug. Fresh install of F19. Have also tried switching to KDE. Same issue.
Actually, it does work with KDE. I didn't realise I needed to switch to KDE in the client!
Hmmm... Although the default toolbar at the bottom of the screen does not appear, so KDE is not working properly
Here's a workaround -- I installed Gnome 2, now called the MATE Desktop: sudo yum -y groupinstall "MATE desktop" Depending on which nx server you use, edit the relevant file: nxserver: /usr/NX/etc/node.cfg freenx: /etc/nxserver/node.conf Change the COMMAND_START_GNOME line to be: COMMAND_START_GNOME=/bin/mate-session Restart the nx server if you chose, and chose gnome as your desktop. You'll get the Gnome 2 desktop which works fine. MATE and GNOME 3 seem to co-exist nicely. Frustratingly this does install a lot over overhead applications (claws-mail,etc.), but it works well.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.