No ldm login on the thinclient

I have seen this behaviour on a regular ubuntu install using ltsp-server on the clients, too.

seems that is caused by the usplash down script running "chvt 1" as last command, for now you can delete the link in /opt/ltsp/i386/etc/rc2.d/S98usplash to solve that.

ltsp (0.85) dapper; urgency=low
 .
   * make ldm stop usplash before we start it, to prevent switching to
     tty1 (closes malone #39294)
   * make the SOUND variable really use boolean values (True/False), not
     "y" to keep consistency with ltsp.org docs
   * applied Pete Savages manpages for the adminscripts to ltsp-server

I am still seeing this on the ltsp-server package that shipped with dapper (0.87).

The server is an over built multicore opteron box and we are using LTSP Term 150 ([url]http://www.disklessworkstations.com/cgi-bin/web/info/ltsp_t150.html?id=sVIsgkVz[/url]) over a 100Mbit network.

I have seen some other threads concerning this issue, but have not seen a resolution yet:

[url]http://www.nabble.com/Cannot-get-X-to-start-on-some-clients-t2178429.html[/url]

a workaround that helps is to create a lts.conf and enable sound (SOUND=True), thats avoids the race condition that causes this bug ...

could you try something that appears to be the real fix? apparently the usplash initscript needs to be called with the start paramater to stop ...

so change the line that reads
/etc/init.d/usplash stop
to be
/etc/init.d/usplash start
in the /opt/ltsp/i386/etc/init.d/ltsp-client file
and see if that helps ...

This did the trick Oliver!

My thin client (533 MHz, 128MB RAM) is much slower than with ltsp 4.2 is this normal behavior because it is pushed over ssh or should I re-examine my setup?

Oliver,

Changing the line that reads
/etc/init.d/usplash stop
to be
/etc/init.d/usplash start
in the /opt/ltsp/i386/etc/init.d/ltsp-client file

did the trick for me, too.

Thanks! We now have a very usable test system. Hope to roll out a full production purchase soon!