IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 27 May 2007   (all times are UTC)

00:23ltspbot` has joined #ltsp
00:41ltspbot has quit IRC
00:44jsgotangco has quit IRC
01:10muh2000_ has joined #ltsp
01:15daya has joined #ltsp
01:17muh2000 has quit IRC
01:41
<daya>
I have run ltsp-build-client, for setting ltsp client environment,but not working
01:41
any idea
01:41muh2000_ is now known as muh2000
02:07vagrantc has joined #ltsp
02:25daya has quit IRC
02:37daya has joined #ltsp
02:55fernando1 has quit IRC
03:00fernando1 has joined #ltsp
03:13ogra has joined #ltsp
03:28Burgundavia has quit IRC
03:32bill_c has joined #ltsp
04:05Q-FUNK has joined #ltsp
04:07Q-FUNK has quit IRC
04:08Q-FUNK has joined #ltsp
04:21maaarek has joined #ltsp
04:25fernando1 has quit IRC
04:30fernando1 has joined #ltsp
04:37nf1 has quit IRC
04:37nf1 has joined #ltsp
04:43ogra-classmate has joined #ltsp
04:50vagrantc has quit IRC
05:35vagrantc has joined #ltsp
05:45ogra-classmate has quit IRC
05:45gonzaloaf has joined #ltsp
06:04Q-FUNK has quit IRC
06:09Q-FUNK has joined #ltsp
06:13nepali has joined #ltsp
06:26freemind has joined #ltsp
06:32Q-FUNK has quit IRC
06:33Q-FUNK has joined #ltsp
06:37
<nepali>
is ltst 5.0 is unstable,?
06:37
I can't work it with debina etch 4.0
06:38Q-FUNK has quit IRC
06:39ogra-classmate has joined #ltsp
06:40
<daya>
why no one is speaking here, whats a channel
06:41
<ogra-classmate>
well, its weekend, what do you expect
06:41
<freemind>
yeap... you can work on debian etch with ltsp 5.0
06:42Q-FUNK has joined #ltsp
06:42
<ogra-classmate>
you actually *should* use ltsp5 on etch
06:43
<vagrantc>
especially with the new backports i just created :)
06:43Q-FUNK has quit IRC
06:43
<ogra-classmate>
vagrantc: can you resend the signed thing with the other key ? i dont have the secret key for the one you signed with anymore
06:44
s/signed/encrypted/
06:44
<vagrantc>
ogra-classmate: hrm. i used the one on your businesscard ...
06:45
<ogra-classmate>
arent there two ?
06:45
gah
06:45
no, there arent
06:45
the one i sign my packages with is the right one ... one sec
06:45Q-FUNK has joined #ltsp
06:45freemind has quit IRC
06:48
<vagrantc>
ogra-classmate: trying to grab your key from launchpad...
06:49
<ogra-classmate>
ah, yeah that should be the right one .
06:49Q-FUNK has quit IRC
06:50Q-FUNK has joined #ltsp
06:50
<vagrantc>
ogra-classmate: seems to be the same key ...
06:50
ogra-classmate: should i use a specific sub-key ?
06:50
<ogra-classmate>
yeah
06:51
the one whose id starts with AD
06:51
just trying to ssh into my other box but the classmate doesnt like to
06:51
firefox and evo dont go well together here
06:52
pub 1024D/A2D06936 2002-06-21
06:52
thats the one
06:52
<vagrantc>
hrm. that's what i thought i used ...
06:52
<ogra-classmate>
somehow gpg --list-keys sees it as my master key
06:52
<vagrantc>
me too
06:53
<ogra-classmate>
well, its signed with
06:53
sub 2048R/8D942A24 2004-12-01 [verfällt: 2009-12-01]
06:53
<vagrantc>
hm.
06:55* vagrantc tries again
06:55Q-FUNK has quit IRC
06:55Q-FUNK has joined #ltsp
07:01* vagrantc fails
07:05
<ogra-classmate>
i'll poke around on my side then, i must have the secret key somewhere
07:06
<vagrantc>
i've explicitly specified to encrypt to either of the other keys, and it always chooses 8d942a24
07:06
<ogra-classmate>
meh
07:10highvoltage has quit IRC
07:11daya has quit IRC
07:15highvoltage has joined #ltsp
07:32f3ew has quit IRC
07:32f3ew has joined #ltsp
07:37ogra-classmate has quit IRC
07:38ogra-classmate has joined #ltsp
07:38Bill_c_ has joined #ltsp
07:38
<nepali>
ogra-classmate, I found tftp error , file not found error in ltsp
07:39
<vagrantc>
nepali: this is on debian etch ?
07:39
<nepali>
vagrantc, yes on debian etch
07:39
vagrantc, I can'
07:39
<vagrantc>
nepali: dpkg -l '*tftpd*'
07:40
<ogra-classmate>
nepali: did you use ltsp 4.2 at any point on that installation ?
07:40
<vagrantc>
or ltsp-utils, more specifically
07:41
<ogra-classmate>
yeah
07:41
<vagrantc>
nepali: dpkg -l '*ltsp*'
07:42
<nepali>
ii tftp 0.17-15 Trivial file transfer protocol client
07:42
ii tftpd 0.17-15 Trivial file transfer protocol server
07:42* vagrantc wonders how '*tftpd*' matched tftp ...
07:43
<vagrantc>
nepali: dpkg -l '*ltsp*'
07:43
<ogra-classmate>
hmm, tftpd ?
07:43
<vagrantc>
right
07:43
<nepali>
I am using ltsp4.1, I can't go through 5.0,
07:44
<vagrantc>
nepali: you probably need to install atftpd or tftpd-hpa ... plain old "tftpd" doesn't work with PXE
07:45
<nepali>
ok
07:45
<vagrantc>
nepali: why can't you install ltsp 5 ?
07:45
or at the very least, 4.2
07:45
<ogra-classmate>
yeah
07:45
<nepali>
vagrantc, I have gone through ltsp 5 once, but I face difficulties in tftp, in doesn't get started,
07:45
<ogra-classmate>
4.1 is obsolete
07:46
<vagrantc>
well, both ogra and i are mostly familar with ltsp 5 ...
07:47
<nepali>
ok in ltsp 5 everything work but tftp doesn't get started, and also it doesn't contain /tftpboot directory
07:48
<vagrantc>
that's fine
07:48
<ogra-classmate>
no
07:48
<vagrantc>
tftp shouldn't get started, and it goes in /var/lib/tftpboot by default
07:48
<ogra-classmate>
tftp is served on debian systems from /var/lib/tftpboot
07:48
/tftpboot isnt FHS compliant in any way :)
07:49
<vagrantc>
the main thing we're missing from ltsp-utils is a configration helper ...
07:49
<ogra-classmate>
ltsp-manager ;)
07:49
<vagrantc>
ogra-classmate: isn't that just a bzr branch?
07:49* vagrantc dodges
07:50
<ogra-classmate>
vagrantc: you were in teh BOF about the ubuntu terminal server CD, werent you?
07:51
<vagrantc>
ogra-classmate: i ... don't think so
07:51
ogra-classmate: well wait ..
07:51
<ogra-classmate>
i agreed there that we'll have ltsp-manager and ltsp-build-client-gtk before gutsy release
07:51
<vagrantc>
ah, yes. i was there.
07:51
or i heard you say it somewhere
07:52
that was with the ubuntu server folks?
07:52
<ogra-classmate>
so for gutsy we should have something ,,, and since the new ltsp-manager code will be using python-ltsp we can just add a commandline gui
07:52
right
07:52
<vagrantc>
i like that idea.
07:52
<ogra-classmate>
about the server DVD
07:52Q-FUNK has quit IRC
07:53
<vagrantc>
having a single backend support both GUI and text mode will be appreciated by administrators.
07:53
of course, some of the python commandline libraries are a little ugly to work with ...
07:53
<ogra-classmate>
and by qt programmers :)
07:53
<vagrantc>
oh yeah, those.
07:54
<ogra-classmate>
isnt there a python-curses
07:54
?
07:54
<vagrantc>
there is ...
07:54
requires some foul language to use, i suspect.
07:55
<ogra-classmate>
you could write shell wrappers and use native ncurses :)
07:55
<vagrantc>
yes, i'll.... get right on that.
07:55
<ogra-classmate>
heh
07:55bill_c has quit IRC
07:57nf1 has quit IRC
07:58
<ogra-classmate>
hmm, did you ever hear of windows ReadyBoost technology in vista?
07:59
seems vista offers you to use a new usbstick as swapspace
07:59
<vagrantc>
sounds like it's for old people or something
07:59
wow. what a clever way to burn usb sticks.
08:00
<ogra-classmate>
i.e. if there is nothing on it it offers to format it and put a swapfile on it
08:00
http://blogs.msdn.com/tomarcher/archive/2006/06/02/615199.aspx
08:00
`Q: Won't this wear out the drive?
08:00
A: Nope. We're aware of thelifecycle issues with flash drives and are smart about how and when wedo our writes to the device. Our research shows that we will get atleast 10+ years out of flash devices that we support.
08:00
i wonder how they do that
08:01
<vagrantc>
yeah, especially with how much windows loves swap
08:01
<ogra-classmate>
heh
08:01
well, its compressed and all
08:01
according to the FAQ
08:06spectra has joined #ltsp
08:12nepali has quit IRC
08:18highvoltage has quit IRC
08:27chupacabra has quit IRC
08:33
<ogra-classmate>
vagrantc: hmm, i think i might have found a possible major slowdown kernel setting ....
08:34
ubuntu uses the cfq scheduler since some time, i think newer debian as well ....
08:34highvoltage has joined #ltsp
08:36
<ogra-classmate>
so we should try booting the e2300 with different elevator kernel options i'm pretty sure if we find the right one we'll see a huge speed improvement
08:36
i'm just playing with scheduler settings on the classmate disks :)
08:39
<vagrantc>
cool
08:39
that'd be cool if it was slowing it down to like 4MHz or something
08:40
<ogra-classmate>
wouch, i just switched the usb disk to the deadline scheduler, suddenly i can use evo and firefox smoothly at the same time
08:46* ogra-classmate tries a reboot with different overall scheduler
08:47ogra-classmate has quit IRC
08:53ogra-classmate has joined #ltsp
08:56
<jammcq>
ummmm, didn't you try the LTSP-4.2 kernel with LTSP-5.0, and find it just as slow?
08:58
and while it could be a scheduler issue, I'm pretty sure it's not a mhz issue, cuz I ran a cpu benchmark program, and the results were nearly identical between ltsp-4.2 and ltsp-5.0. So, it's not like the cpu is actually running slower.
08:58
<ogra-classmate>
jammcq: upstream switched with 2.19 to cfq
08:58
<jammcq>
oh, btw, Good morning everybody :)
08:59
<ogra-classmate>
i'm running the classmate with the deadline scheduler atm and its a lot faster
08:59
<jammcq>
umm, /me doesn't know what that means
08:59
<vagrantc>
jammcq: instructions for using the etch ltsp "backports" are at he bottom of http://wiki.debian.org/LTSP/Howto
08:59
<jammcq>
vagrantc: cooooool
08:59
vagrantc: complete with new repository ?
09:00
<vagrantc>
jammcq: it's slightly more complicated than i originally envisioned, because of gpg-signed package repositories, but not too bad
09:00
<jammcq>
heh, either way, you be rocking
09:00
<vagrantc>
jammcq: well, the instructions wouldn't be very useful without the repository :P
09:01
deb http://pkg-ltsp.alioth.debian.org/debian etch-ltsp-backports main
09:01
i just contains updates ltsp* and ldm packages
09:01
it
09:03* vagrantc contemplates getting a new ltsp upload into experimental
09:04
<ogra-classmate>
why experimental ?
09:04
<vagrantc>
well, i want to make some big changes
09:04
that maybe don't want to bother reverting ... but ...
09:04
<ogra-classmate>
good
09:05
<vagrantc>
i guess it's in testing/lenny already anyways ... so we can break unstable if we have to
09:06
i should probably try and fix petter's bug properly, too.
09:08
<ogra-classmate>
it is fixed with the new console-setup which i assume debian uses as well in unstabkle
09:10
just grab the code from the ubuntu locale plugin ...
09:10
<vagrantc>
well, it's in etch ... but not the default install
09:11
if [ -f /etc/default/console-setup ]; then
09:11
cp /etc/default/console-setup $ROOT/etc/default/console-setup
09:11
fi
09:11
?
09:13
<ogra-classmate>
right
09:13
<vagrantc>
so we'd have to install console-setup on the server before running ltsp-build-client, i'm guessing
09:14
<ogra-classmate>
well, itws in ubuntus derfault install
09:14
<vagrantc>
well, obviously we don't have to do anything on ubuntu here, it's already there :P
09:14
<ogra-classmate>
jammcq: http://www.linuxinsight.com/files/ols2004/pratt-reprint.pdf might be an intresting paper
09:15
i'd expect it in the debian unstable default install as well
09:15
jammcq: from http://www.linuxinsight.com/ols2004_workload_dependent_performance_evaluation_of_the_linux_2_6_i_o_schedulers.html
09:15* jammcq isn't sure he has the attention span to sit and read that document
09:16
<ogra-classmate>
read the web article, its short i'll work into the pdf anyway :)
09:17
<jammcq>
the web article is only 2 paragraphs, then a link to the same pdf
09:17
<ogra-classmate>
i only scratched the surface of that yet, but it seems a valuable place to find our meta performance switch
09:17
right
09:18
its a short description about the pdf
09:18
<jammcq>
i'm thinking you are on to something
09:18cyberorg has joined #ltsp
09:18
<ogra-classmate>
the cfq scheduler is optimized for desktop usage
09:19
which is surely not what we need on a thin client
09:19
<jammcq>
which scheduler does Ubuntu kernel use?
09:19
<ogra-classmate>
cfq
09:19
since edgy
09:19
<jammcq>
hmm
09:19
<ogra-classmate>
debians newer kernels likely as well
09:19
most ubuntu kernel devs are debian kernel team members
09:19
so the setup will be very similar for such defaults
09:23
i'd also love to play with preemption settings, but i dont think there is a commandline option for it
09:24
<vagrantc>
ogra-classmate: did ltsp 5.0.8 actually make it to feisty? it's listed as feisty-proposed ?
09:24
<ogra-classmate>
and i'm not really keen on compiling stuff
09:24
vagrantc: i didnt come around to upload it yet, there is so much paperwork involved in SRUs
09:25
the fix is trivial though
09:27
hmm, 'anticipatory' seems to behave even better than 'deadline' seems thats what was used until 2.6.18 upstream
09:28
<vagrantc>
sure sounds smart.
09:32ogra-classmate has quit IRC
09:40ogra-classmate has joined #ltsp
10:06
<vagrantc>
ok. now i'm confused as hell.
10:06
The following packages have unmet dependencies: ltsp-client: Depends: pulseaudio-esound-compat but it is not going to be installed
10:06
E: Broken packages
10:06
error: LTSP client installation ended abnormally
10:06
chroot /opt/ltsp/i386 apt-get install ltsp-client
10:06
work's fine.
10:08
<ogra-classmate>
different repo for pulseaudio-esound-compat ?
10:08
heh
10:08
youre on etch, right ?
10:08
<vagrantc>
but i do the chroot immediately after without any changes to the sources.list stuff
10:08
<ogra-classmate>
there was no pulse package iirc
10:08
<vagrantc>
sure is
10:08Q-FUNK has joined #ltsp
10:09
<vagrantc>
otherwise it wouldn't work when i install it manually :P
10:09
<ogra-classmate>
are you sure ? i thought it was introduced after freeze
10:09
<vagrantc>
ogra-classmate: when's the last time you used debian etch? :P
10:09
<ogra-classmate>
never ?
10:09
:)
10:10
<vagrantc>
ogra-classmate: :P
10:10
<ogra-classmate>
woody was my last debian
10:10Q-FUNK has quit IRC
10:11Q-FUNK has joined #ltsp
10:13
<vagrantc>
ogra-classmate: i have no idea how well pulseaudio works in debian etch, but it's in there.
10:14
<ogra-classmate>
which version?
10:15
<vagrantc>
0.9.5-5
10:15
<ogra-classmate>
pretty recent
10:16
<vagrantc>
looks like ubuntu has only added 4 patches or so...
10:18Q-FUNK has quit IRC
10:20
<ogra-classmate>
yep
10:21Q-FUNK has joined #ltsp
10:36
<vagrantc>
i am stupid.
10:36
well, it took me too long to figure this out
10:37
pulseaudio-esound-compat: Conflicts: esound
10:37
we're still pulling in the default debian package stuff
10:37
including esound
10:43
<ogra-classmate>
ah
10:43
conflicts but no Replaces ?
10:43* vagrantc makes everything a dependency
10:44
<ogra-classmate>
well, thats up to the pulse maintainer
10:44
but it should have a replaces as well
10:44
and a provides
10:44
<vagrantc>
no, i mean, i'm grabbing all the EARLY_PACKAGES and making them a dependency of ltsp-client :)
10:44
<ogra-classmate>
then you dont get such probs
10:45
thats fine if plse had a provides line ;)
10:45
*pulse
10:46
if pulse provides,conflicts and replaces esound you can have both in the list, the latter will override the first afaik
10:47
<vagrantc>
that's if you only have a single tool providing a single functionality
10:48
<ogra-classmate>
hmm, the ubuntu package has all three
10:49
<vagrantc>
in the case of etch, i suspect pulseaudio was late enough in coming that esound is still the default for most things.
10:49
so it wouldn't be good to "replace" it
10:49
yet
10:49
<ogra-classmate>
hmm
10:50* vagrantc reads policy regarding replaces
10:53
<vagrantc>
oh fun. there's two different uses of Replaces
10:55
<ogra-classmate>
heh
10:55
one for the package and one for files in packages ?
10:55
<vagrantc>
yeah, maybe pulseaudio-esound-compat should provides, conflicts and replaces esound
10:56
presuming it truely provides full esound compatibility
10:56
<ogra-classmate>
Source: pulseaudio
10:56
Version: 0.9.5-5ubuntu4
10:56
Replaces: esound
10:56
Provides: esound
10:56
and
10:57
<vagrantc>
claims to
10:57
<ogra-classmate>
Conflicts: esound
10:57
<vagrantc>
right
10:57
<ogra-classmate>
thats feisty
10:58
<vagrantc>
should probably in debian as well ... it doesn't prevent you from installing classic esound if you really must have it
10:58
<ogra-classmate>
pulseaudio-esound-compat_0.9.5-5ubuntu4_i386.deb
10:58
i synced it from the debian package, and didnt touch the control file iirc
10:58
so debian should have the same here
10:59
<vagrantc>
oh. yes, it does.
10:59
so that doesn't work
10:59
:)
10:59
handling of provides is kind of brain-dead.
10:59
when there's a package that is actually named the same thing
11:00
<ogra-classmate>
yeah
11:03
oooh
11:03* ogra-classmate just saw the answer on pkg-ltsp-devel
11:03
<ogra-classmate>
:)
11:13
<vagrantc>
goodbye ltsp-utils
11:14
so, moving all of EARLY_PACKAGES into ltsp-client's dependencies worked quite nicely.
11:15
which makes dependency resolution and such much easier to handle
11:15Q-FUNK has quit IRC
11:20
<ogra-classmate>
yeah
11:20
but its the area where we always differ
11:20
<vagrantc>
yeah, that's the down side.
11:20
but we always have huge differences in debian/control anyways, even in dependencies
11:20
<ogra-classmate>
and you restrict users to the deps indeed
11:21
<vagrantc>
until i split out ltsp-client-core
11:21
<ogra-classmate>
setting EARLY_PACKAGES wont help if its all deps
11:21
<vagrantc>
EARLY_PACKAGES="ltsp-client-core FOO BAR BAZ"
11:21
<ogra-classmate>
hmm
11:21
<vagrantc>
but ltsp-client should have the dependencies for everything we really want.
11:22
<ogra-classmate>
right
11:22
ok
11:22
<vagrantc>
ogra-classmate: sound good ?
11:23
<ogra-classmate>
yup
11:23
lets do it :)
11:23* vagrantc runs with it
11:23nf1 has joined #ltsp
11:24
<ogra-classmate>
i wonder how to replace the mainline branch with your merged one without having to merge everything again
11:24
<vagrantc>
ogra-classmate: you might be able to just pull
11:24
<ogra-classmate>
bzr should have a --wipe-old-crap option :/
11:24
<vagrantc>
heh
11:25
vagrant-ltsp-mainline is derived from you ltsp-mainline branch ... + feisty + pkg-ltsp main + a few other patches
11:25
<ogra-classmate>
hmm
11:25
i wonder how well even mainline and feisty go
11:26
<vagrantc>
most of feisty's changes seemed appropriate to me.
11:27
<ogra-classmate>
indeed
11:27
<vagrantc>
though i didn't look at them incrementally
11:27
<ogra-classmate>
i mean merge wise
11:28
<vagrantc>
hmmm... don't understand
11:28
<ogra-classmate>
i'm not sure these two merge properly
11:29
<vagrantc>
well, i already merged them.
11:29
<ogra-classmate>
you merged all branches, didnt you ?
11:29
<vagrantc>
yes.
11:29
<ogra-classmate>
i only want to see the two and see what breaks :)
11:30
<vagrantc>
ltsp-mainline + ogra's feisty + pkg-ltsp main
11:30
<ogra-classmate>
just out of curiosity
11:30
<vagrantc>
heh
11:30
ok. just know i've already worked it out :)
11:30
<ogra-classmate>
indeed, i planned to replace the mainline branch with yours
11:30
<vagrantc>
we really need to figure out how to do this more incrementally in the future
11:31
<ogra-classmate>
i also need to put the mainline one under team maintenance, so all ltsp team members have submit permission
11:31
/ltsp/ltsp-drivers/
11:32* vagrantc doesn't know how to drive
11:32
<ogra-classmate>
well, you are in the drivers team, arent you ?
11:32
since sevilla at least
11:32
<vagrantc>
yeah. the team name just sounds weird.
11:32
<ogra-classmate>
heh
11:32
<vagrantc>
my login name seems stupid, too.
11:32
vagrant+ubuntu
11:33
<ogra-classmate>
we're the steering comitee
11:33
so we drive :)
11:34
hmm, that ce-linux forum i'm just reading has intresting stuff
11:34* ogra-classmate should look more in the embedded world
11:34
<ogra-classmate>
*into
11:35
http://tree.celinuxforum.org/CelfPubWiki/BootupTimeResources
11:35
*g*
11:36
lots and lots of directions to look in
11:40
<vagrantc>
pkg-ltsp-devel doesn't like me.
11:40
sometimes it randomly stalls my messages from 0.5-4 days
11:43
<ogra-classmate>
bah
11:51
http://tree.celinuxforum.org/CelfPubWiki/ThreadedDeviceProbing
11:51
that would solve all our udev related slowdowns in one hit
12:04
<vagrantc>
400 milliseconds ... 0.4 seconds ?
12:08
ogra-classmate: you know ....
12:09
ogra-classmate: we could generate the control file dependencies at build time.
12:09
ogra-classmate: and use a variable.
12:11Q-FUNK has joined #ltsp
12:15Q-FUNK has quit IRC
12:17Q-FUNK has joined #ltsp
12:25
<ogra-classmate>
vagrantc: i see about 40-50 seconds on the e2300 for the device detection
12:25
and i guess it would drop to 10-20 secs
12:25
<jammcq>
wow
12:25
did you have a chance to try a different scheduler yet?
12:25
<vagrantc>
nice
12:25* jammcq was gone doing household chores
12:26
<ogra-classmate>
jammcq: no, i'm doing still classmate stuff, but stumbeling upon things i note down for ltsp testing
12:26
these embedded linux guzs have a lot of intresting things to try out :)
12:26
*guys
12:26
<jammcq>
it would be way cool, if we could provide "profiles" for various thin clients
12:26
<ogra-classmate>
yeah
12:27
that should be trivial through readahead for the more beefy ones alraedy
12:27
<jammcq>
oh?
12:27
<ogra-classmate>
for the small ones we need a special mode
12:27
never tried booting with 'profile' ?
12:27
it will speed up your boot a lot
12:28
the profile commandline tells your system to create two readahead tables for stuff that gets preloaded ti ram at start
12:28
<jammcq>
I was using the word "profile" as something I thought would be cool to have. Are you saying there's already something called "profile" ?
12:28
<ogra-classmate>
one for boot and one for desktop related preloading
12:29
there is a profiling mode for readahead, yes
12:29
we can use it for the clients where we have enough power for using readahead
12:29
<jammcq>
ah
12:29
<ogra-classmate>
(its really only helpful with much ram)
12:30
<jammcq>
for those that don't, it would be nice if we could have a set of pre-defined configurations, sort of like we can do with Xorg.conf
12:30
<ogra-classmate>
readahead will then run as the first initscript and preoad everything needed to boot into ram
12:30
<jammcq>
but it's still auto-detecting hardware, eh?
12:30
<ogra-classmate>
jammcq: right, that would be my choice if we dont get any improvenments going in udev, using fixed module set files
12:31
<jammcq>
yeah, exactly
12:31
<ogra-classmate>
but i still belive we can make udev behave better
12:31
<jammcq>
then, provide an easy way for users to create their own profiles
12:31
<ogra-classmate>
on the classmate using a modules file for initramfs got me nearly 15secs
12:32
<jammcq>
does the modules file get read before udev kicks in?
12:32
<ogra-classmate>
jammcq: nope ... make hthat automated ;) the first time a client boots it creates a profile and marks it with its MAC
12:32
<jammcq>
but where does that profile get created ?
12:32
<ogra-classmate>
every subsequent boot it will read that profile first
12:32
on teh server somehow
12:33
no idea, was just a falshing idea
12:33
<jammcq>
oh, "somehow" means still needs to be developed.
12:33
<ogra-classmate>
*flashing
12:33
indeed
12:33
<jammcq>
it's a good plan
12:33
<ogra-classmate>
it needs to end up in the chroot
12:33
<vagrantc>
wouldn't it actually need to end up in the initramfs ?
12:33
<ogra-classmate>
surely nothing for gutsy, but something to keep in mi9nd for later and to spoec properly
12:33
vagrantc: depends :)
12:34
initramfs needs to know it ... that doesnt essentially mean it needs to be in there
12:34
<jammcq>
does all of the hardware detection take place in initramfs? or does some happen after nfsroot is mounted?
12:34* ogra-classmate has *lots* of fun with initramfs and casper for the classmate, i'm really looking forward to do more for ltsp later
12:35
<ogra-classmate>
its about 50/50
12:35
parts go on in initramfs (up to the extend of the shipped modules i.e. in netboot mode you only have input and NIC drivers)
12:35
and the rest runs in init
12:36
the part in the initscript is the slow part
12:36
it probes every device with the complete set of available modules for that device class
12:37
but we can work around that by just making the boot ignore that the udevsettle script exists
12:37
\i already have plans for that
12:37
its a good workaround for gutsy ... for gutsy=1 we should talk with baenc about this patch for an -ltsp kernel: http://lwn.net/Articles/192851/
12:38
*gutsy+1
12:38
<vagrantc>
ogra-classmate: what phase is gutsy in right now ... everything basically synced with debian ?
12:38
<ogra-classmate>
*BenC
12:38
vagrantc: supposed to by end of next week iirc
13:03nf1_ has joined #ltsp
13:03nf1 has quit IRC
13:14lambda has joined #ltsp
13:23sepski has joined #ltsp
13:24PMantis has joined #LTSP
13:33gepatino has joined #ltsp
13:34Egyptian[Home] has joined #ltsp
13:47gepatino has quit IRC
13:54
<vagrantc>
ogra-classmate: so ... what do you think about enabling localdev and sound if the appropriate binaries are found?
13:55
ogra-classmate: and only requiring a configuration option to disable them?
13:55
or other people's thoughts, too
13:55
:)
13:56Egyptian[Home] has quit IRC
13:56
<vagrantc>
ogra-classmate: ditto for X :)
13:58
<dberkholz>
i agree that autodetecting and enabling useful things by default is nice, as long as there's a way to stop it
13:58
<vagrantc>
yeah.
13:58
that's basically what i'm proposing
13:59
<dberkholz>
is there any situation where autodetection could fail but you would still want to force the option on?
13:59
like the binaries show up later for some reason
14:00
<nf1_>
vagrantc, I think the idea is good too
14:01
<vagrantc>
dberkholz: there's nothing in my proposal that prevents that
14:01privet has joined #ltsp
14:01
<vagrantc>
though technically, it might be tricky to actually implement
14:01
<dberkholz>
i'm suggesting more that it could be so unlikely that it's not worth allowing
14:02
<vagrantc>
the autodetection i'm proposing is simply checking if the binaries are available ... i.e. /usr/bin/ltspfsd, /usr/bin/pulseaudio, etc.
14:02
<nf1_>
after all if somebody have any hardware he probably would want to use it right away
14:02
<vagrantc>
and i'm only proposing modifying the init scripts, so it would only be at boot time.
14:03
<dberkholz>
any thoughts on modular init scripts?
14:03
<vagrantc>
ltspfs already detects insertion of new hardware, i'm merely proposing to check weather or not ltspfs is available before starting it
14:04
dberkholz: i've thought about it on many occasions, and wrote a crude modularized implementation even
14:05
<dberkholz>
hm, i really need to get the basic stuff working so i can play around more.
14:05
<vagrantc>
dberkholz: bzr branch: http://llama.freegeek.org/~vagrant/bzr/ltsp/features/vagrant-ltsp-initscripts
14:05
it's a really old branch not worth merging, but it demonstrates the concept, i think.
14:06
dberkholz: it essetially splits it up much like the ltsp-build-client plugins
14:07
dberkholz: i'm not sure it's the best way to go with init scripts ...
14:07
<dberkholz>
i have a feeling it could be more useful in testing and development than in actual use
14:08
<vagrantc>
like, maybe each feature should be a script that gets called/sourced into the init script, but the order is dependent on the distro.
14:08
<dberkholz>
say you just want to restart foo, without rebooting the node or whatever
14:08
<vagrantc>
dberkholz: my main purpose is for multiple distros to share code
14:08
that's more a side-effect
14:08
<dberkholz>
yes, that's clearly desirable
14:09
<vagrantc>
since there's so many init systems around ... having helper scripts would seem the easiest way to plug into different init systems but still share code
14:11
<jammcq>
dberkholz: any modularization that potentially slows down the boot should be looked at very closely, to see if it's really worth it
14:11
<vagrantc>
yes, that's the other concern.
14:12
<dberkholz>
yes, that's a good point
14:12
does debian/etc calculate boot order in advance or does it happen every boot?
14:12* jammcq likes sourcing additional files, vs spawning sub-shells to run them.
14:12
<vagrantc>
jammcq: do you think sourcing 16 small files would be a significant hit?
14:12
<nf1_>
well if it's init script it could be there or not, so everyone will have a choice to run it or not
14:12
<jammcq>
vagrantc: my gut feeling is yes, it would be significant
14:12
<dberkholz>
jammcq: but it could also increase boot speed for people who want to leave out particular features
14:12
<jammcq>
but if someone proves me wrong, that's fine by me
14:13
<vagrantc>
jammcq: that's the degree of modularization in my quick implementation
14:13
<jammcq>
dberkholz: most of my installs have various types of thin clients doing various things, so enabling/disabling is done via setting options, rather than scripts existing or NOT existing
14:13
<vagrantc>
ah yes, that's a nice side-effect ... not need to source the script if the feature isn't enabled
14:14
yeah
14:14
i think we should definitely have it be a "feature enabled -> source relevent code" type of thing
14:16
jammcq: so ... what are all the optional features in ltsp ... sound, localdev, and i would even go so far as to say X :)
14:16
jammcq: any others come to mind?
14:17
<jammcq>
vagrantc: something that I need before using ltsp-5 at a customer site is scanner
14:17pimpministerp has joined #ltsp
14:18
<vagrantc>
jammcq: hrm. well... that's another issue ... :)
14:18
<jammcq>
yeah, that's hugely important to me
14:18
<dberkholz>
i am curious whether that will help. does bash/dash/etc take longer to parse a longer script containing code that's never run?
14:18
<vagrantc>
jammcq: worked in ltsp 4.x ?
14:18
<jammcq>
u betcha
14:18
works beautifully
14:19
<vagrantc>
jammcq: how do you do it?
14:19
<jammcq>
ltsp-sane
14:19* vagrantc remembers playing with (in)sane
14:20
<PMantis>
lol
14:20
jammcq: Of course, there could be the clients needing sane that boot LTSP 4.2, and the other booting 5... but that's messy.
14:21
<vagrantc>
jammcq: is there still time to propose a spec ?
14:21
<jammcq>
umm
14:21
prolly
14:21
<vagrantc>
or does it count as 4.x -> 5.x migration?
14:21
<jammcq>
i'm thinking it shouldn't be hard to just apt-get install sane
14:21
and have it work, with very little effort
14:22
<PMantis>
Within the thin client chroot?
14:23* PMantis is curious about the Ubuntu 7.04 LTSP implementation.
14:24
<vagrantc>
jammcq: is that all there is to it? http://wiki.ltsp.org/twiki/bin/view/Ltsp/Scanners
14:24
in theory...
14:25
<jammcq>
vagrantc: pretty much, I think. you just edit the saned.conf file, and run saned as a service
14:25
<vagrantc>
jammcq: so, being that i don't have a scanner ... think you could try it out? :)
14:26
jammcq: if you can give me step-by-step manual instructions, i'magine i could write a script
14:26
<jammcq>
I have a scanner at the office, but not here at home
14:26
i'm not sure it even needs a script
14:27
<vagrantc>
it could just happen out of the ether?
14:27
<jammcq>
we have a script for ltsp-4.2, cuz we don't use the normal init scripts
14:27
but for debian/ubuntu, I'd imagine it would just install the init script, and away you go
14:28
<vagrantc>
well ... then you can't control it on a per-machine basis
14:28
<jammcq>
ummm, yeah, that's a problem
14:28
that's another reason why we wrote a script :)
14:28
<dberkholz>
detect the hardware?
14:29
<jammcq>
dberkholz: well, it's tricky, cuz there's so many different kinds of scanners, and you prolly want to configure the type of scanner you are using
14:29
it supports parallel, scsi, usb
14:29
<dberkholz>
if udev works properly, they oughta show up at /dev/scanner. or could be changed so they do
14:31
<PMantis>
udev on the client could signal something on the server to modify saned.conf
14:31
<jammcq>
there's a dll.conf file for saned, that has a list of all of the scanner drivers. there's about 70 different drivers. it's best to comment out the ones you know you don't have
14:31
these aren't kernel modules, they are userspace drivers
14:31
so udev may or may not help here
14:32
at my big customer, I have fujitsu and plustek scanners, so I have only those 2 modules un-commented
14:32
then, saned attempts to load each of them, succeeding only on the one that matches the actual hardware
14:32
<vagrantc>
jammcq: is it a one-driver-per-line sort of file?
14:32
<jammcq>
I don't have a mechanism for saying ws001 has a fujitsu, and ws002 has a plustek
14:33
yeah:
14:33
# enable the next line if you want to allow access through the network:
14:33
fujitsu
14:33
plustek
14:33
#net
14:33
#abaton
14:33primeministerp has quit IRC
14:33
<jammcq>
ignore that 1st comment line
14:33
its' for the '#net' line
14:33
i'm running saned out of xinetd
14:34
<vagrantc>
so we could do something like SANE_DRIVERS="foo bar baz" and then code that does echo > sane.driver.conf ; for d in $SANE_DRIVERS ; echo $d >> sane.driver.conf ; done
14:34
<jammcq>
like this:
14:34
XINETD_SERVICES = "saned"
14:34
yeah, we could build the dll.conf file on the fly, from an entry in lts.conf
14:34
and if there's no entry, don't start saned at all
14:35
that'd be better than what ltsp-4.2 does
14:35* vagrantc wonders how complicated the sane init script is
14:35
<jammcq>
i'm not sure there is an init script. it might be that it runs as a service from [x]inetd
14:35
lemme check
14:36
<vagrantc>
hrm.
14:38
<jammcq>
yeah, I just installed sane-utils on my fiesty box, and it doesn't install an init script
14:38
it doesn't update inetd.conf either
14:39
<vagrantc>
fiesty
14:39
<jammcq>
yeah
14:39highvoltage has quit IRC
14:39highvoltage has joined #ltsp
14:40
<dberkholz>
oh, in gentoo we just build the drivers we need so that's not really an issue
14:40
<vagrantc>
build the drivers you need ?
14:41
for sane ?
14:41
<dberkholz>
yeah
14:41
<vagrantc>
so if someone comes along with a driver you didn't previously include, you'd just re-build ?
14:43* jammcq thinks gentoo should compile at boot time, for ultimate performance :)
14:45
<vagrantc>
yeah, show the world what gentoo is made of.
14:46
ogra-classmate: ltsp-client most certainly does not replace ltsp-utils :P
14:48
ogra-classmate: i think you missed.
14:48nf1_ has quit IRC
14:49* PMantis contemplates which was first: compiled code or the compiler
14:49nf1 has joined #ltsp
14:49
<vagrantc>
ogra-classmate: oh, you're free from blame. apparently it was added by mdz
14:50
<dberkholz>
vagrantc: if there was a new scanner added to the system? yeah, we'd rebuild sane-backends for it. it's an option to just build all the drivers too, if you don't want to deal with that
14:54
<vagrantc>
alright folks. off to eat.
14:54vagrantc has quit IRC
14:58muh2000 has quit IRC
15:17Burgundavia has joined #ltsp
15:37vagrantc has joined #ltsp
15:42bronze has quit IRC
16:02
<vagrantc>
ogra-classmate: sounds like nbd timeout is totally useless ... it times out even when the device is accessed regularly, according to sep
16:02
er, sepski
16:02
<Burgundavia>
hey vagrantc
16:02* vagrantc doesn't really know the difference :)
16:02
<sepski>
vagrantc, both !
16:02
sepski = at home, sep = at work
16:02
<vagrantc>
Burgundavia: hey.
16:28sepski has quit IRC
16:42Q-FUNK has quit IRC
16:50Q-FUNK has joined #ltsp
16:51stillflame has joined #ltsp
17:15Q-FUNK has quit IRC
17:19maaarek has quit IRC
17:38cliebow has quit IRC
17:39cliebow has joined #ltsp
17:44vagrantc has quit IRC
17:46gepatino has joined #ltsp
18:07
<PMantis>
Would anyone here mind commenting on my server's booting issue? http://pastebin.ca/514845 #ubuntu is almost useless
18:08cliebow has quit IRC
18:13cliebow has joined #ltsp
18:14bronze has joined #ltsp
18:24lambda has quit IRC
18:33cliebow has quit IRC
19:06gepatino has quit IRC
19:47
<PMantis>
To convert my sever from LTSP 4.2 to Ubuntu 7.04 LTSP-5 (MueCow)... I simply rename /opt/ltsp and install ltsp-server... right?
19:48
<jammcq>
yeah, the cross your fingers :)
19:48
<PMantis>
heh
19:48
<jammcq>
there's a few manual adjustments you'll need to do
19:48
<PMantis>
I'm sure
19:48
<jammcq>
like your tftpd is prolly pointing to /tftpboot, instead of /var/lib/tftpboot
19:48
<PMantis>
pxe
19:48
tftp
19:48
Yeah
19:48
<jammcq>
and your dhcpd will need to be adjusted
19:48
<PMantis>
nbd
19:50
oh, and ltsp-build-client
19:57sahil has joined #ltsp
19:59J45p3r has joined #ltsp
20:20
<sahil>
i keep getting a dhcpd self test failed in ubuntu does anyone have a working dhcpd.conf i could use?
20:23
or how can i resolve this as im not getting any indication as to why it failed
20:24
<jammcq>
where are you seeing that message?
20:24
<sahil>
after i do /etc/init.d/dhcp3-server start
20:24
<jammcq>
on the screen? in a logfile? "where" ?
20:25
<sahil>
jammcq: also do you have any knowledge of those ewayco clients? th t-40 i tried to get them to boot
20:25
in the terminal
20:25
<jammcq>
on the thin client?
20:25
<sahil>
no on the server
20:25
<jammcq>
well, first thing I'd do is go look in /var/log/daemon.log
20:25
<sahil>
its asking me to fix the config but im using the config i had from a working gentoo one
20:25
<jammcq>
see if there's any clues there
20:26
what version of ltsp?
20:26
<sahil>
4.2
20:26
<jammcq>
there's plenty of examples on the ltsp wiki
20:27
<sahil>
theres nothing in the log...yeah ill check them out
20:28
any thoughts on the eway clients? they got as far as trying to start x but it kept failing i tried everything even vesa and no go
20:28
<jammcq>
and the error message is saying "self test failed" ? I've never seen that error out of dhcpd
20:28
dunno about the eway's
20:30
<sahil>
its dhcp3-server does that matter?
20:30
<jammcq>
no
20:30
that's the one you want
20:31
<sahil>
in the wiki it says buggy dhcp3 server
20:31
and im getting the no leases message in the log
20:32
<jammcq>
no, it doesn't say 'buggy'. it says there's an issue that might be considered a bug, but that's not causing your problem
20:32
how about you paste your dhcpd.conf file to the pastebot?
20:33
"buggy" makes it sound like it's riddled with bugs
20:33
<PMantis>
jammcq: BTW...
20:33
# ltsp-update-kernels
20:33
Updating /var/lib/tftpboot directories for chroot: /opt/ltsp/i386
20:33
Updating /tftpboot directories for chroot: /opt/ltsp/i386
20:33* jammcq wonders why PMantis is showing me that
20:33
<PMantis>
it did both... :)
20:33
<jammcq>
oh
20:33
yeah
20:33
taht's actually a patch that I provided
20:34
whichever locations exist get updated
20:35
<PMantis>
heh nice
20:35
Mine happens to be a symlink. so, updating one, updates the other anyhow. :)
20:40
<sahil>
jammcq: i see now i think when i simply run dhcpd3 it says no subnet declaration for eth0
20:40
that could be the problem?
20:40
<jammcq>
which interface are you trying to use?
20:40sbalneav has joined #ltsp
20:40
<sahil>
eth0
20:40
<jammcq>
!s
20:40
<ltspbot`>
jammcq: "s" is Scotty!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
20:40
<sbalneav>
Evening all
20:40
<jammcq>
well, then yeah, it is a problem
20:40
<sbalneav>
Evening jammcq
20:41
<sahil>
haha aright how do i go about defining that and with what?
20:41
<jammcq>
sahil: man dhcpd.conf
20:41
or run ltspcfg and let it create a dhcpd.conf file for you
20:42
<sahil>
i did that and i guess it had some issues
20:42
<jammcq>
so, I asked you to paste your dhcpd.conf file to the pastebot, did you ?
20:42
<sahil>
doing it now
20:46
<PMantis>
Hmmm, ltsp-update-kernels doesn't seem to support etherboot
20:46
<jammcq>
it does, if you have mknbi installed
20:47
<sahil>
http://pastebin.ca/515104 ltspcfg dhcpd.conf, http://pastebin.ca/515106 my dhcpd.conf
20:48
<PMantis>
I'll try that. :)
20:48
<jammcq>
sahil: what's the IP address of your eth0 ?
20:48
<PMantis>
jammcq: would I have to build the client over again?
20:49
<jammcq>
no
20:49
<PMantis>
ltsp-build-client
20:49
<sahil>
169.254.3.14
20:49
<jammcq>
just run ltsp-update-kernels again
20:49
sahil: did you set that up?
20:49
<sahil>
but in ubuntu it lists my interface as eth0:avah for some reason
20:49
<jammcq>
your network isn't setup properly
20:50
169.254.x.x is the 'zero-conf' address
20:50
<PMantis>
Ohhh nbi.img
20:50
<jammcq>
you don't want to do that
20:51
<sahil>
i want it to be using eth0 plain...?
20:51
<jammcq>
yeah
20:52
<sahil>
sorry to be so dumb but how?
20:53
<jammcq>
you need to edit your /etc/network/interfaces file
20:53
setup an entry for eth0, and remove any other mention of eth0 in that file
20:53
<sahil>
and set it an ip and repeat that in dhcpd.conf?
20:54
<jammcq>
well, pick yourself a reasonable IP address for that interface, and be consistent in your dhcpd, /etc/exports, /opt/ltsp/i386/etc/lts.conf files
20:54
set it something like this:
20:54
iface eth0 inet static address 192.168.0.254 netmask 255.255.255.0
20:54
err
20:54
that would be:
20:54
iface eth0 inet static
20:55
address 192.168.0.254
20:55
network 255.255.255.0
21:00
<sahil>
works!, thanks jammcq ill send you a cake
21:00
<jammcq>
heh
21:02
<PMantis>
Hmmm, client booting... keeps running nfs-premount in a loop. "nfsmount: need a path"
21:02
<jammcq>
PMantis: fix your root-path. ltsp-5 doesn't support the IP address being in the root-path
21:05
<PMantis>
Ahh, rebooting... simple dhcp restart froze client
21:07
Cool, client logged in ok.
21:07
much slower that 4.2 though.
21:07
<jammcq>
yep :(
21:12
<PMantis>
Man, 4.2 screams. 5 is neat for local sound a dev out of the box and the integration, but... apps seem to be slower, too.
21:13
errr local sound AND dev
21:13
<jammcq>
they are slower, cuz you are running X through SSH
21:14
<PMantis>
Yeah, realize that... does sound/ltspfs go through ssh as well?
21:14
<jammcq>
sort of. control information goes through ssh, but the data stream doesn't
21:15
<Bill_c_>
hey kids
21:15
<jammcq>
you can switch your X to use xdmcp, but then you'll lose audio and localdevs
21:15
Bill_c_: WHOA !!!!
21:15ogra-classmate has quit IRC
21:15Bill_c_ is now known as bill_c
21:15
<bill_c>
:)
21:15
<PMantis>
Hi there
21:15
<jammcq>
bill_c: where you been dude?
21:16
<PMantis>
This is like old times
21:16
<bill_c>
insanely busy
21:16* PMantis understands that
21:17
<bill_c>
been liking ltsp 5 in ubuntu, very cool
21:17
<PMantis>
Anyone know if dhcpd.conf can use a "like" keyword, like lts.conf can?
21:17
<jammcq>
cool. you moving away from Suse ?
21:17
PMantis: nope, it can't
21:18
<bill_c>
jammcq, yeah, using rpath and ubuntu a lot
21:18
<PMantis>
Hmmm, opportunity for a patch. :)
21:18
<jammcq>
wow, cool
21:18
<PMantis>
rpath?
21:18
<jammcq>
those rpath guys are pretty sharp
21:18
I know a few of them, ex-redhat guys
21:19
<bill_c>
yeah we are really excited about it, spent past month getting it ready
21:19
would like to get a rpath muecow project going
21:20
muekow even
21:20J45p3r has quit IRC
21:20
<PMantis>
rpath is a distro, or software appliance... ?
21:21
<jammcq>
yes, it's also a dessert topping
21:21
<bill_c>
mmm
21:21
<PMantis>
lol
21:21
<bill_c>
PMantis, yeah its pretty neat, I build a package list, and it fills in just what you need for your packages to run
21:22
created a little script that I run at tty1, so users don't really see the console, just a few trouble shooting menu items
21:23
<PMantis>
Eh, I'm putting my wife's client back to 4.2
21:23ogra has quit IRC
21:23
<PMantis>
oops, ticked him off.
21:23
he
21:23
<jammcq>
heh
21:24
<bill_c>
I like how easy it is to run something local now
21:24
<jammcq>
yeah, just mention that ltsp-4.2 is faster than ltsp-5.0, and some people get angry
21:24ogra has joined #ltsp
21:24
<jammcq>
but, he doesn't stay angry :)
21:26
<bill_c>
with the ubuntu muekow, was a lot of the work getting the packages able to work in the chroot, or was it getting the package mgmnt system to work in it>
21:27
<jammcq>
umm
21:27
I don't think it took much for the package mgmt part
21:27
it's mostly getting the startup scripts to only start what's needed for a thin client
21:30
<bill_c>
cool, I'll give that a shot then
21:32
ok I gotta take family to pirates or wife will make me sleep in office again :)
21:32
<jammcq>
heh
21:32
come back again soon
21:37
<sahil>
jammcq: you still around
21:38
<jammcq>
that depends
21:38
<sahil>
heh im getting tftp access violation errors
21:38
<jammcq>
do this: grep tftp /etc/inetd.conf
21:38
show me what it says
21:39
<sahil>
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /srv/tftp
21:39
<jammcq>
ok, chances are, the /srv/tftp is wrong
21:40
where are your kernels ?
21:40
typically, on ubuntu, they are in /var/lib/tftpboot
21:40
<sahil>
ah i put them in /tftpboot manually
21:41
tftpboot/lts rather
21:41
<jammcq>
well, you have an inconstency
21:41
tftpd wants it to be in /srv/tftp
21:41
<sahil>
theres no var/lib/tftboot/
21:42
<jammcq>
which tftpd did you install?
21:42
<PMantis>
How difficult would it be to convert LTSP-5 to use its own DM?
21:42
local DM
21:43
<sahil>
jammcq: 0.17-15ubuntu1
21:43
<jammcq>
PMantis: well, the big problem to overcome, is the thin client doesn't know anything about users
21:43
sahil: what is '0.17-15ubuntu1' ?
21:43
<sbalneav>
PMantis: I'm working on rewriting the LDM in C now, as we speak.
21:43
<sahil>
tftpd
21:44
<PMantis>
sbalneav: What's it written in now?
21:44
<sbalneav>
Currently, it's in python.
21:44
<jammcq>
sahil: yeah, but which one? tftpd, tftpd-hpa, atftpd ?
21:44
<sahil>
tftpd
21:44
<jammcq>
that's the wrong one
21:44
<sahil>
ah
21:45
<jammcq>
you should be using tftpd-hpa
21:45
<sahil>
consider it done
21:45
<jammcq>
installing that should create the /var/lib/tftpboot directory
21:46
<sahil>
that it did
21:46
if i run ltspcfg it says that tftpd has been configured already do i need to change anything with regards to that?
21:47
<jammcq>
yeah, you'll need the tftp entry in /etc/inetd.conf to point to /tftpboot/lts
21:47
<PMantis>
sbalneav: c will certainly be faster than python
21:47
<sahil>
instead of /var/lib/tftpboot?
21:47
<jammcq>
sahil: you are running ltsp-4.2, might as well stick to /tftpboot/lts
21:48
<sahil>
the bin is the same?
21:48
<jammcq>
huh?
21:48
<sahil>
/usr/bin/in.tftpd
21:48
<jammcq>
yeah, the pathname is the same
21:49
<dberkholz>
any reason you guys aren't recommending dnsmasq yet?
21:49
<jammcq>
ummm, cuz we like dhcpd maybe
21:50
<dberkholz>
dns + dhcp + tftp all in one beautiful, easy to configure, small package
21:50
i'm totally going that way for ltsp5 gentoo
21:50
<jammcq>
but what if someone already has dns configured on their server?
21:50
or dhcpd
21:51
<dberkholz>
they can feel free to use that instead. but it won't be the default option
21:51
<jammcq>
choice of dns,dhcpd,tftp vs dnsmasq isn't an LTSP decision
21:51
<dberkholz>
our docs will recommend dnsmasq
21:51* PMantis shudders at the thought of a Gentoo based ltsp-build-client
21:51
<sahil>
jammcq:tftp open timeout now
21:51* sahil gets a boner at the thought of a Gentoo based ltsp-build-client
21:51
<dberkholz>
and that's what our ltsp metapackage will pull by default
21:52
PMantis: why shudder?
21:52
PMantis: for the most part, it'll just be transferring binary packages from the server to the client root
21:52
except for a few client-specific thingies
21:53
<jammcq>
dberkholz: how you gonna handle a glibc built for a 686, when the client is a 586 ?
21:54
<dberkholz>
the binary transfer will just be the default
21:54
people can replace it with a client-specific make.conf with more generic build flags
21:54
<jammcq>
you gonna provide the client-specific make.conf ?
21:54
<dberkholz>
haven't entirely figured that out yet
21:54
<jammcq>
you'll need to
21:54
<dberkholz>
yeah, i know
21:55
<jammcq>
there's TONS of thin clients out there that can't run 686 binaries
21:55
<PMantis>
yeah
21:55
Especially since there's peopls recycling computers by making them thin clients.
21:55
<dberkholz>
that part will be the same as any other cross-arch thing, i'm thinking
21:56
686->586 can be handled the same as 686->ppc
21:56
<jammcq>
well, as long as its handled
21:56
<dberkholz>
my initial plan is to get the simple case running while keeping more complex cases in mind
21:57
it's just the implementation that keeps not happening =D
21:57
<jammcq>
not handling 486 and 586 will make gentoo very un-popular in the ltsp world
21:57
<dberkholz>
people are still using 486?
21:57
<jammcq>
well, there's some geode based thin clients that aren't exactly 586
21:57
<PMantis>
586 is by far the most popular thin client arch, I whould think
21:58
<dberkholz>
i thought at least newer geodes were 686+mmx
21:59
but the limit of my knowledge there is from eavesdropping on olpc
21:59
but there's those not quite 686 via's too..
22:00
anyhow, i'm keeping non-686 clients in mind
22:00
<sahil>
jammcq: in case you missed it tftp open timeout now i checked to see what that was
22:01
and it simply said to check if it was running which it is i believe
22:01
<jammcq>
sahil: look in /var/log/daemon.log for clues. Also, try: netstat -anp | grep ":69 "
22:01
see what it returns
22:03
<sahil>
udp 0 0 0.0.0.0:69 0.0.0.0:* 5220/inetd
22:03
output of netstat
22:04
cannot set groups for user nobody
22:06
<jammcq>
ah
22:06
change your tftp entry in /etc/inetd.conf to be this:
22:07
tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot
22:07
adjust that last paramter to be /tftpboot/lts
22:13
<sahil>
jammcq:still timeout
22:13
<PMantis>
Whats the SCREEN sdm option in ltsp 5?
22:13
<jammcq>
sdm ?
22:14
sahil: did you restart inetd ?
22:14
<sahil>
heh just realized i didn't and did
22:14
<PMantis>
possible values: ldm, sdm, shell, startx, telnet
22:14
<jammcq>
sdm is an old display manager sort of like ldm, it's from debian
22:15
<PMantis>
ahh
22:17
<sahil>
jammcq: file not found now but its def in tftpboot/lts
22:18
<jammcq>
what does your filename entry in dhcpd.conf say?
22:18
<sahil>
vmlinuz-2.6.17.8-ltsp-1
22:18
<jammcq>
that's all?
22:18
<sahil>
yeah
22:18
<jammcq>
or does it say '/tftpboot/lts/vmlinuz-2.6.17.8-ltsp-1' ?
22:18
<PMantis>
wow, I didn't know vi would directly read a gz file... :-)
22:18
<sahil>
it says /lts/vmzlinuz...
22:19
i thought since it has the -s option
22:19
<jammcq>
sahil: well, what's the last paramter you have on the tftp line in /etc/inetd.conf ?
22:19
btw, when I ask what 'filename' says, I really need to know EXACTLY what it says
22:19
not some approximation
22:20
<sahil>
/tftpboot/lts
22:20
<jammcq>
ok, so what happens, is it's looking for: /tftpboot/lts/lts/vmlinuz.....
22:20
see the problem?
22:20
<sahil>
ah yes cause i specified /lts in inetd
22:21
i see
22:28
jammcq:still file not found
22:28
<jammcq>
which did you change?
22:29
<sahil>
i changed the line in dhcpd.conf to read filename "/vmzlinuz-2.6.17.8-ltsp-1"
22:30
<jammcq>
ok, you spelled it wrong
22:30
it's not 'vmz, it's 'vm'
22:30
vmlinuz-2.6.17.8-ltsp-1
22:30
<sahil>
i typed it wrong sorry
22:30
it says vmlinuz
22:30
<jammcq>
and you restarted dhcpd ?
22:30
<sahil>
yes
22:31
uh well i restarted the computer because dhcpd self test failed error comes up again
22:32
<jammcq>
please check that error, I don't believe it says 'self test failed'
22:32
<sahil>
dhcpd self-test failed. Please fix the config file.
22:32
The error was:
22:32
dhcpd self-test failed. Please fix the config file.
22:32
The error was:
22:33
<jammcq>
hmm
22:33
sounds like a syntax error
22:33
what's in /var/log/daemon.log?
22:38
<sahil>
dhcpdiscover from macaddressofclient via eth0/dhcpoffer on 192.168.0.50 to (macaddressofclient) via eth0/dhcprequest 192.168.0.50 (192.168.0.254) from (mac) via eth0/DHCPACK on 192.168.0.50 to (mac) via eth0
22:39
<jammcq>
so dhcpd started. I thought you said you had an error?
22:39
<sahil>
when i do /etc/init.d/dhcp3-server restart it gives an error
22:39
i restarted the computer though
22:40
<jammcq>
well, you have a syntax error in your dhcpd.conf file
22:40
try this:
22:40
/usr/sbin/dhcpd3 -t -cf /etc/dhcpd.conf
22:40
and see what it says
22:41spectra has quit IRC
22:42
<sahil>
Internet Systems Consortium DHCP Server V3.0.4
22:42
Copyright 2004-2006 Internet Systems Consortium.
22:42
All rights reserved.
22:42
For info, please visit http://www.isc.org/sw/dhcp/
22:42
<jammcq>
that's it?
22:43
<sahil>
yes
22:43
/etc/dhcp3/dhcpd.conf instead of just /etc?
22:43
<jammcq>
where is your dhcpd.conf file, in /etc, /etc/dhcpd or /etc/ltsp/dhcpd.conf ?
22:43
<sahil>
i seem to have two
22:43
how do i tell which its using?
22:44
<jammcq>
do you have one in /etc/ltsp ?
22:44
<sahil>
checking
22:45
there is no /etc/ltsp
22:45
<jammcq>
ok, then it's using /etc/dhcp3/dhcpd.conf
22:45
so try running dhcpd3 -t -cf on that one
22:46
<sahil>
same thing as above
22:47
<jammcq>
do this: grep filename /etc/dhcp3/dhcpd.conf
22:48
show me the results
22:49
<sahil>
<jammcq> do this: grep filename /etc/dhcp3/dhcpd.conf
22:49
<jammcq> show me the results
22:49
<PMantis>
heeh
22:50
<sahil>
filename "/pxe/eb-5.0.9-rtl8139.lzpxe";
22:50
filename "/vmlinuz-2.6.17.8-ltsp-1";
22:50
<jammcq>
ah, so which one is it trying to use?
22:51
how ar eyou booting, with PXE or with Etherboot ?
22:51
<sahil>
thats in an if else if statement
22:51
pxe
22:51
<jammcq>
so it's gonna use '/pxe/eb....'
22:51
<sahil>
i can pastebin the dhcpd.conf
22:51
<jammcq>
yeah, do that
22:52
are you booting from a floppy ?
22:52
or do you have a bootrom?
22:52
<sahil>
bootrom
22:53
http://pastebin.ca/515317
22:53
<jammcq>
I don't know what '/pxe/eb-5.0.9-rtl8139.lzpxe' is. if you are really using PXE, you should be loading something like:
22:54
2.6.17.8-ltsp-1/pxelinux.0
22:55
<sahil>
i think its an image from rom-o-matic
22:55
<jammcq>
if you are using pxe, you shouldn't be loading a rom-o-matic image
22:55
yeah, that makes no sense
22:55
<sahil>
wait it can't be actually i didn't get any rom-o-matic image on this server
22:56
<jammcq>
well, your dhcpd.conf file says you are trying to load it
22:56
<sahil>
ya
22:56
<jammcq>
if it doesn't exist, that would account for the 'file not found'
22:56
<sahil>
otherwise it defaults to the other
22:56
which should work right?
22:56
<jammcq>
furthermore, that's not even the right file to be loading
22:56
no
22:56
the other won't work either
22:56
cuz that's for Etherboot
22:56
where did you get the bootrom?
22:57
<sahil>
i have no idea it was on a server my friend was working on my guuess is rom-o-matic
22:57
<jammcq>
huh?
22:58
rom-o-matic is images, not bootroms.
22:58
when you turn on the client, do you see any mention of 'Etherboot' ? or does it say 'PXE' ?
22:58
<sahil>
which is the bootroom the .lpxe?
22:58
it says pxe
22:58
<jammcq>
the .lpxe is a image. a bootrom is a chip
22:59
<sahil>
ah the bootroom is built into my client
22:59
eway tu-40
22:59
<jammcq>
ok, so it IS pxe
22:59
then your 'filename' entry should be: /2.6.17.8-ltsp-1/pxelinux.0
23:00
<sahil>
not vmlinux?
23:00
ok
23:08muh2000 has joined #ltsp
23:09
<jammcq>
I'm heading to bed. g'night all
23:09
<sahil>
jammcq:one more thing please?
23:09
<jammcq>
hurry up
23:09
<sahil>
before you go then im out of your hair forever i hope
23:09
ok nfs mount problem
23:09
where do i pass the init= option?
23:09
<jammcq>
what's the problem?
23:09
<sahil>
and init=what?
23:09
kernel panic
23:09
but nfsmount failed
23:10
<jammcq>
run this: showmount -e
23:11
<sahil>
/opt/ltsp 169.254.0.0/255.255.0.0
23:11
/var/opt/ltsp/swapfiles 169.254.0.0/255.255.0.0
23:11
<jammcq>
that looks kinda wrong, doesn't it?
23:11
<sahil>
ha the ips
23:11
<jammcq>
yeah
23:11
<sahil>
from the old interface
23:11
which file is that in?
23:11
<jammcq>
change it to 192.168.0.0/255.255.255.0
23:11
in /etc/exports
23:12
also, check any ip addresses in /opt/ltsp/i386/etc/lts.conf
23:12
and i'm outta here
23:12
oh yeah
23:12
after changing /etc/exports, make sure you do: exportfs -ra
23:12
then, run showmount -e, to double check it
23:12
<sahil>
kk thanks for all the help
23:18
anyone else around that can help me?
23:19
<sbalneav>
With what?
23:21
sahil: What are you having trouble with
23:22
<sahil>
sbalneav: well i changed my etc/exports file per instructions earlier
23:22
and im still getting mounting problems
23:22
and it all ends with kernel panic - not syncing: attempted to kill init!
23:22
<sbalneav>
Please paste the current exportfs lines?
23:24
<sahil>
/var/opt/ltsp/swapfiles
23:24
192.168.0.0/255.255.0.0
23:24
/opt/ltsp 192.168.0.0/255.255.0.0
23:26
<sbalneav>
Both of those are still wrong.
23:26
You need something like:
23:26
<sahil>
ah the .0.0
23:27
<sbalneav>
/opt/ltsp 192.168.0.0/255.255.255.0(ro,no_root_squash,sync)
23:27
/var/opt/ltsp/swapfiles 192.168.0.0/255.255.255.0(rw,no_root_squash,sync)
23:28
You'll need to do the exportfs -ra again
23:28
<sahil>
and restart nfs?
23:30
sbalneav: still giving same error
23:31
<sbalneav>
I came in late to all this. When version of LTSP are you running, and which OS are you hosting this on?
23:31
And please paste your dhcpd.conf to the pastebot.
23:31
!pastebot
23:31
<ltspbot`>
sbalneav: "pastebot" is The LTSP pastebot is at http://pastebot.ltsp.org. Please paste all text longer than a line or two to the pastebot, as it helps to reduce traffic in the channel. A link to the content will be pasted in the channel.
23:33
<sahil>
doing it
23:33
and 4.2 and ubuntu
23:33
<sbalneav>
Which version of Ubuntu?
23:34
<ltsppbot>
"sahil" pasted "dhcpd.conf" (39 lines) at http://pastebot.ltsp.org/143
23:35
<sahil>
7.04
23:36
<sbalneav>
ok
23:37
so, is ltsp installed in /opt/ltsp-4.2, or in /opt/ltsp?
23:38
<sahil>
thats what it is
23:38
thats the problem rather
23:38
man i just feel worse and worse about myself and my stupidity
23:39
<sbalneav>
Depending on where it's installed, you'll either have to fix the dhcpd.conf file, or the /etc/exports file.
23:50Jenna has joined #ltsp
23:50
<Jenna>
Has anybody tried openmosix on centos 3.8 ? is it production ready stable ?
23:51
sorry wrong channel
23:51
<sbalneav>
sahil: So, is it working now?
23:52
<Jenna>
hey sbalneav
23:52
<sbalneav>
Hello
23:53
<sahil>
sbalneav:its starting x but im getting the cursor on grey screen problem
23:54
<sbalneav>
So, you haven't enabled xdmcp
23:54
<sahil>
i did in gdm.conf
23:55
enable=true and all that
23:55
<sbalneav>
That's not the way to do it in Ubuntu.
23:56
go to System -> Administration
23:56
login window
23:56
Click on the "Remote" tab on the top
23:56
<sahil>
i did it that way too
23:57
configure xdmcp yes?
23:57
<sbalneav>
Change it to "Same as local"
23:57
<sahil>
ah i see
23:57
<sbalneav>
Configure your xdmcp
23:57
log out
23:58
Switch to alt-f1 (text login screen)
23:58
login as yourself
23:58
sudo invoke-rc.d gdm restart