I have an amd64 system (dual AMD Opteron(tm) Processor 250) with the offically unreleased debian/sarge/stable system of which I am very happy and proud to be using. Indeed, the problem I am about to describe is one of the very few problems I have, and in the bigger scheme of things quite small. Nevertheless, it is important to solve this problem if I am to use this machine the way I want to be using it.
I have also recently (within the last year) discovered the nomachine suite of server/client software. I started using this when they offered it for free; provided the number of clients remains at or below 2. This is very usable for me. These packages, which have been made available for debian machines, are extremely useful and, in my opinion, the best for remote access to the machine. This machine is a rack-mounted machine (pampered in an air-conditioned "clean" room) that only gets accessed at the front console on rare occasions. This debian/amd64/sarge/stable system has been set up to run 32-bit applications where necessary as per the instructions on the debian site for both local 64-bit entrant (using configured 32-bit libraries) and the chroot environment. 32-bit applications such as firefox work great in this manner. Indeed, the 32-bit nxclient application also works great except for one flaw I am about to describe. The 32-bit nx packages are installed by forcing dpkg to ignore architecture dependence. They also require 32-bit libstdc ++2.10-glibc2.2 libraries that are also configured into the system so that nxserver runs and nxclient can access the machine as expected. No problem here. The problem: On the remote machine, running the amd64 nxserver via the nxclient Whenever any attempt is made to get out of the active nxclient window (such as minimize, or change windows, or virtual screens), the client machine completely disconnects from the X server and stops all processes that are running within the X server on the client machine. The remote process can be resumed since it appears to the nxserver that the process has been suspended (not terminated), so it is not fatal, but VERY inconvenient. This does not happen on any of the 32-bit (non-amd64) nxservers I have; only this amd64 server. The actual error message that gets printed to the Xorg.0.log file at the time of the X disconnect is (EE) Error loading keymap /var/lib/xkb/server-0.xkm Backtrace: 0: /usr/X11R6/bin/X(xf86SigHandler+0x81) [0x80c3971] 1: [0xb7f40420] 2: /usr/X11R6/bin/X [0x815a32d] 3: /usr/X11R6/bin/X [0x8156a1f] 4: /usr/X11R6/bin/X(CompositeGlyphs+0x9a) [0x814409a] 5: /usr/X11R6/bin/X [0x814bbbc] 6: /usr/X11R6/bin/X [0x81470b5] 7: /usr/X11R6/bin/X(Dispatch+0x18f) [0x808693f] 8: /usr/X11R6/bin/X(main+0x485) [0x806e715] 9: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xdc) [0xb7d308cc] 10: /usr/X11R6/bin/X(FontFileCompleteXLFD+0xa1) [0x806da51] Fatal server error: Caught signal 11. Server aborting I would very-much like to fix this problem. Could anyone help on this or seen this before ? The remote machines running nxclient are also Debian/Stable/Sarge machines, and in one case, a Ubuntu/Edgy machine. -- James D. Freels, Ph.D. Oak Ridge National Laboratory [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
