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


Channel log from 8 February 2010   (all times are UTC)

00:10Faithful has quit IRC
00:23F-GT has quit IRC
00:25Faithful has joined #ltsp
00:39F-GT has joined #ltsp
02:03frederickjh1 has joined #ltsp
02:03frederickjh1 has left #ltsp
02:04frederickjh1 has joined #ltsp
02:06frederickjh1 has left #ltsp
02:08alkisg has quit IRC
02:10alkisg has joined #ltsp
02:19gnunux has joined #ltsp
02:21frederickjh has joined #ltsp
03:08avolkovi has joined #ltsp
03:20
<frederickjh>
Anyone here using the new ltsp cluster packages with Ubuntu LTSP on Karmic 9.10?
03:21
I have a Karmic LTSP install now and am wondering about the upgrade path to ltsp cluster?
03:26
<appiah>
upgrade?
03:40ogra has quit IRC
03:48ogra has joined #ltsp
04:02bobby_C has joined #ltsp
04:08ogra has quit IRC
04:16ogra has joined #ltsp
04:25frederickjh has quit IRC
04:29
<alkisg>
stgraber, highvoltage: just noticing that I did try adding `dpkg-divert initctl` to 000-daemon-handling, and while the clients boot fine with the diversion, that didn't solve the problem of $CHROOT/proc being in use right after a fat client installation. So I forced umount -l in ltsp-update-image for now. :-(
04:40
<highvoltage>
alkisg: ok
04:44
<ogra>
alkisg, meh, cant you do it from the plugin in the finalization stage instead ?
04:45
<alkisg>
ogra: there was already a call to umount in ltsp-update-image...
04:46
<ogra>
yes, but a proper one
04:46
<alkisg>
Hmmm how proper is it? :)
04:46
<ogra>
-l should really only be used as a workaround ...
04:46
<alkisg>
If the user installed something in the chroot manually, ltsp-update-image will still have problems
04:46
<ogra>
so if your plugin makes it break, your plugin should have the workaround as well
04:47
<alkisg>
It's not exactly a problem with the plugin. The same can happen if the user installs something manually in the chroot.
04:47
<ogra>
(the filesystem stays physically mounted with -l ... its just hidden everywhere)
04:47
(in case of proc that will damage your server)
04:47
<alkisg>
We need to find which daemon does that, and a way to bypass it
04:47
It isn't upstart - related, and it isn't hal. I don't know what it is.
04:47
<ogra>
you need to fix the daemon handling indeed
04:48
not using -l in ltsp-update-image was done deliberately though
04:48
to save the user from wiping his server setup
04:48
<alkisg>
How would not using it save the user?
04:48
<ogra>
it blocks
04:48
<alkisg>
It doesn't...
04:49
<ogra>
so the user has to unmount it in the chroot first
04:49
<alkisg>
It just causes a hell of errors in the squashfs
04:49
<ogra>
ltsp-update-image will fail rolling the squashfs
04:49
<alkisg>
It didn't fail for me
04:49
<ogra>
it should
04:49
<alkisg>
It just created a squashfs with a lot of /proc/* empty files in it
04:49
<ogra>
then something changed and nobody updated the code accordingly
04:50
in any case ltsp-build-client shouldnt move on if /proc is still mounted
04:50
since that can severely damage the host
04:50
<alkisg>
build-client? or update-image?
04:50
<ogra>
update-image, sorry
04:50
<alkisg>
I'm not sure I understand this
04:51
<ogra>
too many tools with similar names :)
04:51
<alkisg>
The problem is there, sure. But how can creating a squashfs damage the server?
04:51
<ogra>
having proc mounted gives you full access to the server HW and all running processes of the host system
04:51
<alkisg>
But ltsp-update-image runs *on the server* not on the chroot...
04:51
It already has full access.
04:52
So now I'm just generating a visible error on the user, instead of a filesystem with /proc in it..
04:58
<ogra>
wow, ltsp-update-image changed a lot ... so the proc unmounting doesnt block anymore apparently ... and the forcefully excluding of proc in the mksquashfs call was dropped as well
04:58
(it used to have -e cdrom proc)
04:59
and "umount ${CHROOT}/proc" used to be "umount ${CHROOT}/proc || exit"
05:01hersonls has joined #ltsp
05:01
<alkisg>
Ugh :)
05:01
I also proposed excluding proc from the squashfs command line...
05:03
If `umount ${CHROOT}/proc || exit` was still there, I'd just modify the finalization plugin... :-/ anyway
05:03
<ogra>
either way i wouldnt use -l
05:04
<alkisg>
The main problem is that I have no clue on how to find what uses /proc
05:04
<ogra>
only for temporary workarounds
05:04
<alkisg>
And without umount -l, the fat client plugin wouldn't work in many cases...
05:05
<ogra>
right, as i said ... temporary ... but that should definately be solved before releasing it
05:05
<alkisg>
How? :)
05:05* alkisg is all ears!
05:05
<ogra>
no idea, i have no time to work on ltsp atm
05:05
else i'D do some testbuilds
05:06
<alkisg>
I even tried killing almost everything on the server when $CHROOT/proc was in use, but that didn't help!
05:06
<ogra>
unlikely that its something that runs on the server
05:06
<alkisg>
I wonder if it's some mysterious upstart interprocess communication with sockets involved in this...
05:06
<ogra>
might be
05:07
look at the code :)
05:07
<alkisg>
Right... only 10.000.000 lines of code, shouldn't take long... :D
05:07
<ogra>
upstart isnt that big
05:07
<alkisg>
I did try dpkg-divert'ing upstart (initctl) like the karmic release notes advice. To no avail...
05:07
<ogra>
and grepping for proc shouldnt take long in upstarts source
05:08
but i doublt upstart uses proc ... its more likely using something in /var for IPC
05:09* alkisg thinks that the correct solution will be when we use lxc or qemu to build/test/update the chroot :D
05:10
<ogra>
ugh, why qemu ?
05:10
thats definately a waste over a chroot
05:10
i see a reason to use lxc with chroots in general though
05:16
<alkisg>
Doesn't qemu also emulate different architectures?
05:16
<ogra>
it does
05:16
<alkisg>
(for e.g. powerpc clients...)
05:16
<ogra>
but there is no reason to use it if you dont need to
05:17
i.e. waste all the computing power (and slow down everything significantly) surely makes no sense if you build on x86 compatible HW for x86 compatible clients
05:18mikkel has joined #ltsp
05:40pmatulis has joined #ltsp
06:03avolkovi has quit IRC
06:33pmatulis has quit IRC
06:44vvinet has quit IRC
06:59
<alkisg>
Hrm. It seems like the tftpd-hpa problem also affects debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551828
07:00
Up until Karmid, tftpd-hpa.postinst used inetd and /var/lib/tftpboot
07:00
Now it runs as a daemon by default, and uses /srv/tftp
07:01
That debconf setting also has a high priority, so the user is prompted to verify that this is the correct directory.
07:02
So should LTSP in Ubuntu switch to /svr/tftp as well?!
07:03gnunux has quit IRC
07:04lucascoala has joined #ltsp
07:05gnunux has joined #ltsp
07:08
<_UsUrPeR_>
good morning
07:09jammcq has quit IRC
07:09lucascoala has quit IRC
07:09
<ogra>
alkisg, if tftp-hps is used it should pull the settings from /etc/default imho
07:09
at least for new builds
07:10
<alkisg>
ogra, I installed Lucid 3 days ago...
07:10
<ogra>
existing installs should be covered by the tftp-hpa fix
07:10
<alkisg>
(re-installed :))
07:10
<ogra>
(which might not have entered lucid yet)
07:11
<alkisg>
Hmmm
07:11
Got it, thanks. Looking...
07:11
<ogra>
hmm, nov 2009 ... that should definately be in testing and thus in lucid
07:11
probably the fix didnt work right
07:11
but the file shouldnt be touched on upgrades
07:13
if you see issues with upgrades, file a bug :)
07:13
<alkisg>
ogra, but what about new installations?
07:14
Is the user expected to manually modify the path to /var/lib/tftpboot ?
07:14
(and also put it to inetd.conf?)
07:14
<ogra>
no
07:14
no
07:14
ltsp should properly follow the new defaults
07:14
but definately not break on upgrades
07:15
<alkisg>
Then I should probably file a bug in LTSP for it
07:15
<ogra>
check with vagrant what he did for debian
07:15
<alkisg>
...and we should also modify a lot of wiki pages... hmm... :-/
07:15
<ogra>
definately
07:15
<alkisg>
k, I'll try to contact stgraber and vagrantc later on. Ty! :)
07:16
<ogra>
i'm sure vagrant already dealt with that for debian/testing
07:16
should just be an issue of copying some code
07:16* alkisg is modifying sch-scripts to conflict with tftpd-hpa and use only dnsmasq for the time being... Good thing that stgraber lowered tftpd-hpa to recommends! :D
07:22etyack has joined #ltsp
07:23shawnp0wers has joined #ltsp
07:29Kicer86 has joined #ltsp
07:29cliebow has joined #ltsp
07:30
<cliebow>
a
07:40
<appiah>
b
07:41
<ogra>
c
07:43
<alkisg>
d
07:45
<alincoln>
f
07:45
oops
07:45highvoltage has quit IRC
07:46
<ogra>
you broke at !
07:47
*it
07:47highvoltage has joined #ltsp
07:47
<alincoln>
ah, darnit!
07:47
:P
07:51cliebow has quit IRC
07:51cliebow has joined #ltsp
08:02cliebow has quit IRC
08:02cliebow has joined #ltsp
08:06cliebow has quit IRC
08:07cliebow has joined #ltsp
08:09slidesinger has joined #ltsp
08:14highvoltage has quit IRC
08:28Gadi has joined #ltsp
08:31pmatulis has joined #ltsp
08:33GodFather has joined #ltsp
08:34highvoltage has joined #ltsp
08:38
<sbalneav>
Morning all
08:40
<alkisg>
Good morning sbalneav
08:42
<sbalneav>
looks like tftp-hpa's changed?
08:42
<alincoln>
yeah, an update to that broke my lucid stuff.
08:46cliebow has quit IRC
08:46
<alkisg>
Heh, LTSP 5.2 will also need a tftp dir change :)
08:46cliebow has joined #ltsp
08:46
<alkisg>
(for debian/ubuntu, that is....)
08:47
I think it's a good time to get rid of that 2000 port as well :D
08:47CAN-o-SPAM has joined #ltsp
08:54
<sbalneav>
alkisg: What we ought to do is apply to IANA and get an assigned port number.
08:54
<alkisg>
sbalneav: hmmm I just happen to know the right person to do that... :D
08:55
But we might need more than one number
08:55
(i.e more than one chroots)
08:55
<sbalneav>
Yeah,we'd need 2
08:55
Well, I don't think you can be greedy
08:55
I think one for root and one for swap's all you can pretty much ask for.
08:55
<alkisg>
2 for chroots + 1 for nbdswapd?
08:56
<sbalneav>
one for i386, one for x64?
08:56
<alkisg>
one for fat, one for nvidia clients... whatever
08:56
Usage cases might vary
08:57
<sbalneav>
Well, the specifiction process doesn't go like that.
08:57
<alkisg>
I wonder if we should always be passing the port as a kernel parameter...
08:57
<sbalneav>
You have to be VERY explicit about what each port's going to be used for
08:57
You can't just say "We want 3 ports"
08:58
IANA says, "yeah, you and everyone else. There's 65535 of 'em, why should we assign you 3? " :)
08:58
<alkisg>
Roger that. I'm just saying that it would be nice to have swapd first and nbdroot second, so that we may... abuse the ports a little to add extra chroots
08:59
Those extra chroots will be per-site anyways...
08:59
<sbalneav>
Well, iana aside, where would we put them?
08:59
<alkisg>
9571 + ?
08:59
<ogra>
just make sure to properly handle upgrades :)
08:59
<sbalneav>
i.e. what number/range do we want?
09:00
<alincoln>
are there stretches in the port numbers that IANA sets aside that they won't assign?
09:00
possibly those can be assumed to be "clearer".
09:00
<alkisg>
9571 = ldminfod, 9572 = nbdswapd, 9573 = nbd-server
09:00
<sbalneav>
ogra: Would "properly handle upgrades" mean, you need to re-run ltsp-update-image to install the image on the new port?
09:00
or something more automagic?
09:00
<alkisg>
(and, additional, not iana-approved chroots, to 9574+...)
09:01
<ogra>
sbalneav, adjust inetd.conf if you upgrade the server side
09:01frederickjh has joined #ltsp
09:01
<alkisg>
ogra: I disagree with that tactic. That's what makes people still use woody and dapper. If it broke on updates, they'd upgrade... :D
09:01
<ogra>
and dont forget if you have 10 chrtoots you will need $portnum+10 free
09:02
alkisg, if it broke on upgrades they would go to redhat since thats default behavior :P
09:03
<sbalneav>
Now, now :)
09:03* Gadi suggests a config file for ltsp-update-kernels (or whatever will write to inetd.conf) to pull from
09:05
<Gadi>
/etc/ltsp-update.conf
09:05
er, /etc/ltsp/ltsp-update.conf
09:05
<alkisg>
Gadi, it's currently called /etc/ltsp/update-kernels.conf
09:06
<ogra>
Gadi, that doesnt help during upgrade ... should be handled by posinst scripts
09:06Comete has joined #ltsp
09:06
<Comete>
hi
09:06
<Gadi>
the postinit scripts should include a call to ltsp-update-whatever-changes-the-ports
09:06
<ogra>
right
09:06
<Comete>
i'm trying to setup an Edubuntu 9.10 LTSP server for a school
09:07
<alkisg>
Hi
09:07
<Gadi>
we should probably have a flag to ltsp-update-image that just updates inetd.conf and skips updating the image
09:07
<Comete>
after updating my server, i've rebuild the chroot environment with ltsp-build-client
09:08
<sbalneav>
You know what's really missing from /etc/group? a gcos field.
09:08
<Comete>
but know when i boot my thin clients i get error about "mtab"
09:08
<alkisg>
Would that help in solving the LTSP ports problem? :P
09:09
<ogra>
sbalneav, heh, feel free to get into a 5 year discussion with upstream *g*
09:09* ogra personally agrees though
09:09
<alkisg>
Comete, the mountall warnings are "normal"... what's your actual problem?
09:10
<ogra>
Gadi, ltsp-update-image should get similar options to update-initramfs imho
09:10
and we should probably add a timestamp to the image name
09:10
<Gadi>
why?
09:11
<ogra>
to only update specific images
09:11
<Comete>
alkisg: normal ?
09:11
alkisg: i didn't get this before rebuilding the chroot
09:11
<ogra>
so you can have the same chroot but subsequently add stuff and just call ltsp-update-image
09:12
<alkisg>
Comete: what's the exact wording of that error?
09:13
"according to mtab, <filesystem> is already mounted"?
09:14
<ogra>
these are just warnings ... not errors, dont do any harm
09:15
<Comete>
alkisg: ok thanks, so next problem :)
09:15
if i try to reboot i get a lot of SQUASHFS errors
09:16
"Unable to read page, block ..."
09:16
and the thin client doesn't reboot
09:16
<alkisg>
That was fixed shortly after Karmic
09:16
a "reboot -f" in a script needs to be "reboot -fp"
09:17
You can either change that manually, or put some ppa in your sources, which has (much) updated ltsp versions..
09:17
!stgraber-ppa
09:17
<ltspbot>
alkisg: "stgraber-ppa" :: https://launchpad.net/~stgraber/+archive/ppa
09:18
<Comete>
alkisg: ok, but it is "production safe" ?
09:18
<alkisg>
Urm, hard to say. It's used in production by many people, but of course they're not official updates (even though they are by the ubuntu/ltsp maintainer)
09:19
Search the launchpad bug page for ltsp for the manual fix - it's been filed there
09:19
<Comete>
alkisg: which script should i modify ?
09:20
ok thanks
09:20GodFather has quit IRC
09:20
<vbundi>
with IPAPPEND 3, do I need to have an "ip=..." line too?
09:20
<alkisg>
No
09:21
<vbundi>
ty
09:23
<alkisg>
Was anyone able to run googleearth as a localapp with SSH_FOLLOWSYMLINKS=true (=the default)?
09:24
<Comete>
another problem, i've set up SOUND = Yes but i get no sound on my thin clients, any idea ?
09:24
<vbundi>
did you have sound before your upgrade?
09:24
<alkisg>
(it displays an error about not being able to create a lock == a symlink from ~/.googleearth/file to /proc/pid)
09:25
(and I wonder if there's some trick, like HOME=/tmp/xxx googleearth, to bypass the problem...)
09:26
(it runs fine with SSH_FOLLOWSYMLINKS=false)
09:27
<Comete>
vbundi: no sound before
09:28
vbundi: no speaker icon either...
09:28Ahmuck-Jr has left #ltsp
09:29
<ogra>
are you sure there is a driver for your sound HW in the kernel ?
09:30mikkel has quit IRC
09:31
<Comete>
ogra: don't know
09:31
<ogra>
well, do you know what sound HW the client has ?
09:32
<Comete>
it's an HP thin client
09:32
HP t5145 exactly
09:32
<alkisg>
Comete: sit on a client. Open a gnome terminal. Run: ltsp-localapps xterm. An xterm will open. In that, run: lspci -nn
09:35
<Comete>
alkisg: it's a VIA Azalia HDAC
09:36* alkisg knows how to run lspci, but has no clue about hardware newer than 1995 :)
09:37
<Comete>
:)
09:38
if i run alsamixer in the same xterm, i can see "master", "PCM" etc...
09:38Faithful has quit IRC
09:40
<ogra>
thats a good sign
09:40
can you adjust volumes ?
09:41dro has joined #ltsp
09:41
<Comete>
ogra: yes i can
09:42
<ogra>
was anything muted ?
09:42sutula has joined #ltsp
09:42Kicer86 has quit IRC
09:43
<Comete>
ogra: no nothing
09:53Faithful has joined #ltsp
09:54The_Code has joined #ltsp
09:55
<vbundi>
alkisg: on friday you had suggested I log my terminal's bootup using bootchart to diagnose the very long boot times
09:55
alkisg: I installed bootchart in my chroot but after booting a terminal, I have no logs... am I doin this right?
09:58
<ogra>
did you run ltsp-update-kernels ?
09:58
bootchart logs from the initramfs
09:58
s/logs/starts/
10:05Comete has quit IRC
10:06
<vbundi>
ogra: you lost me... I just thought it would write to /var/log/bootchart/ why would I need to update the kernel, sorry
10:06
<ogra>
you need the updated initramfs, thats where the bootchart binary starts from
10:06
at the end of the install the bootchart package runs update-initramfs to copy itself into the initrd
10:07
<vbundi>
ohh
10:07
<ogra>
the initrd lives under /opt/ltsp/...
10:07
<vbundi>
I see
10:07
yes
10:07
<ogra>
so you need to run ltsp-update-kernels
10:07
<vbundi>
cool thanks, I'll try it again now
10:11jbrett has joined #ltsp
10:17staffencasa has joined #ltsp
10:29gnunux has quit IRC
10:38
<vbundi>
ogra: so should this log file be in /opt/ltsp/i386/var/log/bootchart/ ?
10:39
<ogra>
no, it should be on the running client in /var/log/bootchart
10:40
<vbundi>
oh, I've got my terminals booting directly into an rdesktop client
10:41
<alkisg>
add also screen_02=shell in lts.conf, switch to vt2, and scp it to the server...
10:41
<ogra>
right
10:41
<alkisg>
Does anyone have any good or bad opinion about using dnsmasq as the tftp server?
10:42
<ogra>
apart from the fact that its not supported in ubuntu ?
10:42
no
10:44
<vbundi>
alright so I'll boot to a shell on my thin client... vt2 is a type of terminal? never used it though as far as I know
10:45
<alkisg>
ogra: it's not supported? it's in *main* :)
10:45
<ogra>
huh ?
10:45
thats news to me
10:46
<alkisg>
dnsmasq-base has been in main since hardy, I think...
10:46
<ogra>
ogra@osiris:~/Devel/branches/project-rootstock$ apt-cache show dnsmasq|grep Filename
10:46
Filename: pool/universe/d/dnsmasq/dnsmasq_2.52-1_all.deb
10:47
<alkisg>
vbundi: yes, it's a terminal which you can switch to by pressing alt+ctrl+f2. To return to rdesktop, you press alt+ctrl+f7.
10:47
<vbundi>
alkisg: ohh always referred to em as tty's
10:48
I get what you guys are saying now... lol
10:48
<ogra>
its just another name :)
10:48
<vbundi>
I'm thinking.. scp my terminal?... scp the log file..
10:48
<ogra>
vitual treminal ... tele type terminal
10:48
or so ...
10:49
not sury why the last terminal in tele type terminal is abbreviated with y though, sbalneav might know such stuff :)
10:49
<vbundi>
I was in minicom not too long ago and saw VT2 I thought and I thought it was a type of terminal ie ansi vs vt2
10:50
oh nm I'm thinking vt102
10:52
hmm so /var/log/bootchart/ is empty
10:52
I chrooted into /opt/ltsp/i386, apt-get install bootchart, exit, ltsp-update-kernels, ltsp-update-image
10:53
dunno if the image update is required but I did it
11:01johnny has left #ltsp
11:01
<vbundi>
found the log file under cow/var/log/bootchart/
11:03pmatulis has quit IRC
11:04
<alkisg>
Is there any difference in `chroot "$ROOT" mount -t proc proc /proc` vs `mount -t proc proc "$ROOT/proc"` ?
11:08rhodan_ has joined #ltsp
11:08rhodan has quit IRC
11:09pmatulis has joined #ltsp
11:13
<vbundi>
cool, this bootchart is pretty neat... it looks like around 115s it starts trying to load alsa-utils and amixer.. and it does that for over 3 minutes
11:13
<ogra>
sounds broken to me
11:13
<vbundi>
and I get a ton of pgrep/sleep processes
11:14
<ogra>
can you upload it somewhere ?
11:14
<vbundi>
yea lemme see here
11:16
my disk utilization is 2MB/s, pretty slow isn't it
11:17
<ogra>
well, thats your network utilization
11:17
since your disk is a nbd device
11:17
<vbundi>
thats what I thought.. and 2MB a sec is pretty bad
11:18
<ogra>
well, upload the chart somewhere
11:18
<vbundi>
trying to upload this png to imageshack but it's timing out
11:18
<alkisg>
imagebin.org
11:18
<vbundi>
thanks
11:20
http://imagebin.org/83902
11:22
<ogra>
whats that cmdline you have set, where does it come from ?
11:22etyack has quit IRC
11:22
<vbundi>
?
11:22
<ogra>
also why do you have avahi installed in the chroot
11:23
kernel options: at the top
11:23
thats surely not standard
11:24
<vbundi>
I installed ubuntu server 9.10 x64, apt-get install ltsp-server-standalone, and have installed bootchart into this image
11:24
<ogra>
the 2MB are fine ... it doent access the disk much anymore afterwards
11:24
<alkisg>
ogra, ? Afaik, those are the standard options...
11:24
<vbundi>
I don't think I've done anything else
11:24
<ogra>
your CPU is permanently at 100%
11:24
alkisg, shouldnt
11:24
<alkisg>
Which one?
11:25
<ogra>
kernel options:
11:25
see the top of the image
11:25
we dont set initrd= or BOOT_IMAGGE
11:25
<alkisg>
Yes, but which one of those seem wrong to you?
11:25
<ogra>
i'm not sure that doesnt confuse the kernel
11:25
<alkisg>
We do set initrd, and BOOT_IMAGE is set by pxelinux.0
11:25
<ogra>
we shouldnt have to set initrd
11:26
well, in any case its not the network, nothing is loaded anymore after 15 sec
11:26
<alkisg>
When we use "append initrd..." in pxelinux.cfg/default, then pxelinux appends that to the kernel command line
11:26
<ogra>
well, not nothing but not enough to cause an issue
11:26
alkisg, right, i said we shouldnt need to :)
11:27
<alkisg>
vbundi: here's another image to compare: http://www.stgraber.org/download/bootchart-ltsp-20100126.png
11:27
<ogra>
anyway, looks like ltspfs is totally broken
11:28
<alkisg>
vbundi, what's your network speed?
11:28
<ogra>
to bad one cant really read the things
11:28
<vbundi>
100Mbit
11:28
my pxelinux.cfg/default if it matters
11:28
<alkisg>
Does it work fast once it completes booting?
11:28
<ogra>
alkisg, its not the network, its an issue with the crusoe CPU i guess
11:28
<vbundi>
http://pastebin.org/88327
11:28
<alkisg>
ogra, I'm wondering if the network driver could cause the cpu issue...
11:29
<ogra>
i doubt that would explain the endless loops of the scripts
11:29
<vbundi>
to be honest, I thought it would be faster, they're 800MHZ terminals with plenty of ram and youtube video is pretty choppy running at 1280x1024
11:29
<ogra>
does the client have any kind of HD ?
11:29
<vbundi>
no
11:29
well.. it does
11:29
but I don't think it's being used
11:29
<ogra>
ltspfs tries to mount it i think
11:30
<vbundi>
they're HP T5700 thin clients.. they used to run XPe
11:30
<ogra>
that costs you about a minute
11:30
<vbundi>
I wonder...
11:30
they have disk space but it's set to read only
11:31
HP tool sets it that way so your users don't mess with your base image in XPembedded
11:31
<ogra>
oh, so its a flash disk ?
11:31
<vbundi>
yea
11:32
you can write to it but you have to use lamo hp tools I believe
11:32
<ogra>
hmm
11:32
<vbundi>
I wonder if I can change the write-protect in the bios of the terminal
11:32
afk
11:32bobby_C has quit IRC
11:32
<ogra>
for a test i'D try to remove ltspfsd from the image
11:32
i guess that gains you a lot speedup
11:33
the sound stuff is another different beast
11:33
try to set SOUND=N in lts.conf
11:34
err
11:34
what is gdm and metacity doing there ?
11:34
that chroot is totally messed up
11:34
avahi and gdm should definately not be in there
11:34
<vbundi>
ohh you know what
11:35
I installed gnome-core or something I think because I didn't have any graphical
11:35
<alkisg>
Ouch
11:35
<vbundi>
probably not the way to do it, forgot I did it even
11:35
<ogra>
wipe and redo
11:35
<vbundi>
can I just build another image?
11:35
<ogra>
yes
11:36
<vbundi>
k
11:36
<ogra>
well, another chroot
11:36
you should start from a clean setup
11:36
i.e. a full ltsp-build-client run
11:36
<vbundi>
rm -rf /opt/ltsp/i386
11:37
building client now
11:38
I seem to recall that I had to set the write/protect flag on a USB flash drive and write it to the image that way when I made them for the HP Terminals... I'll see if I can check that out while I wait for it to build
11:54etyack has joined #ltsp
12:04
<vbundi>
if I were to use the internal flash (256MB) on these thin clients, it'd really only be for runnin local apps right? not going to improve performance for running RDP to a w2k3 server
12:05
<ogra>
if you wipe it you could use it as local swap
12:06
but flash isnt really suited for swapping so it would wear out pretty quickly
12:08* alkisg would like to have an option to install an ltsp image locally in such a case :)
12:12
<knipwim>
my keyboard stops working when entering ldm, does anyone know why?
12:14
<dro>
knipwim: you using any adapters on the keyboard?
12:15
knipwim: any type of converters?
12:15
<knipwim>
nope, normal ps/2 keyboard, ldm-2.0.50
12:15
<ogra>
what desktop is running on the server ?
12:15
<dro>
knipwim: as silly as it sounds have you tried another keyboard?
12:16
<knipwim>
dro: no
12:16
<dro>
knipwim: what os you running on the server
12:16
<knipwim>
gentoo
12:16
<ogra>
might be gnome-settings-daemon ... it takes over the kbd config after login, if thats broken that might make the kbd stop working ...
12:16
<knipwim>
ogra: what desktop?
12:16
<ogra>
(just guessing)
12:16
knipwim, the desktop you log in to
12:17
knipwim, ltsp needs a desktop session on the server
12:17
<knipwim>
haven't set it yet
12:17
but i can't even type in a username in ldm
12:18
<ogra>
ah
12:18
is hal running ?
12:18
<knipwim>
i just typed in 4 chars
12:18
and after that it stopped
12:18Egyptian[Home] has quit IRC
12:18
<ogra>
that rather sounds like a system lockup
12:18
can you still ping the client ?
12:19
<knipwim>
yes
12:19Gadi has quit IRC
12:19
<dro>
knipwim: have you updated the chroot?
12:19
<ogra>
mouse works too ?
12:19
<knipwim>
yes, usb mouse
12:19
and i can still log in with ssh
12:19
<ogra>
hmm, then its not hal hanging ...
12:19Lns has joined #ltsp
12:20Egyptian[Home] has joined #ltsp
12:20
<knipwim>
could it still be the gnome-settings-daemon?
12:20
<dro>
knipwim: have you updated the chroot?
12:20
<knipwim>
dro: fresh install
12:21Gadi1 has joined #ltsp
12:21
<dro>
knipwim: never hurts to update it just to make sure
12:21
in the last week 3 people have had weird problems that I've helped, and the fix has been to update the chroot
12:21
knipwim: what is the chroot running, ubuntu?
12:22
<knipwim>
dro: also gentoo
12:22
<dro>
knipwim: i am unfamiliar with updating the chroot in gentoo
12:23
<ogra>
knipwim, do you have a usb kbd around to rule out the kernel ?
12:25
<knipwim>
what a suprise, i actually have
12:27
<ogra>
heh
12:28johnny has joined #ltsp
12:32pmatulis has quit IRC
12:34cliebow has quit IRC
12:34cliebow has joined #ltsp
12:34pmatulis has joined #ltsp
12:34
<knipwim>
ogra: but to no avail
12:35
<ogra>
rebooted the client ?
12:35
same behavior with a fresh boot and usb kbd plugged in
12:35
?
12:35
<knipwim>
twice with usb kbd
12:35
once, some characters
12:35
and second no input at all
12:36
<ogra>
that realkly sounds like the input layer of either the kernel or xorg
12:36
<alkisg>
Try with SCREEN_07=shell, to see if it's xorg or not?
12:37rjune has joined #ltsp
12:37
<ogra>
yeah
12:37
<knipwim>
the keyboard works in the shell
12:38
a default xorg.conf is created at client boot
12:38
<ogra>
then its X or one of the related layers
12:39
<knipwim>
is it located somewhere on the client?
12:39
<ogra>
you shouldnt use an xorg.conf with recent xorg versions
12:39
what version of xorg-server does gentoo use on your system atm ?
12:40
<knipwim>
1.6.5
12:40
<ogra>
that should autodetect all
12:41
try without xorg.conf and see if it behaves any better
12:41
<knipwim>
i don't have one
12:41
thought creating one helped
12:42
but it's not a real solution
12:42
<ogra>
you said one is created during client boot
12:42
no, you should not need one
12:42
<knipwim>
i thought that was the case
12:42
<ogra>
not with recent ltsp
12:42cliebow has quit IRC
12:42
<knipwim>
my current chroot build i'm using
12:42
is from 3 nov 2009
12:42cliebow has joined #ltsp
12:42
<ogra>
it switched about a year ago
12:42
<knipwim>
and doesn't have these problems
12:43
is something done to ldm in the meantime?
12:43
<ogra>
no, its not an ldm issue
12:44
i thought gentoo is on the edge of things, why is your xserver that old ?
12:44* ogra just checked lucid and it has 1.7.3
12:44
<dro>
sounds like you need to update your server and chroot :)
12:45
<knipwim>
ogra: yeah, laugh at the gentoo people :)
12:45
<ogra>
knipwim, if you have a working chroot from nov. and a broken one thats newer, i'D suggest comparing app versions
12:46
specifically since you use an xserver that still needs hal and dbus look at their versions
12:46
the 1.7 series should already use udev/devicekit
12:47
i didnt laugh at you for older versions :)
12:48
i only laugh about gentoo people if i see them compiling half the world sometimes ... but thats been your deliberate choice :)
12:48
<knipwim>
weird, on my working chroot i have xorg-server-1.6.3 and no hal or dbus
12:50
i can install the unstable 1.74
12:51
err, 1.7.4 xorg-server
12:51* ogra checks https://launchpad.net/ubuntu/+source/xorg-server
12:52
<ogra>
i know for sure that we switched to hal input in jaunty
12:52
and out xorg team closely follows upstream
12:53
1.7 should drop the need for hal but moves on to devicekit
12:53
<dro>
knipwim: once booted, and the usb keyboard doens't work, try unplugging it and then plugging it back in
12:54
<ogra>
well, that would clearly point to a kernel/udev issue if that fixed it
12:55
<dro>
knipwim: i found this link, describes your situation
12:55
http://www.linuxquestions.org/questions/gentoo-87/mouse-and-keyboard-unresponsive-when-x-starts-gentoo-744261/
12:56
<ogra>
hmm, that indicates that default gentoo doesnt build evdev
12:57
knipwim, do you have INPUT_DEVICES="evdev" in /etc/make.conf ?
12:57
and do you see evdev being used in the log
12:59
1) Change make.conf and xorg.conf to use "evdev" for both mouse and keyboard. Add 'hal' and 'dbus' to global USE flags.
12:59
2) Run 'emerge -uDN world' to rebuild everything to use evdev (as specified in make.conf).
12:59
that seems to be a proper reciepe to fix the issue
13:00
<knipwim>
evdev is already in the make.conf
13:00
<ogra>
though i doubt you need the mentioned xorg.conf change
13:00
hal will get it from the fdi file
13:01
<knipwim>
going for the xorg-server-1.7.4 install now
13:01
<ogra>
that might need other setting though
13:01
<knipwim>
that should take a while
13:01
<ogra>
hal isnt used in 1.7.4 anymore
13:01
<knipwim>
also recompiling with event debugging on
13:02
<ogra>
well, i'll call it a day now ... still recovering from jetlag
13:03
<knipwim>
ogra: thanks very much
13:03
dro: and you
13:04
well replugging the usb kbd didn't work
13:04
<dro>
ogra: i'm with you there.....my stomach is done for today
13:11
<vbundi>
hey thanks for the help btw ogra
13:15
hey I noticed when this terminal is booting it looks like it's saying it's setting ramswap to 58xxxK
13:15
I think this terminal has either 256 or 512MB ram, I figured more would be used
13:16
<johnny>
you don't need much to just boot and do everything
13:16
it's only with local apps that you actually need more memory than that
13:16
<vbundi>
ah
13:16The_Code has quit IRC
13:17
<vbundi>
I did a new client build because I screwed my old chroot up, and now I'm getting squashfs errors and memory errors etc
13:17
<dro>
vbundi: did you update the kernels, update the image, reboot, and then update t he image again ?
13:18
<vbundi>
didn't reboot but I did the other
13:18
<dro>
did you move the chroot from the default location?
13:19
<vbundi>
dro: no
13:19
<dro>
vbundi: do just like you did before
13:19
<vbundi>
dro: looks like my server is still running 2.6.31-17.. the new client I built is running the new 31-19 kernel
13:19
<dro>
vbundi: update the chroot, do the kernel u pdate, update the image, reboot, then udpate the image again
13:20
<vbundi>
alrighty
13:24spectra has joined #ltsp
13:26dro_ has joined #ltsp
13:30dro has quit IRC
13:30dro_ has quit IRC
13:30dro has joined #ltsp
13:30
<dro>
vbundi: that resolve it?
13:30
<vbundi>
dro: just trying it now
13:33alkisg has quit IRC
13:33
<vbundi>
hey, if I update pxelinux.cfg/default do I need to update the image or kernel
13:33
it keeps losing my changes and reverting back to it's old self
13:34
<dro>
vbundi: i already told youa bout that, the ltsp-update-kernels has a known bug that over writes the pxelinux.cfg/default when you run it
13:35
so you kernel update then your image update, then adjust your pxelinux.cfg/default accordingly
13:36
<vbundi>
dro: ah I must have missed that
13:36Gadi1 is now known as Gadi
13:36
<dro>
vbundi: k well now you know!
13:36
<Gadi>
... and knowing is half the battle...
13:37
<dro>
Gadi: agreed...the rest is done with LIGHTSABERS!
13:37
lol
13:37
<vbundi>
kids: The more you know. *Star in background*
13:37alkisg has joined #ltsp
13:37
<vbundi>
ok well we'll see it's still taking a while to boot, but maybe my bootchart will make a little more sense this time
13:38
I screwed up my chroot last time...
13:44
<dro>
||||||||||/|\-----------------------------\
13:44
||||||||||\|/-----------------------------/
13:44
lightsaber fight?
13:50
<vbundi>
apparenlty there's something wrong with my sound?
13:50
http://imagebin.org/83916
13:50
in any event.. I've shaved over a minute off my boot time!
13:51
<sbalneav>
!docs
13:51
<ltspbot>
sbalneav: "docs" :: For the most current documentation, see https://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstream
13:51
<dro>
vbundi: grats
13:52GodFather has joined #ltsp
13:52
<vbundi>
dro: you'll notice i'm sittin at 4:04 still lol
13:53
<dro>
vbundi: 4 minute boot time?
13:53
<vbundi>
dro: yes look at the bootchart lol
13:54
sbalneav: are you directing me toward SOUND=false?
13:57
<dro>
vbundi: probably but also to read the documentation
13:57
i've always used sound=false
13:58
<sbalneav>
vbundi: No, I was responding to an email on ltsp-discuss, and just needed a link to the documentation :)
13:58
lol, sorry if you thought I was "sending you a message"
14:00
<Gadi>
vbundi: I was actually working on a similar troubleshooting exercise over the weekend
14:00
vbundi: if you drop to a shell and run: ps -efw|grep udev
14:00
do you see multiple udevd instances?
14:02
<vbundi>
Gadi: I will let you know when I Get back, I have to run out for a few
14:03
sbalneav: I wasn't offended or anything ;)
14:03
bbl
14:07dro has quit IRC
14:45ogra has quit IRC
14:45ogra has joined #ltsp
14:46
<cliebow>
Gadi: how do i pick up exit status..or results of $answer=`dhcping -c 10.10.0.4 -s 10.10.0.3 `;
14:47
<Gadi>
in perl?
14:47
<cliebow>
yeah
14:47
<Gadi>
prolly still $?
14:47
<cliebow>
k!
14:50
<Lns>
CAN-o-SPAM: I can't believe that expo is on the 19th...Everything under the sun is scheduled for that day, most notably the LAN party I was going to for the weekend =( So I guess I can't make it!
14:52
<CAN-o-SPAM>
Lns: ah shoot! we'll these games better be more entertaining than tux type and tux math
14:52yanu has quit IRC
14:53yanu has joined #ltsp
14:53
<Lns>
CAN-o-SPAM: =p I'd skip it but my sister is also going to be in town from Denver, but also it's the first LAN party with all my friends since years! it's almost like a reunion
14:54
CAN-o-SPAM: are you going to take any video of the lectures/etc? That would be so good to get up on YouTube or something..
14:59
<sbalneav>
Lns: I heard that tcm-ng's shelved?
14:59
<Lns>
sbalneav: no..? who'd you hear that from?
15:01
<sbalneav>
Can't remember who
15:01
<Lns>
sbalneav: we just picked up a new dev actually, we were going to start planning a gameplan. The codebase has been totally cleaned up - just not in primetime readiness yet
15:01
sbalneav: https://launchpad.net/tcm-ng
15:02
wanna join the dev team? :)
15:02hersonls has quit IRC
15:03
<sbalneav>
heh, everyone needs a piece of me :)
15:06
<Lns>
that's cuz you're so awesome!
15:10
<cliebow>
Gadi:Thanks..Senior moment,,
15:11cliebow has quit IRC
15:12pmatulis has quit IRC
15:21johnny has left #ltsp
15:23Dantix has joined #ltsp
15:24
<Dantix>
hi all, I can't find how to customize the screen geometry for a particular session. Can someone help me?
15:30
<alkisg>
Dantix: for a session? Can't you use gnome-display-properties for that?
15:32GodFather has quit IRC
15:33
<Dantix>
alkisg: the problem is my sessions boots direct into an RDP client, so I have not window manager running
15:33
<Lns>
Dantix: can't you adjust your rdp client connect settings for resolution?
15:33
<alkisg>
Dantix: and I assume you don't want to set the resolution for all sessions on that PC, just for one rdp session, right?
15:35
<Dantix>
Lns: I suppose can, but the X screen seems to be 800x600 from the boot and that is I don't know how to change
15:35
alkisg: yes, I need a few session running on 1024x768 and the other on 800x600
15:36
<Lns>
ldm.conf... x_mode_0 or something isn't it?
15:36
<alkisg>
Dantix: and how are you planning on notifying the client to change the resolution from within the windows session?
15:37
Will that be a per-user setting?
15:37
<Dantix>
alkisg: I hope if I have an X session of 1024x768 the RDP client will open its session within that resolution
15:37
automagically
15:37
<Lns>
alkisg: i don't think he means 'user session' as you and i thought
15:38
<alkisg>
Dantix: sure, but how/when will it switch to 800x600?
15:38
<Lns>
Dantix: try adding a section in ldm.conf for that machine, with "X_MODE_0=1024x768" as an option in it
15:39
<alkisg>
I mean, at what point is the decision of 800x600 vs 1024x768 going to be made? When the thin client boots? When the user logs on to the windows server?
15:39
<Dantix>
alkisg: the user should not to switch manually, the session (tied to its MAC) should be boot within the resolution I want..
15:39
when the client boots
15:40
Lns: I'll try with that.. thanks
15:40
<Lns>
np
15:40
<alkisg>
Dantix: ah, ok, so you want all sessions on that particular client to use the same resolution.
15:42
<Dantix>
yes
15:42
for me session like PC
15:42
or workstation
15:44
thank both, I'll back tomorrow with news
15:44
<alkisg>
OK... The "modern" way to force a resolution is with XRANDR_MODE_0, but if you don't see more than 800x600, you might also have a problem with the monitor EDID settings, and you might need X_VERTREFRESH / X_HORZSYNC.
15:45
<Dantix>
alkisg: but all that tweak must be done in which file?
15:45
<alkisg>
!lts.conf
15:45
<ltspbot>
alkisg: "lts.conf" :: http://manpages.ubuntu.com/lts.conf
15:45
<alkisg>
^^ that file
15:45
<Dantix>
right, thanks
15:46
see you o/
15:46Dantix has left #ltsp
15:46
<alkisg>
Good luck
15:52
<frederickjh>
Anyone out there upgraded to Ubuntu Karmic LTSP and then set up the LTSP Cluster packages?
15:52
I a have a working Karmic LTSP system and am wondering about the "upgrade" path to add the LTSP Cluster packages.
15:55shawnp0wers has quit IRC
15:57vagrantc has joined #ltsp
16:08
<vbundi>
Gadi: I've got that ps -efw|grep udev for you if you're around
16:09
<alkisg>
vagrantc, hi, did you handle the tftpd-hpa change to /srv/tftp? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=551828 It just reached Ubuntu...
16:09
<vagrantc>
alkisg: i'm pondering switching to atftpd, honestly.
16:10
<alkisg>
Heh!!!
16:10* alkisg is thinking about using dnsmasq solely
16:10
<vagrantc>
the default upgrade path resulted in a totally broken setup
16:10
<alkisg>
vagrantc: the most important is, on which path?
16:10
<vagrantc>
dnsmasq is appealing as well
16:10
<alkisg>
/var/lib/tftpboot or /srv/tftp?
16:10
Is the latter supposed to be fhs compliant?
16:10
<vagrantc>
alkisg: oh, even if you get the path right, that's not necessarily enough ... i had to specify some commandline flags.
16:11
alkisg: yeah, it's an FHS compliance issue
16:11
alkisg: i did add support in ltsp-update-kernels so that it also copies to /srv/tftp if present
16:12
<vbundi>
could I get some feedback on what is up with my boot process on this thin client? it seems as though I'm having issues with alsa
16:12
http://imagebin.org/83940
16:13
<alkisg>
vagrantc: but which one's the "proposed" one for debian/ltsp for now on?
16:13
<vagrantc>
alkisg: does it matter?
16:14
<alkisg>
Ehm, shouldn't we have one?
16:14
There's a bunch of wiki pages out there, that would need to be updated
16:14
<Gadi>
vbundi: multiple udevd?
16:14
<vagrantc>
alkisg: ah, i see what you're saying...
16:14
<alkisg>
I.e. "when tftpd-hpa prompts you to enter the directory, put /var/lib/tftpboot in the text box"...
16:14
<vagrantc>
alkisg: well, honestly, i'd prefer to keep it as is.
16:15
alkisg: does it prompt on fresh installs?
16:15
<alkisg>
Yup
16:15
<vagrantc>
well, at least it does that.
16:15
the upgrade process is wretched ...
16:15johnny has joined #ltsp
16:15
<alkisg>
vagrantc: but if there's going to be a change, then a combined LTSP 5.2 / path change / 2000 port change might be better...
16:15
<vagrantc>
alkisg: i see
16:15* vagrantc still needs to file bugs on tftpd-hpa ...
16:16
<vagrantc>
it was one of those excersizes in yak shaving that i never got around to wrapping up
16:16
<alkisg>
Heh :D
16:16
<vbundi>
Gadi: yea looks like it, http://pastebin.org/88508
16:16
<vagrantc>
i fixed it enough to test LTSP, but keep forgetting to file bugs
16:17
<Gadi>
vbundi: yeah, I was having the same issues - and it drives up CPU and memory
16:18
<vbundi>
Gadi: I'm not sure if it's caused by the integrated sound, but I'll try disabling it and see what changes...
16:18
<Gadi>
vbundi: I think if we can figure out the LOCALDEV and SOUND issues, we can fix the slow booting on a lot of these platforms
16:18
vbundi: from what I read, there are issues between the kernel 2.6.31 and udev
16:19
and I bet you are not on a standard intel or amd CPU, right?
16:19* alkisg is already using dnsmasq in proxydhcp mode, so votes for a switch to dnsmasq :D We just drop a file in /etc/dnsmasq.d/ltsp.conf and we're done! :)
16:19
<Gadi>
are you on an NSC Geode or Transmeta?
16:19
<vbundi>
Gadi: no it's an hp terminal running a Trasnmeta TM5700
16:19
Gadi: pretty standard terminal though
16:20
<Gadi>
yeah, I bet the transmeta gets very little love from the test department
16:20
vbundi: the CPU is not standard at all
16:20
how much market share does transmeta have?
16:20
and how many kernel devs are testing it?
16:20
<vbundi>
more than intel in the terminal market I bet ;)
16:21
<Gadi>
I bet ur wrong
16:21
<vagrantc>
alkisg: it's definitely tempting ... although tricky to determine how to drop that file there automatically without disrupting existing network setups.
16:21
<alkisg>
Indeed. But it will provide cleaner upgrades in the future.
16:22
<vagrantc>
alkisg: at least on debian, it requires the sysadmin to add a one-liner to the dhcp configuration ... i guess i could do the same with dnsmasq.
16:22
<vbundi>
What does intel put in thin clients anyways, Atoms are really the first thing thats got into the ULV market right?
16:23
<Gadi>
vbundi: prolly more atom cpus out there than transmeta
16:24* vagrantc hasn't heard transmeta mentioned for 6 or so years
16:24
<vbundi>
Gadi: yeah I can't really say for sure, I mean... atoms have been around for 2 years and they're extremely popular
16:25
Gadi: but I mean.. there are boatloads of these thin clients out there from a lot longer than 2 years ago, you'd think the support would be there
16:25
<Gadi>
for the brand new kernel?
16:25
:)
16:29
<vbundi>
Gadi: yeah well geeze, can't it just work? ;D
16:33
what do you guys recommend for cost effective terminals nowadays then?
16:34etyack has quit IRC
16:34
<Gadi>
vbundi: oh, we'll make it work
16:34
:)
16:35
vbundi: have you ever taken a liveCD to that thing?
16:35
ie a karmic livecd
16:35
to see if it takes long to boot?
16:37mushroomtwo has joined #ltsp
16:37
<vbundi>
hmm no, they don't have CD-roms actually.. I suppose I could boot it with a usb drive
16:37mushroomblue has quit IRC
16:39
<vagrantc>
how does ubuntu's alsa detect that you're using remote pulseaudio support?
16:39
when logged in from an ltsp client?
16:40
<Gadi>
vagrantc: .asoundrc or some such
16:40
<vagrantc>
Gadi: the ~/.asoundrc ?
16:40
<Gadi>
yeah
16:40
it makes pulseaudio a virtual sound device
16:41
<vagrantc>
on debian, i have the instructions to use /etc/asound.conf ... though that doesn't work for servers. although there's a nice way to support that with environment variables.
16:41
<Gadi>
pcm.!default { type pulse }
16:41
ctl.!default { type pulse }
16:41
something along those lines
16:41
<vagrantc>
yeah, that's what i have in the instructions for debian's sound support
16:42
though not on a per-user basis ... ?!
16:42
what tweaks ~/.asoundrc ?
16:44
i'm thinking i'd like to add hooks to ldm to set some environment variables, so that there's less to tweak server-side.
16:45
<Gadi>
Im not sure what ubuntu does these days
16:46
I know a few versions ago, we had an Xsession.d/ script on the server
16:46
<vagrantc>
yeah, i included that in debian until i realized it relied on patches to one of the alsa packages that weren't in debian
16:46
<Gadi>
but, yeah, an env var is most welcome
16:47
but, be sure to make it depend on SOUND_DAEMON setting
16:48
and also be sure to set the local env vars accordingly for localapps
16:48
<vbundi>
Gadi: 5+ minutes and counting on a 9.10 liveusb
16:49
<vagrantc>
Gadi: debian-edu is using this: http://svn.debian.org/wsvn/debian-edu/trunk/src/debian-edu-config/etc/asound.conf
16:49
Gadi: in conjunction with this: http://svn.debian.org/wsvn/debian-edu/trunk/src/debian-edu-config/etc/X11/Xsession.d/15debian-edu-ltsp
16:49
Gadi: but i'd like to drop the second bit, and just set the variable from LDM
16:50
<Gadi>
vbundi: great news! that means it is out of the realm of our LTSP scripts
16:50
:)
16:51* vagrantc hands Gadi a brew for passing the buck
16:51
<Gadi>
hehe
16:52mushroomblue has joined #ltsp
16:52
<Gadi>
no, its just another example of where we ltsp folks have to step in and fix the problems the rest of the linux world leaves behind
16:52
:)
16:52
<vagrantc>
Gadi: so, the tricky part of setting ALSA_DEFAULT_PCM from LDM is if they're not using that ...
16:52
<Gadi>
which is why we accumulate so many hacks and workarounds
16:52
<vagrantc>
if they're not using LDM ... i guess nothing will go wrong ...
16:52mushroomtwo has quit IRC
16:52
<vagrantc>
er, if they're not using ALSA
16:53
<Gadi>
vagrantc: well, so you still have a server side tweak
16:53frederickjh has quit IRC
16:53
<Gadi>
the only reason those vars are honored is because of the asound.conf
16:53
<vagrantc>
if they've got some wacky alsa setup though, we might have to make all kinds of tweaks anyways...
16:54
Gadi: ah, true enough ... it requires some server-side tweaking, that they could do something with if they didn't like our reasonable defaults.
16:54
<Gadi>
now, if you could set the location of asoundrc with an env var,
16:55
<vagrantc>
then we could really abuse XDG_DATA_DIRS to the max!
16:55
<Gadi>
you could have your own asoundrc in a tmp dir that supercedes the one in home
16:55
:)
16:55
speaking of which, we should have a LOCAL_APPS_MENU_FORCE option
16:55
<vbundi>
Gadi: is there anything I can do to help?
16:56
<vagrantc>
well, i think i'm going to split up ldm-trunk/rc.d/X95-run-x-session into a few more pieces and tweak the sound stuff a little.
16:56
<Gadi>
which would remove conflicting entries oin a user's homedir
16:56
vbundi: well, you could try removing ltspfsd from the chroot
16:57
and seeing if that speeds things up
16:57
<vagrantc>
Gadi: that'll just cause clever people to use a different desktop filename :)
16:57
and most people to feel the authoritarian hand
16:57
<Gadi>
vagrantc: we don't ddesign around clever people
16:57
:)
16:57
<vagrantc>
we design for the weak willed!
16:58
<Gadi>
we respect clever people, by not preventing them from cleverly working around an authoritarian system
16:58
:)
16:58* vagrantc hands Gadi another brew
16:59GodFather has joined #ltsp
17:03
<vbundi>
Gadi: removing ltspfsd will break everything else won't it?
17:04
<Gadi>
vbundi: does it allow you to just remove ltspfsd?
17:05
<vbundi>
no ltsp-client depends on it
17:05
unless I do dpkg --force or something
17:05
<Gadi>
if not, try just renaming /opt/ltsp/i386/lib/udev/ltspfs_entry
17:06
to something else
17:06
and updating the image
17:06
<vbundi>
k
17:06
<Gadi>
that should cause the boot to go much faster, based upon your bootchart with all of the udev calls to ltspfs_entry
17:07
now, that won't necessarily tell us why there are so many udev calls, but it is a place to start
17:08* Gadi thinks he read about a udevadm call that we can make in the initramfs to limit the number of udevd children spawned
17:08
<Gadi>
funny how there's even birth control for udevd these days
17:08
:)
17:14
<vagrantc>
Gadi: you think it's a good idea or a bad idea to split out all the environment variable setting in ldm-trunk/rc.d/X95-run-x-session into separate hooks?
17:16* Gadi looks...
17:16
<vagrantc>
it's a few more filesystem calls, but allows for a little more flexibility to insert something in between each setting of variables...
17:17
i think i'd at the very least split it into one hook that sets the variables, and another that actually does something
17:20
<Gadi>
well...
17:20
hmm...
17:21
you can still insert your own stuff right now
17:21
just by setting CLIENT_ENV
17:22
and at least this way, the core stuff is all self-contained
17:22
<vagrantc>
Gadi: but not conditionally ...
17:22
<vbundi>
Gadi: that's more like it! 2:11 http://imagebin.org/83960
17:22
<vagrantc>
Gadi: i.e. you can't set a variable based on the detected value of SOUND_DAEMON or some such
17:22
<Gadi>
vagrantc: sure you can, with just an earlier script that is sourced
17:22
sure you can
17:22
make an X94-myscript
17:23
that does:
17:23
[ "$SOUND_DAEMON" = "pulse" ] && CLIENT_ENV="$CLIENT_ENV foo"
17:23
<vagrantc>
Gadi: the sound handling code has: if [ -z "$SOUND_DAEMON" ]; then SOUND_DAEMON=pulse ...
17:23
<vbundi>
I'm out till tomorrow, thanks for all the help
17:23
<Gadi>
oh, I see, you cant override what is there, you mean
17:24
<vagrantc>
Gadi: yes.
17:24
<Gadi>
vbundi: great!
17:24
btw
17:24
:)
17:24
vbundi: see, we know the problem but not the cause
17:24
<vbundi>
yeah If you want more help with testing I'll be glad to do so tomorrow
17:25
<Gadi>
vbundi: always happy to have testers
17:25
:)
17:25
thanks for helping to prove that "slow hardware" is not necessarily the cause of "ltsp's bloat"
17:25
:)
17:25
LTSP 4.2 just didn't use udev
17:25
or, well, not today's udev
17:26
vagrantc: how do you propose to code it with overrides?
17:26
vagrantc: wothout removing a file from the package/
17:27
<vagrantc>
Gadi: move all the variable setting to X90-*, to give room to break everything before X95-*
17:28
<Gadi>
ok
17:28
while ur at it, maybe you can come up with better var names than MY_SOUND
17:28
:)
17:28
<vagrantc>
heh. i just realized that i can't test if my new patches are working with virtual thin clients on the same machine as the virtual ltsp server...
17:30* vagrantc disables sound support on the server.
17:31
<vagrantc>
Gadi: maybe i'll just make my tweak for ALSA_DEFAULT_PCM and be happy.
17:31
<Gadi>
hehe
17:31
slacker
17:32
meanwhile, I think I am about to set out on a quest to prove that ltsp5 can indeed work on low end clients
17:33
as long as we workaround the real issues
17:33
<vagrantc>
heh
17:33
without features, we can boot at any speed we want!
17:33
<Gadi>
ie, if you set SCREEN_07=shell and it takes 4 minutes to get there, it aint the features
17:34
the problem's not the features, its all these new systems that they move to
17:34
that work great in limited situations
17:34XuzhouJim has joined #ltsp
17:34
<Gadi>
but are left untested in many cases
17:35
"I sped up performance, but I set my timeouts so short that on slow hardware, it spawns a million procs and makes things even slower!"
17:35
<vagrantc>
i wonder if instead of using ALSA_DEFAULT_PCM i should use LTSP_ALSA_PCM or some such ...
17:37
<johnny>
Gadi, considered rebuilding everything against a different c lib?
17:37
<vagrantc>
LTSP_ALSA_DEFAULT ...
17:37
<alkisg>
Gadi: my 500 mhz / 64 ram clients boot on 1:10. I think that's fine..
17:37
<Gadi>
johnny: gentoo's ur domain
17:37
:)
17:38
alkisg: ever done a bootchart?
17:38
<johnny>
Gadi, no.. i mean like finding an existing maintained rebuild of ubuntu packages against a different c lib..
17:38
<alkisg>
Gadi, nope...
17:38
<johnny>
Gadi, i can't even run gentoo on this machine.. too old
17:38
<alkisg>
Doesn't ubuntu does that for lucid :D
17:38
<johnny>
5 year old laptop
17:38
i mean i can.. it's just too slow to install packages
17:38
tha'tts why i use fedora
17:39
<Gadi>
I am just saying, before we jump to "we need a smaller image" or "we need fewer services" or "we need a different distro", we should actually scientifically figure out the problem
17:39
it was like when we tackled video way back when
17:40
everybody had theories on why playing movies on the LTSP server may have issues
17:40
none of which were founded in reality
17:40
:)
17:40
alkisg's the PhD here - he knows where Im coming from
17:40
:)
17:41
<alkisg>
:D
17:41
<vagrantc>
oh no, science!
17:42
next thing people will be calling for is testing code before uploading!
17:42
<Gadi>
as soon as we *demonstrated* the lack of sync between video and audio caused most of the problems and *demonstrated* that playing with "-ao null" allowed fullscreen video with no degradation
17:42* alkisg is waiting for Gadi to bring up the big formulas...
17:42
<johnny>
Gadi, go ahead
17:42
fix it
17:42
<Gadi>
... we were able to show how moving from ESD to pulse along with LDM_DIRECTX could resolve most of the bottleneck
17:42
<johnny>
i don't care.. my stuff is fine :)
17:42
<Gadi>
hehe
17:43
spoken like a true member of the FOSS
17:43
<johnny>
as long as it doesn't get worse, i'm OK :)
17:43
<Gadi>
community
17:43
<johnny>
Gadi, well.. it would help if i had more than 3 terminals
17:43
i don't have lots of requirements for ltsp ...
17:43
no speakers even
17:44
<vagrantc>
all it needs to do is handle a few disasterous coffee spills, and you're set.
17:44
<johnny>
as long as people can use firefox/openoffice/solitaire
17:44
it's all there
17:44mfdutra has joined #ltsp
17:44
<johnny>
flash sucks still
17:44
but that's not your fault
17:44
or ltsps fault
17:45
<Gadi>
well, we'll try to break your 3 terminals before lucid
17:45
:)
17:46
<mfdutra>
hello. who writes /tmp/ldm-logout-action ?
17:46
I never get it written
17:47
<alkisg>
mfdutra: I think that moved to /var/run... what version are you using?
17:47
<vagrantc>
mfdutra: what version of ldm? newer versions write to /var/run/ldm-logout-action
17:47
<mfdutra>
2:2.0.48-0ubuntu1
17:47
I can't find either
17:48
well, maybe ldm is writing there and when it starts over, it deletes the file... dunno
17:50
<Gadi>
g'night guys
17:50Gadi has left #ltsp
17:50
<alkisg>
g'night from me too :)
17:50
<vagrantc>
mfdutra: the files in /opt/ltsp/i386/usr/share/ldm/rc.d/ is where to look for the code
17:50
<mfdutra>
so did I
17:51alkisg has quit IRC
17:51
<mfdutra>
I can only see a reference to it in X99-zzz-logout-action
17:51
but that's where it reads the file, not writes
17:52
<vagrantc>
ah, right ...
17:52
<mfdutra>
I grepped all the ldm code also
17:52
<vagrantc>
mfdutra: you need to use a custom .desktop file
17:52
<mfdutra>
uh?
17:53XuzhouJim has quit IRC
17:53
<vagrantc>
the desktop file created /tmp/ldm-logout-action and called gnome-session --logout or whatever it was called
17:53
<mfdutra>
hmm
17:53
people logout through the indicator-applet-session
17:53
<vagrantc>
ltsp-trunk/localapps/doc/examples/*.desktop
17:54
the new way, if the patches make it into gnome-session, will "just work".
17:54
<mfdutra>
hmm
17:55
<vagrantc>
and wouldn't be hard to backport the functionality... it's just two files to drop into place
17:56
but still requires a custom .desktop file or support built-in to gnome-session (or whatever calls your logout action)
17:57
<mfdutra>
gnome-session could have an exit status for logout or reboot
17:57
<vagrantc>
if it does, it should be easy to write a wrapper script
17:57
<mfdutra>
yup
17:58
I'll check what that indicator thing fires when the user clicks on it
18:05
<vagrantc>
i tried to do something similar with lxde-logout, ended up filing a bug
18:12CAN-o-SPAM has quit IRC
18:42mfdutra has quit IRC
18:48vagrantc has quit IRC
19:05rjune has quit IRC
19:46Lns has quit IRC
20:16
<sbalneav>
Who here knows enough about irc to remove this registration thing
20:16
freenode's upgraded, I say we take it off
20:17slidesinger has joined #ltsp
20:22
<sbalneav>
sigh, I can't remember how to get ops
20:22
it's /msg chanserv sommatorother
20:22ChanServ sets mode: +o sbalneav
20:23
<sbalneav>
ah
20:36
Uuuuugh
20:38
Anyone know how to remove this /mode +q $~a
20:39
I see lots of information on how to add things to the quiet list, none on how to remove 'em
20:42sbalneav sets mode: -q $~a
20:43
<sbalneav>
Ooooh
20:43
think I did it.
21:00loather-work has quit IRC
21:02loather-work has joined #ltsp
21:09GodFather has quit IRC
22:05jhutchins has quit IRC
22:07jhutchins_lt has quit IRC
22:10daya_ has joined #ltsp
22:19rjune has joined #ltsp
22:20Faithful has quit IRC
22:42daya_ has quit IRC
22:52shogunx has quit IRC
22:54shogunx has joined #ltsp
22:58Lns has joined #ltsp
23:11Lns has quit IRC
23:13johnny has left #ltsp
23:14Lns has joined #ltsp
23:16johnny has joined #ltsp
23:47yanu has quit IRC