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


Channel log from 12 February 2012   (all times are UTC)

00:11epaphus2 has left IRC (epaphus2!~epaphus@200.122.149.9, Ping timeout: 252 seconds)
00:12NeonLicht has left IRC (NeonLicht!~NeonLicht@darwin.ugr.es, Ping timeout: 252 seconds)
00:12NeonLicht has joined IRC (NeonLicht!~NeonLicht@darwin.ugr.es)
00:14freedomrun has left IRC (freedomrun!~quassel@89.142.248.83, Remote host closed the connection)
00:14killermike has joined IRC (killermike!~killermik@2.26.103.46)
00:14epaphus2 has joined IRC (epaphus2!~epaphus@200.122.149.9)
00:20monteslu_ has joined IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net)
00:23monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 260 seconds)
00:53vedranm has left IRC (vedranm!~vedranm@inf2.ffri.hr, Quit: leaving)
01:32Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
01:53adrianorg_ has left IRC (adrianorg_!~adrianorg@186.213.152.248, Ping timeout: 265 seconds)
02:21vagrantc has left IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net, Ping timeout: 245 seconds)
03:02andy__ has left IRC (andy__!~andy@h247.95.31.71.dynamic.ip.windstream.net, Ping timeout: 240 seconds)
03:30killermike has left IRC (killermike!~killermik@2.26.103.46, Remote host closed the connection)
03:30killermike has joined IRC (killermike!~killermik@2.26.103.46)
03:50Parker955_Away is now known as Parker955
04:00alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net)
04:12andygraybeal has left IRC (andygraybeal!~andy.gray@obsidian.casanueva.com, Excess Flood)
04:13andygraybeal has joined IRC (andygraybeal!~andy.gray@obsidian.casanueva.com)
04:34cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, *.net *.split)
04:37cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
04:50Parker955 is now known as Parker955_Away
05:02alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
05:12
<alkisg>
Plymouth fails to start even if I just put init=/sbin/init in grub, so it's not ltsp-init's fault
05:32
Something evil, probably plymouth itself, checks for init=* in the kernel command line, and hides plymouth in that case
05:33
stgraber: By renaming /sbin/init to /sbin/init.real, and /sbin/ltsp-init to /sbin/init, plymouth worked fine. I'll file a bug in plymouth about it.
05:39
Found it, in plymouth's changelog:
05:39
* Restored code to disable Plymouth's graphical plugins when an alternate
05:39
init= is given on the kernel command-line, otherwise init=/bin/bash
05:39
doesn't work so well when Plymouth is in the initramfs.
05:40
plymouth (0.8.1-1), 26 Mar 2010
05:52
They do support another kernel command line parameter to force showing the splash screen though: plymouth:force-splash
05:52
...which works
05:57
stgraber: so we can either put that additional kernel parameter in pxelinux.cfg/default, or if you could ask scott@ubuntu... if he wants to restrict disabling the graphical plugins only in the init=/bin/bash or even init=/bin/* cases.
05:58
Even if he just allows /sbin/init*, we can name ours /sbin/init-ltsp
06:02
Filed a bug about it, https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/930865
06:08
<muppis>
Does Plymouth have any other functionality than just showing splash?
06:12
At work we faced a problem where plymouth caused a hang in ro nfs root. Tried to remove, but depencies were something incredible that we looked other way round.
06:13
Which was not what we wanted, but works.
06:47cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 240 seconds)
07:01cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
08:12loather has left IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep)
08:24
<alkisg>
In case anyone's interested, I just wrote a 'how to create an nbd file-based "partition", for development purposes, to be able to quickly do changes in the chroot without having to run ltsp-update-image' all the time:
08:24
https://help.ubuntu.com/community/HowToSetupLTSPDevelEnvironment#Using_an_NBD_file-based_.22partition.22
09:02khildin has joined IRC (khildin!~khildin@ip-80-236-223-208.dsl.scarlet.be)
09:18
<alkisg>
/dev/nbd0 /rofs btrfs...!!! Cool! Exporting btrfs compressed images works by default on Precise
09:19
So it's possible to only have a fat chroot in a file, /opt/ltsp/images/i386.img, without needing /opt/ltsp/i386 and without ever needing to run ltsp-update-image
09:22freedomrun has joined IRC (freedomrun!~quassel@89.142.248.83)
09:24
<alkisg>
qemu can use a file-based partition as a VM hard disk, right? So it should now be almost possible to maintain fat chroots graphically
09:36freedomrun_ has joined IRC (freedomrun_!~quassel@89.142.248.83)
09:37freedomrun has left IRC (freedomrun!~quassel@89.142.248.83, Ping timeout: 252 seconds)
10:16khildin has left IRC (khildin!~khildin@ip-80-236-223-208.dsl.scarlet.be, Ping timeout: 240 seconds)
10:19adrianorg_ has joined IRC (adrianorg_!~adrianorg@187.115.110.202)
10:29khildin has joined IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be)
10:55freedomrun_ has left IRC (freedomrun_!~quassel@89.142.248.83, Remote host closed the connection)
11:25piet has joined IRC (piet!5b605e82@gateway/web/freenode/ip.91.96.94.130)
11:27
<piet>
hi folks, got my fat-clients run completely. Everythings runs fine. There are only error-messages messing up my boot-screen . . .
11:29
<No caching mode page present> and <Assuming write cache: write through> are showing up . . .
11:29freedomrun has joined IRC (freedomrun!~quassel@89.142.248.83)
11:30
<piet>
according to dmesg it has something to do with sdb2 which is a sound stick for audio with a little fat where win-divers are located . . .
11:30
this thing is only readeable si that might have something to do with it . . .
11:32
my Question now is: is there any chance to get rid of the message screwing up the boot screen, because there is no other negative effect.
11:41andy__ has joined IRC (andy__!~andy@h247.95.31.71.dynamic.ip.windstream.net)
11:43Yet_another_Bill has left IRC (Yet_another_Bill!billy@nat/redhat/x-jqcjudpixndyzmep, Quit: Good night ^_^)
11:48
<alkisg>
piet: if you put it in the server and run dmesg, don't you see the same messages?
11:48
(or in any other machine, not ltsp-clients...)
11:49freedomrun has left IRC (freedomrun!~quassel@89.142.248.83, Remote host closed the connection)
12:09
<piet>
no, I have an ubuntu set on the local disc of the fat client. Starting that no message appears.
12:23monteslu_ is now known as monteslu
12:36toscalix has joined IRC (toscalix!~toscalix@85.137.146.26.dyn.user.ono.com)
12:41piet has left IRC (piet!5b605e82@gateway/web/freenode/ip.91.96.94.130, Quit: Page closed)
12:44Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71)
12:52piet has joined IRC (piet!5b605e82@gateway/web/freenode/ip.91.96.94.130)
12:53
<piet>
@alkisg: so back again I just checked the dmesg-log and indeed the message shows up there, as well. Means the problem is not ltsp-orientated . . .
12:55
@alkisg I aspected this. Because I don't want to write to this medium necessarlily - I don't mind the problem but under native ubuntu the error message appaears in the log, but not on boot-screen . . .
12:55cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Remote host closed the connection)
12:56cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
12:56
<alkisg>
piet: grep append /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
12:56
What's the output of that command?
12:56
<piet>
@alkisg My question was : Is there a chance to prevent this message while booting?
12:56
<alkisg>
(on your server)
12:58
<piet>
wait a minute I'll try it . . .
12:59
@alkisg # grep append /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default append ro initrd=initrd.img quiet splash nbdname=ltsp_i386
13:01
<alkisg>
Sounds OK... piet, please file a bug about this in launchpad
13:01
!ubuntu-bug
13:01
<ltsp`>
alkisg: ubuntu-bug: To file a bug report for Ubuntu LTSP, go to https://bugs.launchpad.net/ubuntu/+source/ltsp
13:02
<piet>
@alkisg ok, I will try my best, thank You
13:12alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
13:17bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
13:37alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
13:53khildin has left IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be, Read error: Operation timed out)
14:01Parker955_Away is now known as Parker955
14:08komunista has joined IRC (komunista!~slavko@adsl-195-098-005-032.dynamic.nextra.sk)
14:12khildin has joined IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be)
14:13[GuS] has joined IRC ([GuS]!~MysT@unaffiliated/gus/x-663402)
14:29mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk)
14:54ba has joined IRC (ba!~ba@airport.kg)
14:55
<ba>
hi guys! can you tell me..how to determine how much megabytes sends LTSP server to the CLIENT before it shows LDM? umm, I guess it's completely depends on a nbd image right?
15:00toscalix has left IRC (toscalix!~toscalix@85.137.146.26.dyn.user.ono.com, Remote host closed the connection)
15:13
<komunista>
ba: I never measure this exactly, but it sends the initrd image, NBD image is not send at all, but mounted via network and after this mount (IMO) only needed files are transferred, to they can be executed/readed and some communication between ldm and ldm server happens...
15:14
<ba>
komunista, got it!
15:14
komunista, thank you!
15:30
is there any way to mount nbd image allowing writes? (i.e not readonly). Say to update it from one Client and then make it readonly again.
15:32
<piet>
@alkisg: Did my best: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/931007, never did that before, one time will always be the 1st time ;-) hope that's professional enough :)
15:33
<alkisg>
piet: very nice :)
15:33
ba: are you using fat clients?
15:33
<ba>
alkisg, yes
15:34
<alkisg>
Currently it's not possible, unless if you switch from nbd to nfs and export it rw and mount only one client etc etc, it's messy
15:34
In some of the next versions it'll be much easier to do it
15:34
<ba>
alkisg, 12.04? :D
15:34
<alkisg>
You'll even be able to boot the chroot with vbox and customize it there
15:35
Half of the necessary stuff will be there in 12.04, but not all of it
15:35
So it will be possible in 12.04 but it will still not be very easy to do it
15:35
<ba>
alkisg, is there any new features coming with 12.04? so we can test?
15:35
alkisg, I would love to test..
15:36
<alkisg>
ba: currently it's not really ready for user testing, only experienced users/developers may help now
15:36
In a couple of weeks, it will be
15:37
<ba>
alkisg, ok. cool. Btw it would be extremely demanding feature since not all the stuff can be installed within the server and ltsp-chroot. Like drivers etc. If we could mount with write permissions we could install those drivers and turn them back to readonly mode..
15:37
alkisg, Citrix's Provisioning Server supports it :D
15:38
<alkisg>
Yeah, I know how cool it will be. E.g. install ubuntu in a client with drivers and everything, apt-get install ltsp-client, copy the result to the server, ready
15:38
No ltsp-build-client necessary
15:38
<ba>
alkisg, exactly
15:38
<alkisg>
Personally I don't care at all about citrix or any other companies though... :D
15:39
<ba>
alkisg, ok. me too now. I avoid their products :D
15:39
<alkisg>
I'm not selling ltsp so I'm not competitive :P
15:39
I'm just using it in my classrooms :D
15:39
<ba>
alkisg, ok ok..I just mentioned it for ideas
15:40
alkisg, if it's not a secret how much clients do you have?
15:40
<alkisg>
It's fun thought that I first thought about this, then tried to implement it, and then a week or so ago I heard that citrix was doing the same thing
15:40
No it's not a secret, personally I've only one school lab but I'm supporting about 250 schools with about 12 clients each
15:41
<ba>
alkisg, cool
15:46
<alkisg>
About new features... the main new feature is what you're saying, i.e. a new direction where the chroots will be able to be upgraded or booted from normal PCs too, or even you'll be able to install ltsp-client to a normal pc and boot it as an ltsp client
15:46
But it's halfway there, not ready yet
15:48
<khildin>
alkisg: does this mean you can have a local copy of the chroot on a standard client?
15:49
<alkisg>
khildin: yes, it also means you can install your distro normally on a standard client and then install ltsp-client, and that's your ltsp chroot, without using ltsp-build-client at all
15:49
<khildin>
that is the best news I have heard in a looooong time... ^^
15:49
how will it deal with updates on the LTSPserver?
15:50
is there a check mechanism that compares local copy with server chroot?
15:50
<alkisg>
You can e.g. have 8.04 chroots with 12.04 servers now, they're not much related to the server
15:50
Ah no I didn't mean what you understood
15:50
<khildin>
then what?
15:50
<alkisg>
It will be possible to boot the local pc with that, yes, but the copying is your responsibility
15:51
<khildin>
can you use a different distro/desktopmanager in chroot than installed in server?
15:51
<alkisg>
Now it's not possible to boot the local pc with an ltsp chroot even if you transfer it yourself
15:51
Sure, you can
15:52
<khildin>
What will be necessary to have that check/copy done automaticly?
15:53
<alkisg>
Someone to implement it? :D Maybe using rsync over ro NFS?
15:53
But it'll be slow, I don't like that method
15:53
I'd prefer a caching solution instead of that
15:53
<khildin>
Actualy I am busy coordinating a desktop sollution for Zentyal server.... and LTSP is one of the possible options...
15:54
<alkisg>
What is a "desktop solution" ?
15:56
<ba>
alkisg, nice. any other tasty features? :D P.S: move on please :D
15:56
<khildin>
a desktop client that actualy is centrally manageble by a sys admin
15:57
<alkisg>
And why rsync locally instead of just netbooting it without a hard disk?
15:58
<khildin>
to limit local bandwith usage?
15:58
<alkisg>
I don't think that will work, updates are very large, caching would limit the bandwidth 10 times better
15:59
<khildin>
cache localy?
15:59
fine with me... :)
15:59
<alkisg>
Yes, whatever the client reads from the network, to store it locally to be reused later, as long as it's not changed on the server
15:59
<khildin>
that's what I am looking for ...
15:59
<alkisg>
Though I don't know of anyone working on implementing this :)
15:59
<khildin>
would be great
16:00
and also would be usable for 'road warriors' that are not on the network
16:00
or am I asking too much now?
16:00
:D
16:00
<alkisg>
Sure, it would
16:00
<ba>
alkisg, can you confirm that currently if Fat Clients changes something (like installs a program) all the changes are in RAM and not on the server?
16:01
<alkisg>
ba: yup
16:01
Also he normally can't install anything, sudo doesn't work
16:01
<ba>
alkisg, but it's root (with SCREEN_02=shell)
16:01
<alkisg>
ok then
16:01
As you said it
16:01
<ba>
alkisg, I am installing stuff and testing there normally
16:02
alkisg, I was just wondering...if nbd is read only..where does it store it's changes
16:02
<alkisg>
a tmpfs in the client RAM
16:02
nbd on the server, tmpfs in ram, both merged with aufs or overlayfs
16:02
<ba>
alkisg, and in no way in the server?
16:02
<alkisg>
Right
16:02
<ba>
alkisg, thanks! (I was wondering why my server becomes out of space sometimes..strange)
16:03
<alkisg>
When you run ltsp-update-image and clients are booted, then the /opt/ltsp/images/i386.img file is deleted, but the space isn't freed,
16:03
until all clients are rebooted and connections closed
16:04
<ba>
alkisg, how is that possible? (file is deleted but the space isn't freed)
16:04
alkisg, but it makes sense 100%
16:04
<alkisg>
That's how linux does it, files in use are not freed
16:04
<ba>
alkisg, it explains everything
16:05
<alkisg>
That's also how updates work, while you're using the existing programs/services etc
16:05
(apt-get update)
16:05
<ba>
alkisg, but after ltsp-update-image is finished my clients shows a lot of squashfs errors. Does it mean that they are not connected to server anymore?
16:06
<alkisg>
They shouldn't show squashfs errors. Yes, it probably means they lost the nbd connection.
16:07
<ba>
alkisg, my server is Ubuntu server 11.10 32bit. mmm.
16:07
<alkisg>
Another new feature (which doesn't come from ltsp) is btrfs, you can create a partition-in-a-file, even with btrfs compression=on, and serve that
16:07
<ba>
alkisg, thank you! finally I know what's the h*** was happening
16:07
<alkisg>
So you won't need ltsp-update-image at all
16:07* alkisg goes back to writing some code...
16:08
<ba>
alkisg, this is...awesome! (btrfs, I am waiting for it many months) P.S: see ya
16:27markit has joined IRC (markit!~insegnant@dynamic-adsl-84-223-84-28.clienti.tiscali.it)
16:28
<knipwim>
i'm wondering how big a typical thin client nbd image is for others distro's then gentoo
16:29
i'm at 394mb now
16:30
<markit>
hi, I've a pc that goes to 800x600 or something more instead of 1280x1024. In lts.conf I've put [00:15:f2:54:bf:9d] and then XRANDR_MODE_0=1280x1024 but seems not to take effect
16:30
maybe hw does not support? or is not taken ?
16:30
or should mac address be in capital letters?
16:31
<knipwim>
the mac adress is ok
16:32killermike has left IRC (killermike!~killermik@2.26.103.46, Remote host closed the connection)
16:47
<knipwim>
[GuS]: i may have a clue on the tftp ltsp download issue
16:51
<alkisg>
knipwim: about 773 MB in Ubuntu 10.04
16:52
280 MB the compressed nbd image
16:52
markit: what's the output of xrandr in that pc?
16:57Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com)
17:01
<stgraber>
alkisg: Scott James Remnant is no longer active in Ubuntu development but my time is the one maintaing plymouth so I can have a look
17:03alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
17:03
<stgraber>
alkisg: 17:01 < stgraber> alkisg: Scott James Remnant is no longer active in Ubuntu development but my time is the one maintaing plymouth so I can have a look
17:03
alkisg1: ^
17:03alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 245 seconds)
17:04
<stgraber>
alkisg1: ok, I found the bit in the code that does it, it doesn't actually check for the value of init=, it just exits whenever init= is set
17:05alkisg1 is now known as alkisg
17:05
<stgraber>
alkisg: can you add "plymouth:force-splash" to your boot command line?
17:05
<alkisg>
Hey stgraber, I'm going to pick up my kids, I'll be back in 10 minutes or so
17:05
<stgraber>
alkisg: this should bypass the check and show the splash
17:05
<alkisg>
stgraber: see the pad notes
17:05
Yes, it does
17:05
<ba>
knipwim, my image is 1.5Gigs
17:06
<knipwim>
ba: fat client?
17:06
<ba>
markit, look at your X logs
17:06
knipwim, ummm yeah :D
17:06
knipwim, you are right
17:07
<alkisg>
stgraber: err sorry I meant see the bug report, I wrote the possible workarounds there: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/930865
17:07
(but also see the pad for non-plymouth-related stuff)
17:07
bbiab
17:21
<markit>
ba: I've set a different resolution and in fact it uses it, the strange is that I've 12 SAME pc that gets automatically teh correct resolution
17:21
and that one that does not, even if forced
17:21
I've resetted the bios to defaults, and re-set like the others, but no way
17:21
very strange, I give up for today
17:22
<ba>
markit, so you have 12 SAME pc's and ONE of them behaving strangely? is that correct>?
17:22
<markit>
ba: yes!
17:23
<ba>
markit, i.e. it's not using forced resolution?
17:23khildin has left IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be, Ping timeout: 260 seconds)
17:23
<markit>
ba: none of them use anything in lts.conf and work fine except one
17:23
<ba>
markit, have you looked at your X logs? (in a thin client itself)
17:23
<markit>
at least, the MB is the same, maybe bios version could be different
17:23
<ba>
markit, graphic card is the same?
17:24
<markit>
ba: sorry not, I missed your post (was working in the room with some wires) and disconnected and put away that foulty
17:24
ba: is shown in x logs? I've no live cd to try
17:24
<ba>
markit, use SCREEN_02=shell and look at your /var/log/X.0.log (or something)
17:24
<markit>
oh, well, I've one, sysrescuecd, let me check
17:25
<ba>
markit, no! you have to check the X logs in your Client's machine and not in your server
17:26
markit, and look for "EE" or "WW" messages in that file (/var/log/Xorg.0.log or /var/log/Xorg.1.log)
17:26
<markit>
ba: ok, I was going to boot the client with systrescue cd and look at lspci
17:26
but ok :)
17:26
<stgraber>
alkisg: I've replied on the pad. I'll upload a new snapshot now.
17:27
<ba>
markit, your issue looks like a graphics driver issue
17:27
<alkisg>
stgraber: back, reading...
17:28
markit: your client boots in 800x600, right? Why not upload the output of xrandr so that we can see it?
17:28
<markit>
ba: yes, the strange thing is that affects only one
17:28
alkisg: it boots at 960x800 or something, I forced to 800x600 and took the parameter, so it sees my config
17:29
<stgraber>
alkisg: uploading now
17:29
<alkisg>
markit: ok, since it boots you don't need sysresccd or anything
17:29
<markit>
let me log there and connect to konversation
17:29
<ba>
markit, are you using it as a fat client?
17:29
<markit>
thin client
17:30markit_client has joined IRC (markit_client!~federico4@dynamic-adsl-84-223-84-28.clienti.tiscali.it)
17:30
<markit_client>
hi, xrandr says
17:30
Screen 0: minimum 320 x 240, current 960 x 600, maximum 960 x 600
17:30
so it's gotting it's maximum
17:31
<alkisg>
markit_client: try X_HORZSYNC=30-88 and X_VERTREFRESH=55-72 in lts.conf
17:31
<markit>
is a 17" lcd screen
17:32
(just in case you know those parameters can break it :))
17:32markit_client has left IRC (markit_client!~federico4@dynamic-adsl-84-223-84-28.clienti.tiscali.it, Remote host closed the connection)
17:32
<ba>
markit, btw (lol) how about monitors? are they same too?
17:32
<markit>
yes
17:33
I umplugghed from a OK pc and plugged there
17:34
<alkisg>
stgraber: we can't do the complete switch to using the nbd initramfs script + the nbdroot=host:port/path, because we need udhcpc for network configuration, right? (I don't, but I think it was needed for dhcp updates?)
17:34
<markit>
alkisg: much better but monitor says "out of range!!!" :)
17:34
<alkisg>
markit: do you have epoptes?
17:34
in that lab?
17:34
<markit>
how could not have? :) sure
17:34
<alkisg>
OK, open a root console for that client,
17:34
run: export $(/usr/share/epoptes-client/get-display)
17:34
<markit>
last time I tried did not worked
17:34
<alkisg>
and then: xrandr
17:35
<markit>
do you mean "root remote"?
17:35
<alkisg>
Root, local
17:35
<markit>
ok
17:35
<stgraber>
alkisg: yeah, we need udhcpc otherwise IPs will be given to other clients and the existing one will just freeze
17:35
<markit>
alkisg: I've a blank screen and the cursor, no prompt
17:35
<ba>
markit, wait
17:35
<stgraber>
alkisg: new ltsp is building in the ppa now
17:35
<markit>
and the title of the window is "socat"
17:36
<ba>
markit, I think alkisg meant you to use SCREEN_02=shell or something
17:36
<alkisg>
stgraber: normally dhcp3-server pings before giving the ip elsewhere, but ok, let's not do things in a hurry. But note that we *can't* use nbdroot=xx now, since nbd uses that
17:36
<markit>
alkisg: but really, better you mind ltsp project, your time is much better spent there is not urgent here
17:36
ba: do you know epoptes project? www.epoptes.org
17:37
<alkisg>
markit: can you put LDM_AUTOLOGIN, LDM_USERNAME and LDM_PASSWORD for that user, so that it automatically logs in?
17:38
It's easier to check with xrandr the monitor timings then
17:38
<ba>
markit, no
17:38
<stgraber>
alkisg: yeah, but the setups where we had the issue is with a cluster of DHCP servers serving > 10000 IPs over hundreds of VLANs with the firewalling preventing the DHCP servers from talking to the clients (like most corporate/governement network will do)
17:38
(the switches relay the DHCP queries so the DHCP server never talks to the clients directly)
17:38
<ba>
markit, (thanks for the link!, very interesting)
17:39
<alkisg>
stgraber: ok, in the future we may try ipappend 3 in the initramfs, and dhclient --renew-ip-or-something in the real file system, but let's leave all that for later. So currently we can't use the nbd script.
17:40
<stgraber>
yeah, we can try that for 12.10
17:40
<alkisg>
stgraber: do you mind if we have a really long kernel command line? boot=ltsp_nbd plymouth:force-splash init=/sbin/ltsp-init etc?
17:40
That's 3 additional parameters from previously...
17:40
<stgraber>
alkisg: nope, as long as it's not longer than the maximum size, I'm fine ;)
17:40
<alkisg>
Hehe, no, it's not
17:40
<markit>
alkisg: ok, I removed the timing thing (not to break the monitor) and added those parameters, ok?
17:41
<alkisg>
markit: no leave the timings too
17:41
...but,
17:41
also put: XRANDR_MODE_0=1024x768
17:41
<markit>
native res is 1280x1024
17:41
<alkisg>
It doesn't matter
17:41
We just want the output of xrandr, when not limited by broken EDID
17:41
But I suppose you're *sure* that the monitor can show more than 960xwhatever,right?
17:42
<markit>
yes, really sure
17:42
<alkisg>
ok
17:42
<markit>
btw,. now works fine
17:43
and no error from the monitor about frequency
17:43
<alkisg>
Nice, what's the output of xrandr now?
17:43
<markit>
epoptes root local? let me try
17:43
<alkisg>
markit: no now do user-local
17:43
It's easier since you logged in
17:44
<markit>
you mean I go there and open a terminal there, right?
17:44
<alkisg>
markit: no, from epoptes
17:44
Open terminal > user, local
17:45
<markit>
alkisg: I get a blank window with a cursor but no prompt
17:45
and if I enter a command and press ENTER nothing happens
17:45
<alkisg>
markit: something's wrong there, we need to see what it is, but ok go and try it locally on the client
17:46
<[GuS]>
knipwim: sorry, just recently read you
17:46
<markit>
locally tells me that max res is now 1680x1200
17:46
<[GuS]>
knipwim: what could be the problem?
17:46
<knipwim>
nice
17:46* [GuS] brb
17:46
<alkisg>
markit: ok, now try xrandr -s 1280x1024
17:48
<markit>
ehm I'm already at that res
17:48
I set that in lts.conf
17:48
<alkisg>
Ah ok then
17:48
So you're good to go :)
17:48
<markit>
yes, but don't know why :) does not matter at all now, thanks a LOT
17:48
<alkisg>
If you have time, I'd like to see why user > local terminal etc does not work
17:48
markit: it's because the driver couldn't read properly your monitor's timings
17:49[GuS] has left IRC ([GuS]!~MysT@unaffiliated/gus/x-663402, Remote host closed the connection)
17:49Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving)
17:49
<markit>
alkisg: I have time sure
17:49
<alkisg>
stgraber: btw I've just tried to make a btrfs "partition" in /opt/ltsp/images/i386.img with dd/mkfs.btrfs, then I loop-mounted -o compress that to /opt/ltsp/i386 and then I ran ltsp-build-client. The result was 1.3 Gb while `du -sh` showed 2.4 Gb, pretty good. I'm sure that can now be directly booted with `nbd-server -c`, without tmpfs/aufs, and with init=/sbin/ltsp-init. :)
17:50
markit: vnc? alkisg.dyndns.org
17:50
(from the server and maybe after that from the client too)
17:52
<markit>
ok, done from the server
17:52
I've modified lts.conf in the meantime
17:52
removing autologin, should I put there again?
17:52
<alkisg>
no need
17:52
<markit>
(was not reading chat...)
17:52
<alkisg>
markit: since you have a thin client, you need x11vnc -noshm -connect alkisg.dyndns.org
17:53
<stgraber>
alkisg: well, one client will be able to boot it if exported read/write but that's it. Otherwise you'll need nbd's copy-on-write which will kill your network because all the writes will happen on the server
17:54
<alkisg>
stgraber: nbd-server -c is copy on write, yes
17:54
And the diff is only about 10 mb per client
17:54
...which would go on the client tmpfs, so sometimes in NBD_SWAP, so again on the server anyway
17:54
<stgraber>
right, that'd indeed work but would be pretty bad in case of disconnects not to mention what happens when you have 5000 clients ;)
17:55
<alkisg>
I think it's much less than what the clients need while booting
17:55
<stgraber>
not to mention a "dd if=/dev/urandom of=/tmp/blah" on a client will kill your server ;)
17:55
<alkisg>
Caching is still local to the client
17:56
It'll write as much as the virtual disk free space, which can be arranged to be e.g. 500 mb
17:57
I haven't tried anything in such big setups, but for low-end clients the result was more free mem locally ==> faster client
17:57
markit: can you login to that client and vnc to me from there?
17:58
<markit>
witrh the above command?
17:58
-noshm?
17:58
<alkisg>
Yes
17:58
<stgraber>
yeah, offering a few more storage options might be interesting in the future but I'd likely keep squashfs+overlayfs+tmpfs as the default as it's well tested (that's what we have for the livecds) and works pretty well
18:00
<alkisg>
Sure. stgraber btw we try to allocate swap from the server in ltsp_nbd for clients with <100 mb ram, I think that can be moved to initramfs-scripts.d too, should I put it there?
18:00
So that the 2 tries for NBD swap allocation are merged into one (and remove it from ltsp-init-common)
18:00
<stgraber>
yes, there shouldn't be any change between doing it from initramfs or doing it just before init
18:01
<alkisg>
We're on the real file system now, so I think we can use the encryption stuff which we couldn't do from the initramfs
18:01
The 60 seconds delay isn't there for thin clients, and I've yet to try the emit thing you told me for the fat clients which have the problem
18:02
<stgraber>
I'm actually surprised thin clients don't have the issue, they actually probably do but it's just not visible as what we care about is started before that
18:03
actually, I have an idea which should fix both cases
18:03
can you write a new /etc/network/interfaces containing only:
18:03
auto lo
18:03
iface lo inet loopback
18:03
auto <current interface>
18:03
iface <current interface> inet manual
18:04
where <current interface> will likely be eth0 (not sure if we currently hardcode eth0 in the initramfs code)
18:05
hmm, actually, not sure that'll work ...
18:05
alkisg: on the machine where you get the 60s delay, can you look at what's in /etc/network/interfaces?
18:05
<alkisg>
stgraber: yeah that code works, the interfaces is like you said above
18:06
<stgraber>
alkisg: ok, might be worth trying to remove eth0 from /etc/network/interfaces, only keeping the loopback in there
18:06
<alkisg>
No then network-manager breaks the connection completely
18:06
<stgraber>
ah right, network manager ... ;)
18:06
<alkisg>
Give me some minutes to check a problem with epoptes on markit's class and I'll try more tests, including the emit thing, or removing more services...
18:07
<stgraber>
ok, you need to emit static-network-up then, having it emitted for both thin and fat clients would be best
18:08
alkisg: http://paste.ubuntu.com/839388/ should do the trick
18:08
alkisg: that's an upstart job to dump in /etc/init/ of the client
18:09
<alkisg>
ty, will try it in a few
18:09khildin has joined IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be)
18:13
<alkisg>
markit: the epoptes daemon needed a restart, but I don't know what troubled it. Can you mail me /var/log/epoptes.log?
18:13
It should be working ok from now on...
18:13
<markit>
sure, give me privately your email
18:13
<alkisg>
alkisg at gmail
18:14ba has left IRC (ba!~ba@airport.kg)
18:15
<markit>
done, I've to run thanks a lot
18:15markit has left IRC (markit!~insegnant@dynamic-adsl-84-223-84-28.clienti.tiscali.it, Remote host closed the connection)
18:16mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Ping timeout: 248 seconds)
18:19dptech has joined IRC (dptech!~dptech@can06-1-82-242-223-39.fbx.proxad.net)
18:22map7 has left IRC (map7!~map7@teksup41.lnk.telstra.net, Ping timeout: 245 seconds)
18:22map7 has joined IRC (map7!~map7@teksup41.lnk.telstra.net)
18:28vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
18:31mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk)
18:39
<alkisg>
Meh I didn't update ltsp_nbd and the code that adds "eth0 manual" to /etc/network/interfaces ran twice... let me remove that and test again...
18:39vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Quit: leaving)
18:41vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
18:43vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Client Quit)
18:45vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
18:47vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
18:50
<alkisg>
Without the duplicate "eth0 manual" entry, a VM thin client boots in 50'. Not too bad, but we may want to remove more services...
18:52
As a fat client too, so stgraber I didn't even have to try the upstart job you suggested.
18:54vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Quit: leaving)
18:54vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net)
18:54
<alkisg>
...btrfs does eat up a lot of ram though :(
18:57
<stgraber>
alkisg: cool
18:58
<alkisg>
!ubuntu-2d
18:58
<ltsp`>
alkisg: ubuntu-2d: To select ubuntu-2d as your default session, put this line in your lts.conf: LDM_SESSION="gnome-session --session=ubuntu-2d"
19:06
<alkisg>
stgraber: about resolvconf, did you put the relevant code in nfs-bottom/ltsp?
19:07
mkdir -p /run/resolvconf/interface/ ==> that's missing "$rootmnt" in front...
19:07
But shouldn't we move that too, to the initramfs-scripts ?
19:08
Let's save the initramfs environment to ltsp_config, and move that code from nfs-bottom/ltsp to initramfs-scripts.d...
19:10
Errr we basically don't need nfs-bottom/ltsp at all now, do we?
19:12
<stgraber>
alkisg: it's not missing $rootmnt
19:12
alkisg: /run in the initramfs is moved to $rootmnt/run at the end of the initramfs script
19:13
alkisg: so the initamfs script needs to create it in /run/ for it to appear in $rootmnt/run afterwards
19:13
<alkisg>
stgraber: ah, I see, so something else goes wrong and it doesn't end up in the real system
19:14
<stgraber>
it does in current Ubuntu (5.2.16) with the code I copy/pasted from trunk, so something after that broke it
19:14
do you see /run/resolvconf/interfaces/LTSP at all in your case?
19:14
<alkisg>
No
19:15
<stgraber>
ok, that's pretty weird
19:15
<alkisg>
Ah and /me needs to remember to disable screensaver locking for fat clients... it's broken now with gsettings
19:16
<stgraber>
alkisg: oh, I think I know why. 50-resolv-conf contains $rootmnt in the checks
19:16
alkisg: as it's called in the chroot, it shouldn't have $rootmnt there
19:17
<alkisg>
stgraber: hmmm well, I've switched to using init=/sbin/ltsp-init, right?
19:17
So DNS_SERVER isn't available at that point if we don't save it before
19:18
We can copy /tmp/net-eth0.conf somewhere in the real system, if we need it, or store the vars we want to ltsp_config
19:19
<stgraber>
ok, I fixed 50-resolv-conf but it'll need the final /run to be mounted (that's the case if ran from ltsp-init, not if ran though chroot in initramfs) and requires the environment variables to be set
19:20
yeah, if we want to deal with resolv.conf from initramfs-scripts, we need to save the environment, otherwise we need to keep doing it in ltsp_nbd
19:20
<alkisg>
stgraber: to save the vars in ltsp_nbd: http://paste.ubuntu.com/839513/
19:21
***in ltsp_config, I mean
19:22
grep -v '=$' /tmp/net-*.conf >> "$rootmnt/var/cache/ltsp/ltsp_config"
19:22
<stgraber>
looks reasonable
19:22
and I assume you already source ltsp_config in init-ltsp?
19:22
<alkisg>
Yes, it's done by ltsp-common-functions
19:46Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!")
19:48alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg)
19:50alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 260 seconds)
19:50alkisg1 is now known as alkisg
19:58vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Ping timeout: 260 seconds)
20:06komunista has left IRC (komunista!~slavko@adsl-195-098-005-032.dynamic.nextra.sk, Quit: Leaving.)
20:14sepski has left IRC (sepski!~sep@40.211.jostedal.no, Ping timeout: 240 seconds)
20:34markit has joined IRC (markit!~marco@88-149-177-66.staticnet.ngi.it)
20:41piet has left IRC (piet!5b605e82@gateway/web/freenode/ip.91.96.94.130, Quit: Page closed)
21:13dptech has left IRC (dptech!~dptech@can06-1-82-242-223-39.fbx.proxad.net, Quit: When two people dream the same dream, it ceases to be an illusion. KVIrc 3.4.2 Shiny http://www.kvirc.net)
21:18loather has joined IRC (loather!~khudson@wsip-98-175-250-115.sd.sd.cox.net)
21:24alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
21:43mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Quit: Leaving)
21:48bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Quit: Goin' down hard)
21:51khildin has left IRC (khildin!~khildin@ip-80-236-212-243.dsl.scarlet.be, Quit: I'm gone, bye bye)
22:10loather-work has joined IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net)
22:13veloutin has left IRC (veloutin!~veloutin@modemcable121.135-59-74.mc.videotron.ca, Read error: Connection reset by peer)
22:34ByPasS has left IRC (ByPasS!pbernier@nat/revolutionlinux/x-pqilphefkadalwcs, Ping timeout: 245 seconds)
22:34ByPasS has joined IRC (ByPasS!pbernier@nat/revolutionlinux/x-djfshhamszrvsmtj)
22:39alexqwesa_ has joined IRC (alexqwesa_!~alex@alexo-veto.broker.freenet6.net)
22:39alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Read error: Connection reset by peer)
23:28loather-work has left IRC (loather-work!~khudson@wsip-98-175-250-115.sd.sd.cox.net, Quit: This computer has gone to sleep)
23:43markit has left IRC (markit!~marco@88-149-177-66.staticnet.ngi.it, )