Remote Login via XDMCP is not working

[Mahmoud Kassem]

Binary package hint: gdm

XDMCP is not working.
I have 2 Gusty desktops on the same network with no firewall settings, one has XDMCP enabled.
" When I try to connect to it, I see a "dead" X screen (with the X cursor in the middle) for a split second, then I'm return to my local login screen. "

http://ubuntuforums.org/showthread.php?p=3490207

** The GDM starts without problems while XDMCP is enabled ,but the XDMCP connection does not work as explained above.

Steps to Reproduce:
1. Enable Remote Login on PC1 running Ubuntu Gusty/7.10 from Administration > Login Window > Remote with Style same as Login
2. Reboot PC1 to complete enabling the Remote Login.
3. From another PC (PC2) running Ubuntu Gusty/7.10, use Options > Remote Login via XDMCP from the Login Screen
4. PC1 appears on the list, connect to it

Result:
I see a "dead" X screen (with the X cursor in the middle) for a split second, then I'm returned to my local login screen.
Or If I was using the switch user option, I'm returned to the lock screen window asking for my local login password.

[Sebastien Bacher (seb128)]

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

[K. Lange (k-lange)]

I'm not entirely sure they're the same bug. The problem here is when trying to login to a remote computer, GDM doesn't start. The bug you say this is a duplicate of is GDM not starting when XDMCP is enabled on the local computer, the exact opposite of this.

[Mahmoud Kassem (mmkassem)]

After reading bug #118193, I think they are not the same bug too. As KevinLange said, this bug occurs while GDM is already started.

[Mahmoud Kassem (mmkassem)]

Changing back to New since this bug is not the same as bug #118193

[K. Lange (k-lange)]

My remote server has the following in its syslog:
gdm_slave_xioerror_handler: Fatal X error

[K. Lange (k-lange)]

I think we have enough evidence to show that there is a bug. Switch to "confirmed"?

[Steve Jackson (aearenda)]

I have come across this too, I believe. However, setting the remote greeter to 'plain with facebrowser' instead of 'same as local' works around the issue.

[Steve Jackson (aearenda)]

Cannot replicate my workaround on a different remote system, same local system. May be a red herring.

[CassieMoondust (cassie-lx)]

XDMCP do not work for me too. Al works fine, but if I try to connect from another Machine (Cygwin,Xming, Feisty or Gutsy) the screen goes black and i see the gdm loginscreen again. In Feisty it works. In Gutsy don't. SSH etc. works fine.

[Nick McGill (nick-mcgill)]

I don't know whether this helps, but it seems to be a problem with the 7.10 remote login.
I set up 2 machines, 1 Feisty, and one Gutsy. The fiesty machine can login to Gutsy and Feisty systems, but the Gutsy machine cannot connect to any remote systems with XDMCP.

This happens with Ubuntu and Xubuntu (I haven't tested Kubuntu).

These machines are still 'vanilla', so if I ca be of any assistance, please let me know.

Nick

[CassieMoondust (cassie-lx)]

Yes, my gusty machine cannont connect to the feisty machine and from another machines with Feisty or Cygwin installed I can connect to them. But it works about two or three weeks ago during the beta test. After an update it loose it's funktionality and I do not know why.
Gutsy as a XDMCP- "server" do not work, but it can still be seen in the xdmcp chooser from any machine, but login does not work for me.

[Steve Jackson (aearenda)]

Force-downgrading gdm to the version as at gutsy beta (2.20.0-0ubuntu2) fixes the remote end for me - I can connect to it with other systems; but it does not fix the client end (I still can't use XDMCP to connect out from Gutsy).

[Marco A L Barbosa (malbarbo)]

Why importance is Low?

I have two computers in home, the old one connect to the new one with xdmcp.
I upgraded the two computers to gutsy and cannot use the old one anymore.

My systems was working, but now are not. This is bad.

[CassieMoondust (cassie-lx)]

Think this bug is higher than low. We want to connect several old machines based on win/cygwin and ubuntu to one server in an office environment. But with gutsy this does not work. I WIll try this downgrading thing. Hope this bug will be fixed soon for us, i think xdmcp is an essential feature of linux!

[Nick McGill (nick-mcgill)]

I agree that this is an important feature, so its status shpuld reflect that.

What is worrying is that the functionality has not been removed, but has been broken!

[Sebastien Bacher (seb128)]

What difference will a status change do? This bug should rather be sent upstream or worked by somebody getting the issue, there is ten of thousand of bugs and limited ressources working on those that's why it takes time to reply on bugs, not because the settings are not correct

[Stefano Angeleri (weltall)]

Same problem here. I can connect to whathever host i want with the feisty pc (even to the gutsy one), but there is no way to connect to whathever from the gutsy pc (i can't connect even to feisty and fedora). i still can see the hosts fine but trying to connect to the makes the nvidia logo shown and then gdm crashes entirely or just returns to the normal login window. i can use fine from the same computer other solutions like xnest.
The Steve's workaround worked for me to connect to the gutsy machine from the feisty one

[Grizzly (sven-witterstein)]

[Bug #148474] mentions an error message, so this bug is a dupe i should say.
However, I also have the problem. Whereas LinuxTSC works fine under XP, but kills the Applets and Keyboard Layout when connecting to an x64-Arch server
It is hateful to have this feature broken but it definitely is broken.

Could you please all look if you have this in /var/log/syslog:
Oct 3 11:02:10 Id2ndR-SFF gdmchooser[6424]: GLib-GObject-WARNING: /build/buildd/glib2.0-2.14.1/gobject/gsignal.c:1019: unable to lookup signal "activate" of unloaded type `GtkMenuItem'

[Grizzly (sven-witterstein)]

I researched why my applets broke when logging in with LinuxTSC. Big difference between local display on the machine and remeotely accessing is:
Local, "Visual effects" and "Wobbly Windows" are activated.
I found out that then you cannot name your desktops in the desktop chooser, only after disabling.
It might be worth trying to disable all visual effects on the machine locally, then trying to xdmcp to it.

[Steve Jackson (aearenda)]

I do have the messages in /var/log/syslog that Grizzly mentioned, on the local machine, if I use a local Gutsy to try to connect to remote Gutsy with XDMCP from the GDM login screen (it always works using Xnest on the local machine instead of GDM).

On reflection I believe this bug has been discussing two issues which are often encountered together, but which may be unrelated:
1. Gutsy's inability to be connected inwards to using XDMCP from GDM on other machines, regardless of the version on the connecting machine - this is worked-around by reverting gdm on Gutsy to 2.20.0-0ubuntu2.
2. Gutsy's inability to connect outwards using XDMCP from GDM to other machines, regardless of version of the other machine. This is not fixed by reverting gdm to 2.20.0-0ubuntu2.

One or both of these may be duplicated in Bug #148474 (BTW, how do I insert a link to that bug? It isn't obvious to me.)

I have no wobbly windows or other effects in use.

[Nick McGill (nick-mcgill)]

I also have Grizzly's error message.

I have no video effects enabled (video cardds are not upt to it!)

[CassieMoondust (cassie-lx)]

I don't know why, but scince yesterday it works on my home machine. I can connect from another machine (windowsxp with xming) to my gutsy gibbon. And locally wiht Xnest :1 -query 127.0.0.1 works to. In booth cases i had the ugly empty grey x-window with the x-cursor, now i see the login screen. At work it does not work, but i don't know why this is the case, booth machines have the same updates and the same settings...perhaps i have installed a package that brings me the funktionality for xdmcp?
I'm a little confused...

[Steve Jackson (aearenda)]

Xnest has always worked for me, both from other systems and from Gutsy systems - it is broken when connecting by selecting XDMCP from the GDM screen, rather than a nested session. It seems to me that during connection establishment, the remote Gutsy GDM now sends a response that the local GDM (no matter what version) cannot handle, but a local Xnest can (this is avoided by downgrading GDM as above). This is further confused by Gutsy as local GDM failing to connect to other remote systems that previous versions can connect to (which is not so avoided).

[Andrés Rassol (anra)]

I have the same problem trying to login from Feisty to Gutsy.

[Israel Benítez Esquivel (israelbz)]

I have the same problem, and partialy solved:

1. GDM greeter must be plain.

2. I need execute metacity from a command line because it don't start when the session starts.

I'been tried to find more data, but I couldn't find in any log.

[Id2ndR (id2ndr)]

I can confirm that it works using tsclient on localhost (that use Xnest). I just have a keyboard layout trouble but that not the trouble of this bug.

[Nick McGill (nick-mcgill)]

This seems to be a problem with gdm

I installed kdm on my gutsy machine and was then able to connect to a remote (feisty) machine running gdm.

I have not yet been able to test whether I can connect from to a guty machine using this setup.

[hd (hd-dyballa)]

I use 14 thin clients to login via XDMCP on feisty. Since the update yesterday 12 of them get an login screen and work, 2 not, also cygwin connect fails. The login screen starts , you can see just the cursor, and then restarts. Feisty was working very well with all clients ( even cygwin ).

[Chocwise (chocwise)]

I'm just here to confirm this bug. On the remote machine I've Dapper Server Edition installed. On the local machine Gutsy upgraded from Feisty. Since the Upgrade XDMCP doesn't work anymore.

Grizzly asked for that row out of the syslog. I have it as well after trying to connect via XDMCP:
chocwise@asgard:~$ cat /var/log/syslog | grep gobject/gsig
Oct 26 02:47:33 asgard gdmchooser[29214]: GLib-GObject-WARNING: /build/buildd/glib2.0-2.14.1/gobject/gsignal.c:1019: unable to lookup signal "activate" of unloaded type `GtkMenuItem'

Would be happy to see it fixed soon. I love that feature.

[Michał Straszak (mstraszak)]

From what I saw from strace output, one of gdm child-processes ends with SIGSEGV signal. I don't know exactly at which point (it was after sending GDM_LOCAL_GET_NEXT or something like this, I can't check now), I don't know how to use gdb with multiprocess applications, nor how to force gdm to generate corefile - can anyone give some hint here?
Anyway, I'll keep investigating.

[Jonas Eberle (jonas-eberle)]

I have the same bug. Gutsy (GDM) tries to XDMCP to Gutsy. See the relevant /var/log/syslog messages on the client side attached. The server side does not log anything to /var/log/syslog. Changing to "simple" ("einfach" in german) interface has no effect. BTW, I use the "fglrx" driver.
This is a bad thing, graphical remote login is an essential feature on Linux desktops. I would like to help out if I can do anything.

[Jonas Eberle (jonas-eberle)]

here comes the syslog when "debug output" is enabled. this time from the other machine, not running on "fglrx".
Please take this bug serious.

[K (kkumar)]

I too end up with this issue. but I can see a error message on my laptop screen when I tried to login from my laptop into desktop.

Quote:
There already appears to be an X server running on display :1. Should another display number tried? Answering no will cause GDM to attempt starting the server on :1 again. (You can change console by pressing Ctrl-Alt plus a function key, such as Ctrl-Atl-F7 to go to console 7. X servers usually run on consoles 7 and higher.

After pressing 'yes' there is a popup box saying ..

Quote:
The specified display number was busy, so this server was started on display :2.

after that it returned to normal local login screen where i can login to my laptop.

[CassieMoondust (cassie-lx)]

I have installed Gutsy 7.10 to our server and XDMCP ist NOT working. in /etc/gdm/gdmconfig-custom ist XDMCP enabled, but with Xnest :1 -query 127.0.0.1 i get only a gray checked window with the xcursor inside. On my home-machine it works! But if I compare the booth config-files there is no difference and installed are the same packages of gdmon booth machines! I am very confused. We need this functionality for our Terminalclients.

[Israel Benítez Esquivel (israelbz)]

¿the X server is accepting TCP conections?

Check the DisallowTCP parameter in section [security], it must be false:

DisallowTCP=false

El mié, 07-11-2007 a las 22:10 +0000, Papamatti escribió:
> I have installed Gutsy 7.10 to our server and XDMCP ist NOT working. in
> /etc/gdm/gdmconfig-custom ist XDMCP enabled, but with Xnest :1 -query
> 127.0.0.1 i get only a gray checked window with the xcursor inside. On
> my home-machine it works! But if I compare the booth config-files there
> is no difference and installed are the same packages of gdmon booth
> machines! I am very confused. We need this functionality for our
> Terminalclients.
>

[Id2ndR (id-2ndr)]

The trouble should be at client side. Server configuration is OK since
tsclient allow to connect to.

[hd (hd-dyballa)]

on my PC at home XDMCP with gdm is not working, XDMCP with kdm does, both with cygwon or Igel Thinclient.
At school we need gdm. With 12 Igelclients it is working, 2 can't login, first the gray window appears and then you
can see for a short moment the start of gdm, and this behavior repeats, also with cygwin. All Igelclients have the
same configuration. I need gdm working as soon as possible.

[robsyd (robsydemail)]

I don't understand why the importance of this bug is kept low.
The separation between the GUI and the kernel is one of the most important difference between Linux and Windows.
This bug is very serious, mainly In the education environment, where many clients often refers to one server.
I guess the education environment should be considered a strategical target by developers.

[Haulbag (tim-ideadynamics)]

I'm connecting to a Gutsy remote from a Debian Sid gdm client. It kept crashing, like everyone mentioned above, but I followed Steve's advice to "setting the remote greeter to 'plain with facebrowser' instead of 'same as local' " and followed Israel's advice to change DisallowTCP=false in the gdm.conf file, and everything works now. I tried just changing DisallowTCP=false, but that didn't solve anything. I don't know if it really did anything at all (I was too lazy to change it back), and it was probably Steve's solution that fixed it.

If this workaround fixes things for people, I would agree that this is a low priority. You can still have a background picture if you set it as the Logo file if you need a pretty login screen.

[Gustavo Rahal (gustavo-grahal)]

Yeah, really seems a problem on the client
from a gutsy machine to a gutsy machine
X :1 -query <hostname_of_gutsy_machine_running_gdm>

Works fine...

[Jonas Eberle (jonas-eberle)]

Yes, it is working like that!

I can leave all other options in gdm.conf untouched or change them, it is always the same:
Gutsy`s GDM will not connect to Gutsy.

But if I change to a console, I can start the XServer manually like Gustavo Rahal proposed and it ALWAYS works for me:
X :1 -query <hostname_of_gutsy_machine_running_gdm>

This bug seems to affect the graphical front-end only.

[robsyd (robsydemail)]

I'm testing
Server with Feisty (I haven't enought courage to update it)
Clients with Gutsy
The servers are settled with remote greeter to 'plain with facebrowser'.
The clients have 'DisallowTCP=false' in the gdm.conf.

from the console 'X :1 -query <hostname_of_gutsy_machine_running_gdm>' gives only a "dead" X screen (with the X cursor in the middle).

[K (kkumar)]

By the way, I have two machines installed with Gusyt, one is upgraded from
old version and another one is a fresh install.

When I go to 'Login Window' different machines has different gui. I guess
the one upgraded is carrying the old screen from old version. As explained
before I am not able to login from one machine to other using XDMCP. Using
XDMCP i cant even login into that local machine too.

'X :1 -query <hostname_of_gutsy_machine_running_gdm>'

When I use above command i get following error

bash: X:1: command not found

I guess I need to install to work that command.

On Nov 9, 2007 5:03 AM, robsyd <email address hidden> wrote:

> I'm testing
> Server with Feisty (I haven't enought courage to update it)
> Clients with Gutsy
> The servers are settled with remote greeter to 'plain with facebrowser'.
> The clients have 'DisallowTCP=false' in the gdm.conf.
>
> from the console 'X :1 -query <hostname_of_gutsy_machine_running_gdm>'
> gives only a "dead" X screen (with the X cursor in the middle).
>
> --
> Remote Login via XDMCP is not working in Ubuntu Gusty/7.10
> https://bugs.launchpad.net/bugs/150193
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[flynn (flynn)]

@Green_Star

I guess your command maybe wrong. It should exactly 'X :1 -query <hostname_of_gutsy_machine_running_gdm>'.
After the X command there is a blank space!

I can confirmed that this solution works for me too on two Gutsy installation from the commandline.

[K (kkumar)]

Thanks man, I corrected the command, now I am able to XDMCP-login into same
machine where I ran this command. I have to test logging into other
machines.

On Nov 9, 2007 6:02 AM, gnubuntu <email address hidden> wrote:

> @Green_Star
>
> I guess your command maybe wrong. It should exactly 'X :1 -query
> <hostname_of_gutsy_machine_running_gdm>'.
> After the X command there is a blank space!
>
> I can confirmed that this solution works for me too on two Gutsy
> installation from the commandline.
>
> --
> Remote Login via XDMCP is not working in Ubuntu Gusty/7.10
> https://bugs.launchpad.net/bugs/150193
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[MAGreen (m-a-green)]

Please, please, please raise the Importance!

[Nick McGill (nick-mcgill)]

Although I can connect using this method, I cannot disconnect, so the workaround is, at best, a kludge :(

[K (kkumar)]

Yes, same thing happened to me. Disconnect doesn't work? So I tried to go to
my original terminal by pressing Ctrl+Alt+F5 something like that. I tried
several F* keys to go to my original desktop because I do not know where my
desktop is running. After couple of tries I went to my screen and found that
command was killed with some errors (I thought of killing it by pressing
Ctrl+D but it was killed already).

On Nov 9, 2007 1:26 PM, Nick McGill <email address hidden> wrote:

> Although I can connect using this method, I cannot disconnect, so the
> workaround is, at best, a kludge :(
>
> --
> Remote Login via XDMCP is not working in Ubuntu Gusty/7.10
> https://bugs.launchpad.net/bugs/150193
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[CassieMoondust (cassie-lx)]

@Benítez Esquivel:
In my case "Xnest :1 -query 127.0.0.1" wasn't work locally on my machine, restarting gdm has changed nothing.
Then I do the (so i believe) most importend step, i use the command "sudo gdmflexiserver --command="UPDATE_CONFIG" and restart gdm via "sudo /etc/init.d/gdm restart" from the textconsole. After that, Xnest works ! But unfortunately it works only on my own machine locally.
Now I've tried DisallowTCP=false, because it was set true before - thanks to Benìtez Esquivel - after updating and restarting gdm i could see the gdm-login-screen from my xming-windowsxp client - BUT after logging in nothing happens - no desktop appears, only an empty brown window.
Thinking on my problems with XFCE and XDMCP on my old Feisty-Server i'd remember, that there was problems with the ESD-Enlightenment Sound Deamon, wich can transport Audio from the server to the client, but Cygwin/xming doesn't support this. On Windows there is no ESD at default. So I turn all Audiosettings to ALSA instead automatic.
Then i do the update-command and restarts gdm like obove - and voila - i can login and work with xming !

Very strange, so i think - something went totally wrong with this gdm-thing...why this doesn't work automatically? In my oppinion this is a bug in the init.d-script: it does not update the settings for gdm before gdm (re)starts.

Hope this helps someone :-)

[Nick McGill (nick-mcgill)]

If I move back to my original desktop (Ctrl+Alt+F7), then back to remote login, then the remote session has crashed with a graphics error (Screen 0 is not DRI capable) - I put that down to my crappy video card!

[Heitor Mauricio (nixrider)]

Doing some tests here:
Running Gutsy on client and Dapper in server
with this command:

X :1 -query <hostname_of_gutsy_machine_running_gdm>

I could login in server but couldn't logout. Had to come back to terminal (Gnome) and ctrl-C to finish the remote session.
This gave me some keyboard err.
Then I got to the User Switcher, at Preferences, and checked the box that says -->> Create new logins in nested windows.
After an User Switcher err, a Xnest session started and I could login into the server... and logout too.
The changes in gdm.conf-custom didn't take any effect. Neither changing the theme for remote sessions nor allowing TCP.
Well, that's it for now

[CassieMoondust (cassie-lx)]

@Heitor Mauricio: Confirm this, the same happens here.

[Andriy Gerasika (andriy-gerasika)]

+1. I have the same problems.
Switching to KDM helps, but not 100%: even then XDMCP is not working as smoothly as it was in Edgy.

[Andriy Gerasika (andriy-gerasika)]

sorry, Feisty. XDMCP was working excellent in Feisty Fawn. Now, in Gutsy Gibbon it is not...

[CassieMoondust (cassie-lx)]

Have changed to KDM at work, can now connect with xming but not with cygwin !!! If I end the xming session it crashes, this never happens on feisty before.
Something went totally wrong with xdmcp in gutsy, and i think taking every newest deb from lenny is really not always a good idea, i feel like a alpha-tester...
Has someone test older versions of the gdm packet? In the gutsy repos are no older debs after the release anymore. :-(
Nomachine NX works great but only for 2 users, (or a working freenx with a free client).
We need xdmcp functionality at work for our very old clients (P2 - 350MHz etc). If xdmcp is politically not wanted please give us an alternative or an implementation/replacement for xdmcp (for example freenx integrated in gdm with secure over a ssh-connection)...BUT we need an remote desktop!
Please let us know what we have to do, that we can get xdmcp to work...

[CassieMoondust (cassie-lx)]

add: Most of the clients have win2000 installed, xming doesn't work anymore with it.

[Andriy Gerasika (andriy-gerasika)]

I have tried using VNC, but it is so terribly slow, that is almost not usable.

[Israel Benítez Esquivel (israelbz)]

@Papamatti

I'm using gdm on plain mode, is working well with our ltsp-4.2 clients,
so I'm not testing anything else, but I have some ideas:

Have you test with xdm or wdm?

The ubuntu ltsp project use ldm for remote login over ssh
(https://help.ubuntu.com/community/UbuntuLTSP/Tour)

El mar, 13-11-2007 a las 18:35 +0000, Papamatti escribió:
> Have changed to KDM at work, can now connect with xming but not with cygwin !!! If I end the xming session it crashes, this never happens on feisty before.
> Something went totally wrong with xdmcp in gutsy, and i think taking every newest deb from lenny is really not always a good idea, i feel like a alpha-tester...
> Has someone test older versions of the gdm packet? In the gutsy repos are no older debs after the release anymore. :-(
> Nomachine NX works great but only for 2 users, (or a working freenx with a free client).
> We need xdmcp functionality at work for our very old clients (P2 - 350MHz etc). If xdmcp is politically not wanted please give us an alternative or an implementation/replacement for xdmcp (for example freenx integrated in gdm with secure over a ssh-connection)...BUT we need an remote desktop!
> Please let us know what we have to do, that we can get xdmcp to work...
>

[Sebastien Bacher (seb128)]

There is http://bugzilla.gnome.org/show_bug.cgi?id=495623 about a similar issue upstream with a patch to try

[Brooxta (brooxta)]

The current upstream patch does not fix this issue. See the Gnome Bugzilla link for more details.

[J Armando WP Jeronymo (jose-armando)]

I have one 400MHz PC with 7.10 and a 2600MHz with 7.06. I try to XDMCP from 400MHz to 2600MHz with the results described by the other contributors above.

When trying a method described in one of the Ubuntu forum comments on this problem, I noticed that the XDMCP login box "connect" control shows a mouse-over message like "open session on the last selected machine". I am not sure of the English phrase because the 400MHz computer language was updated to Gusty in Brazilian Portuguese and despite having changed the current language to English (US) no matter what I do I cannot change the welcome screen not the XDMCP login box to English (the 2600MHz language is French). The PT-BR phrase is "abrir uma seção na última máquina selecionada".

I have no skills to investigate this further and so am adding this here is case it can be of help to someone.

[brunus (reg-paolobrunello)]

Hi,
while waiting for this bug to be fixed, I've found this workaround, that needs openssh server and xnest to be installed on the remote machine: http://www.macosxhints.com/article.php?story=20041117115414383
Not that user friendly, for sure, but it works, even from gutsy to gutsy...

I hope it helps.

brunus

[J Armando WP Jeronymo (jose-armando)]

Ciao Bruno,

I have a fast box (A) with Dapper and a slow one (B) with Gusty which since the upgrade no longer can XDMCP to (A). I've checked the hint you mentioned and actually managed to login into (A) from (B) but when I try to start the empty nested window the server returns:

Fatal server error:
Unable to open display "".

I tried this from (A) to (A) as well the behavior was the same.

echo $DISPLAY returns :0.0 and when I tried to use it instead of :1 the server returned :-

Fatal server error:
Server is already active for display 0
        If this server is no longer running, remove /tmp/.X0-lock
        and start again.

Any ideas?

Grazie

Jose Armando

[wormkid (wormkidblue)]

In my case I can login to remote at first time.

After logout, I can see login screen and login, but I can only see just orange screen.
Gnome doesn't start.

Both updated latest Gutsy.

It just works fine at first login. but next, nothing I can do but login.

Wish it solved soon.

[brunus (reg-paolobrunello)]

Hi Jose Armando,
make sure both machine have xnest (and openssh server) installed, and that you activated the XDMCP distant login on both. Make sure that the -geometry option is small enough to fit into your remote machine resolution (so, try 800x600). I also have a Dapper and a Gutsy and I managed to connect this way in both ways (A to B and B to A).
Display :0 is the default display, used by the user logged locally on the target machine. You may try to connect to display :1, :2 or :3 whenever you get a /tmp/.Xn-lock error which simply means that display is already in use. In fact, when you log out abruptly, the machine doesn't automatically free up the display you were using.

Answering to wormkid, I tried and successfully logout and login again no problem, so I don't know whay you're having this problem. You may try to close the Xnest window instead and reconnect using a different display, say :3 instead of :1.
When you have used the 3 extra displays, you have to reboot the target machine in order for the /tmp to be cleaned up and have the 3 displays available again.

brunus

[J Armando WP Jeronymo (jose-armando)]

Hi again brunus,

From Gnome Login Screen setup window I made sure XDMCP is enabled on both machines, restarted both, logged from B into A as I earlier described but the server still replies that it is unable to open display "".

Is there a different method to enable XDMCP I might try? Why the system returns what seems to be an empty string as the display number?

Thanks again

Jose

[K (kkumar)]

Is that mean everything fixed? did Ubuntu pushed that fix? Still I am not
able to use XDMCP!

On Dec 4, 2007 2:53 AM, Bug Watch Updater <email address hidden>
wrote:

> ** Changed in: gdm
> Status: Unknown => Fix Released
>
> --
> Remote Login via XDMCP is not working in Ubuntu Gusty/7.10
> https://bugs.launchpad.net/bugs/150193
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Sebastien Bacher (seb128)]

the ubuntu task will be closed when the bug is fixed in ubuntu, that's not the case yet, is there anybody getting the issue wanting to try the patch suggested and comment on whether it's working correctly?

[J Armando WP Jeronymo (jose-armando)]

I'd be more than glad to try the patch provided someone tells me how or points me to the appropriate howto. Bugs are great opportunities to learn new things!

[caktux (caktux)]

I can also confirm this bug using a Gutsy 7.10 server and Gutsy 7.10 client.

[caktux (caktux)]

I replaced gdm with kdm on the server side but now I get:
Could not init font path element /usr/share/fonts/X11/cyrillic, removing from list!
FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be 1; fixing.
when trying to connect. I do get to see the kdm login screen for a fraction of a second.

[J Armando WP Jeronymo (jose-armando)]

In case someone can spare the time to point me to the right direction I'm still available to try the patch. :-)

[Obleak (fraser-arkhostings)]

same behavior here too.
client -> server
gutsy -> edgy (fails)
gutsy -> feisty (fails)
gutsy -> gusty (fails)

I can work around the problem by using kdm instead

Jose, I think this is the patch Sebastien is referring to: http://bugzilla.gnome.org/show_bug.cgi?id=495623#c19

[J Armando WP Jeronymo (jose-armando)]

Thanks Obleak!

I had already seen the patch at gnome Bugzilla but I simply do not know what to do with it! I do not know whether all I have to do is to copy/paste it on a file (which file) or if I have to compile my gnome and reinstall gdm or what.

I have some time and a lot of interest to test the patch but really need someone to start me in the right direction. :-)

[brunus (reg-paolobrunello)]

Hi Jose,
I'm quite a linux newbie myself, but applying a patch seems to be an easy task, according to what I've read on the wikipedia under patch (http://en.wikipedia.org/wiki/Patch_%28Unix%29). On ubuntu, you have to install the package patch first, in order to apply the patch via command line.
I'm also longing to try the patch, but so far I'm too busy with other stuff, so I root for you Jose! :-)
good luck,

brunus

[J Armando WP Jeronymo (jose-armando)]

Hi brunus,

Package "patch" seems to be in the default installation and I read its manual and then tried this:

1. Opened the patch text file at http://bugzilla.gnome.org/attachment.cgi?id=99743&action=view, pasted it into a file in my system and named the file "patch".

2. Run patch: $ patch -i /home/user/Desktop/patch --verbose

The package finds the input file but returns "cannot find the file to patch at input line 3". Line 3 seems to be

|+++ gdm/common/gdm-common.h

but I cannot find neither a path "gdm/common" nor a file "gdm-common.h".

I will research further on how to use "patch" in ubuntu but meanwhile any clues anyone?

Tks/Jose Armando

[Kip Warner (kip)]

Greetings Gentlemen. What you want to do is get the source (apt-get source gdm), then apply the patch, and then rebuild the package. I don't remember the exact commands off hand for the latter two. You then install the package. The thing to take away from all of this is that patches are almost always applied to source code.

Kip

[J Armando WP Jeronymo (jose-armando)]

Hi Kip and brunus, thanks.

I managed to go as far as downloading the source and applying the patch however when I am having troubles rebuilding the package. I gave it up for today but will try again tomorrow.

Thanks again for yr guidance.

[Id2ndR (id-2ndr)]

> I managed to go as far as downloading the source and applying the patch
> however when I am having troubles rebuilding the package. I gave it up
> for today but will try again tomorrow.
>
> Thanks again for yr guidance.

There are explanation in bug #173890. I put these bellow (the package
should be updated) :

Instead of adding the -d option to dpkg-buildpackage you can do the
following command before anything else (this installs the required
dependencies).

sudo apt-get build-dep flashplugin-nonfree

That downloads and installs all of the dependencies for the flash plugin
(including development dependencies).

So the corrected instructions would be:

sudo apt-get build-dep flashplugin-nonfree
wget http://launchpadlibrarian.net/10756602/flashplugin-nonfree_9.0.115.0ubuntu2.tar.gz
tar -zxvf flashplugin-nonfree_9.0.115.0ubuntu2.tar.gz
cd flashplugin-nonfree-9.0.115.0ubuntu2
dpkg-buildpackage -b -rfakeroot

[J Armando WP Jeronymo (jose-armando)]

Id2ndR,

I cannot see the point here! Haven't you got the wrong thread by mistake?

[Kip Warner (kip)]

I think he has the wrong thread too. Here is what you want to do. Let us assume the patch gdm-2.20.1-svnfixes.patch has been downloaded into the current directory.

apt-get source gdm (this gets the source code to gdm and unpacks in current dir)
sudo apt-get build-dep gdm (this gets anything else needed to compile the above package)
cd gdm-2.20.0
patch -p1 < ../gdm-2.20.1-svnfixes.patch
dpkg-buildpackage -rfakeroot -uc -b
cd ../

You should now have the newly compiled gdm package in the directory where you started. Install as you normally would. Note that the patch is for 2.20.1, but the source in the repo appears to be for 2.20.0. The patch applies without worry, but I have not tested xdmcp since I don't have another machine available to connect to right now.

Kip

[J Armando WP Jeronymo (jose-armando)]

I can see the end of the tunnel now :-)

Well, almost midnight here. Had better trying it tomorrow.

Thanks again Kip. Will post results ASAP.

[Kip Warner (kip)]

No problem. The code is not just open, but the knowledge of it too.

Kip

[Id2ndR (id2ndr)]

Jose,

No I haven't made a mistake. I put an other example. Here we want to do the same thing except that we also need to patch the source.
To resume :
- get the source : apt-get source (instead of wget)
- build environment for compilation : apt-get build-dep
- patch the source (this wasn't done for the other package)
- build package : dpkg-buildpackage -b -rfakeroot (I just don't know what is "-uc" switch that Kip used)

[J Armando WP Jeronymo (jose-armando)]

Hi Id2ndR

So sorry! You were only too kind to help and I was quite rude.

Thanks for your inputs and example. I will be more careful next time.

Jose Armando

[J Armando WP Jeronymo (jose-armando)]

Hello all,

at first dpkg-buildpackage would return an error but upon inspecting messages I concluded that it was possible a permission problem and gave up -rfakeroot and run it with sudo:

$ sudo dpkg-buildpackage -b -uc

It took almost half-an-hour in my old 400MHz AMD but at the end I had my deb package. I used gdebi which advised that the package was the same version as the most current one and offered to reinstall it. I accepted and it was reinstalled.

After installation the upgrade available icon appeared and the in upgrade manager offered to update the same package which I decided not to.

After restarting the computer I tried to make the xdmcp connection and it worked :-). However, the desktop was set to a 1400 x 1050 instead of my usual 1024 x 768. In fact, only when I accidentally brought the pointer to the top edge and noticed the backgrounf scrolling down I realized what was going on. I then scrolled the program bar into view and corrected the resolution.

In all, it seems to be working fine. I'm uploading the package to one of my websites so all can have it: exportdriver.com/gdm-patched.tar.gz.

Thanks to all that helped me with this. It was a great learning experience and I come out with the feeling I did something useful for the community.

[J Armando WP Jeronymo (jose-armando)]

P.S. - No point in tar.gzing the package. You may find it at http://exportdriver.com/gdm_2.20.1-0ubuntu1_i386.deb

[Alfonso Eusebio (alfonso-eusebio)]

Hi,

Just to confirm that the patch fixed it for me too.
XDMCP from Gutsy to Gutsy.

It even works with Compiz (on the target computer)!

Cheers,

[Kip Warner (kip)]

I think you want to bump the package release number so that our package manager's stop prompting us for upgrade after we install the patched build.

Kip

[J Armando WP Jeronymo (jose-armando)]

Yes! But how to?

[asis (supporto-asis)]

here is the deb for 64 platform:
http://www.asis.it/gdm_2.20.1-0ubuntu1_amd64.deb

please keep in mind that to connect from gutsy to gutsy you need to Ctrl-Alt-F1 and 'sudo X :1 -query xxx.xxx.xxx.xxx' on client side.
To connect from feisty (maybe edgy too?) to gutsy you need to switch to simple style for remote access too on server (gutsy) side.

All in all I think the problem is partially solved...
Valerio

[J Armando WP Jeronymo (jose-armando)]

I just created and successfully applied a new package with version number bumped up to 0ubuntu2. It can be found at http://exportdriver.com/gdm_2.20.1-0ubuntu2_i386.deb.

I also posted a small explanation on how to bump the version number here: http://ubuntuforums.org/showthread.php?p=4003604#post4003604.

[Sebastien Bacher (seb128)]

The issue should be fixed in hardy now

[Sebastien Bacher (seb128)]

I've uploaded a patched version to gutsy-proposed now

[Sebastien Bacher (seb128)]

The corresponding SVN commit is http://svn.gnome.org/viewvc/gdm?view=revision&revision=5498

[Martin Pitt (pitti)]

Accepted into gutsy-proposed, please test.

[asis (supporto-asis)]

Sebastien patch works on the following:

Edgy or Feisty to Gutsy (but simple style must be set on Gutsy)
Gusty to Gutsy,Feisty,Edgy (but you must Ctrl-Alt-F1 and 'sudo X :1 -query xxx.xxx.xxx.xxx' on the client)

It does not work if style is set "as local" and one must 'sudo X ...' on gutsy.
I think the final patch should try to solve those issues too.

[Sebastien Bacher (seb128)]

what do you call simple style? could you describe easy steps to trigger the issue using the updated version?

[asis (supporto-asis)]

Sorry for my bad english.

1. My server is Gutsy, my client is Feisty.
Let's enable xdmcp on gutsy: System -> Administration-> Login Window -> Remote, now you can choose between "Same as Local" (in my tests it never has worked. Ie: blank screen and back to local machine) and "Plain with face browser" (here what i wrongly named "simple style").
Feisty connects to Gutsy ONLY if i set "Plain with face browser".

2. My server is Gutsy, my client is Gutsy.
On client side I must Ctrl-Alt-F1 and type "sudo X :1 -query xxx.xxx.xxx.xxx" where xxx.xxx.xxx.xxx is the server ip address. System -> Administration-> Login Window ->Remote can be set "Same as Local". Trying to connect on login screen (Options-> Remote Login via XDMCP) does not work. IE: blank screen and back to local.

Final note:
All my tests are done setting in my /etc/gdm/gdm.conf

[xdmcp]
Enable=true

otherwise my server is not listed on welcome login screen clicking on Options-> Remote Login via XDMCP.

[Richard Seguin (sectech)]

Still broken is Hardy Alpha-3

[[e-mail] (jerome-libel)]

Hello,

I have 3 serveurs gutsy
XDMCP is enable on them

Connecting wtih x-win32 from a windows client works perfectly, conecting from a debian sarge login windwo works too.
Conecting from login window of a gutsy client fails, I get mys severs list but when choosing one, it came back to local login window.

[J Armando WP Jeronymo (jose-armando)]

Jerome,

have you tried this patch: http://exportdriver.com/gdm_2.20.1-0ubuntu2_i386.deb ?

Bonne chance!

[Sebastien Bacher (seb128)]

Why do you recommend using this version? Did you try the gutsy stable update?

[Hendy Irawan (ceefour)]

Sebastian:

What "gutsy stable update"?

I have all repositories enabled (including backports, updates) and my gdm still can't be used to connect XDMCP.

Both clients and server are Gutsy. Using plain face browser.

If you mean your patch, can you tell me how to apply your patch, thank you.

[Sebastien Bacher (seb128)]

What version of gdm do you use?

[Hendy Irawan (ceefour)]

Sebastien:

$ gdm --version
GDM 2.20.1

"sudo X :1 -query xx" works, but unfortunately it's a very rough workaround.

[Sebastien Bacher (seb128)]

could you rather use dpkg -l gdm, your command doesn't list the revision

[Hendy Irawan (ceefour)]

Sebastien:

Seems to be: 2.20.1-0ubuntu1

$ dpkg -l gdm
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii gdm 2.20.1-0ubuntu GNOME Display Manager

$ aptitude show gdm
Package: gdm
New: yes
State: installed
Automatically installed: no
Version: 2.20.1-0ubuntu1
Priority: optional
Section: gnome
Maintainer: Ubuntu Desktop Team <email address hidden>
Uncompressed Size: 15.8M
Depends: libart-2.0-2 (>= 2.3.18), libatk1.0-0 (>= 1.13.2), libattr1 (>=
         2.4.4-1), libc6 (>= 2.6-1), libcairo2 (>= 1.4.0), libdbus-1-3 (>=
         1.1.1), libdbus-glib-1-2 (>= 0.74), libdmx1, libfontconfig1 (>= 2.4.0),
         libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.14.0), libgnomecanvas2-0
         (>= 2.11.1), libgtk2.0-0 (>= 2.12.0), libpam0g (>= 0.99.7.1),
         libpango1.0-0 (>= 1.18.3), librsvg2-2 (>= 2.18.1), libselinux1 (>=
         2.0.15), libwrap0, libx11-6, libxau6, libxcomposite1 (>= 1:0.3-1),
         libxcursor1 (> 1.1.2), libxdamage1 (>= 1:1.1), libxdmcp6, libxext6,
         libxfixes3 (>= 1:4.0.1), libxi6, libxinerama1, libxml2 (>= 2.6.29),
         libxrandr2 (>= 2:1.2.0), libxrender1, debconf (>= 0.5) | debconf-2.0,
         adduser, libpam-modules (>= 0.72-1), libpam-runtime (>= 0.76-13.1),
         gnome-session | xterm | x-window-manager | x-terminal-emulator,
         xbase-clients, alsa-utils, gksu (>= 1.0.7), lsb-base (>= 3.0-10),
         librsvg2-common, kbd | console-tools
Recommends: whiptail | dialog, zenity, gdm-themes, xserver-xephyr | xnest,
            ubuntu-artwork | edubuntu-artwork | xubuntu-default-settings,
            ubuntu-sounds, libpam-gnome-keyring
Suggests: locales, hibernate
Breaks: gnome-session (<= 2.17.91-0ubuntu1), gnome-screensaver (<=
        2.17.7-0ubuntu2), fast-user-switch-applet (<= 2.17.3-0ubuntu1),
        powermanagement-interface (<= 0.3.11)
Provides: x-display-manager
Description: GNOME Display Manager
 gdm provides the equivalent of a "login:" prompt for X displays- it pops up a
 login window and starts an X session.

 It provides all the functionality of xdm, including XDMCP support for managing
 remote displays.

 The greeting window is written using the GNOME libraries and hence looks like a
 GNOME application- even to the extent of supporting themes! By default, the
 greeter is run as an unprivileged user for security.

PS: I apologize for addressing you before as "Sebastian".

[Sebastien Bacher (seb128)]

you don't have the gutsy-proposed version which has the patch, could you try with this one? Don't worry about the name mispelling, that's a common one ;-)

[Hendy Irawan (ceefour)]

Now using this version on both client and server (both Gutsy):

$ aptitude show gdm
Package: gdm
New: yes
State: unpacked
Automatically installed: no
Version: 2.20.1-0ubuntu2
Priority: optional
Section: gnome
Maintainer: Ubuntu Desktop Team <email address hidden>
Uncompressed Size: 15.8M
Depends: libart-2.0-2 (>= 2.3.18), libatk1.0-0 (>= 1.13.2), libattr1 (>=
         2.4.4-1), libc6 (>= 2.6-1), libcairo2 (>= 1.4.0), libdbus-1-3 (>=
         1.1.1), libdbus-glib-1-2 (>= 0.74), libdmx1, libfontconfig1 (>= 2.4.0),
         libglade2-0 (>= 1:2.6.1), libglib2.0-0 (>= 2.14.0), libgnomecanvas2-0
         (>= 2.11.1), libgtk2.0-0 (>= 2.12.0), libpam0g (>= 0.99.7.1),
         libpango1.0-0 (>= 1.18.3), librsvg2-2 (>= 2.18.1), libselinux1 (>=
         2.0.15), libwrap0, libx11-6, libxau6, libxcomposite1 (>= 1:0.3-1),
         libxcursor1 (> 1.1.2), libxdamage1 (>= 1:1.1), libxdmcp6, libxext6,
         libxfixes3 (>= 1:4.0.1), libxi6, libxinerama1, libxml2 (>= 2.6.29),
         libxrandr2 (>= 2:1.2.0), libxrender1, debconf (>= 0.5) | debconf-2.0,
         adduser, libpam-modules (>= 0.72-1), libpam-runtime (>= 0.76-13.1),
         gnome-session | xterm | x-window-manager | x-terminal-emulator,
         xbase-clients, alsa-utils, gksu (>= 1.0.7), lsb-base (>= 3.0-10),
         librsvg2-common, kbd | console-tools
Recommends: whiptail | dialog, zenity, gdm-themes, xserver-xephyr | xnest,
            ubuntu-artwork | edubuntu-artwork | xubuntu-default-settings,
            ubuntu-sounds, libpam-gnome-keyring
Suggests: locales, hibernate
Breaks: gnome-session (<= 2.17.91-0ubuntu1), gnome-screensaver (<=
        2.17.7-0ubuntu2), fast-user-switch-applet (<= 2.17.3-0ubuntu1),
        powermanagement-interface (<= 0.3.11)
Provides: x-display-manager
Description: GNOME Display Manager
 gdm provides the equivalent of a "login:" prompt for X displays- it pops up a
 login window and starts an X session.

 It provides all the functionality of xdm, including XDMCP support for managing
 remote displays.

 The greeting window is written using the GNOME libraries and hence looks like a
 GNOME application- even to the extent of supporting themes! By default, the
 greeter is run as an unprivileged user for security.

---
Nothing is improved, same issue. Using plain face browser for remote logins, doesn't work.

sudo X :1 thingy works, but it's a workaround not a fix.

[Alexandre Racine (alexandreracine)]

Hendy, try the simple mode.

More details: On your remote machine, go in system - admin - connection Window (this is a translation, I don't know the correct terms in English), choose remote and then you have 3 choices. Deactivated, identical to local connection, or simple. Use the simple one.

[Alexandre Racine (alexandreracine)]

Follow up. The weird part.

So I reinstalled my old machine with gutsy (7.10) and I could connect from my new machine gutsy with terminal server and xnest in XDMCP mode.. I put the old machine in a closet ;) and connect to it and it work, do some things and poof. It's gone. Can't connect to it anymore with XDMCP. It does work with ssh -X -Y and I can run some graphical apps with this.

So I search the web, try those two patch (32bit and 64bit) and try it again. Does not work again. I switch to the simple mode type on the remote machine and it works. Just like that.

Can some confirm that this is actually happening? Simple mode works and "same has local" does not work? Should I open a new bug report or this is the same? Thanks

[Harry Sufehmi (harry-sufehmi)]

Just to confirm that setting remote login to plain in gdm made LTSP 4.x works in Gutsy.

Also this issue needs to be given a higher priority.
A case study : I have had cases where LTSP5 doesn't work because the workstations are of lower spec. LTSP 4.x works just fine in these cases.

But with this problem, I can't deploy Gutsy as its server (nor Hardy it seems for now)
I can workaround it, indeed, but this has been confirmed to work only on plain Gutsy installation (eg: no updates installed yet). I don't know yet whether it will continue to work after you updated it.

Another thing, it seems that gdm 2.20.2 will bring this issue back.
RedHat has managed to fix it on their gdm 2.20.1 package, but the problem returned when they released gdm 2.20.2
Please be careful not to repeat their mistake.
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=379511

Thanks for the discussions so far, keep it coming guys.

Thank you.

[Richard Seguin (sectech)]

Confirmed as working on hardy beta PROVIDING you manually make the change in gdm.conf

[Meethoss (steve-thepicketts)]

I installed the patch on my server to update GDM (http://exportdriver.com/gdm_2.20.1-0ubuntu2_i386.deb) after having already enabled XDMCP and the Remote Greeter. I then installed xnest on both server and client and rebooted both machines. I can connect using sudo X :1 -query xxx.xxx.xxx.xxx but still cannot connect from the login screen. I'm not sure if I've missed something but I hope the fact of installing xnest on both machines helps someone else get this far as I've not seen that mentioned yet (I couldn't get anything working with xnest being installed first).

Also out of interest, when I run dpkg -l gdm after installing the patch it gives me the following:

steve@linux:/var/www$ dpkg -l gdm
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii gdm 2.20.1-0ubuntu GNOME Display Manager

[Jurgis Pralgauskis (jurgis-pralgauskis)]

just in case: connecting to gutsy from hardy beta works

[Martin Pitt (pitti)]

So apparently the version in gutsy-proposed (-0ubuntu2) does not fix this bug completely, but according to Sebastien it should fix it partly.

How many people are running this version? Does it cause any apparent regressions or other problems?

[markusd112 (markusd112)]

I have updated to Ubuntu 8.04 in the hope, that this problem is fixed in the new release, but the problem still exists: I cannot connect to another machine in my local LAN, both now running ubuntu 8.04. I will get only a black screen and it doesn't work. The discussions about the bug are a little bit confusing. Has the reason for the bug been found? Changing the session manager to KDM is not really helpful, because some essential functions of the ubuntu gnome desktop doesn't work with kdm (e.g. switching the user).
When will the bug be fixed? Thanks a lot.

[Martin Pitt (pitti)]

Reopening. Neither the gutsy SRU nor the hardy version seem to fix this.

[Martin Pitt (pitti)]

I removed the gutsy-proposed version again, since there was unclear feedback, and the problem is not solved yet in intrepid and hardy.

[Fabrix (spedisci)]

Very very bad thing!
No connection to remote XDMCP from Ubuntu 8.04 and praevious 7.10.
It's a long time bug and none fix it!
I must switch to another distro! Sigh Sigh, bye bye Ubuntu!

[Sebastien Bacher (seb128)]

you should rather switch to an another os since the bug is a GNOME one and not an ubuntu one and other distribution will likely the a similar issue

[Jurgis Pralgauskis (jurgis-pralgauskis)]

for me it works connecting from Hardy to Gusty (still, haven't tried Hardy to Hardy)

[Hendy Irawan (ceefour)]

The strange thing is that LTSP is working fine....

And LTSP uses XDMCP, GDM, and other technologies... which is more complex setup than just XDMCP

[J Armando WP Jeronymo (jose-armando)]

Then, couldn't it be that this bug is never solved because gnome or ubunto or whoever is involved would have us rather use LTSP instead of XDMCP? I had never heard of LTSP but liked what I read in Wikipedia and will give it a try.

By the way, with the patch mentioned above I can login from Gutsy to Gutsy.

[Hendy Irawan (ceefour)]

LTSP is not a replacement for XDMCP.

Rather, XDMCP (I guess) is needed as part of LTSP.

XDMCP plays a much smaller role (i.e. only the X/graphics part) than LTSP (which covers everything from routing sound to USB devices).

So it surprises me that XDMCP can't work while I can use LTSP without problems (Gutsy-Gutsy and Hardy-Hardy). If this is indeed a GNOME bug that is distro-independent, why LTSP+GNOME is working?

[Andrés Rassol (anra)]

LTSP doesn't use GDM, it uses LDM.

[Steve Jackson (aearenda)]

Just to clear up any confusion and speculation, LTSP in Ubuntu uses LDM for the terminal sessions by default, but earlier versions used to use GDM via XDMCP from the terminals and it can still be configured do so. This suits slower, older terminals. LTSP addresses a different need to XDMCP and both should work and be supported by Ubuntu.

Terminals use a tailored version of the operating system and do not run GDM locally - this is why they work when others do not.

[Georg Graf (georg-graf)]

Hardy LTSP doesn't work with XDMCP! I have set this in my lts.conf:
SCREEN_07 = startx
Result: No GDM-Login appears on the terminals!
The settings in /etc/gdm/gdm.conf-custom where checked and ok, ufw is disabled.
Only a X - Pointer appears in the middle of the screen.

with SCREEN_07 = ldm : It works fine, but have an evolution problem with the login keyring on the terminals.

[Fabrix (spedisci)]

I changed distro (centos 5.1) not OS and here it works fine! Try yourself.

2008/5/27 Sebastien Bacher <email address hidden>:

> you should rather switch to an another os since the bug is a GNOME one
> and not an ubuntu one and other distribution will likely the a similar
> issue
>
> --
> Remote Login via XDMCP is not working
> https://bugs.launchpad.net/bugs/150193
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Martin Pitt (pitti)]

Unsubscribing ubuntu-sru. Please resubscribe once this is fixed in the development release, and a patch exists for the SRU process.

[Mehul J. Rajput (mehulrajput)]

I have this problem in hardy too. Is there a work around for this bug?

[adamis (adamis)]

I've had this problem in Hardy as well as in the Alpha of Intrepid Ibex. Whenever I try to connect to my file server I have no problems seeing the file server using the remote login manager and clicking on it starts the connection however I never get a login window to login into the file server machine, I just get the Grey background with the "X" as a cursor.

I've looked at everything from firewalls, IVP6, I've even switched between kdm and gdm on the file sever to see if that was the issue. I've also walked through the guides several times to make sure that I had everything enabled correctly.

I've had XDMCP working before but it was a very long time ago. Both machines started out as Fiesty Fawn machines and I've upgraded them both to Hardy Heron and now to Intrepid Ibex.

[n3ko (n3ko74)]

I had the same problem tonight. I googled, and found nothin'. It seemed the problem serious. Tried to stace gdm and see, the connection start...

To be short: installed bind, and ... magic ... gdm works.
Googled some for find a way, to turn of authoritative reverse name lookups... found nothin' :(

[n3ko (n3ko74)]

sorry i forgot:
it was an up to date Hardy as server the clients:
 - another hardy with X -query and Xnest: both ok now.
 - debian 4.0 with X -query and Xvnc4: both ok now.
 - some Wyse thin client with a linux (unknown version) they are not working yet.

the wyse clients not work with kdm eighter. They can connect and login to xdm, but there is problem with keyboard configuration. (cant change us->hu)
the same clients with an older gdm on the debian works fine. (can connect, login, the keyboard is ok).

it's realy a new bug?

[GercoKees (gercokees)]

Is this still a bug in intrepid?

[n3ko (n3ko74)]

Which one?
1) The `Gdm isn't workin, when reverse dns lookup fails'
2) Or the `Old X terminals can't connect to new gdm'

[bford16 (bford16)]

This is still a problem in intrepid. I see the exact behavior described above. "gdmchooser[10437]: GLib-GObject-WARNING:."
Kernel is 2.6.27-7-generic (AMD64)

Originally I was able to use XDMCP with no problem at all. Some update broke it.

[bford16 (bford16)]

Also, this appears to have happened before. A bug filed for Gentoo (marked SOLVED) claims that updating GDM to version 2.20.2 fixed the issue. Intrepid uses version 2.20.8.

http://bugs.gentoo.org/show_bug.cgi?id=199606

[bford16 (bford16)]

One more comment: I opened Firestarter (not installed by default; do "sudo apt-get install firestarter") and enabled port 177 from my XDMP server. Suddenly XDMCP works again. However, "sudo ufw status" says "not enabled," so I don't know why that works.

[cu_ (avkv-prasad)]

It is still a problem in Intrepid. Little more information from syslog.
There are two more threads with exact same issues in ubuntuforums...but no solutions.
Again, it worked before. Some update broke it.

Dec 22 17:06:18 server gdm[5366]: DEBUG: gdm_xdmcp_host_allow: client->hostname is 127.0.0.1
Dec 22 17:06:18 server gdm[5366]: DEBUG: Attempting to parse key string: debug/Enable=false
Dec 22 17:06:18 server gdm[5366]: DEBUG: gdm_xdmcp-handle_manage: Got display=1, SessionID=1181938353 Class=MIT-unspecified from MIT-unspecified1
Dec 22 17:06:18 server gdm[5366]: DEBUG: gdm_xdmcp_handle_manage: Failed to look up session id 1181938353
Dec 22 17:06:18 server gdm[5366]: DEBUG: XDMCP: Sending REFUSE to 1181938353
Dec 22 17:06:18 server gdm[5366]: DEBUG: gdm_forward_query_lookup: Host ::ffff:127.0.0.1 not found
Dec 22 17:06:18 server gdm[5366]: DEBUG: decode_packet: GIOCondition 1
Dec 22 17:06:18 server gdm[5366]: DEBUG: XDMCP: Received opcode QUERY from client ::ffff:127.0.1.1 : 60899
Dec 22 17:06:18 server gdm[5366]: DEBUG: gdm_xdmcp_host_allow: client->hostname is 127.0.1.1
Dec 22 17:06:18 server gdm[5366]: DEBUG: XDMCP: Sending WILLING to ::ffff:127.0.1.1

[DalaiDakkar (dalaidakkar)]

Same problem with me, trying to connect to intrepid ibex via a fedora client and screen flashes with login window, then dissapears and back to fedora,

cat /var/log/messages
Jan 5 18:37:22 localhost acpid: client connected from 5644[0:0]
Jan 5 18:37:22 localhost acpid: 1 client rule loaded
Jan 5 18:37:23 localhost gdmchooser[5660]: GLib-GObject-WARNING: gsignal.c:1019: unable to lookup signal "activate" of unloaded type `GtkMenuItem'
Jan 5 18:37:27 localhost acpid: client connected from 5675[0:0]
Jan 5 18:37:27 localhost acpid: 1 client rule loaded
Jan 5 18:37:28 localhost acpid: client connected from 5675[0:0]
Jan 5 18:37:28 localhost acpid: 1 client rule loaded
Jan 5 18:37:30 localhost kernel: gdm-binary[5671]: segfault at 000004d0 eip 05c4d328 esp bfbdc470 error 4
Jan 5 18:37:30 localhost gdm-binary[2262]: WARNING: gdm_cleanup_children: child 5671 crashed of signal 11
Jan 5 18:37:30 localhost gdm-binary[2262]: WARNING: gdm_cleanup_children: Slave crashed, killing its children

[cu_ (avkv-prasad)]

Hi,

I forgot to post. My problem got resolved (accidentally). It had (for some reason had to do with the router). The problem is, XDMCP tries to get to port 177 on the local host. For some reason, it is going thru the router and my router was blocking it. My mistake was I upgraded Ubuntu AND changed my router at the same time. I ended up moving back to my old router.

To test to see if you have the same problem... please remove the network chord and try vnc-ing into local machine and it works fine.
The curx of the issue is port 177 on the host needs to be reachable from the client.

Hope this helps.

[Sergio Zanchetta (primes2h)]

The 18 month support period for Gutsy Gibbon 7.10 has reached its end of life -
http://www.ubuntu.com/news/ubuntu-7.10-eol . As a result, we are closing the
Gutsy task.

[Sebastien Bacher (seb128)]

the issue is deprecated in the new gdm so closing the bug