IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 10 February 2010 (all times are UTC)
| 00:02 | alkisg has joined #ltsp | |
| 00:02 | try2free has left #ltsp | |
| 00:16 | daya has quit IRC | |
| 00:27 | ltspbot has joined #ltsp | |
| 00:48 | pts_ has joined #ltsp | |
| 00:57 | alkisg has quit IRC | |
| 01:26 | alkisg has joined #ltsp | |
| 01:26 | alkisg has joined #ltsp | |
| 01:46 | frederickjh has joined #ltsp | |
| 01:58 | FuriousGeorge 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:20 | bobby_C has joined #ltsp | |
| 02:28 | Briareos1 has joined #ltsp | |
| 02:28 | <Briareos1> good morning
| |
| 02:34 | Selveste1_ has quit IRC | |
| 02:44 | ltspbot has joined #ltsp | |
| 02:44 | sbalneav has joined #ltsp | |
| 02:50 | gnunux has joined #ltsp | |
| 02:50 | <gnunux> hi
| |
| 02:58 | F-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:06 | Egyptian[Home] has quit IRC | |
| 03:06 | <Briareos1> yes
| |
| 03:07 | Egyptian[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:34 | ogra has joined #ltsp | |
| 03:38 | Egyptian[Home] has quit IRC | |
| 03:52 | ltspbot has joined #ltsp | |
| 03:57 | sbalneav 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:06 | Egyptian[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:19 | Egyptian[Home] has quit IRC | |
| 04:19 | Egyptian[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:25 | alkisg has quit IRC | |
| 04:25 | Egyptian[Home] has quit IRC | |
| 04:39 | ogra_ is now known as ogra | |
| 04:39 | ogra has joined #ltsp | |
| 04:41 | F-GT has joined #ltsp | |
| 04:54 | Egyptian[Home] has joined #ltsp | |
| 04:55 | sene has joined #ltsp | |
| 05:01 | Egyptian[Home] has quit IRC | |
| 05:03 | Egyptian[Home] has joined #ltsp | |
| 05:09 | Sorell has quit IRC | |
| 05:11 | Sorell has joined #ltsp | |
| 05:12 | Egyptian[Home] has quit IRC | |
| 05:12 | hersonls has joined #ltsp | |
| 05:12 | isojussi 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:15 | Egyptian[Home] has joined #ltsp | |
| 05:21 | <Sorell> are you logged in as an root?
| |
| 05:31 | Egyptian[Home] has quit IRC | |
| 05:32 | Sorell has quit IRC | |
| 05:34 | Sorell 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:44 | Egyptian[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:49 | Egyptian[Home] has quit IRC | |
| 05:50 | Selveste1_ has joined #ltsp | |
| 05:55 | Egyptian[Home] has joined #ltsp | |
| 05:56 | isojussi has quit IRC | |
| 05:57 | bobby_C has quit IRC | |
| 05:59 | Egyptian[Home] has quit IRC | |
| 06:01 | Egyptian[Home] has joined #ltsp | |
| 06:01 | Selveste1_ has quit IRC | |
| 06:01 | Selveste1_ has joined #ltsp | |
| 06:06 | Egyptian[Home] has quit IRC | |
| 06:14 | Selveste1_ has quit IRC | |
| 06:14 | Sorell has quit IRC | |
| 06:14 | Selveste1_ has joined #ltsp | |
| 06:31 | pmatulis has joined #ltsp | |
| 06:33 | Egyptian[Home] has joined #ltsp | |
| 06:38 | Egyptian[Home] has quit IRC | |
| 06:50 | Egyptian[Home] has joined #ltsp | |
| 06:52 | GodFather has joined #ltsp | |
| 06:56 | Selveste1_ has quit IRC | |
| 06:56 | Selveste1_ has joined #ltsp | |
| 06:58 | Egyptian[Home] has quit IRC | |
| 06:58 | pimpministerp has joined #ltsp | |
| 07:01 | Egyptian[Home] has joined #ltsp | |
| 07:05 | shawnp0wers has quit IRC | |
| 07:15 | Kicer86 has joined #ltsp | |
| 07:17 | Egyptian[Home] has quit IRC | |
| 07:21 | alkisg has joined #ltsp | |
| 07:22 | Egyptian[Home] has joined #ltsp | |
| 07:25 | Lns has quit IRC | |
| 07:30 | Selveste1_ has quit IRC | |
| 07:34 | vvinet has joined #ltsp | |
| 07:35 | scottmaccal has joined #ltsp | |
| 07:36 | scottmaccal has quit IRC | |
| 07:39 | etyack has joined #ltsp | |
| 07:42 | jammcq has quit IRC | |
| 07:47 | Egyptian[Home] has quit IRC | |
| 07:49 | shawnp0wers has joined #ltsp | |
| 08:10 | Egyptian[Home] has joined #ltsp | |
| 08:13 | grantk has joined #ltsp | |
| 08:14 | bobby_C has joined #ltsp | |
| 08:24 | mgariepy has joined #ltsp | |
| 08:26 | Egyptian[Home] has quit IRC | |
| 08:28 | ogra has quit IRC | |
| 08:40 | Lns has joined #ltsp | |
| 08:47 | pts_ has quit IRC | |
| 08:47 | bobby_C has quit IRC | |
| 08:48 | bobby_C has joined #ltsp | |
| 09:03 | Egyptian[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:14 | Egyptian[Home] has quit IRC | |
| 09:16 | Briareos1 has quit IRC | |
| 09:19 | GGD has joined #ltsp | |
| 09:21 | CAN-o-SPAM has joined #ltsp | |
| 09:23 | ogra has joined #ltsp | |
| 09:25 | bobby_C has quit IRC | |
| 09:32 | dtrask has joined #ltsp | |
| 09:33 | Gadi_eeepc has joined #ltsp | |
| 09:38 | bobby_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:48 | litlebuda has joined #ltsp | |
| 09:49 | Gadi_eeepc has quit IRC | |
| 09:49 | waldo323 has joined #ltsp | |
| 09:50 | Gadi_eeepc has joined #ltsp | |
| 09:56 | etyack 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:01 | cliebow has joined #ltsp | |
| 10:03 | litlebuda has quit IRC | |
| 10:03 | litlebuda 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:08 | vagrantc 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:19 | Sorell 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:25 | Sorell has quit IRC | |
| 10:26 | <sbalneav> vbundi: the X server has gotten much larger and "full featured" since ltsp 4.2
| |
| 10:26 | etyack 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:42 | gnunux 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:53 | damianos 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:00 | alkisg 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:04 | GodFather has quit IRC | |
| 11:07 | pmatulis 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:18 | pmatulis has joined #ltsp | |
| 11:18 | <damianos> I'll get it ....BRB (gotta reboot)
| |
| 11:19 | damianos 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:26 | damianos 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:38 | johnny 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:39 | johnny 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:40 | mikkel 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:45 | damianos 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:52 | Lns 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:54 | Selveste1_ 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:56 | shawnp0wers 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:08 | waldo323 has quit IRC | |
| 12:12 | GGD_ has joined #ltsp | |
| 12:16 | GGD has quit IRC | |
| 12:17 | Lns 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:20 | waldo323 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:43 | alkisg has joined #ltsp | |
| 12:45 | GGD has joined #ltsp | |
| 12:46 | * vagrantc looks for signs of compcache | |
| 12:47 | GGD 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:49 | GGD_ 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:59 | GGD has joined #ltsp | |
| 12:59 | Egyptian[Home] has joined #ltsp | |
| 13:11 | litlebuda has quit IRC | |
| 13:15 | litlebuda 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:55 | mgariepy has quit IRC | |
| 13:56 | mgariepy has joined #ltsp | |
| 14:00 | litlebuda has quit IRC | |
| 14:01 | litlebuda 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:04 | cliebow 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:07 | litlebuda 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:12 | Kicer86 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:21 | etyack1 has joined #ltsp | |
| 14:21 | Gadi_eeepc has quit IRC | |
| 14:21 | etyack has quit IRC | |
| 14:21 | <vagrantc> oh gadi
| |
| 14:23 | not *that* simple
| |
| 14:23 | Gadi_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:24 | Sorell 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:25 | GodFather 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:32 | etyack1 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:39 | frederickjh 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:47 | Sorell 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:57 | pmatulis 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:04 | etyack has joined #ltsp | |
| 15:06 | pimpministerp has quit IRC | |
| 15:06 | highvoltage has quit IRC | |
| 15:07 | hersonls has quit IRC | |
| 15:08 | litlebuda has joined #ltsp | |
| 15:08 | highvoltage 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:27 | CAN-o-SPAM has quit IRC | |
| 15:27 | <alkisg> Yes - I'm worried if it's erased on boot, not afterwards...
| |
| 15:28 | CAN-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:30 | highvoltage 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:37 | shogunx 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:48 | highvoltage 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:52 | litlebuda has quit IRC | |
| 15:54 | litlebuda 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:58 | alexqwesa has quit IRC | |
| 15:59 | alexqwesa 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:08 | litlebuda 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:23 | Selveste1__ has joined #ltsp | |
| 16:23 | <Gadi_eeepc> whats up?
| |
| 16:23 | <vagrantc> it's exhibiting the same problem that debian testing is experiencing
| |
| 16:24 | Selveste1_ 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:25 | CAN-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:28 | mikkel 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:29 | GodFather 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:37 | grantk has left #ltsp | |
| 16:38 | pmatulis 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:40 | comfrey_ has joined #ltsp | |
| 16:40 | <vagrantc> i.e. the duplicate functions issue
| |
| 16:40 | <Gadi_eeepc> right
| |
| 16:40 | mgariepy 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:47 | evilx has quit IRC | |
| 16:47 | evilx 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:49 | etyack 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:00 | vvinet has quit IRC | |
| 17:01 | <vagrantc> Gadi_eeepc: why would start_ltspfsd need to run anywhere else, though...
| |
| 17:02 | lucascoala 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:09 | alkisg has quit IRC | |
| 17:11 | bobby_C has quit IRC | |
| 17:11 | lucascoala 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:29 | mgariepy has joined #ltsp | |
| 17:31 | <vagrantc> Gadi_eeepc: yup. 128 works fine.
| |
| 17:36 | <Lns> Gadi bork bork borked it =p
| |
| 17:39 | lucascoala 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:00 | Lns 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:07 | vvinet 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:16 | lucascoala has quit IRC | |
| 18:17 | <vagrantc> i see two ltspfsd's running...
| |
| 18:17 | they're parent/child, so that's probably fine...
| |
| 18:24 | lucascoala 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:46 | etyack 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:48 | staffencasa 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:53 | Ahmuck 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:54 | slidesinger 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:08 | FuriousGeorge 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:14 | Faithful 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:30 | Faithful has joined #ltsp | |
| 19:46 | GGD has quit IRC | |
| 20:04 | lucascoala 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:27 | F-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:32 | slidesinger has joined #ltsp | |
| 20:32 | try2free has joined #ltsp | |
| 20:33 | lucascoala 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:46 | F-GT has joined #ltsp | |
| 20:46 | mgariepy has quit IRC | |
| 20:47 | pmatulis has quit IRC | |
| 20:56 | shogunx has joined #ltsp | |
| 21:36 | try2free has quit IRC | |
| 21:52 | etyack has quit IRC | |
| 23:03 | tstafford has quit IRC | |
| 23:11 | Faithful has quit IRC | |
| 23:49 | map7 has quit IRC | |
| 23:53 | Mip5 has joined #ltsp | |
| 23:53 | <Mip5> howdy folks
| |
| 23:57 | Mip5 has left #ltsp | |