[K12OSN] LDM crashing on trying to log in.

[Gary Nutbeam]

Thanks. I'm going to download the image and have a look at it.

On 10/18/2013 09:23 AM, Radek Bursztynowski wrote:
> I tested it the once again. I can confirm that trying to log in that
> epel-6-i386 image installed 2 mounts ago crash on trying to log in.
>
> But the image installed few days ago using my parameters works fine. I
> copied this to another one LTSP server, and I have just finish the test
> of copied image. Works fine with no crashing on trying to log in.
>
> If you want to try my working image you can download it, both i386 and
> x86_64 versions:
> http://www.bursztynowski.pl/ftp/linux/LinuxTerminalServerProject/5/5.4/epel-6-thin_client_image/
>
> I renamed chroot directory to epel-6-i386_base and epel-6-x86_64_base.
>
> Best regards,
> Radek
>
> ---
>> Thanks for the info. Unfortunately I tried this with US information
>> substituted and still have LDM crashing. I was running a Scientific
>> Linux client and it was working better. I'll see if I can rollback to
>> that, or maybe try the version out of the EPEL repo.
>>
>> On 10/14/2013 04:51 PM, Radek Bursztynowski wrote:
>>> Hello,
>>>
>>> I have the same problems. The problem with first attempting to log in I
>>> solved (I believe). This solution concerns i386 and x86_64 thin client
>>> image (epel6-i386 and epel-6-x86_64).
>>>
>>> I added to /opt/ltsp/chroot/etc/sysconfig three files which I couldn't
>>> find after ltsp-build-client script execution:
>>>
>>>
>>> (Polish parameters)
>>> clock
>>> ZONE="Warsaw/Europe"
>>>
>>> i18n
>>> LANG="pl_PL.UTF-8"
>>>
>>> keyboard
>>> KEYTABLE="pl2"
>>> MODEL="pc105"
>>> LAYOUT="pl"
>>> KEYBOARDTYPE="pc"
>>>
>>> and my /opt/ltsp/i386/etc/ltsp_chroot is not empty but includes
>>>
>>> LTSP_CHROOT=/opt/ltsp/i386 line
>>>
>>> and /opt/ltsp/x86_64/etc/ltsp_chroot includes
>>>
>>> LTSP_CHROOT=/opt/ltsp/x86_64 line.
>>>
>>> Now LDM doesn't reload and works fine.
>>>
>>> I am not sure that this the best solution, but it helped me.
>>>
>>> Thin client still doesn't reboot or shutdown.
>>>
>>> I tried Debian LTSP too, but I retrieved. Finally I moved Debian thin
>>> client image to LTSP on CentOS 6.4 and I can use it, but I prefer epel-6
>>> images. In my opinion the most stable thin client image is Scientific
>>> Linux 6.1 (ltsp-server 5.2) and I recommend it.
>>>
>>> Best regards,
>>> Radek
>>>
>>> ---
>>>> It would be a lot of work for me to move to Debian, because of
>>>> applications to be moved, tested on Debian, etc. Plus everything we do
>>>> is CentOS and Fedora based.
>>>>
>>>> I can't shutdown or reboot the client either. I saw a hack on the list
>>>> that I haven't tried yet to "fix" the shutdown/reboot problem.
>>>>
>>>> On 10/14/2013 10:42 AM, k12ltsp wrote:
>>>>> Hi Gary,
>>>>>
>>>>> We have the same problem I'm afraid.
>>>>> Using ltsp-server-5.4.5-24.elg.x86_64 but with 32 bit clients. Atom
>>>>> processors in the clients with at least 1GByte RAM.
>>>>> Usually work reliably once logged in.
>>>>>
>>>>> Also cannot shutdown or reboot the client. Tried some suggestions from
>>>>> the list, but they didn't help.
>>>>>
>>>>> Things seem to have got worse recently, and I don't have the skills to
>>>>> try and fix it, we do IT support for small businesses and web/database apps.
>>>>>
>>>>> Now trying Debian Wheezy with LTSP - just works, so looks like I shall
>>>>> jump ship.
>>>>>
>>>>> Regards
>>>>> Trevor
>>>>> http://www.infocentrality.co.uk
>>>>>
>>>>> On 14/10/13 16:03, Gary Nutbeam wrote:
>>>>>> I'm having stability problems with LDM. I'm using decent thin clients
>>>>>> now (1700 model from disklessworkstations.com, hyperthreading atom, 2GB
>>>>>> RAM etc.).
>>>>>>
>>>>>> I'm using ltsp-server 5.4.5-24 on CentOS 6.4 64bit from the ltsp repo at
>>>>>> ltsprepo.s3.amazonaws.com.
>>>>>>
>>>>>> When first attempting to log in, after entering the username, LDM seems
>>>>>> to crash, and restart. The second attempt to login works fine. If it
>>>>>> doesn't crash on the first attempt, the X session crashes very shortly
>>>>>> afterwards, usually when trying to launch an application. After the
>>>>>> initial weirdness, everything seems to settle down and work.
>>>>>>
>>>>>> This behavior happens on both the physical thin clients AND a virtual
>>>>>> client.
>>>>>>
>>>>>> Has anyone seen this problem and know what might be causing it?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Gary.
>>>>>>
>>>>>> _______________________________________________
>>>>>> K12OSN mailing list
>>>>>> K12OSN at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/k12osn
>>>>>> For more info see <http://www.k12os.org>
>>>>>
>>>>> _______________________________________________
>>>>> K12OSN mailing list
>>>>> K12OSN at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/k12osn
>>>>> For more info see <http://www.k12os.org>
>>>>>
>>>>
>>>> _______________________________________________
>>>> K12OSN mailing list
>>>> K12OSN at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/k12osn
>>>> For more info see <http://www.k12os.org>
>>>
>>>
>>> _______________________________________________
>>> K12OSN mailing list
>>> K12OSN at redhat.com
>>> https://www.redhat.com/mailman/listinfo/k12osn
>>> For more info see <http://www.k12os.org>
>>>
>
>