Bug 452518
| Summary: | Incoming nx connections fail due to nx package shared library path problem | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Brian Morrison <bdm> |
| Component: | nx | Assignee: | Axel Thimm <Axel.Thimm> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 9 | CC: | gwync |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-07-02 18:27:09 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Brian Morrison
2008-06-23 14:41:30 UTC
All the libraries are invoked by setting LD_LIBRARY_PATH in a wrapper to the libexec bits. I'm not sure why it doesn't work for you, it probably means that you are invoking the libexec bits directly. The package used to publish its libraries to ldconfig, but it was considered a pollution of xorg space (as it did indeed share the same SONAMEs), so it had to be redesigned to leave ldconfig and rpm out. Well, I don't really see how I can invoke the libexec bits directly, I'm simply logging in externally with the Windows NX client. Oddly v3.1.0 of that didn't work either, but v3.2.0 does work fine. How would you suggest I debug this further? I have had one other problem with the system since updating to F9, maybe there is something wrong somewhere. Certainly with the default configuration of having installed the packages and left the /etc/nxserver directory keys alone it didn't work (whereas in F7 is did), I don't see how it can do other than what was intended. OK, just to make sure you're clear on what I'm doing. The remote machine (running Fedora 9) is acting as an NX server, I won't claim to be knowledgeable about NX in general. I can see that there is an additional library path set in /usr/libexec/nx/nxwrapper, but I don't see how this gets called when I connect with my NX client remotely. My logs have showed problems with /usr/libexec/nx/nxnode and with /usr/libexec/nx/nxagent, both complaining about the inability to find shared libraries such as liXcomp.so.3, so my changes made this work. How is nxwrapper involved in this process? I can see that it should be called and then pass execution to the correct script with the LD_LIBRARY_PATH set with /usr/lib/nx added to the path, but it seems this does not happen. Any assistance with changing the configuration to make it work how you intended would be appreciated. Further tests reveal that the problem appears to be due to a mismatch between the nx and freenx-server package archs, I had nx.i386 and freenx-server.x86_64 as this is what anaconda installed during my F7->F9 upgrade. The version of freenx-server is the one available in updates. Manually finding freenx-server.i386 (again from updates) and installing it in place of the x86_64 version (there is no nx.x86.64 in any of the repos) and manually undoing my changes to /usr/lib/nx and /etc/ld.so.conf.d/ has given me a working setup with the installation defaults. Might be worth finding out why the repos insist on presenting a broken combination of packages..... I'm making this a duplicate of bug #446816, but that doesn't address the issue with anaconda installing a wrong set of packages. If you'd like to see that addressed, please open a bug against anaconda with this info, thanks! As to the missing nx x86_64 build: The current workaround is to remove the x86_64 freenx-server build as well and have x86_64 use the i386 builds. See also bug #446816. *** This bug has been marked as a duplicate of 446816 *** |