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


Channel log from 26 April 2009   (all times are UTC)

00:18pmatulis has quit IRC
00:47nicoAMG has joined #ltsp
00:48alkisg1 has joined #ltsp
00:48alkisg has quit IRC
00:55alkisg1 has quit IRC
00:59vagrantc has joined #ltsp
01:03vagrantc has quit IRC
01:26alkisg has joined #ltsp
01:29hanthana_ has joined #ltsp
01:44hanthana has quit IRC
01:47phantom has joined #ltsp
01:47F-GT has quit IRC
02:35mede has joined #ltsp
02:35
<mede>
hello everyone
02:35
i have a question here
02:36
how to setup multiple server
02:38
<cyberorg>
mede, search for ltsp cluster
03:02ogra_ has quit IRC
03:02ogra has quit IRC
03:02ogra_ has joined #ltsp
03:03ogra has joined #ltsp
03:10
<mede>
tq cyberorg..
03:10
but i have nothing idea with that
03:10nubae1 has quit IRC
03:11nubae has joined #ltsp
03:12
<cyberorg>
mede, what distro?
03:52hanthana_ is now known as hanthana
04:19russell_nash has joined #ltsp
04:19russell_nash has left #ltsp
04:45
<mede>
edubuntu
04:45
cyberorg
04:45ogra_ has quit IRC
04:46
<cyberorg>
mede, see documentation link in the /topic look for get_hosts
04:47alkisg has quit IRC
04:48
<mede>
ok...thanks
04:49
i will try to explore it
04:49mede has quit IRC
05:44Shingoshi_ has joined #ltsp
05:45Shingoshi has quit IRC
06:03ogra_ has joined #ltsp
06:30mikkel has joined #ltsp
06:39danil has joined #ltsp
06:40
<danil>
Hi folks. Can't get working ltsp client cause of wrong resolution on my Samsung 940n monitor and geForce 6100 video. Could you give me an advice?
06:42
tried # X_MODE_0 = "1280x1024" 108 1280 1328 1440 1688 1024 1025 1028 1066
06:42
X_MODE_0 = "1280x1024@60i" 49.50 1280 1312 1496 1528 1024 1047 1053 1077 interl
06:42
but no luck
07:10
<nubae>
danil: did u set X_CONF=True
07:21
<danil>
i tried different combinations
07:23
when i use it, and provide custom xorg.conf i get blinking message : xauth tryin new authority file /root/.Xautority
07:23
and x fail to start even i've added copy_dir "/root" in ltsp-client-config file
07:26
half way to success: i 've switched to console 2 at thin client , dpkg-reconfigure xserver-xorg, after have added HorizSync 31-75 , VertRefresh 60-75 into new xorg.conf returned to console 7 and ctrl+alt+backspace so xorg started fine
07:27
in gnome now i can switch to right resolution for this monitor (1280x1024)
07:28
but question is : How add this settings right in lts.conf ? should i use custom xorg.conf or pass this parammetrs via monitor options?
07:29phantom has quit IRC
07:31phantom has joined #ltsp
07:39
<nubae>
danil: either or should work for you
07:44alkisg has joined #ltsp
07:45
<danil>
ok it's work via custom xorg.conf but disadvatage is need always ltsp-update-image if i change xorg.conf in /opt/ltsp/....
07:46
could you provide right syntax X_MONITOR_OPTION_01 HorizSync = 31-75
07:46
i would like change it via /var/lib/tftboot/i386/lts.conf
07:47
googled but nothing found
07:54
<nubae>
!docs
07:54
<ltspbot`>
nubae: "docs" is For the most current documentation, see http://wiki.ltsp.org/twiki/bin/view/Ltsp/LtspDocumentationUpstream
07:55
<nubae>
u should find it in there ^^^
07:56danil has left #ltsp
08:08mistik1 has quit IRC
08:12mistik1 has joined #ltsp
08:29
<zamba>
how can i change the default language used for my image?
08:31
<alkisg>
ltsp-build-client --extra-help|grep locale
08:33
<zamba>
alkisg: what if i've already built the image?
08:33
<alkisg>
distro/version?
08:33
<zamba>
itnrepid
08:33
eh
08:33
intrepid*
08:33
that being ubuntu
08:34
<alkisg>
zamba: `cat /opt/ltsp/i386/etc/environment` - does it have your LANG there?
08:35
<zamba>
nope
08:35
<alkisg>
*sorry, I mean *any* LANG there?
08:35
(e.g. english)
08:35
<zamba>
nope
08:35
nothing there
08:35
<alkisg>
Nothing? not even the path?
08:35
Maybe you've build an amd64 chroot?
08:36
<zamba>
nope.. it's i386
08:36
<alkisg>
And the file exists and has nothing in there, or it doesn't exist at all?
08:36
<zamba>
but i believe if the standard is used, then nothing is defined in /etc/environment
08:37
sure, the file's there
08:38
<alkisg>
zamba: and this one? cat /opt/ltsp/i386/etc/default/locale
08:38
<zamba>
haven't got that
08:38
<alkisg>
Erm... what does /etc/environment have?
08:38
<zamba>
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
08:39
<alkisg>
I see - out of curiosity, what language did you install in? English?
08:39
<zamba>
yeah
08:42
<alkisg>
zamba: well, in jaunty the LANG goes in /opt/ltsp/i386/etc/environment - but it just get copied from /etc/environment
09:03vvinet has joined #ltsp
09:14alkisg has quit IRC
09:20alkisg has joined #ltsp
10:00litlebuda has joined #ltsp
10:09yoshi has joined #ltsp
10:09yoshi is now known as Guest30963
11:10nubae1 has joined #ltsp
11:12nubae has quit IRC
11:15alkisg has quit IRC
11:17vagrantc has joined #ltsp
11:19litlebuda has quit IRC
11:20litlebuda has joined #ltsp
11:24
<zamba>
is it possible to get my thin clients to authenticate against a central ldap server?
11:24
individually, that is
11:24
instead of going through the ltsp server
11:25
<vagrantc>
of course it's possible. do you want to know if it's easy?
11:25
<zamba>
yeah :)
11:25
point is.. i've set up my fat clients to authenticate against a central server and also map up the /home from the same server
11:25
and i want to have the identical setup for my thin clients as well
11:26
i see that /etc/fstab gets modified when booting the thin client?
11:26
<vagrantc>
then set up your ltsp server to authenticate via ldap
11:26
<zamba>
well.. i can get it working when logging in on the console
11:26
but not gdm
11:26
<vagrantc>
how about ssh?
11:27
<zamba>
works too
11:27
<vagrantc>
!release
11:27
<ltspbot`>
vagrantc: "release" is please mention the linux distro and release you're using :)
11:27
<zamba>
what's the cow directory on /?
11:28* vagrantc wonders what version zamba is running
11:28
<zamba>
intrepid
11:29
<vagrantc>
zamba: so, unless you've explicitly configured it to use XDMCP, it will use LDM by default, which logs in via ssh.
11:29
zamba: so you need to configure ssh to authenticate via ldap.
11:30
gdm doesn't come into the picture.
11:30
<zamba>
ssh authenticates using ldap
11:30
i've just confirmed it
11:30
and the thin client uses its own connection to the ldap server, without going through the ltsp server
11:31
<vagrantc>
i thought you said you wanted your thin clients to behave like the fat clients you already had working?
11:31
<zamba>
yeah
11:31
meaning they should authenticate to the ldap themselves, instead of going through the ltsp server
11:32
<vagrantc>
the thin clients don't do any authentication.
11:32
<zamba>
hm..
11:32
why can i log in directly to the thin client using ssh then?
11:32
<vagrantc>
the thin clients provide a login screen, that logs into the server via ssh. so all authentication happens on the server.
11:32
<zamba>
aha
11:32
got it
11:33
<vagrantc>
99% of the time, if you want to do something, you do it on the server.
11:33
installing packages, authentication, whatever. all happens on the server. NOT the thin client.
11:33
<zamba>
the same goes for the mounting of the home directory?
11:33
<vagrantc>
yes.
11:35
<zamba>
this is a bit confusing :)
11:35
but i'll try
11:35
i thought everything happened in the chroot?
11:35
let's say i want to mount a /data directory that should be accessible for the thin clients?
11:36
do i mount it into the chroot or in the global /data directory?
11:36
will mounting it in the chroot even work?
11:36
then i'm thinking like: mount -t cifs //server/share /opt/ltsp/i386/data/
11:37
my first thought was to set up the mount in /opt/ltsp/i386/etc/fstab, but that won't work?
11:37alkisg has joined #ltsp
11:38
<vagrantc>
zamba: do you want it accessible to the user who logs in from the thin client, or the server?
11:38
<zamba>
the user who logs in from the thin client
11:38
the same goes with the home directory as well
11:38
<vagrantc>
the user is logged in to the server, so it needs to be mounted on the server.
11:38
99% of the time...
11:38
<zamba>
but why setting up stuff in the chroot? i don't get that part of it :)
11:38litlebuda has quit IRC
11:39
<vagrantc>
zamba: i guess you know better than i, i will stop annoying you now.
11:39
<zamba>
if i want to install a new package, let's say openoffice, why do i first have to chroot into /opt/ltsp/i386 and then install it?
11:39
vagrantc: huh?
11:39
<vagrantc>
zamba: because you're doing it wrong?
11:39litlebuda has joined #ltsp
11:39
<zamba>
vagrantc: i'm confused, that's all.. i don't mean to be sarcastic or anything.. i just want to understand fully how this works
11:40
if i'm bothering you with my questions, feel free to just ignore them..
11:40
<vagrantc>
zamba: i don't know how else to say it. NEARLY EVERYTHING happens on the server.
11:40
zamba: installation of packages, authentication, running processes, etc. all happens on the server.
11:40
<zamba>
yeah, but i'm having problems differentiating between what happens in the chroot of the thin client and "globally" on the server
11:41
<cyberorg>
zamba, simply put, don't mess with chroot ever unless you know what you are doing :)
11:41
hi vagrantc
11:41
<vagrantc>
cyberorg: thank you!
11:42
<zamba>
but chrooting is a way of installing packages that you only want accessible for the thin clients? like if you don't want the same package installed on the ltsp server?
11:42
(this is for the sake of discussion)
11:42
<vagrantc>
zamba: no.
11:42
<zamba>
http://www.ltsp.org/twiki/bin/view/Ltsp/MueKow
11:43
i'm reading under "A New Approach"
11:43
For example, If you want to install firefox into an LTSP tree on a Debian system, you'd run the following commands:
11:43phantom has quit IRC
11:43
<zamba>
chroot /opt/ltsp/i386
11:43
apt-get install mozilla-firefox
11:43
<vagrantc>
zamba: think of the thin client as an extra keyboard, mouse and monitor for your server. you wouldn't install packages on your keyboard, would you?
11:43
zamba: that's the 1%
11:43
<zamba>
vagrantc: that's installing packages, isn't it?
11:43
which i'm doing and want to be doing
11:43
<vagrantc>
zamba: that's talking about localapps.
11:44
<zamba>
basically applications that consume CPU at the client versus the server, right?
11:44
<vagrantc>
zamba: that's one distinction, yes.
11:45
<zamba>
and it will also make the footprint of the image larger and more complex, right?
11:45
<vagrantc>
zamba: for a genuine thin client, EVERYTHING is on the server. for a fat client, the server just provides disk. for LOCAL_APPS, you do a little of both.
11:45
<zamba>
ah, ok
11:45
then i'm starting to get the idea here, i think
11:45
<vagrantc>
zamba: first, understand what a regular thin client works, then start playing with other stuff.
11:45phantom has joined #ltsp
11:46
<vagrantc>
zamba: burn that distinction into your brain.
11:46
<zamba>
yeah
11:46hanthana has quit IRC
11:46
<zamba>
i think i should just wipe the image i've created ;)
11:46
i've been installing quite a few packages chrooted :)
11:47
<alkisg>
zamba, the LTSP docs describe pretty nicely what a thin client is: http://www.ltsp.org/~sbalneav/LTSPManual.html#id2518323
11:47
<zamba>
another distinction would mean that i don't have to rebuild the image every time packages are being upgraded, right?
11:48
alkisg: ok, thanks, i'll read through it
11:48hanthana has joined #ltsp
11:48
<alkisg>
zamba: e.g. to answer your last question: "All the regular maintenance (software updates, administration) takes place on the server."
11:49
<cyberorg>
vagrantc, happy news is we finally managed to get sound with xrdp without writing to any file
11:51
it will still break on resume, we'll try to figure out setting pa server on resume
11:51
<vagrantc>
cyberorg: ah, cool!
11:51
<cyberorg>
xrdp requires patching
12:08
<vagrantc>
stgraber: did the ltspfs local mounting work for you with jaunty? both the mounts as root as well as per-user mounts?
12:20
<stgraber>
vagrantc: per-user I'm not sure, these as root I'm using in production (for rdesktop)
12:20japerry has joined #ltsp
12:21
<stgraber>
cyberorg: are these changes to rdesktop/xrdp done upstream or is it OpenSUSE specific ?
12:21
<vagrantc>
stgraber: gadi had added a couple commits after the upstream version in jaunty, didn't know if they made it in as patches.
12:21
<cyberorg>
stgraber, at the moment they are only in a test machine :)
12:21* vagrantc has heard xrdp upstream has been a little stubborn with regard to patches
12:22
<cyberorg>
vagrantc, last time i checked xrdp-devel mailing list had disappeared
12:22
<stgraber>
vagrantc: nope, we don't have these two commits but haven't heard of issues without them though (probably because I didn't advertise that it should be working per-user)
12:22
<vagrantc>
dead upstream!
12:23
stgraber: heh :)
12:23
stgraber: congrats on the release, by the way!
12:23
<stgraber>
vagrantc: thanks. Working on the feature list for the next one now :) Will send that to ltsp-dev soon so everyone knows what I'll break in the next 6 months ;)
12:24
<vagrantc>
heh :)
12:24
<stgraber>
my main goal is integrating "ltsp-remoteapp" :)
12:24
it's a small script I'm working on basically doing the oposite of ltsp-localapp
12:24
so a localapp can start a software on the server
12:24
<vagrantc>
heh
12:24
we're going crazy!
12:25
and we're not going to stop!
12:25
<cyberorg>
stgraber, seamless rdesktop?
12:25
<stgraber>
especially looking after that for firefox, basically all mimetypes would be sent to that script, it'll then copy the file if it's not accesible from the server and then start the application with xdg-open on the server.
12:25
for now it works perfectly with firefox and openoffice :) you click on a .odt on google and you get ooo starting on the server with your file.
12:26
<vagrantc>
nice!
12:26
<stgraber>
(but the script is really ugly and I don't have the mimetype integration yet)
12:26
<cyberorg>
yup, great idea!
12:26
<vagrantc>
seamless localremotelocalremoteapps!
12:26
<stgraber>
cyberorg: I guess it'll depend if that's upstream or not :)
12:27
I can do without having to maintain patches on xrdp and rdesktop and having it upstream means that debian will do the work and I'll just have to sync :) (well, depends on how active is the maintainer in Debian for these two)
12:28
<vagrantc>
ANYWHERE_APPS=True
12:28
<cyberorg>
stgraber, sorry, didn't quite get you there, this work is using xrdp?
12:28
xrdp can't do localapps
12:29
<vagrantc>
not yet!
12:29
<stgraber>
cyberorg: nope, was talking of your RDP stuff :) it's somewhere on my list too but waiting on upstream inclusion before working on it.
12:30
and yeah, usually the issue with RDP is that it's a fullscreen app so won't work with localapps
12:30
I have the same issue with some NX deployments we're planning, you can't mix that with localapps and so limit it for very slow thin clients that can't do localapps.
12:31
<cyberorg>
vagrantc, if it really works on xrdp, that is probably a way to go for ltsp default, but xrdp upstream is non-existent :(
12:31
we have local dev and sound working, only thing missing is localapps
12:32
stgraber, not just being a full screen app, the X server is actually running on the server, so whatever xprop we set stays over there
12:32
<ogra_>
according to SF the xrdp code was last updated on jul 18 2008
12:32
doesnt seem to dead to me
12:33
<cyberorg>
ogra_, right only few months left till one year :)
12:36
<ogra_>
last commit 5 days ago actually on http://xrdp.cvs.sourceforge.net/viewvc/xrdp/xrdp/
12:38
<cyberorg>
hmm, ML is back up again too
12:40vagrantc has quit IRC
12:42
<alkisg>
Is this of any interest to LTSP? http://usbip.sourceforge.net/
12:42
<cyberorg>
here is novell's changes http://sourceforge.net/mailarchive/forum.php?thread_name=1225400989.21992.83.camel%40opensuse-gnome.nomad&forum_name=xrdp-devel
12:42
<ogra_>
alkisg, ancient
12:43
<alkisg>
Meaning? obsolete, or that everyone already knows about it?
12:43
<cyberorg>
alkisg, see ltsp-discuss/developers ML i sent instructions for how to test
12:43
<ogra_>
i reviewed it yars ago when we looked for localdevice support
12:43
<alkisg>
ogra_, so it isn't suited for LTSP environments?
12:43
cyberorg: looking...
12:44
<ogra_>
alkisg, no idea what happened since then ... we decided for improving ltspfs for ltsp5 back then
12:44
<cyberorg>
alkisg, no
12:44
it makes all usb ports unusable on the server
12:44
<ogra_>
might have changed or improved
12:44
<cyberorg>
some bug
12:44
<alkisg>
cyberorg: you mean the local (server's) usb ports?
12:44Guest30963 has quit IRC
12:44
<ogra_>
but iirc there were very intrusive kernel patches involved
12:45
<cyberorg>
ogra_, it is part of the kernel now
12:45
<alkisg>
Ah, I thought it was a clean module... with no patches involved
12:45
<ogra_>
ah
12:45
it wasnt in 2005/6
12:45
<cyberorg>
alkisg, no patches now :)
12:45
<alkisg>
Right. Well, it sounded too good to be true :)
12:45
<ogra_>
it was quite hackish once and not very secure
12:46
but as i said, its years ago that i looked
12:46
<alkisg>
If it could work on a per user basis, and over the ssh tunnel...
12:46
<ogra_>
and i personally wouldnt vote for replacinf ltspfs :)
12:47
<alkisg>
ogra_, it would make things more clean - e.g. ntfs formatted sticks, cameras...
12:47
locale settings...
12:47
<ogra_>
ntfs sticks work, cameras do ....
12:47
<cyberorg>
ogra_, not secure at all, as there is no authentication mechanism
12:47
<ogra_>
not sure what you mean
12:48
at least in ubuntu
12:48
if they dont its a bug
12:49
<cyberorg>
ogra_, usbip does not have authentication
12:49
<ogra_>
yes, you would need to hack it
12:49
<cyberorg>
ogra_, oh, you meant cameras, they work on ltsp?
12:50
<ogra_>
well, in disk mode in any case ... for ptp mode i think vagrant started some work
12:50
i did all my ltspfs development i ever did with one single usb key and my casio camera
12:50
would surprise me if it wouldnt work anymore
12:51
and for the ptp mode gphoto cams vagrant has an ltspfs branch somewhere ... we should merge that :)
12:52
<cyberorg>
alkisg, some scripts for usbip http://groups.google.com/group/proj-uron/browse_thread/thread/a8c34aeb5f58113d#
12:52
ogra_, camera for video/webcams, not as storage device, that would work?
12:53
<ogra_>
ah, well, no
12:53
but thats one of the usecases we started localapps for
12:54
better to have the cam app running locally than saturate the network with even more data tranfers
12:54
<stgraber>
yeah, I've skype deployed as localapp in some schools, work just fine :)
12:54
<cyberorg>
ogra_, thats what i thought :)
12:54
<ogra_>
even with compression you have the same prob aqs in the other direction
12:58
<alkisg>
cyberorg: thanks, I get the feeling that it would work on a per user basis (usbipd -D)... but also that security would be a problem... :(
12:59
<cyberorg>
alkisg, once it is exported, anyone can connected to the usb device from anywhere in the network :)
12:59
<alkisg>
There's an option to ""4> Export the device to 'host'"
13:00
...meaning a specific host, but still, traffic won't be encrypted
13:00
<cyberorg>
alkisg, with ltsp server everyone is on the same host = server :)
13:01
<nubae1>
heh
13:01
funny how the server - client thing still trips up even the most hardened users ;-)
13:01
<alkisg>
That could be arranged by asking for the same username somewhere in the code, but it would mean one more patch...
13:03
If it supported encrypted traffic, then it wouldn't even need to check for a username.
13:04
But I guess tcp is out of the question due to latency, so it would be like reimplementing ssh :P
13:05
<cyberorg>
nubae1, sync up the latest -unstable iso, it has nomad working again
13:06
<nubae1>
ok
13:07nubae1 is now known as Nubae
13:19vagrantc has joined #ltsp
13:29nicoAMG has joined #ltsp
13:42yoshi has joined #ltsp
13:43yoshi is now known as Guest68446
13:54bobby_C has joined #ltsp
14:01Shingoshi_ has quit IRC
14:07vvinet has quit IRC
14:16Egyptian[Home] has quit IRC
14:17Egyptian[Home] has joined #ltsp
14:24japerry_cat has joined #ltsp
14:40nicoAMG has joined #ltsp
14:40japerry has quit IRC
14:40cinch_ has quit IRC
15:02rjune_ has quit IRC
15:04alkisg has quit IRC
15:07rjune_ has joined #ltsp
15:33lucascoala has joined #ltsp
15:42nicoAMG has quit IRC
15:49bobby_C has quit IRC
15:56vagrantc has quit IRC
15:58vagrantc has joined #ltsp
16:03nicoAMG has joined #ltsp
16:10vagrantc has quit IRC
16:11vagrantc has joined #ltsp
16:59litlebuda has quit IRC
17:01japerry_cat has quit IRC
17:03litlebuda has joined #ltsp
17:21GodFather has joined #ltsp
17:26din_os has joined #ltsp
17:31mikkel has quit IRC
17:32din_os has left #ltsp
17:32
<zamba>
i have a question which i believe may fall into the 1% that you actually have to do in the chroot of the thin client.. when logging on the thin clients i need to use unionfs to mount a rw "layer" on top of a given user's home directory..
17:33
this is because all users share the same username when logging on and to prevent changes made by one user being replicated to the other users
17:33litlebuda has quit IRC
17:34
<zamba>
i use pam.d to automatically mount the unionfs whenever a user logs on
17:34
the libpam-mount package in debian
17:35
if this is done on the server then the mount will in all practice be a permanent mount
17:35
and only related to the server instance and then all thin clients
17:35
if it's done on the thin clients, then it's only available on the different ones
17:36
<vagrantc>
why not just use separate users for each login?
17:37
<zamba>
simplicity
17:37
this is for a school with students aged 7 to 14
17:38
<vagrantc>
you're not gaining any simplicity by setting up a dynamically mounted unionfs layer just to use the same user for all logins.
17:38
<zamba>
it works perfectly for the fat clients
17:39
and it's also very important that all students see exactly the same desktop
17:39
for the learning environment
17:40
it's like communism :)
17:43
but my question is still.. this would probably fall into the 1% category?
17:47
<vagrantc>
pam happens server side, so libpam-mount will probably not work well for what you're trying to do.
17:48
<zamba>
hm
17:48
what would be the solution for my problem then?
17:52
<vagrantc>
if you're clever enough to do crazy things with unionfs mounts at login, surely you can figure it out.
17:52
<zamba>
i'm trying to figure out what exactly i did in my enqueries to personally insult you, but i've yet to find any valid reason..
17:52
<vagrantc>
stgraber: i'm messing around with jaunty's LTSP ... i'm getting a squashfs error at boot, and /etc/resolv.conf on the thin clients is broken...
17:53
<zamba>
vagrantc: i'm sorry i've wasted your precious time with my questions.. the next time just do me the favour of ignoring them
17:53
do us both the favour, that is
17:58
<vagrantc>
zamba: well, most people are receptive to help, and you seemed insistant on ignoring it earlier. so i'll endeavor to be helpful, but i don't appreciate people wasting my time.
17:58
<stgraber>
vagrantc: squashfs or nbd error ?
17:59
<vagrantc>
stgraber: squashfs errors
17:59
<stgraber>
vagrantc: how broken is your resolv.conf ? I was reported that when using lts.conf to change your DNS server the resolv.conf may be 000 and so be broken, other than that no issue were reported
17:59
<zamba>
vagrantc: in what way am i ignoring your help?
17:59
<stgraber>
hmm, did you try to rebuild your squashfs image then ? maybe something went wrong at build time
18:01
<vagrantc>
stgraber: i'm about to. the really weird thing is it works with a virtualbox thin client
18:01
<stgraber>
hmm, indeed that's really weird
18:01
<vagrantc>
zamba: just when i repeatedly said everything happens on the thin client, and you still kept asking about things i mentioned explicitly that happen on the server.
18:01
stgraber: i'll try and re-build the image.
18:02
<zamba>
vagrantc: when? earlier today? i told you i had a confusion about it and i needed some more examples on it.. i'm sorry that i don't just intuitively swallow knowledge like you do
18:02yanqui has quit IRC
18:04
<vagrantc>
zamba: i'm sorry if i seemed short with you, i tried to help when i was busy with other things, and it was frankly unclear to me how you could have miscontrued a few things.
18:06
but it happens, and my apologies.
18:08
stgraber: the SQUASHFS error seems to happen between the first "Negotiation" right after "Setting up LTSP client" and the second "Negotiation" message
18:08
<zamba>
ok, and i have to apologize for english not being my first language, so i often need a little more help than the "native speaker" :)
18:08
<vagrantc>
though it also happens on the one that works as well.
18:08vvinet has joined #ltsp
18:09MikeMc has joined #ltsp
18:09
<stgraber>
vagrantc: really weird, there was a race condition during the NBD reconnect but that was fixed. Usually all you should see is a read error then the nbd reconnection ...
18:10
<vagrantc>
stgraber: if i don't set DNS_SERVER and SEARCH_DOMAIN the file ends up being unreadable ...
18:11
<stgraber>
and what does it look like in /opt/ltsp/i386/etc/resolv.conf ?
18:11
<vagrantc>
stgraber: "cat /etc/resolv.conf" results in "cat: /etc/resolv.conf: Input/Output Error" until i "touch /etc/resolv.conf"
18:12
stgraber: /opt/ltsp/i386/etc/resolv.conf is a normal file with your typical contents
18:12
stgraber: i even manually mounted the squashfs image, and it looks the same...
18:13
i'm going to try and rebuild the image and see what happens
18:16
<stgraber>
so when mounting the squashfs image on the server without nbd you get the same input/output error ?
18:16
<vagrantc>
stgraber: no, then it works fine :) just to make it really confusing.
18:19
<stgraber>
I did a few test here and can't reproduce it ... looks like some kind of race condition at boot time. What is your thin client like ? fast/slow ?
18:20BugsBunnyBR has joined #ltsp
18:22
<vagrantc>
stgraber: 1.2GHz, 512MB ram for the real thin clients ... my virtualbox thin client is running on a 1.2GHz laptop, with 64MB of ram...
18:24
<stgraber>
hmm, ok, so if that's a race condition it's really weird I haven't seen it yet. Most of my users at the office are either on Atom 1.6 Ghz with 1GB of RAM or Via 1.0Ghz with 512MB of RAM ...
18:25
<vagrantc>
stgraber: you do the disconnect/reconnect nbd thing to prevent what?
18:26
<stgraber>
that's to reload nbd in persistent mode
18:26
because even if you start it with -persist from the initrd it won't work
18:26
the way it works on disconnect is that the nbd process disappears and is then respawned from its previous location in our case from the initrd that's no longer loaded
18:26
<vagrantc>
i'll see if disabling that at least makes this other behavior go away...
18:27
<stgraber>
you should be able to disable that by commenting the configure_nbd part of the init script
18:27
<vagrantc>
and re-rolling the NBD image ...
18:29japerry has joined #ltsp
18:29dark4og has joined #ltsp
18:34
<vagrantc>
stgraber: that fixed it!
18:34
stgraber: by breaking persistance ... how bad is that?
18:36
<stgraber>
well, if for whatever reasons your inetd on the server crash you will find yourself without a working root filesystem
18:37
though I don't really understand why it's happening, the code was improved to avoid that kind of race condition by reconnecting the nbd as soon as possible
18:38
the only better way of fixing that that I could think of was to change nbd to handle the reconnection properly, either in the kernel or in the user-space binary
18:38
for now it looks like when the connection is lost the kernel module is respawning nbd-client so it can reconnect the nbd and that's just not working with the way the initramfs works ...
18:43
<BugsBunnyBR>
someone here is having problems to do the terminal find tftp server in LTSP 5.0 on ubuntu 9.04?
18:44
the terminal find the right ip on the server..but can't charge the kernel file
18:45
the terminal get's time out
18:59BugsBunnyBR has quit IRC
19:04dark4og has quit IRC
19:05MikeMc has quit IRC
19:06hanthana has quit IRC
19:10nubae1 has joined #ltsp
19:11Nubae has quit IRC
19:18nicoAMG has quit IRC
19:31
<zamba>
vagrantc: concerning my issue earlier.. do you have some suggestions to how i can solve it? i'm afraid i need to keep the single user, but maybe i can export the file system in a different way..?
19:32
<vagrantc>
i've actually got to run right this second... will talk more later
19:32vagrantc has quit IRC
19:37japerry has quit IRC
19:56
<slashdotfx>
oops, I've just upgrade ltsp chroot to 2.6.29 kernel
19:56
it say "squashfs error major/minor mismatch"
19:57
mksquashfs is not backward compatible
20:00vvinet has quit IRC
20:06Faithful has joined #ltsp
20:19try2free has joined #ltsp
20:21
<slashdotfx>
try to upgrade to squashfs4 didn't work either
20:30try2free has left #ltsp
20:39GodFather has quit IRC
20:40vvinet has joined #ltsp
20:55
<slashdotfx>
i see that squashfs4 need to support lzma, the author didn't work on it yet
20:55
since lzma afaik, isn't integrated into the current kernel
20:59lucascoala has quit IRC
21:21dark4og has joined #ltsp
21:22dark4og has quit IRC
21:22dark4og has joined #ltsp
21:30vvinet has quit IRC
21:31try2free has joined #ltsp
21:36try2free has left #ltsp
22:40dark4og has quit IRC
22:56alkisg has joined #ltsp
23:00japerry has joined #ltsp
23:04aminus has joined #ltsp
23:04
<aminus>
hi im having trouble
23:04
booting a dell gx1
23:39yoshi has joined #ltsp
23:39yoshi is now known as Guest68355
23:47Guest68446 has quit IRC