[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] LDM crashing on trying to log in.



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 redhat com
> >>>> https://www.redhat.com/mailman/listinfo/k12osn
> >>>> For more info see <http://www.k12os.org>
> >>>
> >>> _______________________________________________
> >>> K12OSN mailing list
> >>> K12OSN redhat com
> >>> https://www.redhat.com/mailman/listinfo/k12osn
> >>> For more info see <http://www.k12os.org>
> >>>
> >>
> >> _______________________________________________
> >> K12OSN mailing list
> >> K12OSN redhat com
> >> https://www.redhat.com/mailman/listinfo/k12osn
> >> For more info see <http://www.k12os.org>
> >
> >
> > _______________________________________________
> > K12OSN mailing list
> > K12OSN redhat com
> > https://www.redhat.com/mailman/listinfo/k12osn
> > For more info see <http://www.k12os.org>
> >



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]