When connecting always appears message: The connection with the remote server was shut down. Immediately after "Establishing display connection" On server side in nxserver.log I see: /usr/lib64/NX/bin/nxagent: symbol lookup error: /usr/lib64/libXfixes.so.3: undefined symbol: _XGetRequest Reproducible: Always Steps to Reproduce: 1. install and configure nxserver-freenx 2. connect with nxclient Actual Results: cannot get into desktop Expected Results: my gnome desktop
Created attachment 316461 [details] emerge --info
So did you run revdep-rebuild yet after the recent Xorg related upgrades?
nx le # revdep-rebuild * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 100% ] * Dynamic linking on your system is consistent... All done.
Could this be related? https://bugzilla.redhat.com/show_bug.cgi?id=782251
_XGetRequest is a symbol from >=x11-libs/libX11-1.4.99 (rather, 1.5.0) and this undefined will happen to everyone who does the mistake of *downgrading* X.org and it's libraries (like libX11) Downgrading is not supported. Since you have emerged the newer libX11 at some point, upgrade back to it, and stick to it. Go upwards, not downwards
x11-libs/libXi-1.6.1 was built with the following: USE="(multilib) -doc -static-libs" So, i did not downgrade. But it seems that nxserver ships its own libXi: nx log # locate libXi.so /usr/lib32/libXi.so /usr/lib32/libXi.so.6 /usr/lib32/libXi.so.6.1.0 /usr/lib64/libXi.so /usr/lib64/libXi.so.6 /usr/lib64/libXi.so.6.1.0 /usr/lib64/NX/lib64/libXi.so /usr/lib64/NX/lib64/libXi.so.6 /usr/lib64/NX/lib64/libXi.so.6.0
(In reply to comment #6) > x11-libs/libXi-1.6.1 was built with the following: Who said anything about libXi? "i is not 11"
*** Bug 424683 has been marked as a duplicate of this bug. ***
oooops, my fault sorry i never downgraded anything! ;) x11-libs/libX11-1.5.0 was built with the following: USE="ipv6 (multilib) -doc -static-libs -test"
This is what i get when running manually le@nx ~ $ /usr/bin/nxnode --agent NX> 1000 NXNODE - Version 3.2.0-74-TEAMBZR104 OS (GPL, using backend: 3.5.0) NX> 716 Starting NX Agent ... NXAGENT - Version 3.5.0 Copyright (C) 2001, 2011 NoMachine. See http://www.nomachine.com/ for more information. Info: Agent running with pid '13969'. Session: Starting session at 'Fri Jul 6 17:14:57 2012'. Info: Using alpha channel in render extension. Info: Not using local device configuration changes. error opening security policy file /usr/X11R6/lib/X11/xserver/SecurityPolicy nxagentXkbGetRules: WARNING! Failed to stat file [/usr/X11R6/lib/X11/xkb/rules/xorg]: Unknown error -1. /usr/lib64/NX/bin/nxagent: symbol lookup error: /usr/lib64/libXfixes.so.3: undefined symbol: _XGetRequest NX> 716 NX Agent exited with status: 127 NX> 1001 Bye.
*** Bug 425548 has been marked as a duplicate of this bug. ***
manual rebuilds of X11 libraries is required after downgrade, done by accident or not, like emerge -1 libXtst libXfixes
Why are you talking about downgrading?
well.... i try the following now nx le # emerge -1av `qlist -IC libX` These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-libs/libX11-1.5.0 USE="ipv6 -doc -static-libs -test" 0 kB [ebuild R ] x11-libs/libXau-1.0.7 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXdmcp-1.1.1 USE="-doc -static-libs" 0 kB [ebuild R ] x11-libs/libXfont-1.4.5 USE="ipv6 -doc -static-libs" 0 kB [ebuild R ] x11-libs/libXext-1.3.1 USE="-doc -static-libs" 0 kB [ebuild R ] x11-libs/libXfixes-5.0 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXrender-0.9.7 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXt-1.1.3 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXi-1.6.1 USE="-doc -static-libs" 0 kB [ebuild R ] x11-libs/libXmu-1.1.1 USE="ipv6 -doc -static-libs" 0 kB [ebuild R ] x11-libs/libXpm-3.5.10 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXScrnSaver-1.2.2 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXcomposite-0.4.3-r1 USE="-doc -static-libs" 0 kB [ebuild R ] x11-libs/libXcursor-1.1.13 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXdamage-1.1.3 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXft-2.3.1 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXinerama-1.1.2 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXp-1.0.1 USE="-static-libs" 294 kB [ebuild R ] x11-libs/libXrandr-1.3.2 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXv-1.0.7 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXxf86vm-1.1.2 USE="-static-libs" 0 kB [ebuild R ] x11-libs/libXaw-1.0.11 USE="-doc -static-libs" 0 kB [ebuild R ] x11-libs/libXtst-1.2.1 USE="-doc -static-libs" 0 kB Total: 23 packages (23 reinstalls), Size of downloads: 294 kB Would you like to merge these packages? [Yes/No]
Manual rebuild of the X libraries doesn't appear to solve this particular issue. I had actually rebuilt my entire system as mentioned in the duplicate bug, and it did not help. If libXtst is built while libX11 1.5 (current stable) is installed, it takes on a reference to _XGetRequest, and then nxagent will fail to run with a _XGetRequest symbol lookup error. nx itself seems to be unable to cope with changes caused by the new libX11. The only way to reliably get nxagent to run at this time is to downgrade libX11 to 1.4.4 (and don't forget to re-emerge the rest of your xlibs that are looking for libX11 1.5 or xorg will fail to start).
Why this bug is marked RESOLVED Invalid! Whoever mark marked libX11-1.5.0 stable screw it up and now they are trying to tell us it is our fault because we try to downgrade it. I never tried to downgrade anything during the process and got hit by the same bug. Why Samuli Suominen is trying to push his agenda about downgrading it, his sounds as if it was our fault. I solved the problem by going to: net-misc/nxserver-freenx It seems to me upgrading Gentoo seems to me is more and more problematic. Maybe for those of us who need stable system once it is working, never upgrade it for 2-3 years and reinstall the enteire system after.
I also do not understand this behaviour. I never downgrade any packages without a reason. And I really do not thing, that this is my fault here. Anyways, what did you fix? I have got this problem with nxserver-freenx.
(In reply to comment #13) > Why are you talking about downgrading? I think he's referring to my comment on bug 424683 but I don't think he understood what I wrote. I downgraded libX11 as part of a workaround until this issue can be fixed. nx runs without the error when the xlibs are rebuilt around libX11 1.4.4 My downgrading was not the cause and had nothing to do with the _XGetRequest symbol lookup problem I was experiencing. That started happening only after upgrading to libX11 1.5 and rebuilding my xlibs on that version.
(In reply to comment #17) > I also do not understand this behaviour. I never downgrade any packages > without a reason. And I really do not thing, that this is my fault here. > > Anyways, what did you fix? I have got this problem with nxserver-freenx. I made a type I did fix it by unmerging: nxserver-freenx and emerged: net-misc/nxserver-freeedition Here are some hints, where to find the ssh-key for the client etc.: http://www.nomachine.com/documentation/admin-guide.php freeedition worked for me. An alternative would be to mask x11-libs/libX11-1.5.0 and "emerge -1 =x11-libs/libX11-1.4.4 and run revdep-rebuild (hopefully it will fix it for you) if you go this way post the results. Ps. It seems to me Samuli Suominen want this problem to go away by making the bug INVALID; but it is not happening. Samueli get real, open this but and fix it! Don't pretend it is not there!
Ok, i am trying downgrading right now. I did this a few days ago and revde-rebuild did not help me by this. I emerge all libX* manually now and will see then! ;) i never got freeedition running. :(
(In reply to comment #20) > Ok, i am trying downgrading right now. I did this a few days ago and > revde-rebuild did not help me by this. I emerge all libX* manually now and > will see then! ;) > > i never got freeedition running. :( What kidnd of problem you had with freeedition? After you unmerge freenx and emerge freeedition. Restart it, find the ssh key. Freeediton installs the key in diferent place. You will find it in: /usr/NX/share/keys/default.id_dsa.key just copy this key to you client and it should work; it did work for me.
It is working again!! Downgraded to libX11-1.4, libXi-1.5 and reemerged libX* like mentioned in comment 14. So, one should fix this for newest libX11
(In reply to comment #21) > (In reply to comment #20) > > Ok, i am trying downgrading right now. I did this a few days ago and > > revde-rebuild did not help me by this. I emerge all libX* manually now and > > will see then! ;) > > > > i never got freeedition running. :( > > What kidnd of problem you had with freeedition? > > After you unmerge freenx and emerge freeedition. > Restart it, find the ssh key. Freeediton installs the key in diferent place. > You will find it in: > /usr/NX/share/keys/default.id_dsa.key > > just copy this key to you client and it should work; it did work for me. dont know exactly. Maybe the keys were the problem. but i cannot really tell.
(In reply to comment #19) > An alternative would be to mask x11-libs/libX11-1.5.0 > and "emerge -1 =x11-libs/libX11-1.4.4 If you're going to do this it bears mentioning that at least in my case libXi blocked the downgrade to libX11-1.4.4 and had to have >=1.6.0 masked as well. Nothing else needed to be masked in my case, but ymmv. revdep-rebuild was also not able to determine all the necessary rebuilds. The xlibs needed to be manually re-emerged after the downgrade to libX11 1.4.4. (In reply to comment #22) Whoops, I see you found out about libXi already.
(In reply to comment #24) I'll be upgrading another system on Friday, so what do I need to mask beside: mask x11-libs/libX11-1.5.0
le@nx ~ $ cat /etc/portage/package.mask >=x11-libs/libX11-1.5 >=x11-libs/libXi-1.6
Well, libGL also says undefined reference.... So i really dont know where this goes. Dont want to remerge everything. Ill try freeedition now...
hmm, i removed the two masks and remerged the newest libX11 and libXi versions. revdep-rebuild also does nothing here. Hope this will finally solve my problems now. (freeedition is running, thx for the tip) ;)
Looks like libGL does need to be rebuilt if you downgrade libX11, and I discovered that pulseaudio would segfault until rebuilt as well. I went ahead and rebuilt everything related to X (gnome, etc) regardless of whether it was actually necessary, just to make sure everything was on the same page with regard to the version of libX11. I have everything running stable at this point on libX11 1.4.4. I'm posting this through a Gnome NX session in fact. nxserver-freeedition is a binary distribution of Nomachine's server, so I expect that will work regardless of what your xlibs are up to.
After a few mails with Xenon (and the details from this bug and bug #425548), I can confirm this is a bug in net-misc/nx (and the way we build the NX libraries). For a long time, nx was built to rely on some system X11 libraries, but as time passes and code diverges, this gets buggier and buggier. x2go upstream (more or less the only still active NX project) also reported instability problems with this system, and now build nx libs in a more standalone way. I added an updated nx package, using x2go patched sources. This works fine with x2go, and from a quick test, still works with freenx. So please test with =net-misc/nx-3.5.0.14 I hope this does not trigger hidden bugs so we can stable this one quickly
i cannot see this update in portage.
Weel, did not wait long enough. This seems to work now! :)
But now.... revdep-rebuild -> * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 78% ] * broken /usr/lib64/NX/bin/nxauth (requires libNX_Xau.so.6) [ 100% ] * Generated new 3_broken.rr * Assigning files to packages * /usr/lib64/NX/bin/nxauth -> net-misc/nx * Generated new 4_raw.rr and 4_owners.rr * Cleaning list of packages to rebuild * Generated new 4_pkgs.rr * Assigning packages to ebuilds * Generated new 4_ebuilds.rr * Evaluating package order * Generated new 5_order.rr * All prepared. Starting rebuild emerge --complete-graph=y --oneshot --jobs=4 --load-average=1.5 net-misc/nx:0 over and over again...
Sorry I missed one X library, fixed in -r1 (will appear soon in your emerge sync)
Everything seems to be fine now! :)
I've updated to the new nx package, unmasked the libX11 update and rebuilt everything. libX11 & libXtst have references to XGetRequest once more, and the new nx package seems to be fully working.
Was hitting the same issue after emerge -eav system; emerge -eav world echo net-misc/nx >> /etc/portage/package.keywords emerge nx fixed the issue. Now using 3.5.0.14-r1 tested with neatx Thanks for the bugfix! Cheers,
Can we get the more recent working nx stabilized? I just ran into this problem on a completely fresh x86 build.
does this problem persist in stable tree? using ~amd64 i have no problems since this bugfix
(In reply to comment #40) > does this problem persist in stable tree? > Yes, hence my comment. Just install a stage3, kde-meta, and x2goserver and try to connect to it.
3.5.0.14-r1 was my target for a new stable version, however bug #430096 (problems with newer cairo) delayed that. I plan a big stabilization request on x2goclient/server and nx 3.5.0.15 after the usual 30 days, but in the meantime I have nothing against a quick stabling round for nx-3.5.0.14-r1
I'll go ahead and test on both x86/amd64 then. I should know the results of a complete build in about 18 hours.
(In reply to comment #43) > I'll go ahead and test on both x86/amd64 then. I should know the results of > a complete build in about 18 hours. My EC2 x2goserver 32/64-bit images both work fine with this version of NX. I can stabilize on amd64 at least if you want to proceed.
Thanks for testing, let's go ahead on this in bug #436760.