[08:03] <alkisg> Good morning
[11:51] <freedom> does edubuntu builtin dhcp server?
[11:52] <freedom> how do i run ltsp after install?
[16:09] <kidar> hi alksig
[16:10] <kidar> hope u remember me. have a problem in the classroom that i set up
[16:21] <kidar> the pcs that have win98 have only 24mb ram. server has 3gig
[16:22] <kidar> is there a way of setting up server to give more mem
[16:28] <alkisg> To use 24MB PCs as ltsp clients? It's too little RAM, they won't boot with that
[16:29] <alkisg> 64MB is the lowest minimum for 10.04, and even then it won't work out of the box, but a few manual changes are needed in some startup scripts
[16:29] <alkisg> About 80MB is the "out of the box" minimum
[16:54] <kidar> how about booting straight from network card with these pc, is there anyway i can configure ltsp server to give sufficient ram to the stations
[17:21] <alkisg> kidar: there's no way to boot any recent linux version with those stations
[17:22] <alkisg> The only way to make them useful with linux would be to either use the ancient LTSP 4, which noone uses anymore, or use some ancient distro like Deli-linux, and then do remote X to the ltsp server
[17:22] <alkisg> (that's not LTSP anymore though)
[17:29] <kidar> or alternatively get more mem
[17:31] <kidar> in the system i also 3 pcs which have 128mb and xp. managed to get them to boot using the onboard nic but it is very slow
[17:32] <alkisg> Did you try LDM_DIRECTX=True? It gives speed at a security cost.
[17:33] <alkisg> Also, if you don't have gigabit network, it'd help to upgrade it, at least from the server to the switch.
[17:40] <kidar> server is gigabit rest 10/100
[17:42] <kidar> regarding ldm no i did not try. where/ how to? also the school does not have internet so a solution for that too pls or alt i can bring it home again
[17:42] <kidar> by the way did not get ur name the last time :)
[17:51] <alkisg> The proper channel for ltsp questions is #ltsp, there's a link to the ltsp docs there
[17:51] <alkisg> Also the man page has some info about it: http://manpages.ubuntu.com/lts.conf
[18:06] <alkisg> Btw, for the gigabit server<=>switch connection to work, you'd need to disable flow control, otherwise it's 10 times slower: https://help.ubuntu.com/community/UbuntuLTSP/FlowControl
[20:51] <highvoltage> alkisg: hey there, how are you doing?
[20:51] <alkisg> Hi highvoltage
[20:52]  * alkisg is watching a video about some new ministry plans *not* to have computer lessons in high schools in Greece..!!!
[20:54] <mhall119> that's sad to hear
[20:54] <mhall119> what was the rationale?
[20:54] <alkisg> mhall119: are there computer lessons in secondary education in your country?
[20:55] <mhall119> alkisg: not much, mostly tough typing when I went through school
[20:55] <alkisg> No idea about the rationale, the plans are not official yet - but I really wonder why they'd do that
[20:55] <mhall119> I don't think it's any more indepthy now
[20:55] <highvoltage> alkisg: what? how's that possible!?
[20:55] <alkisg> Ugh. Here we even had some programming lessons in high schools (17 y.o.)
[20:55] <highvoltage> alkisg: I guess there'll probably be some objections :)
[20:55] <alkisg> I hope so... :)
[20:56] <mhall119> I wish programming was a required topic for all high schools
[20:56] <mhall119> in the near future, everybody is going to need to understand at least some of it
[20:56] <highvoltage> alkisg: I've been tasked to test NBD this week and look at its current status
[20:56] <alkisg> Now they say they won't have any computer lessons at all, not even optional ones, for students wanting to go to universities that involve programming...
[20:56] <alkisg> highvoltage: and?
[20:57] <highvoltage> alkisg: stgraber told me that you had some problems before in your implementations, I just wanted to check if there's something not already in the bug lists and if there's something else I should also note :)
[20:58] <alkisg> nbd-proxy is causing problems to lots of people, I'm not sure if the bug reports reflect that well enough,
[20:58] <alkisg> and there are some upstart problems which I worked around in a recent commit (trying up to 10 times - some clients make it on the 8th try!),
[20:59] <alkisg> other than those, nbd works well
[21:00] <highvoltage> ouch
[21:01] <alkisg> If I had to give an estimate, I'd say that about 5-10% of ltsp clients don't boot without those nbd-proxy/upstart-or-udev workarounds... :(
[21:02] <alkisg> About nbd-proxy, I think it'd be good if stgraber only used that for cluster installations by default,
[21:02] <highvoltage> oops, I see I just said nbd earlier, I meand nbd-proxy :)
[21:02] <alkisg> and for a proper solution to the udev problem, a more experienced hacker than me would be needed - I tried udevadm settle but it didn't work for me
[21:02] <highvoltage> *meant
[21:02] <highvoltage> (ugh Mondays)
[21:04] <alkisg> Also the "disabling compression by default" too would be better if it was only enabled for ltsp cluster, as it's causing a lot of slowdown
[21:06] <stgraber> hmm, maybe you're lucky not to go through the case where having compression causes kernel panic but it was really easy to reproduce with ltsp-live back in lucid
[21:06] <stgraber> no compression turned the kernel panic issue down to 0 so it was prefered to do it this way and let people re-compresss (at their own risk) than the other way around
[21:07] <alkisg> stgraber: I've reenabled compression for all schools here in greece, so I can report for about 1000 clients that they work OK
[21:07] <alkisg> Wasn't it working OK previously in 8.04-9.10?
[21:07] <stgraber> it was yes, something in the kernel made it break after that
[21:08] <stgraber> we still run with compression on for 8.04 and 9.10 (though we try to get rid of these ;))
[21:08] <alkisg> stgraber: without compression it's much slower, e.g. fat clients need twice the time to boot
[21:08] <alkisg> In any case it's been working ok in all installations here
[21:09] <alkisg> (with compression on)
[21:10] <alkisg> Maybe those people that you refer to had networking problems, and compression == off just means that they'll get periodic crashes instead of nbd "notifying" them with kernel panics?
[21:10] <stgraber> I'll be re-testing with Natty but at least on lucid I could get kernel panics almost 50% of the time with two machines on a gigabit network, one being a regular core2 laptop as a server and the other an asus EEE as a client
[21:10]  * alkisg has seen that and it was solved when the people fixed their network sockets...
[21:11] <stgraber> they were connected through two cat6 network cables (tested for gigabit without any issue) and didn't go through any router
[21:11] <stgraber> these issues seem to happen more often when the network speed was great
[21:11] <alkisg> Any realtek cards there? Maybe it was a driver issue....
[21:11] <stgraber> intel e1000 both sides IIRC
[21:12] <alkisg> Hmmm weird that I never saw that problem... I've personally tested on gigabit networks too
[21:12] <stgraber> it was so reproducable that I couldn't even get my lucid benchmarks right just because it'd freeze half of the time ;)
[21:12] <alkisg> omg :)
[21:13] <stgraber> I tried with every single mksquashfs parameters to improve the situation and the only way I found that would restore stability to 100% was to turn off compression
[21:13] <alkisg> stgraber: ah, were you using nbd-proxy?
[21:13] <stgraber> then I managed to do over 2000 reboots in a row without any crash
[21:13] <alkisg> I've seen it fail many times, I'm not using it on greece at all
[21:13] <alkisg> So maybe it's a nbd-proxy/nbd compression combination problem
[21:14] <alkisg> If you could test without nbd-proxy on that environment where you were seeing the problem, that'd help...
[21:14] <stgraber> nbd-proxy was doing what it was supposed to in these cases. So running it would freeze in these cases and without it it wouldn't freeze immediately but doing a "find /" after boot would return I/O errors
[21:15] <alkisg> Except for clients not booting at all with nbd-proxy, I've also seen it have "negotiation problems" and "unexpected header in nbd reply" and stuff like that