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


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

00:02alkisg has joined #ltsp
00:02try2free has left #ltsp
00:16daya has quit IRC
00:27ltspbot has joined #ltsp
00:48pts_ has joined #ltsp
00:57alkisg has quit IRC
01:26alkisg has joined #ltsp
01:26alkisg has joined #ltsp
01:46frederickjh has joined #ltsp
01:58FuriousGeorge has joined #ltsp
01:58
<FuriousGeorge>
hey all
01:59
one of my clients wants me to run kb / mouse /vid cables from the server room to an adjacent room where they want to use the server directly
01:59
i don't see why not, but it just feels wrong
01:59
can anyone talk me down?
02:03
<appiah>
for server console access? sure why not?
02:03
many places has a console room where you can access your servers without entering the server room
02:06* Lns wants a console room
02:08
<appiah>
but it can be nice once in a while to enter the server room and try to work with all that noise
02:09
<Lns>
I have 4 rackmount servers right by me every day
02:09* frederickjh wants a server room too 8-)
02:09
<Lns>
it gets old =p
02:09
FuriousGeorge, console access is always really good (for when you need bios/etc. access, or if the server doesn't come up right)..but other than that you can always just use an x server anywhere on the network to get to her
02:13
I was just talking to my wife yesterday about wanting a IP-KVM... *drool*
02:19
<FuriousGeorge>
Lns: of course i have console access, and i don't see what damage my users could do, but I was just nervous about it
02:20bobby_C has joined #ltsp
02:28Briareos1 has joined #ltsp
02:28
<Briareos1>
good morning
02:34Selveste1_ has quit IRC
02:44ltspbot has joined #ltsp
02:44sbalneav has joined #ltsp
02:50gnunux has joined #ltsp
02:50
<gnunux>
hi
02:58F-GT has quit IRC
02:59
<Briareos1>
will nbd make a swapfile for every client - or only of the client runs out of ram / needs it?
03:02
<alkisg>
If nbd_swap is enabled, then it will make a swap file for every client. By default it's disabled, unless the client has < 48 ram.
03:03
<Briareos1>
alkisg, strange - i just followed the guide to set it up, booted a thin client - but theres only one file in /tmp that _is not_ the size i provided nbdswapd.conf
03:04
<alkisg>
What guide?
03:04
<Briareos1>
https://help.ubuntu.com/community/UbuntuLTSP/EnableNBDSWAP
03:04
ls -ahl /tmp/tmp.* GIVES -rw------- 1 root root 0 2010-01-02 16:35 /tmp/tmp.LGhMxM6958
03:05
<alkisg>
Do you have Ubuntu 8.04?
03:06Egyptian[Home] has quit IRC
03:06
<Briareos1>
yes
03:07Egyptian[Home] has joined #ltsp
03:07
<alkisg>
Enter those commands, and upload the result to pastebin:
03:07
cat /var/lib/tftpboot/ltsp/*/lts.conf
03:07
cat //etc/ltsp/nbdswapd.conf
03:08
*with one slash, not two...
03:08
<Briareos1>
SIZE=1024
03:08
for the second
03:08
NBD_SWAP = True
03:08
for the first
03:09
<alkisg>
You need a [Default] on top of that
03:09
<Briareos1>
and the date of the tmp-file is also not current - so it's probably not related to the setup i just did :)
03:09
<alkisg>
[Default]
03:09
<Briareos1>
ah
03:09
<alkisg>
NBD_SWAP=True
03:09
<Briareos1>
is it normal that the file didn't exist at all?
03:09
<alkisg>
Yes
03:09
<Briareos1>
i had to create it ...
03:09
ok
03:09
<alkisg>
How much RAM do your clients have?
03:10
<Briareos1>
not too sure, but i think the lowest could even be 128
03:10
<alkisg>
And, why do you want such a big swap space?
03:10
<Briareos1>
or 256 is possible as well
03:10
<alkisg>
And, are you using localapps?
03:11
<Briareos1>
well ... i just thought for testing i can make it that big - as the space is available anyways
03:11
localapps - not yet ... i wanted to take all the hints i got here yesterday and run them down sequentially (if that's proper english :))
03:11
<alkisg>
And, do your clients have local disks? if so, you could make a swap partition in them...
03:12
<Briareos1>
most of them do.
03:12
<alkisg>
OK, my advice is:
03:12
With 128 or 256 RAM, you can't use localapps, no matter how much swap space you make
03:12
So you don't really need a big swap space
03:13
If your clients have a local disk, and you're able to make an e.g. 512 MB swap partition, do that
03:13
<Briareos1>
i could switch all clients to ~1 GB ram
03:13
okay, can you hint me any documents on the local swap partition?
03:13
<alkisg>
If you can put more RAM in the clients, then you'll be able to use localapps or even fat clients
03:14
<Briareos1>
btw: I put the [Default] there - and still no new tmp-file
03:14
<alkisg>
I assume they also have CD drives? You can boot them with an ubuntu live cd, and use gparted to make a swap partition...
03:15
<Briareos1>
ah will ltsp automatically notice a normal swap partition on the client?
03:15
<alkisg>
I think an extra line is needed - just a minute...
03:15
USE_LOCAL_SWAP=True
03:15
(in lts.conf)
03:16
<Briareos1>
very interesting
03:16
<alkisg>
If you have local disks, there's no reason to use nbd_swap
03:17
<Briareos1>
but for a quick solution without the need to configure all the clients it'd be
03:18
there are about 15 users on it and they're complaining about a lack of speed :)
03:18
<alkisg>
Well swapping won't get you speed :)
03:18
<Briareos1>
well ... one is not complaining - he's got the strongest clientmachine
03:19
<alkisg>
swap == stability, avoiding crashes etc. It doesn't offer any speed at all.
03:20
<Briareos1>
okay ... that would be a start
03:20
hangs also occur frequently
03:20
:)
03:21
what could be another reason for the nbd_swap not to work? is there anything else i can check?
03:26
<alkisg>
You rebooted the client?
03:26
<Briareos1>
several times
03:26
<alkisg>
Append these on lts.conf:
03:26
SCREEN_02=shell
03:26
SCREEN_07=ldm
03:27
<Briareos1>
ldm? is it ldm not gdm?
03:27
<alkisg>
Reboot the client. Press alt+ctrl+f2. A terminal will appear. On that, enter: getltscfg -a
03:27
Yes, it's ldm
03:27
The "LTSP Display Manager"
03:28
<Briareos1>
somehow i was thinking it was changed to gdm at some point of the ltsp development ...
03:28
anyways i'll try that
03:28
one moment
03:30
<alkisg>
Also, the best thing you can do for speed, is to enable LDM_DIRECTX. See the lts.conf man page for a description of the speed vs security story.
03:30
!lts.conf
03:30
<ltspbot>
alkisg: "lts.conf" :: http://manpages.ubuntu.com/lts.conf
03:34ogra has joined #ltsp
03:38Egyptian[Home] has quit IRC
03:52ltspbot has joined #ltsp
03:57sbalneav has joined #ltsp
04:01
<Briareos1>
could it be that the "/var/lib/tftpboot/ltsp/i386/lts.conf" isn't used at all? how can i check that?
04:06Egyptian[Home] has joined #ltsp
04:11
<alkisg>
Briareos1: if you put "SCREEN_02=shell" and that didn't work, then probably the clients don't get lts.conf at all.
04:11
To verify that, open /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default, and add "break=init" at the end of the kernel line
04:12
Then reboot a client. It should spawn a shell while booting.
04:12
In that shell, enter: cat /etc/lts.conf
04:12
If you see your lts.conf there, the clients get it, otherwise they don't.
04:13
Other than typos, one reason for the clients not to get lts.conf is if the dhcp server doesn't send the "filename" field to the ipconfig client.
04:18
<Briareos1>
ok i'll check the dhcp - cuz i get "no such file or dir" for the cat
04:19Egyptian[Home] has quit IRC
04:19Egyptian[Home] has joined #ltsp
04:21
<Briareos1>
filename "/ltsp/i386/pxelinux.0";
04:21
- is this to be seen from the chroot environment?
04:22
locate pxelinux.0 GIVES
04:22
/opt/ltsp/i386/boot/pxelinux.0
04:22
/var/lib/tftpboot/ltsp/i386/pxelinux.0
04:22
/opt/ltsp/i386/usr/lib/syslinux/pxelinux.0
04:23
and several for amd64
04:24
all three have todays date - while the one in the syslinux are last modified in march 09
04:24* alkisg needs to go, bbl
04:25
<Briareos1>
okay thanks, see you
04:25alkisg has quit IRC
04:25Egyptian[Home] has quit IRC
04:39ogra_ is now known as ogra
04:39ogra has joined #ltsp
04:41F-GT has joined #ltsp
04:54Egyptian[Home] has joined #ltsp
04:55sene has joined #ltsp
05:01Egyptian[Home] has quit IRC
05:03Egyptian[Home] has joined #ltsp
05:09Sorell has quit IRC
05:11Sorell has joined #ltsp
05:12Egyptian[Home] has quit IRC
05:12hersonls has joined #ltsp
05:12isojussi has joined #ltsp
05:13
<isojussi>
?
05:14
is it possible to allow admin user to configure user accounts from clients with gui account manager?
05:15Egyptian[Home] has joined #ltsp
05:21
<Sorell>
are you logged in as an root?
05:31Egyptian[Home] has quit IRC
05:32Sorell has quit IRC
05:34Sorell has joined #ltsp
05:42
<isojussi>
it has worked before but when i updated from 8.04-->9.10 I can't edit/create user accounts from clients. The button which allow to modify user accounts is greyed out
05:43
from server it works Ok
05:44Egyptian[Home] has joined #ltsp
05:45
<isojussi>
I can make/edit user accounts in server, but other admin has no physical access to it, so it would be great that he could manage them from clients
05:48
<ogra>
sadly that wont work due to the new policykit/consolekit architecture ...
05:48
<isojussi>
is there a reason to that?
05:48
<ogra>
policykit forbids people that are not on the local to change user credentials
05:48
i *think* you can configure it but i'm not sure
05:49
there has been a graphical policykit tool, noit sure it still exists, i'd do a test install and play with it
05:49
for reasons ask upstream :)
05:49Egyptian[Home] has quit IRC
05:50Selveste1_ has joined #ltsp
05:55Egyptian[Home] has joined #ltsp
05:56isojussi has quit IRC
05:57bobby_C has quit IRC
05:59Egyptian[Home] has quit IRC
06:01Egyptian[Home] has joined #ltsp
06:01Selveste1_ has quit IRC
06:01Selveste1_ has joined #ltsp
06:06Egyptian[Home] has quit IRC
06:14Selveste1_ has quit IRC
06:14Sorell has quit IRC
06:14Selveste1_ has joined #ltsp
06:31pmatulis has joined #ltsp
06:33Egyptian[Home] has joined #ltsp
06:38Egyptian[Home] has quit IRC
06:50Egyptian[Home] has joined #ltsp
06:52GodFather has joined #ltsp
06:56Selveste1_ has quit IRC
06:56Selveste1_ has joined #ltsp
06:58Egyptian[Home] has quit IRC
06:58pimpministerp has joined #ltsp
07:01Egyptian[Home] has joined #ltsp
07:05shawnp0wers has quit IRC
07:15Kicer86 has joined #ltsp
07:17Egyptian[Home] has quit IRC
07:21alkisg has joined #ltsp
07:22Egyptian[Home] has joined #ltsp
07:25Lns has quit IRC
07:30Selveste1_ has quit IRC
07:34vvinet has joined #ltsp
07:35scottmaccal has joined #ltsp
07:36scottmaccal has quit IRC
07:39etyack has joined #ltsp
07:42jammcq has quit IRC
07:47Egyptian[Home] has quit IRC
07:49shawnp0wers has joined #ltsp
08:10Egyptian[Home] has joined #ltsp
08:13grantk has joined #ltsp
08:14bobby_C has joined #ltsp
08:24mgariepy has joined #ltsp
08:26Egyptian[Home] has quit IRC
08:28ogra has quit IRC
08:40Lns has joined #ltsp
08:47pts_ has quit IRC
08:47bobby_C has quit IRC
08:48bobby_C has joined #ltsp
09:03Egyptian[Home] has joined #ltsp
09:04
<sbalneav>
Morning all
09:05
<alincoln>
morning
09:08
<vvinet>
morning !s
09:11
<sbalneav>
vvinet: the !s's gotta be the first thing on the line if you want the bot to respond
09:11
!s
09:11
<ltspbot>
sbalneav: "s" :: Scotty!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
09:12
<sbalneav>
!last jammcq
09:12
<ltspbot>
sbalneav: (last [--{from,in,on,with,without,regexp} <value>] [--nolimit]) -- Returns the last message matching the given criteria. --from requires a nick from whom the message came; --in requires a channel the message was sent to; --on requires a network the message was sent on; --with requires some string that had to be in the message; --regexp requires a regular expression the message must (1 more message)
09:12
<sbalneav>
!seen jammcq
09:12
<ltspbot>
sbalneav: jammcq was last seen in #ltsp 11 hours, 3 minutes, and 1 second ago: <jammcq> hellooooo
09:14Egyptian[Home] has quit IRC
09:16Briareos1 has quit IRC
09:19GGD has joined #ltsp
09:21CAN-o-SPAM has joined #ltsp
09:23ogra has joined #ltsp
09:25bobby_C has quit IRC
09:32dtrask has joined #ltsp
09:33Gadi_eeepc has joined #ltsp
09:38bobby_C has joined #ltsp
09:41
<vbundi>
!docs
09:41
<ltspbot>
vbundi: "docs" :: For the most current documentation, see https://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstream
09:48litlebuda has joined #ltsp
09:49Gadi_eeepc has quit IRC
09:49waldo323 has joined #ltsp
09:50Gadi_eeepc has joined #ltsp
09:56etyack has quit IRC
09:58
<vbundi>
!docs
09:58
<ltspbot>
vbundi: "docs" :: For the most current documentation, see https://sourceforge.net/apps/mediawiki/ltsp/index.php?title=Ltsp_LtspDocumentationUpstream
09:58
<vbundi>
oops
10:01cliebow has joined #ltsp
10:03litlebuda has quit IRC
10:03litlebuda has joined #ltsp
10:04
<vbundi>
alright so even with LDM_DIRECTX=Y and my resolution lowered to 1024x768 (same as what the ltsp4 server is set to) my video is still a bit choppier in LTSP5
10:05
is it overhead, or are there some settings to tweak still that I'm not finding
10:08vagrantc has joined #ltsp
10:12
<Lns>
vbundi, what video chipset do you have?
10:14
<vbundi>
Lns: radeon
10:16
Lns: I was thinking yesterday that it might not be loading the correct module, but I think it is, I'm just checking now
10:16
<Lns>
vbundi, have you tried ...what is it in lts.conf.. sets color depth
10:16
<vbundi>
I ran lspci -vv -nn |grep radeon shows it
10:16
x_color_depth = "16"
10:17
<Lns>
yeah
10:17
<vbundi>
yep
10:17
<Lns>
hmm
10:17
how much vidram? Do you have it set up in the bios of the client?
10:18
<vbundi>
yea, I think it's 8MB but it could be 16, I booted the exact same machine on my ltsp4 server first, and then ltsp5
10:19
<Lns>
vbundi, how many clients are online?
10:19
could it be network congestion?
10:19Sorell has joined #ltsp
10:21
<Lns>
vbundi, are you using the same application server in both ltsp4 and 5? Admittedly ltsp5 distros are a bit heavier in graphics...
10:22
that would explain it alone
10:22
I would think, anyway..
10:22
<vbundi>
no network is good
10:23
<Lns>
be back in a bit..breakfast =)
10:23
<vbundi>
Lns: totally separate servers, one is running etch the ltsp5 is 9.10
10:23
<Ahmuck>
Sorell ...
10:23
Sorell:
10:25Sorell has quit IRC
10:26
<sbalneav>
vbundi: the X server has gotten much larger and "full featured" since ltsp 4.2
10:26etyack has joined #ltsp
10:26
<sbalneav>
LTSP 4.2 runs a very old X server, whereas ltsp 5 runs whatever X server the distro runs with.
10:27
Xorg has gotten much bigger since the ltsp4.2 days, and requires more memory and cpu.
10:27
As well, the kernel's gotten bigger
10:28
libc's gotten bigger
10:28
etc.
10:28
ltsp5 will need more resources on a thin client than 4.2 did.
10:28
just the same way that Debian Squeeze needs more resources than Sarge did
10:29
or Lucid needs more resources than Breezy did
10:29
etc.
10:33
<vagrantc>
ltspppbot: learn ltsp5vs42isgoingtorequiremoreresources as
10:40
<vbundi>
yeah I realize xorg is totally different now, which is why I asked if it was just overhead or if there were a couple last tweaks I could try that I hadn't seen
10:42gnunux has quit IRC
10:42
<vagrantc>
the newest vi.po translations contains whitespace differences that cause 0% overlap on the diff ... probably at end-of-line...
10:44
i can't even find the whitespace difference...
10:48
<Gadi_eeepc>
vagrantc: why does run_parts_list use find|sort to find the files?
10:50
<vagrantc>
Gadi_eeepc: to have a sorted list of files, and the ability to selectively find only certain prefixes?
10:51
<Gadi_eeepc>
can we replace it with something like:
10:51
for file in ${1}/${2}*; do [ -f $file ] && echo $file; done
10:52
<vagrantc>
i think that doesn't handle empty or missing directories
10:52
well, i guess it does...
10:52
because of the -f
10:52
Gadi_eeepc: ah, that will also sort differently based on locale
10:52
<Gadi_eeepc>
really?
10:52
<johnny>
you know it is a blizzard when the snow goes up and not just sideways :)
10:52
<Gadi_eeepc>
why?
10:53damianos has joined #ltsp
10:53
<vagrantc>
Gadi_eeepc: because different languages have different sorting preferences?
10:53
<Gadi_eeepc>
LANG=C then?
10:53
<vagrantc>
i suppose.
10:53
it might be more complicated than that
10:54
Gadi_eeepc: let's just say i'm nervous about changing that code.
10:54
it was a lot harder to get right than i expected
10:54
<johnny>
somebody needs to run an automated test lab with a bunch of vms..
10:54
this could be a branchable change too..
10:54
<Gadi_eeepc>
fair enough
10:55
I am still going to replace basename with a shell construct
10:55
if thats ok
10:55
<vbundi>
so being that my hardware limits me to ltsp4, am I still going to be able to install ltsp 4.2 on a newer distro like Karmic, or am I better off going to Dapper
10:55
<vagrantc>
Gadi_eeepc: we could definitely replace the echo $basefile egrep with a case statement, i think.
10:55
well.... maybe not.
10:55
<johnny>
vbundi, you're screwed in the near term..
10:55
altho you're probably not trying to use local apps..
10:56
dapper has no security updates anymore does it?
10:56
<Gadi_eeepc>
as in: case "$basefile" in [0-9a-zA-Z_\-]*) echo $file ;; esac ?
10:56
<vbundi>
all I want to do is boot something that runs an RDP client... this office runs Windows only ERP software
10:57
<vagrantc>
Gadi_eeepc: does that match only files that contain all those characters, or only those that begin with those characters?
10:57
<johnny>
ah.. then you're probably ok.. until you upgrade windows to require a newer version of rdp/rdesktop
10:57
<vagrantc>
Gadi_eeepc: that code ignores your standard backup files and whatnot.
10:57
<Gadi_eeepc>
should be begin, but will test
10:57
usually to match in the middle you need an extra * in front
10:57
<vbundi>
Johnny: yep, that's when it'll be time for them to shell out some $$$, but they don't want to do that yet
10:57
<vagrantc>
well, it needs to match *all* the characters, not just beginning.
10:58
i needs to *not* match 0abcde.bak
10:58
<Gadi_eeepc>
oh, I see
10:58
<vagrantc>
for example...
10:58
<vbundi>
johnny: so is ltsp4.2 on Karmic do-able without insanity?
10:58
<Gadi_eeepc>
eh, lets leave it be
10:58
or now
10:59
<vagrantc>
not sure if there's a way to do that with case
10:59
<Gadi_eeepc>
*for
10:59
<johnny>
vbundi, sorry.. no idea..
10:59
<vagrantc>
many quests to purge outside shell calls...
10:59
<johnny>
ltsp5 was already way out..
10:59
by the time i got involved
10:59
err ltsp 4.2
10:59
never used it
10:59
<vbundi>
johnny ah ok
10:59
<johnny>
i just know it's completely unsupported by most people
11:00
<Gadi_eeepc>
I also think I should add something like a: VOLUME_MANUAL param to tell my sound configure code to *only* set the channells a user specifies
11:00
<johnny>
including many people in this room.. if just for the simple fact that we never used it..
11:00
<Gadi_eeepc>
(as opposed to all channels like it does now)
11:00
that would speed things up for low-end clients
11:00
<vagrantc>
i suspect, given the direction of things, ltsp 4.2 will just become incompatible with X one day.
11:00alkisg has quit IRC
11:00
<johnny>
vbundi, so.. you tried ltsp5 with stgraber ppa?
11:00
<vbundi>
yea I haven't had much luck finding documentation on it..... the LTSP4 server we are running now was set up years ago by the old IT guy
11:01
<johnny>
and updated xlib?
11:01
<vbundi>
johnny, no just using karmic repository
11:01
<johnny>
try that
11:01
<vbundi>
ok
11:01
<johnny>
pretty sure i saw somebody recommend that to you
11:01
oh wait.. karmic.. were those fixes every in karmic?
11:01
ever*
11:01
guess alkisg isn't here to ask..
11:01
vbundi, it's worth a shot anyways
11:01
<vagrantc>
a lot of our recent speed improvement refactoring isn't in karmic
11:02
<johnny>
you can always put it back the old way
11:02
<vagrantc>
though probably in the ppa's
11:02
<Gadi_eeepc>
vbundi: when you test, are you testing rdesktop?
11:02
<vbundi>
yes
11:02
<Gadi_eeepc>
then, xlib wont helpp you
11:02
:)
11:02
<johnny>
Gadi_eeepc, so.. what changed with rdesktop that made it suck for him then?
11:03
<Gadi_eeepc>
define suck
11:03
!suuck
11:03
<ltspbot>
Gadi_eeepc: Error: "suuck" is not a valid command.
11:03
<Gadi_eeepc>
!suck
11:03
<ltspbot>
Gadi_eeepc: Error: "suck" is not a valid command.
11:03
<vbundi>
haha
11:04GodFather has quit IRC
11:07pmatulis has quit IRC
11:09
<Gadi_eeepc>
vbundi: btw, you would be surprised how much disk I/O impacts performance
11:09* Lns concurs with Gadi_eeepc's statement
11:09
<Gadi_eeepc>
on the server side that translates into IO to server disks (and NFS if on NFS)
11:10
on the client side, that translates into NBD and the access to the fillesystem on which i386.img lives
11:10
<damianos>
Can somebody help me with a dual boot problem?
11:10
<Gadi_eeepc>
poor client side IO will also lead to worse X performance and longer boot times
11:11
<vbundi>
so features such as bitmap caching where you would expect to increase performance, might actually slow things down if there's poor IO on the client?
11:11
<Lns>
!ask
11:11
<ltspbot>
Lns: "ask" :: Don't ask to ask a question, simply ask it, and if someone knows the answer, they'll respond. Please hang around for at least 15 minutes after asking a question, as not everybody constantly monitors the channel.
11:11
<Lns>
damianos, ^^^
11:12
<Gadi_eeepc>
vbundi: well, bitmap caching is hopefully done in speedy client RAM
11:12
but if the read access from the read-only rootfs is slow
11:12
it means that every time Xorg needs to grab a new file from the rootfs, there's an impact
11:13
<vbundi>
I wonder if some stuff changed in rdesktop that is causing the slowdown
11:13
<damianos>
sorry...I have an ltsp server on a dedicated drive and XP on another dedicated drive...XP goes to BSOD on boot if the linux drive is connected....XP will boot fine if the linux drive is unplugged
11:13
<Gadi_eeepc>
now, usually, you only feel that when X inits
11:13
vbundi: try changing XSERVER=vesa
11:13
<Lns>
damianos, heh..
11:13
<Gadi_eeepc>
see if it is slow even with geeneric drivers
11:14
<vbundi>
Gadi_eeepc: ohh I didn't think of that... I have done that on ltsp4 and it works way better on some clients
11:14
<Lns>
ati drivers = not the most fun to deal with
11:14
<vbundi>
damianos: sounds like a windows issue man
11:15
<Lns>
Not to knock MS but I think it's so amusing how even Win7 doesn't understand ext*
11:15
<damianos>
that's what I was afraid of...I'm pretty good with this stuff but bootloaders are a mystery to me
11:15
<Lns>
it's like "na na na na, I don't see you, na na na"
11:15
damianos, it shouldn't bsod just because another drive is connected though...
11:16
<Gadi_eeepc>
damianos: which drive is set in the BIOS?
11:16
<Lns>
even if it's the evil linux
11:16
<vbundi>
Lns: evil linux indeed!
11:16
<damianos>
that's what I didn't understand....I figured if it was a boot issue it shouldn't boot either way
11:16
I have the jumper on the XP drive setting it to Master
11:17
The linux drive is first in the boot order in the BIOS
11:17
<Gadi_eeepc>
is the Linnux drive set to slave?
11:17
<Lns>
damianos, when does it bluescreen?
11:17
<damianos>
yes
11:18
<Gadi_eeepc>
and if you set the bios to boot from the master , it fails?
11:18
<damianos>
Either way I change it in the bios, XP will BSOD if Linux is connected
11:18
<Lns>
damianos, what's the info on the bsod
11:18pmatulis has joined #ltsp
11:18
<damianos>
I'll get it ....BRB (gotta reboot)
11:19damianos has quit IRC
11:19* Lns checks the uptime on his ltsp servers
11:23
<vbundi>
Gadi_eeepc: xserver=vesa gives unreadable X display
11:24
<Lns>
:/
11:26damianos has joined #ltsp
11:26* vbundi googles for ltsp 4.2 info
11:32
<damianos>
the error is "Check your hard drive to make sure it is properly terminated. Run CHKDSK /F to check for hard drive corruption and then restart your computer... ...STOP: 0x0000007b (0XF7A5D524,0XC0000034,0X00000000,0X00000000)"
11:35
<Lns>
whhaaaat
11:35
did you try another data cable?
11:36
another ide channel?
11:36
nice how it tells you to basically hose your linux filesystem by running chkdsk /f
11:36
<damianos>
I'm thinking that maybe I should set Linux to Master
11:36
<Lns>
;)
11:37
<vbundi>
are you using grub to boot or what
11:37
<damianos>
The only thing I have XP for is for some games and to test web pages in Internet Destroyer
11:37
<vbundi>
windows that is.. or is it windows boot loader
11:37
<damianos>
I am using grub to boot I think
11:38johnny has left #ltsp
11:38
<damianos>
I'm thinking that I have to add something to XP's boot.ini file to let it know that Grub is in charge
11:38
<vbundi>
so when your computer starts up you get an option that says Linux_Distro_Whatever and another option that says Windows XP
11:38
<damianos>
yes
11:39
then it asks me if I want to run windows normally , safe mode, last known good configuration etc
11:39johnny has joined #ltsp
11:40
<vbundi>
if you take your windows drive out of the machine (or unplug it) can you still get into linux?
11:40
<damianos>
yes
11:40mikkel has joined #ltsp
11:41
<vbundi>
ok so put your XP Pro CD in, and boot into recovery mode (F6?) there should be an option to repair your windows install
11:41
<Lns>
damianos, I'd verify all of your bootloader settings for windows and maybe even run fixmbr/fixboot or whatever it is from a windows rescue session..other than that, LTSP chan might not be the best place to figure it out ;)
11:41* sbalneav wonders what this has to do with LTSP?
11:41* Lns highfives sbalneav
11:41
<vbundi>
^ Lns
11:42* Lns spent all day yesterday ridding a win machine of a trojan...again... and comes to #ltsp to remember that software isn't always horrible to work with ;)
11:42
<Lns>
sorry i'll shut up now
11:44
<vbundi>
ok so on an LTSP note, however unsupported... does anyone have access to old LTSP4.2 documentation? I found all the tgz's and .ltsp files on the server but have no idea wtf to do with em
11:45
<damianos>
ok...I'll leave...sorry to get off topic
11:45damianos has left #ltsp
11:47
<sbalneav>
vbundi: I beleive there's a lot of old documentation on the wiki
11:47
As well, I think the old doco pdf's still on SF
11:48
<Gadi_eeepc>
vbundi: what do you get when you run: chroot /opt/ltsp/i386 dpkg -l ltsp-client
11:49
<vbundi>
5.1.90-0ubuntu3
11:50
<sbalneav>
http://sourceforge.net/projects/ltsp/files/
11:50
I think there's a guide for 3.0
11:50
<Gadi_eeepc>
vbundi: ok, that is the one in the karmic repos. stgraber's ppa has a newer one which has more speed improvements (tho not all)
11:51
vbundi: you may want to add his ppa in the chroot and upgrade
11:51
<vbundi>
sbalneav: ah thanks, I was getting boken links on the LTSP wiki
11:51
Gadi_eeepc: I added it to the server but not the chroot.... I guess that might help me
11:51* Gadi_eeepc hopes stgraber uploads some new packages today in anticipation of feature freeze
11:52
<vbundi>
what's feature freeze
11:52
<Lns>
brr
11:52Lns has quit IRC
11:52
<Gadi_eeepc>
when ubuntu stops allowing new features to packages
11:52
<vbundi>
ah I see
11:52
<Gadi_eeepc>
for the next release
11:53
<sbalneav>
The ltsp wiki's pretty broken.
11:54
<vbundi>
yeah, thanks for the link to SF, I wasn't bein lazy just couldn't find anything behind all the cobwebs
11:54Selveste1_ has joined #ltsp
11:54
<vbundi>
so ltsp 3.0 is fundamentally the same install as 4.x?
11:55
<sbalneav>
kinda sorta
11:55
lots of differences
11:56
<vbundi>
well I found some info for 4.1 and it didn't sound too horrible... run ltsp-utils and choose your packages to install
11:56shawnp0wers has quit IRC
11:57
<Gadi_eeepc>
actually, it was ltspadmin, iirc
11:57
<vbundi>
however ltsp-utils seems to be only available in the 4.1 downloads..
11:57
<Gadi_eeepc>
ltsp-utils wass the package name
11:57
but why do you need it?
11:58
if you have a working ltsp4.2, just tar it up
11:58
and move it
11:58
<vbundi>
"working" is relative for this install
11:59
yes it works... the other IT guy hasn't documented anything and there are plenty of little problems
12:00
he's a programmer so basically whenever he ran into a problem setting up ltsp 4.2 he wrote some script to get around it.
12:02
<johnny>
uhmm.. i'm a programmer..
12:02
first thing i do is get on the support channel if i can't find any docs
12:02
<vbundi>
not what I meant
12:03
I can see I coulda worded that a bit differently
12:03
<sbalneav>
Out for lunch, bbiab
12:08waldo323 has quit IRC
12:12GGD_ has joined #ltsp
12:16GGD has quit IRC
12:17Lns has joined #ltsp
12:17
<stgraber>
Gadi_eeepc: FF is next week
12:18
Gadi_eeepc: I'm currently uploading daily snapshots to my PPA, then will release 5.2 and upload everything to Lucid next week
12:19
<Lns>
stgraber: do you know anyone using your ppa w/hardy?
12:19
<stgraber>
Lns: no, I don't have backports for hardy
12:20
<Lns>
oh, i thought i saw it in the list
12:20
<stgraber>
the daily are only for Lucid and stable releases are backported to Karmic
12:20
I don't think current LTSP would work on Hardy at all (at least not with the current packaging)
12:20
<Lns>
gotcha, no worries =)
12:20waldo323 has joined #ltsp
12:21
<vagrantc>
is it all the nbd/aufs/squashfs stuff that would make it difficult to backport?
12:21
the debian backports have always been pretty trivial.
12:23
<ogra>
hmm, no alkis around
12:24* vagrantc waves to ogra
12:24
<ogra>
the swapfile stuff in ltsp_nbd is just there to get a client to boot at all so you can do debugging etc ...
12:24
<vagrantc>
on really low spec machines ...
12:24
<ogra>
with testing i found the minimum to keep the kernel running at that stage was 48M
12:25
thats why i picked that value
12:25* ogra waves back to vagrantc
12:25
<ogra>
you really dont want to run a client that actually *needs* to swap permanently over the net :)
12:25
<vagrantc>
heh
12:26
<ogra>
min_ram=49152 is just one of these "very last resort" things :)
12:27
<vagrantc>
ogra: so you're thinking it should stay that way?
12:28
<ogra>
well, someone should test if thats still accurate
12:28
<stgraber>
vagrantc: don't you have compcache in Debian ?
12:28
<vagrantc>
stgraber: i don't think so
12:28
<ogra>
if you dont hit OOM its still ok
12:28
stgraber, i think it went upstream
12:28
but only with .32
12:29
<stgraber>
hmm, ok. It really helps with LTSP on low-memory thin clients
12:29
<vagrantc>
stgraber: right.
12:29
<ogra>
it does
12:29
<vagrantc>
i've been testing with .32-trunk ... though i could look at .32
12:32
<Lns>
wow compcache sounds like a cool idea!
12:33
<vagrantc>
i remember the idea being proposed for compressing on-disk swap space ... but it actually makes more sense all in ram.
12:33
<Lns>
hehe, from https://wiki.edubuntu.org/Compcache - Martha is a teacher and just got a bunch of old PCs donated for the class. All of them have 500MHz PII CPUs, 32MB memory, no HDD and PXE boot capable network cards. The principal of the school agreed that money for an LTSP server in in the budget. Marthas husband is Ubuntu enthusiast and just read that with Intrepid Ibex the requirements for LTSP clients dropped to 32MB. On the weekend marthas husba
12:33
nd installs Ubuntu LTSP from the alternate CD, sets up the network in her classroom and everything works out of the box.
12:33
<vagrantc>
stgraber, ogra: do you know what kernel config options i'd look for for compcache?
12:34
<ogra>
no, sadly i dont know whats used after the merge ... it used to be COMPCACHE when it was a patch
12:34
<vagrantc>
Lns: well, almost...
12:34
<stgraber>
vagrantc: CONFIG_BLK_DEV_COMPCACHE=m
12:35
vagrantc: according to /boot/config-2.6.32-12-generic here
12:37
<vbundi>
Lns: lies!
12:37
<Lns>
vbundi: ?
12:37
hehe
12:37
<ogra>
dont call me a liar !
12:37
:)
12:37
<vbundi>
Lns: my 800mhz 256MB terminals barely run ;P
12:38
<ogra>
though i admit martha is made up
12:38
<Lns>
i'm sure there's a martha *somewhere*...
12:38
<vbundi>
maybe because they are non-intel processors
12:38
<ogra>
vbundi, 500MHz PII CPUs :)
12:38
<Lns>
it never said they used graphical sessions either ;)
12:38
<vbundi>
lol
12:39
<Lns>
see all these pretty graphics just cause problems.
12:39
<vbundi>
how old is Martha
12:39
<ogra>
yeah, we should switch back to matricx printers for output anyway
12:39
*matrix
12:39
monitors suck so much power
12:39
<vbundi>
<-- has 2 of them within 10 feet of him.
12:40
I also have a 6 inch b/w monitor
12:40
<Lns>
ogra: =p think of the noise!
12:41
<ogra>
Lns, think of earplugs :)
12:41
<Lns>
*ahem* So I have an ltsp client with a tty...a *real* teletype that is..and i can't get firefox to display my homepage
12:41
<vbundi>
Matrix printers cost more than 17" LCD's to buy fyi ;)
12:42
<Lns>
I run out of paper whenever I click reload
12:42
<vbundi>
lol
12:43alkisg has joined #ltsp
12:45GGD has joined #ltsp
12:46* vagrantc looks for signs of compcache
12:47GGD has quit IRC
12:47
<ogra>
vagrantc, look for /dev/ramzswap
12:47
<stgraber>
"Dec 12, 09 - compcache is now in mainline -- it will be part of kernel 2.6.33.
12:48
"
12:48
<vagrantc>
ah.
12:48
<stgraber>
/lib/modules/2.6.32-12-generic/kernel/ubuntu/compcache
12:48
so it's not upstream in 2.6.32
12:48
<ogra>
ah, i think our kernel team is working on backporting the .33 version
12:49
<vagrantc>
i'd really like to have that in debian ... but i think the current plan is to use .32
12:49GGD_ has quit IRC
12:49
<ogra>
doesnt the debian kernel team backport from mainline on request ?
12:50
<vagrantc>
ogra: i'll file a wishlist bug
12:50
does it *require* userspace tools?
12:50
or is it useful just with the kernel modules?
12:50
<ogra>
its only the kernel module
12:50* vagrantc knows there's compcache-tools sitting in debian's NEW queue
12:51
<ogra>
you need to supply the size/percentage on modprobe
12:59GGD has joined #ltsp
12:59Egyptian[Home] has joined #ltsp
13:11litlebuda has quit IRC
13:15litlebuda has joined #ltsp
13:29
<alincoln>
i'm trying to figure out LOCAL_APPS_EXTRAMOUNTS (in upstream bzr). if i give it "/media", X01-localapps will not mount it - sshfs gives a "read: connection reset by peer" error and nothing else useful, even if sshfs_debug is used. it mounts my user's /home just fine, but not other directories I put in EXTRAMOUNTS. it does not seem to be a permissions thing - if i have X01-localapps spit out uid/gid using the id command, it show
13:32
oh! and if i go to a root shell and do it manually, it works fine.
13:32
<vagrantc>
fun
13:33
<alincoln>
i can have /media, /opt, whatever all mounted via sshfs
13:33
just doesn't work via X01-localapps.
13:34* Gadi_eeepc wonders if the double-quotes in the sshfs call are correct
13:34
<alincoln>
i can check quick...
13:34* Gadi_eeepc would remove them
13:40
<vagrantc>
Gadi_eeepc: regarding your latests ltspfs commit: i'm wondering if "echo $!" properly handles the backgrounded cdpinger call...
13:41
<Gadi_eeepc>
well, really we only need to touch the file
13:41
I just grab the pid for kicks
13:41
:)
13:41
<alincoln>
Gadi_eeepc: removing those double quotes doesn't help this.
13:41
<vagrantc>
would be even better to verify the pidfile...
13:41
<Gadi_eeepc>
well $! should get you the pid of the last backgrouded proc
13:41
<alincoln>
i'll continue to poke at it, but if anyone's got any good ideas...
13:42
<Gadi_eeepc>
alincoln: do this
13:42
echo sshfs ..... >/tmp/debug
13:43
<vagrantc>
Gadi_eeepc: it also doesn't handle removing a USB cdrom and plugging it back in again.
13:43
well, i guess it might ...
13:43
<Gadi_eeepc>
and then on the next line
13:43
<vagrantc>
no... it woudl fail
13:43
<Gadi_eeepc>
sshfs ...... 2>>/tmp/debug
13:43
vagrantc: why would it fail?
13:44
<vagrantc>
Gadi_eeepc: because cdpinger wouldn't get started after re-inserting it.
13:44
<Gadi_eeepc>
cdpinger would just continue running for the device
13:44
it would never stop running
13:44
<vagrantc>
Gadi_eeepc: cdpinger dies when you unplug a USB cdrom.
13:44
<Gadi_eeepc>
how?
13:44
<vagrantc>
it just does.
13:44
<Gadi_eeepc>
what causes it to die?
13:44
<vagrantc>
it commits suicide when it's device disappears.
13:44
<Gadi_eeepc>
how dramatic
13:45
<vagrantc>
you asked
13:45
<Gadi_eeepc>
ok
13:45
so, we need to remove the pid
13:45
hen cdpinger dies
13:45
<vagrantc>
the USB cds make it really tricky.
13:45
<Gadi_eeepc>
or check the pid
13:45
<vagrantc>
but yeah, that should handle it... we hope.
13:45
<Gadi_eeepc>
like u say
13:46
I think Id prefer removinng
13:46
<vagrantc>
simple and to the point.
13:46
<Gadi_eeepc>
Ill add the code
13:47
<HardDisk>
i'll bring the girls
13:48
<Gadi_eeepc>
man - that must be some hard disk
13:48
<alincoln>
Gadi_eeepc: i already did that - the command looks the same for the /home sshfs and the EXTRAMOUNTS sshfs commands
13:49
same socket, everything
13:50
<HardDisk>
how's the project going on? you know I've mentioned to my boss to try to test your technology to load balance avayas
13:50
<Gadi_eeepc>
alincoln: did you redirect stderr
13:50
?
13:50
<HardDisk>
we have an tftp app running for avaya phones
13:51
<alincoln>
Gadi_eeepc: yep, both stdout and stderr
13:51
<HardDisk>
i want to try the cluster model to see how it handles them
13:51
<alincoln>
when it fails, there's only the "read: ..." link
13:51
er line
13:52
when it succeeds, there
13:52
's some extra info, depending on if i've added sshfs_debug.
13:53
auth.log just gives sshd messages that say "Failed password for root"
13:53
when an sshfs mount fails.
13:55mgariepy has quit IRC
13:56mgariepy has joined #ltsp
14:00litlebuda has quit IRC
14:01litlebuda has joined #ltsp
14:01
<alincoln>
Gadi_eeepc: er, misunderstood your redirect suggestion at first, but yes, i've looked at stdout and stderr from the good sshfs and bad sshfs commands, and checked that the commands themselves look right.
14:03
<Gadi_eeepc>
alincoln: can you paste your current X01-localapps?
14:03
<alincoln>
well, i have since removed all the debugging stuff i put in there :P you want to see what i had for that too?
14:04
<Gadi_eeepc>
whatever is currently running
14:04
<alincoln>
k
14:04
<Gadi_eeepc>
warts and all
14:04
:)
14:04cliebow has quit IRC
14:07
<alincoln>
Gadi_eeepc: http://ltsp.pastebin.com/m68be3c5d
14:07
all that's changed in that from upstream are some uid/gid checks i put in.
14:07litlebuda has quit IRC
14:07
<vbundi>
if I wanted to boot a different PXE image on my ltsp server is it just a matter of copying the files to /var/lib/tftpboot and setting a filename in dhcpd.conf
14:08
<alkisg>
vbundi, yes
14:08
<vbundi>
thx
14:10
<Gadi_eeepc>
alincoln: you are on ubuntu, right? (nbd+aufs)
14:11
<alincoln>
Gadi_eeepc: right-o
14:11
lucid
14:11
pulling stephane's lucid packaging stuff to use
14:12Kicer86 has quit IRC
14:12
<Gadi_eeepc>
out of curiosity, can you make a directory on the server /tmp/foo aand set LOCAL_APPS_EXTRAMOUNTS=/tmp/foo
14:12
?
14:14
<alincoln>
yep - i did that for one called /media/testmedia, but i can try inside /tmp instead in case that's different
14:14
one sec
14:18
Gadi_eeepc: makes the directory just fine on the client, but does not mount it. same message from sshd in auth.log.
14:19
/home mount works fine as before.
14:21etyack1 has joined #ltsp
14:21Gadi_eeepc has quit IRC
14:21etyack has quit IRC
14:21
<vagrantc>
oh gadi
14:23
not *that* simple
14:23Gadi_eeepc has joined #ltsp
14:24
<vagrantc>
Gadi_eeepc: so...
14:24
Gadi_eeepc: it's more complicated than that :)
14:24* Gadi_eeepc shakes fist at WAP
14:24Sorell has joined #ltsp
14:24
<Gadi_eeepc>
vagrantc: do tell
14:24
<vagrantc>
Gadi_eeepc: cdpinger will call ltspfs_entry with remove when a CD is ejected ... but we don't want to remove the pid file at that point
14:25
<Gadi_eeepc>
ur kidding
14:25GodFather has joined #ltsp
14:25
<vagrantc>
Gadi_eeepc: heh
14:25
<Gadi_eeepc>
do we still put the marble in the top and have it hit the boot to make the diver fall in the bathtub?
14:25
<vagrantc>
"let me think up a good way to pull Gadi_eeepc's leg while ..."
14:26
Gadi_eeepc: well, this is more like square marbles
14:26* vagrantc renames cdpinger to rubegoldbergpinger
14:27
<vagrantc>
it all comes down to the fact that CD insertion/removal gives no udev events.
14:27
that's why it's such a mess.
14:29
<Gadi_eeepc>
well, we also do not distinguish events
14:29
there are 4 events:
14:30
drive insertion/removal and disc insertion/removal
14:30
<vagrantc>
for most devices, they're the same... which is why udev works as well as it does
14:30
<Gadi_eeepc>
right
14:30
<vagrantc>
i'm presuming DVDs have the same issues
14:31
<Gadi_eeepc>
so you are trying to launch/kill cdpinger on the first
14:31
and ltspfsmount/umount on the second
14:32etyack1 has quit IRC
14:32
<Gadi_eeepc>
ok
14:32
<vagrantc>
drive removal implies disc removal, but drive insertion doesn't imply disc insertion
14:32
<Gadi_eeepc>
so I am clearer now
14:33
well, even easier:
14:33
drive insertion -> cdpinger launch
14:33
drive removal -> cdpinger kill
14:33
disc insertion -> add_device
14:34
disc removal -> remove_device
14:34
<vagrantc>
sounds so simple... but... :)
14:35
<Gadi_eeepc>
if we want to do it this way,
14:35
we need the call from udev to be distinguishable from the call from cdpinger
14:36
cdpinger cannot simply make the same call udev would
14:36
<vagrantc>
that would be cleaner
14:36
<Gadi_eeepc>
so, cdpinger should call ltspfs_entry cdrom add_disc
14:37
ltspfs_entry cdrom remove_disc
14:37
<vagrantc>
what about ltspfs_entry add_cdrom || ltspfs_entry remove_cdrom
14:37
rather than adding a third parameter
14:38
<Gadi_eeepc>
there's always a second param
14:38
normally, ltspfs_entry is called with device action
14:38
<vagrantc>
sure.
14:38
<Gadi_eeepc>
well, other way around
14:38
action device
14:39
we have no control over udev's call
14:39
it always does add/remove
14:39frederickjh has quit IRC
14:39
<Gadi_eeepc>
but, we can control cdpinger
14:39
and have an add_disc/remove_disc
14:39
<vagrantc>
well, we could add more udev rules ... but nicer to change cdpinger, yes. yes!
14:39
that would simplify things immensely!
14:39
Gadi_eeepc: you've done it again!
14:40
<Gadi_eeepc>
so, under "add" we simply add the drive
14:40
and with add_disc we do the ltspfsmounter stuff
14:40
and I guess "add" == launch cdpinger
14:40
and remove == kill cdpinger
14:41
which is not too far off from what you allready have
14:41
:)
14:41
which should make this easy
14:43
<vagrantc>
the only change would be in call_cdpinger?
14:44
i guess we could even get rid of call_cdpinger...
14:44
<Gadi_eeepc>
no, we need it
14:45
"add" -> add_device() -> call_cdpinger -> exit
14:45
<vagrantc>
so it just needs to check for a different argument.
14:45
<Gadi_eeepc>
or be done at a different time
14:45
yeah
14:46
need to move things
14:46
"add_disc" -> add_device
14:46
"add" -> call_cdpinger
14:46
<vagrantc>
ah.
14:46
<Gadi_eeepc>
"remove" -> kill_cdpinger
14:46
"remove_disc" -> remove_device
14:47Sorell has quit IRC
14:47
<Gadi_eeepc>
add/remove conditional on device == cd
14:47
<vagrantc>
why not just use a conditional based on the arguments?
14:47
<Gadi_eeepc>
well, udev will call "add/remove" for every device
14:48
<vagrantc>
and it has to happen after the LOCALDEV_DENY stuff
14:49
<Gadi_eeepc>
right
14:53
<vagrantc>
Gadi_eeepc: you working on this, or should i?
14:53
<Gadi_eeepc>
Ill give it a whirl
14:53
if you can help test?
14:53
we will need to recompile cdpinger
14:53
<vagrantc>
i'm not in the best position to test, in that cdpinger hasn't worked for me for months... :)
14:53
<Gadi_eeepc>
as the ltspfs_entry call is hardcoded in there
14:53
<vagrantc>
i guess i could test on lenny.
14:53
<Gadi_eeepc>
hmm...
14:54
well, I am sure there are others here we could solicit
14:54
I am snowed in atm
14:54
working from home
14:54
:)
14:54
<vagrantc>
i'll build a lenny chroot ... last i tried, that worked.
14:55
then i can test the packages from backports.org i uploaded the other day. :)
14:57pmatulis has quit IRC
14:57
<vagrantc>
i should really pull out a real thin client, too.
14:57
<ogra>
yeah, take an ARM one
15:04etyack has joined #ltsp
15:06pimpministerp has quit IRC
15:06highvoltage has quit IRC
15:07hersonls has quit IRC
15:08litlebuda has joined #ltsp
15:08highvoltage has joined #ltsp
15:19
<Gadi_eeepc>
vagrantc: heading ur way
15:19
r131
15:20
dont forget to compile cdpinger
15:20
<vagrantc>
Gadi_eeepc: i nearly always build from source
15:20
too likely to waste time on stupid mistakes otherwise :)
15:21* Gadi_eeepc id just accounting for the "nearly" ;)
15:21
<vagrantc>
:)
15:22
<alkisg>
Hmmm I'm missing something. At break=init, I can see DNS_SERVER and SEARCH_DOMAIN properly exported at the environment. But when the client boots, they're not in the environment and the dns from the dhcp server isn't used...
15:22
Ah, the change of root erases all of the environment?
15:22
<vagrantc>
your initramfs script is running in the initramfs environemnt ... it probably cleans up the environment before starting init
15:23
<alkisg>
Hum. Problem :(
15:23
So we _still_ don't have the ability to get dns from the dhcp server...
15:24
<Gadi_eeepc>
ltsp_config.d
15:24
;)
15:24
<alkisg>
:)
15:24
<Gadi_eeepc>
write to it from initramfs
15:24
<alkisg>
Is it writable?
15:24
<vagrantc>
it can be
15:25
<Gadi_eeepc>
or
15:25
<alkisg>
I could write to root/resolv.conf from the initramfs... :D
15:25
<Gadi_eeepc>
write to /var/cache/ltsp_config
15:25
along with the NBD_SERVER
15:26
<alkisg>
But is that guaranteed to be kept? Wasn't there a thought to delete it whenever new info from the server needs to be fetched?
15:27
<Gadi_eeepc>
is this not to set resolv.conf on boot?
15:27CAN-o-SPAM has quit IRC
15:27
<alkisg>
Yes - I'm worried if it's erased on boot, not afterwards...
15:28CAN-o-SPAM has joined #ltsp
15:28
<Gadi_eeepc>
no worries
15:28
if it is there to set SERVER, it will be there to set resolv.conf
15:28
:)
15:30highvoltage has quit IRC
15:30
<alkisg>
Yup, seems to work. Thanks guys, I'll commit this shortly.
15:31
<Gadi_eeepc>
alkisg: while you are in that portion of the code, can you test something else?
15:31
<alkisg>
Sure, what?
15:31
<Gadi_eeepc>
dhcpd.conf has an option for setting mtu
15:32
I wonder if udhcp picks it up
15:32
<alkisg>
Ah, in dnsmasq words?
15:32
I don't think so
15:32* alkisg mans udhcpc...
15:32
<Gadi_eeepc>
its a special option
15:32
<alkisg>
You're in luck :)
15:33
http://manpages.ubuntu.com/manpages/lucid/en/man8/udhcpc.8.html
15:33
mtu The MTU.
15:33
So the current code should be already exporting it to the initramfs
15:33
(and of course discarded afterwards...:))
15:33
<Gadi_eeepc>
cool
15:34
<alkisg>
Do you want me to put that to ltsp_config as well?
15:34
<Gadi_eeepc>
well it prolly uses it when it brings up the interface
15:34
no
15:34
<alkisg>
Ah, dhclient? cool
15:34
<Gadi_eeepc>
it prolly already works
15:34
<alkisg>
Eeeerrr
15:34
OK
15:34* Gadi_eeepc wonders about ipconfig....
15:36
<alkisg>
I do see code for setting mtu in the ipconfig sources...
15:36
I don't see code for reading it from dhcp, though :)
15:37
<Gadi_eeepc>
hmm
15:37shogunx has quit IRC
15:46
<alkisg>
Gadi, so now DNS_SERVER can hold multiple space separated IPs, right? I'll export all of them to ltsp_config....
15:47
<Gadi_eeepc>
yup
15:48highvoltage has joined #ltsp
15:51
<vagrantc>
wow. i forgot how much the optimizations we made improved things.
15:51
i'm just initially testing ltsp 5.1.88 ...
15:52litlebuda has quit IRC
15:54litlebuda has joined #ltsp
15:56
<alkisg>
Urm I can't write to /root from udhcp, the root is not available yet... any clues on where to put that code?
15:58
<Gadi_eeepc>
alkisg: ltsp_nbd?
15:58alexqwesa has quit IRC
15:59alexqwesa has joined #ltsp
16:00
<alkisg>
OK by me... I also wonder what will happen if both the dhcp server and lts.conf contain a dns server entry
16:01
<Gadi_eeepc>
you could also put it in nfs-bottom/ltsp
16:01
<alkisg>
Right, that's what I was looking now
16:01
<Gadi_eeepc>
maybe that's a bit more universal
16:01
<alkisg>
And I could check there if the DNS_SERVER is set by lts.conf
16:02
Ah, no need, it'll override the environment variable automatically
16:02
So setting dns in lts.conf will override the dns provided by dhcp - nice.
16:02
<Gadi_eeepc>
does udhcp get relaunched after the switchroot in the rootfs, or is it the same proc that continues to run from initramfs-space?
16:03
<alkisg>
It's the same, but udhcp then is supposed to launch a different script
16:03
(... and the results will be discarded - but anyway we only care about the lease update)
16:03
<Gadi_eeepc>
so, the question is does resolv.conf get rewritten when the lease refreshes
16:03
<alkisg>
Nope
16:04
<Gadi_eeepc>
good
16:04
<alkisg>
udhcp doesn't set anything
16:04
And I really doubt if it'll find the script to call, after the initramfs... :D
16:05
<vagrantc>
alkisg: is the script to call in tmp?
16:05
alkisg: with a predictable filename?
16:05
if so, it's very dangerous with localapps.
16:06
<alkisg>
Hmmm right
16:07
I thought of an alternative way to call it, it's in the comments there, but I didn't want to change the code more than I should
16:07* vagrantc posts a sign "Just when you think it's *ok* to use static filenames in /tmp, think again!"
16:08litlebuda has quit IRC
16:08
<alkisg>
Is the initramfs generally writable?
16:09
Can I copy udhcp to /usr/share/initramfs-tools/script/udhcp while on the initramfs?
16:10
<Gadi_eeepc>
alkisg: but, in initramfs-space, udhcp will know it as /scripts/udhcp
16:10
<alkisg>
Gadi_eeepc: not if I copy it... :)
16:10
udhcpc -s /usr/share/initramfs-tools/script/udhcp
16:11
<Gadi_eeepc>
ugh
16:11
well, to solve vagrantc's issue, simply use mktemp
16:11
<alkisg>
That's really clean, if we have write access there... :)
16:11
<Gadi_eeepc>
to create the filename
16:12
<alkisg>
It'd make the code much more readable - using the same script instead of generating another
16:12
<Gadi_eeepc>
you would need to also make a symlink or some such
16:12
so the path is the same in initramfs-space
16:13
/usr/share/initramfs-tools/scripts/udhcp -> rootfs/usr/share/initramfs-tools/scripts/udhcp
16:13
<alkisg>
Yup, that's why I'm asking if there's generally write access in the initramfs...
16:13
<Gadi_eeepc>
not at the init-premount point
16:14* alkisg does have write access to lucid init-premount right now, but doesn't know if that's true for other distros...
16:14
<Gadi_eeepc>
of course, you could always copy the script in the nfs-bottom and relaunch udhcp - but then you are requesting a lease for a third time
16:15
:)
16:15
how do you even have rootfs there?
16:15
<alkisg>
I don't need a rootfs
16:15
I need to mkdir /usr in the initramfs...
16:15
Not mkdir /root/usr...
16:16
<vagrantc>
there's write access to the initramfs immediately.
16:16
but not to /root/ (in a meaningful way)
16:16
<Gadi_eeepc>
right, but that /usr is not the same as rootfs' /usr
16:16
<alkisg>
Gadi_eeepc: udhcp only cares about the path...
16:17
<Gadi_eeepc>
isnt the script generated in initramfs?
16:17
<alkisg>
OK here are the comments I put on udhcp:
16:17
<vagrantc>
it's kind of an elegant hack to use /usr/share/initramfs-tools/scripts/udhcp ... you get the same script in both places (on a good day)
16:18
<alkisg>
# 1) copy the current script to /usr/share/initramfs-tools/script/udhcp while inside the initramfs (!),
16:18
# 2) run udhcpc -s /usr/share/initramfs-tools/script/udhcp,
16:18
# 3) use a "case 'prereqs' / 'bound' ..." to know if it's called from udhcp or not.
16:18
# This way no script would need to be generated, and udhcpc would be able to
16:18
# locate the current script even after the normal boot completes! :-)
16:18
<Gadi_eeepc>
isnt the script generated in initramfs?
16:18
<alkisg>
Yes
16:18
<vagrantc>
seems cleaner ... though wouldn't it need to behave differently on initial call and subsequent calls?
16:18
<alkisg>
But it's also there on the chroot
16:18
<Gadi_eeepc>
the identical script?
16:19
<alkisg>
Yes
16:19
<Gadi_eeepc>
oh
16:19
<alkisg>
It'd just need a prereqs part
16:19
<Gadi_eeepc>
oh
16:19
then yeah, do that
16:19
easy-shmeezy
16:20
<alkisg>
k... urgh coding will be easy, but testing will take a lot of time... :D
16:20
<vagrantc>
Gadi_eeepc: cdpinger didn't start...
16:20
<Gadi_eeepc>
vagrantc: you testing a usb cdro?
16:20
*cdrom
16:21
<vagrantc>
Gadi_eeepc: no, just a regular one.
16:21
Gadi_eeepc: that worked with 0.5.14 just moments before
16:21
<Gadi_eeepc>
can you take out the cdpinger call in the initscripts?
16:21
inf configure_localdev
16:22* Gadi_eeepc just remembered we have that one there
16:22
<Gadi_eeepc>
which we should remove
16:23
<vagrantc>
i manually started cdpinger, but it's not doing anything.
16:23
huh.
16:23Selveste1__ has joined #ltsp
16:23
<Gadi_eeepc>
whats up?
16:23
<vagrantc>
it's exhibiting the same problem that debian testing is experiencing
16:24Selveste1_ has quit IRC
16:24
<vagrantc>
says "Disk detected. Mounting" every 3 seconds.
16:24
<Gadi_eeepc>
huh
16:25
<vagrantc>
thanks to sbalneav's syslog reporting, i have some clue as to what it's trying to do ...
16:25
Gadi_eeepc: even after ejecting the disk.
16:25CAN-o-SPAM has quit IRC
16:26* sbalneav 's ears perk up
16:26
<vagrantc>
but not enough of one :(
16:26
it *is* comforting to know it's trying, at least :)
16:27
<sbalneav>
A for effort!
16:27
Heading home, back on tonight.
16:28
<Gadi_eeepc>
even after ejecting?!
16:28
<vagrantc>
Gadi_eeepc: yes.
16:28mikkel has quit IRC
16:28
<vagrantc>
something is amiss.
16:29
<Gadi_eeepc>
seems it is not correctly getting CDROM_DRIVE_STATUS
16:29
<vagrantc>
maybe qemu is confusing it. i really need to be able to test on real hardware...
16:29GodFather has quit IRC
16:30
<Gadi_eeepc>
ah
16:30
it should only loop there if the sttatus is CDS_DISC_OK
16:31
<vagrantc>
so it found an actual bug?
16:32
<Gadi_eeepc>
maybe its a qemu bug?
16:33
<vagrantc>
maybe.
16:33
works fine with older hardware, though.
16:33
er, older version of ltspfs
16:34
or not...
16:36
<Gadi_eeepc>
well, I dont like that cdpinger was never called to begin with
16:36
that one's on us
16:37
need to see why ltspfs_entry didnt fire it off
16:37grantk has left #ltsp
16:38pmatulis has joined #ltsp
16:40
<vagrantc>
Gadi_eeepc: and the versions i'm running where it does work have the configure_localdev bug, so it wasn't being started from init
16:40comfrey_ has joined #ltsp
16:40
<vagrantc>
i.e. the duplicate functions issue
16:40
<Gadi_eeepc>
right
16:40mgariepy has quit IRC
16:41
<Gadi_eeepc>
the one you are testing now also has that bug?
16:41
<vagrantc>
yes.
16:41
just to say, with version ltspfs 0.5.14 it works. with ltspfs-trunk it doesn't.
16:42
ldm 2.0.52, ltsp 5.1.98
16:43
no /var/run/cdpinger.*.pid files
16:44
oops, that's with 0.5.14 ... let me check the newer version
16:44
<Gadi_eeepc>
oh wait1
16:44
I think I found something
16:44
huh?
16:45
oh nm
16:45
didnt see the "shift" in the arguments
16:45
we're good
16:47evilx has quit IRC
16:47evilx has joined #ltsp
16:49
<vagrantc>
well, not good, per se
16:49
<Gadi_eeepc>
oh
16:49
I did find something
16:49
I need to move where I start ltspfsd
16:49etyack has quit IRC
16:49
<Gadi_eeepc>
it is still started in add_device
16:49
grr
16:49
one se
16:51* Gadi_eeepc bets you dont have ltspfsd running
16:59
<vagrantc>
Gadi_eeepc: good bet :)
17:00vvinet has quit IRC
17:01
<vagrantc>
Gadi_eeepc: why would start_ltspfsd need to run anywhere else, though...
17:02lucascoala has joined #ltsp
17:03
<vagrantc>
Gadi_eeepc: it should only start ltspfsd when it's actually needed ... cdpinger could be running without a CD
17:06
at least, i think that should work...
17:06
<Gadi_eeepc>
right - as long as there is at least one verified device, ltspfsd should be launched
17:06
any subsequent call to ltspfsd will check to make sure it is there
17:07
ltspfsd never needs to be killed
17:07
<vagrantc>
right
17:09alkisg has quit IRC
17:11bobby_C has quit IRC
17:11lucascoala has quit IRC
17:15
<vagrantc>
now this is weird.
17:15
Gadi_eeepc: it's recognizing a usb stick as a CDROM drive.
17:17
ah, but i might be confusing the issue by using an .iso image as a USB stick...
17:20
Gadi_eeepc: i wonder if it's not actually the changes you made today that broke it...
17:25
i'll try ltspfs-trunk r128
17:29mgariepy has joined #ltsp
17:31
<vagrantc>
Gadi_eeepc: yup. 128 works fine.
17:36
<Lns>
Gadi bork bork borked it =p
17:39lucascoala has joined #ltsp
17:45
<vagrantc>
indepotpotpot
17:49
<Gadi_eeepc>
so, wait
17:49
now with ltspfsd moved, does it work?
17:50* vagrantc tries
17:51
<Lns>
lol vagrantc
17:53
cheekin in de baskit
17:53
2 points
17:54* Lns would blame his muppets knowledge on having a 17 month old, but it was actually his wife that is so into it =p
17:56
<vagrantc>
booting...
17:57
Gadi_eeepc: i had hope, but my skepticism won.
17:57
Gadi_eeepc: no go.
17:57
no ltspfsd, no cdpinger.
17:58
ltspfs_token was created, however.
17:58* Lns waves goodbye to the chan
17:59
<vagrantc>
we'll fix it, i swear!
18:00
<Gadi_eeepc>
huh
18:00Lns has quit IRC
18:00
<vagrantc>
Gadi_eeepc: i don't think cdpinger needs ltspfsd ... as ltspfs_entry starts ltspfsd if needed.
18:01
<Gadi_eeepc>
well, ok
18:01
we have a few questions here
18:01
first, if ltspfs_token got created - did it get created by ltspfs_entry?
18:01
or somewhere else
18:02
if by ltspfs_entry, then why did ltspfsd not run?
18:02
is there a /var/run/ltspfsd.pid file?
18:02
<vagrantc>
no pid file
18:03
<Gadi_eeepc>
then perhaps ltspfsd errored out and caused ltspfs_entry to exit 1
18:03
which would explain why cdpinger never started
18:03
can you run ltspfsd by hand?
18:07
<vagrantc>
i put some more noise in ltspfs_entry ...
18:07
if that doesn't work, i'll try it by hand.
18:07vvinet has joined #ltsp
18:07
<Gadi_eeepc>
I think your token may have been created in xinitrc.d
18:07
<vagrantc>
quite possibly.
18:08
<Gadi_eeepc>
hmm... I hope I dont have a syntax error in ltspfs_entry causing the script not to run
18:08
*blush*
18:13* Gadi_eeepc sees no such syntax errors
18:13
<vagrantc>
well, adding a usb stick works.
18:15
<Gadi_eeepc>
well, thats something
18:15
:)
18:16lucascoala has quit IRC
18:17
<vagrantc>
i see two ltspfsd's running...
18:17
they're parent/child, so that's probably fine...
18:24lucascoala has joined #ltsp
18:24
<Gadi_eeepc>
found a little thing
18:24
might be the cause of the cdpinger issue
18:24
just pushed it
18:25
<vagrantc>
if i start cdpinger manually, it calls ltspfs_entry once with add_disc
18:26
ah, the mode is borked.
18:26
<Gadi_eeepc>
thats good
18:26
why?
18:26
<vagrantc>
the backwards compatibility for add_fstab_entry and remove_fstab_entry (back when they were separate scripts)
18:27
<Gadi_eeepc>
ahhh....
18:27
I see
18:27
will fix
18:28
<vagrantc>
may as well use a case statement.
18:30
<Gadi_eeepc>
done
18:30
pushed
18:30
<vagrantc>
finally, i did something useful... :)
18:30
<Gadi_eeepc>
good eye
18:30
:)
18:31
<vagrantc>
in fact, we could probably safely ditch the compatibility code at this point...
18:31
<Gadi_eeepc>
we're so diligent about being backwards compatible
18:31
:)
18:31
<vagrantc>
i mean, it's older than debian's stable distribution.
18:32
older than what's in...
18:32
though just barely.
18:32
<Gadi_eeepc>
dont suppose you want to cheat and just copy ltspfs_entry over
18:32
:)
18:32
instead of rebuilding the source
18:33* vagrantc cheats
18:38
<Gadi_eeepc>
did the cheater prosper?
18:38
<vagrantc>
no
18:38
<Gadi_eeepc>
wha wha wha
18:40
we're very close
18:40
did cdpinger start at least?
18:40
<vagrantc>
no
18:40
<Gadi_eeepc>
ltspfsd?
18:40
<vagrantc>
ltspfsd did, at least.
18:40
<Gadi_eeepc>
\o/
18:40
<vagrantc>
but probably only because the usb stick is plugged in
18:41
<Gadi_eeepc>
wha wha wha
18:41
<vagrantc>
without usb... let's see what happens.
18:41
<Gadi_eeepc>
wait, you didnt reboot?
18:42
<vagrantc>
i actually had to reboot the server...
18:42
<Gadi_eeepc>
hehe
18:43
<vagrantc>
maybe we should enable some ltspfs_entry debugging...
18:43
troubleshooting udev issues is a pain...
18:44
<Gadi_eeepc>
ok - conditionally tho
18:44
maybe an LTSPFS_DEBUG var in lts.conf
18:44
<vagrantc>
ok, without a cd or usb stick inserted... nothing happens!
18:45
<Gadi_eeepc>
thats good
18:45
now, insert a cd
18:45
<vagrantc>
nada
18:45
<Gadi_eeepc>
ltspfsd?
18:45
<vagrantc>
nope
18:45* vagrantc tries usb
18:46etyack has joined #ltsp
18:47
<vagrantc>
ltspfsd.pid is present (though empty)
18:47
entries added to ltspfs_fstab
18:47
<Gadi_eeepc>
hmm
18:47
I wonder if the udevinfo vars are seen by the functions....
18:48
maybe I need to do that earlier...
18:48
<vagrantc>
that shouldn't make a difference.
18:48
<Gadi_eeepc>
sure it does
18:48
the cd stuff is all based on ${ID_TYPE}
18:48staffencasa has quit IRC
18:48
<Gadi_eeepc>
which may be empty
18:48
so nothing fires
18:49
<vagrantc>
the variables aren't looked at when you load the functions, only whenm you run them.
18:49
<Gadi_eeepc>
that's what I thought
18:49
but, maybe something is screwy
18:50
<vagrantc>
starting cdpinger manually i got a different syslog error...
18:50
"starting, device = /dev/cdrom"
18:50
followed by "Device /dev/cdrom disappeared. Exiting."
18:51
<Gadi_eeepc>
thats with a cd inserted?
18:51
<vagrantc>
yes.
18:52
<Gadi_eeepc>
thats weird
18:52
that means it cannot read from the drive
18:52
are you sure the drive is /dev/cdrom
18:52
?
18:52
<vagrantc>
yup
18:53Ahmuck has quit IRC
18:53
<Gadi_eeepc>
so, that's nothing I did
18:54
and if you remove the cd andd reinsert it?
18:54slidesinger has quit IRC
18:55
<Gadi_eeepc>
(is this all qemu accessing a physical drive ?)
18:55
<vagrantc>
this is all qemu acessing an .iso
18:57
doesn't recognize media change events...
18:57
cdpinger is still running...
18:58
<Gadi_eeepc>
and you ran cdpinger cdrom?
18:58
<vagrantc>
/usr/sbin/cdpinger /dev/cdrom
18:58
<Gadi_eeepc>
isnt it cdpinger cdrom (not /dev/cdrom)
18:59
<vagrantc>
either should work, no?
18:59
<Gadi_eeepc>
I dont think so
18:59
I think in ur case it will look for /dev/dev/cdrom
18:59
<vagrantc>
look at that.
19:00
back to the "Disk detect. Mounting" every 3 seconds...
19:01
<Gadi_eeepc>
well, now we're back in sbalneav's territory
19:02
well, actually
19:02
it *should* b calling ltspfs_entry every 3 seconds now
19:02
is it?
19:04
<vagrantc>
doesn't appear to be.
19:06
<Gadi_eeepc>
well, then either ltspfs_entry is not in /lib/udev or g_spawn_command_line_sync doesnt work anymore
19:07
<vagrantc>
definitely is in /lib/udev/
19:07
<Gadi_eeepc>
is the pid of cdpiinger changing?
19:07
every 3 seconds
19:08FuriousGeorge has quit IRC
19:08
<vagrantc>
still doesn't start at boot ...
19:09
and the logging i put into ltspfs_entry isn't kicking in...
19:10
<Gadi_eeepc>
did you put any logging at the top just to show that ltspfs_entry was called?
19:10
<vagrantc>
yeah, it went nowhere.
19:10
<Gadi_eeepc>
huh
19:10
<vagrantc>
it's getting called before /var/log and syslog are available.
19:10
<Gadi_eeepc>
so udev is not firing at all
19:10
<vagrantc>
it's registering the remove events.
19:11
<Gadi_eeepc>
oh - dont use syslog
19:11
just echo to a tmpfile
19:11
<vagrantc>
oooh... sometihing new...
19:11
Gadi_eeepc: i did both
19:13
starting cdpinger manually ... it works once ... though continues to try mounting it again.
19:14Faithful has quit IRC
19:15
<Gadi_eeepc>
I dont get it
19:17
<vagrantc>
me neither.
19:17
i'm wondering if cdpinger was always doing this, and it's only because i can see the output through syslog that i even see what it's doing.
19:17
<Gadi_eeepc>
maybe
19:18
I wonder if the backwards compat is screwing up things
19:18
<vagrantc>
Gadi_eeepc: i really don't get how it's only calling ltspfs_entry add_disc once
19:18
don;t see how...
19:18
now that it's "fixed" :)
19:18
<Gadi_eeepc>
well, when you insert a cd, it should
19:18
only call it once
19:19
<vagrantc>
maybe cdpinger's syslog messages are slightly misleading?
19:19
<Gadi_eeepc>
maybe
19:19
actually, yeah
19:19
it should call it once
19:19
but check every 3 seconds for status
19:20
if the disk is still inserted, it should not keep calling add_disc
19:20
once it is removed, it should call remove_disc
19:21
tho, we should confirm with sbalneav
19:21
but, for me, that is the desired behavior
19:22
and if the drive disappears, it calls remove_disc
19:22
and udev handles when cdpinger is alive and when it is dead
19:23
<vagrantc>
seems like a good idea.
19:23
<Gadi_eeepc>
which should be exactly how ltspfs_entry is coded now
19:23
<vagrantc>
it looks like in the switch statement the two syslog calls maybe should be in the if statements.
19:23
<Gadi_eeepc>
so, we should just make sure that cdpinger does what we expect
19:24
right
19:24
thaat would be clearer
19:24
<vagrantc>
but i'm not positive...
19:25
<Gadi_eeepc>
or there should be two
19:25
one that says "Tray open"
19:25
outside the if
19:25
and another "Unmounting" inside the if
19:26
and actually, it should be "Tray open or no disc"
19:26
want me to change it?
19:27
<vagrantc>
we should probably get it so that there aren't messages every 3 seconds.
19:27
that's just too noisy.
19:27
<Gadi_eeepc>
ok, only in the if statements, then
19:27
<vagrantc>
for debugging, we might want more, though.
19:27
<Gadi_eeepc>
then, we should have sbalneav add a flag
19:27
:)
19:28
brb - need to get kids to bed
19:30Faithful has joined #ltsp
19:46GGD has quit IRC
20:04lucascoala has quit IRC
20:06
<vagrantc>
Gadi_eeepc: verify_device is the last function called for the CD device...
20:07
and i think i see why...
20:08
<Gadi_eeepc>
FSTYPE?
20:08
<vagrantc>
tyupe
20:08
yup
20:08
if there's no CD in there, FSTYPE will be empty.
20:08
it used to run call_cdpinger before checking for FSTYPE
20:09
<Gadi_eeepc>
ah
20:09
hmm
20:09
I guesss we should move that code into add_device
20:09
<vagrantc>
though that still doesn't explain why it doesn't start with a cd inserted...
20:10
<Gadi_eeepc>
can we set FSTYPE=auto instead of mailing?
20:10
*bailing
20:10
hehe
20:10
<vagrantc>
then you'll end up with a lot of bunk devices
20:11
a lot of bunk mounts, that is
20:11
it'll clean them up when they fail to mount, i guess.. but it's messy.
20:12
maybe only die if FSTYPE is not CD?
20:12
er, ID_TYPE=CD && -z $FSTYPE
20:13
<Gadi_eeepc>
right
20:13
that might work
20:13
but, wait
20:13
<vagrantc>
a little ugly...
20:13
<Gadi_eeepc>
nm
20:13
not that ugly
20:14
cd's seem to be a special case
20:15
but thats not the syntax we need
20:15* vagrantc tries it for kicks
20:15
<Gadi_eeepc>
we need [ "${ID_TYPE}" != "cd" ] && [ -z ${FSTYPE} ] && exit 1
20:16
<vagrantc>
[ -z "$FSTYPE" ] && [ "$ID_TYPE" != "cd" ] && exit 1
20:16
heh
20:16
decent minds think pretty close
20:16
<Gadi_eeepc>
hehe
20:16
u can that again say
20:16
<vagrantc>
i'm still not sure that won't have undesireable repercussions...
20:17
but let's see if it at least handles this case.
20:18
ltspfsd and cdpinger start with no cdroms or usb sticks inserted.
20:19
<Gadi_eeepc>
that goods
20:19
<vagrantc>
inserting a CD works...
20:19
<Gadi_eeepc>
\o/
20:20
<vagrantc>
ejecting doesn't remove the entry
20:20
though that might just be qemu-isms.
20:20
<sbalneav>
Evening all
20:21
<vagrantc>
!s
20:21
<ltspbot>
vagrantc: "s" :: Scotty!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
20:22
<Gadi_eeepc>
vagrantc: well, I never was too keen on the whole sed -i of a file you are reading from stdin
20:23
<vagrantc>
Gadi_eeepc: heh
20:24
sbalneav: we've been busy breaking cdpinger all day!
20:24
<Gadi_eeepc>
vagrantc: we should really break that up
20:24
and use the while loop to get MOUNTPOINT
20:25
<sbalneav>
vagrantc: Find the problem?
20:25
<Gadi_eeepc>
and do the sed'ing and stuff after the loop
20:25
did you commit ur fix?
20:25
<vagrantc>
sbalneav: we've broken too much to know for sure :)
20:26
<Gadi_eeepc>
its totally better
20:26
:)
20:26
<vagrantc>
pushed.
20:26
no more broken than it ever was...
20:27F-GT has quit IRC
20:27
<vagrantc>
Gadi_eeepc: i'm looking at the set with udevinfo ... that's ghastly.
20:30
LTSP, a sub-project of "while read"
20:30
i should go be useless to society or something
20:32
<Gadi_eeepc>
ok - pushed my change
20:32slidesinger has joined #ltsp
20:32try2free has joined #ltsp
20:33lucascoala has joined #ltsp
20:35
<Gadi_eeepc>
which set with udevinfo?
20:35
<vagrantc>
nevermind.
20:36
Gadi_eeepc: so none of the .pid files work
20:36
well, the don't contain ... pids.
20:36
<Gadi_eeepc>
huh
20:36
<vagrantc>
that syntax didn't get me anything from bash or dash.
20:37
<Gadi_eeepc>
did you run a proc in the background?
20:37
<vagrantc>
no
20:37
though in one case, it's a backgrounded proc, and in the other, it isn't backgrounded.
20:37
<Gadi_eeepc>
ah, so that's the problem
20:37
<vagrantc>
part of it
20:38
<Gadi_eeepc>
well if you do: true &; echo $!
20:38
you should get a number
20:38
<vagrantc>
cdpinger.*pid doesn't get created.
20:38
ltspfsd.pid does.
20:39
ltspfsd.pid is empty, though
20:39
<Gadi_eeepc>
and yet, cdpinger runs....
20:40
<vagrantc>
indeed.
20:40
<stgraber>
maybe is it working in some weird ways ?
20:40
I guess if you start a program and it forks before detaching itself from the shell (as daemons do)
20:40
the initial PID won't exist anymore
20:40
and will give you an empty output for $!
20:41
<Gadi_eeepc>
do we need $$?
20:41
or will that just give us the controlling shell?
20:41
hmm...
20:42
cdpinger is backgrounded tho
20:42
explicitly
20:42
well, in that case, we dont get a pid file at all
20:43
ooh...maybe it doesn't like the $1
20:44
no, that should work
20:46F-GT has joined #ltsp
20:46mgariepy has quit IRC
20:47pmatulis has quit IRC
20:56shogunx has joined #ltsp
21:36try2free has quit IRC
21:52etyack has quit IRC
23:03tstafford has quit IRC
23:11Faithful has quit IRC
23:49map7 has quit IRC
23:53Mip5 has joined #ltsp
23:53
<Mip5>
howdy folks
23:57Mip5 has left #ltsp