[03:05] <LedHed> I'm having trouble with LTSP clients and Compiz.
[03:05] <LedHed> Is it possible to turn it off?
[03:06] <LedHed> I set visual effects = none,  but gtk-window-deco keeps eating up my CPU
[05:22] <alkisg> Good morning
[08:22] <vmlintu> Anyone experiencing problems with nbd-proxy on lucid? We've been testing it and it seems to cause quite a few boot problems with some clients. The symptoms are that the boot process just hangs before login screen (something like half of boots fail). When nbd-proxy is taken out of the picture, there are no boot problems.
[08:23] <alkisg> I'm having RAM problems with nbd-proxy, it needs 25 MB of ram and that's too much for thin clients
[08:24] <alkisg> I wonder if we should at least put a kernel parameter to disable it... e.g. pxelinux.cfg/default: quiet splash no-nbd-proxy or something
[08:37] <alkisg> Hmm or better, an lts.conf option. OK I'm gonna implement that, it's surely useful for 64mb clients.
[08:46] <alkisg> Bah it's not possible to parse lts.conf before mounting the root fs, because getltscfg is not available...
[08:47]  * alkisg wishes that getltscfg actually run on the server, and the clients only got the part that is relevant for them as a shell script with VAR=VALUE entries...
[08:47] <alkisg> Or better yet that we ditched lts.conf completely and made an ltsp_client_config.d directory in /etc/ instead.
[08:59] <alkisg> stgraber: how would you feel about adding a kernel parameter to disable nbd-proxy, while also disabling it by default for clients with < 100mb ram?
[08:59] <alkisg> http://alkisg.pastebin.com/HnxZ5g6m
[09:00] <alkisg> nbd-proxy here needs 23980 KB RAM while nbd-client only needs 1684.
[09:02] <alkisg> ..and for maverick wouldn't it be better to send any nbd-related patches upstream, and completely ditch nbd-proxy?
[09:08] <vmlintu> I didn't realise that it requires so much memory
[09:08] <alkisg> For example, with nbd-proxy, I can't run gparted locally on a client, while without it, I can. (https://help.ubuntu.com/community/UbuntuLTSP/GParted)
[09:08] <alkisg> (on an 64mb ram client)
[09:12]  * alkisg also hasn't ever experienced the problem that nbd-proxy is supposed to be solving...
[09:27] <vmlintu> I'll have to do some more testing with nbd-proxy and figure out how to disable it if it keeps causing problems..
[19:47] <bencrisford> highvoltage: meeting tonight?
[19:48] <highvoltage> bencrisford: yep
[19:48] <bencrisford> :)
[19:48]  * bencrisford runs date -u, he doesnt trust his brain to do the calculation
[19:48] <alkisg> In 10 minutes?
[19:49] <bencrisford> thats what I make it :)
[19:49] <highvoltage> alkisg: yep
[19:49] <alkisg> Ty
[19:49]  * highvoltage is thankful that he doesn't live in a country with DST or anything weird like that
[20:14] <alkisg> stgraber: hi, how would you feel about adding a (optional, of course) kernel parameter to disable nbd-proxy, while also disabling it by default for clients with < 100mb ram? http://alkisg.pastebin.com/HnxZ5g6m
[20:19] <stgraber> alkisg: it wouldn't affect any of my deployments and < 100MB is probably < i686 so won't boot on maverick anyway ;) so I'm fine with that
[20:19] <alkisg> Nice. Whoah, maveric won't support booting Pentium III's ?
[20:20] <alkisg> (or even celerons, amd k6 etc...)
[20:21] <stgraber> alkisg: depends, I believe most P3 are i686 but P2 will be unsuported and so are AMD Geodes
[20:22] <alkisg> OK, P2's and Geodes are rare here, but celerons @300/600 MHz with 64MB RAM are too common
[20:22] <alkisg> (more than 50% of our ltsp installations)
[20:22] <alkisg> Thanks :)
[20:33] <alkisg> Hmmm ok so we lose Pentium MMX and AMD K6, no big deal. Mendicino etc are i686, so no problem...
[20:34] <alkisg> *Mendocino
[21:02] <highvoltage> stgraber: p2 are i686 too
[21:02] <highvoltage> alkisg: Pentium Pro and up is i686
[21:03] <alkisg> highvoltage: I read that MMX and AMD K6 are 586
[21:03] <alkisg> ...so we'll lose about 1 out of every 10 clients, not a really big deal... (considering that we'll keep lucid for at least 2 years)
[21:04] <highvoltage> alkisg: yep, the old Pentium 1s before the Pentium Pros (that's about all the Pentiums slower than 200mhz) won't work
[21:05] <alkisg> Some MMX that I have are 233 MHz and the AMD K6's are 300 MHz
[21:05] <highvoltage> those machines are pretty badly supported atm anyway in terms of display cards, disk controllers, etc. imho nobody should be using them already :)
[21:05] <highvoltage> alkisg: hmm, and the 233mhz ones aren't pentium pro yet?
[21:06] <alkisg> The amd k6 boots ltsp 9.10 in about 70 seconds while the others on that lab (celerons @600mhz) boot in 60 seconds - so it's really usable, not a big difference from the others
[21:06] <alkisg> It can play full screen video and everything..
[21:06] <highvoltage> alkisg: at least there's lucid that's lts if you have to use old stuff
[21:07] <alkisg> Yup, we'll be sticking to lts releases from now on - ltsp is in good shape now for us
[21:07] <alkisg> (while in hardy it wasn't suited for greek schools)
[21:08] <highvoltage> *nod*
[21:08] <alkisg> highvoltage: need any help in that live ltsp script?
[21:08] <highvoltage> lots of things have improved between hardy and lucid
[21:09] <alkisg> E.g. we cold massively speed it up by manually appending the users to passwd/shadow... hacky, but it would save a couple of minutes
[21:09] <highvoltage> alkisg: the plan is to convert it to a quickly application. currently it uses zenity which is very very limited in terms of functionality
[21:10] <highvoltage> alkisg: I'm not at all against that. it's on a live system that gets trashed on reboot so I can't see why it should specifically be a problem
[21:10] <alkisg> It could also be tweaked to work with single nic systems, and even in proxydhcp mode (external dhcp server around)
[21:10] <highvoltage> alkisg: could even go as far as have the entries pre-defined and just use cat >> to add it to the passwd file, that would make it pretty much instant
[21:11] <highvoltage> it does work with single-nic systems currently
[21:11] <alkisg> We could add one user normally and then duplicate that entry - it should be quite portable and also instant
[21:11] <highvoltage> (if you only have eth0 and it's currently configured then you can specify eth0:1 and it will work)
[21:11] <alkisg> highvoltage: proxydhcp == without the ltsp server being the dhcp server
[21:11] <highvoltage> ah right
[21:12] <alkisg> I.e. when the server is wired to a switch and a router is around, which is a common setup
[21:13] <alkisg> (otherwise the users would have to shut off the router's dhcp server)
[21:33] <alkisg> stgraber: could we put ltsp-chroot to /usr/sbin like debian does?