IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 25 February 2008 (all times are UTC)
| 00:09 | plamengr has joined #ltsp | |
| 00:14 | indradg_ has quit IRC | |
| 00:31 | cyberorg has joined #ltsp | |
| 00:42 | ian_ has quit IRC | |
| 00:47 | ian_ has joined #ltsp | |
| 00:47 | cyberorg_ has joined #ltsp | |
| 00:48 | cyberorg has quit IRC | |
| 00:48 | cyberorg_ is now known as cyberorg | |
| 01:05 | <vagrantc> klausade: updated: *
| |
| 01:05 | klausade: updated: deb http://pkg-ltsp.alioth.debian.org/debian etch-ltsp-backports main
| |
| 01:05 | anyone else using debian etch with ltsp backports is encouraged to try them out.
| |
| 01:05 | ian__ has joined #ltsp | |
| 01:05 | <vagrantc> main thing is some new features in ldm
| |
| 01:06 | autologin, guest login ...
| |
| 01:08 | sound support isn't as good as i'd like, but local devices are working good.
| |
| 01:09 | ian_ has quit IRC | |
| 01:15 | ian__ has quit IRC | |
| 01:56 | <sep> vagrantc, i'm considering using ltsp backports. so i will definitiftly try them out
| |
| 01:56 | plamengr has quit IRC | |
| 01:58 | <vagrantc> sep: cool.
| |
| 01:59 | sep: i was also meaning to ping you regarding http://bugs.debian.org/445312
| |
| 01:59 | <sep> yes ?
| |
| 01:59 | <vagrantc> sep: mainly, can you reproduce it with the current version in sid ?
| |
| 02:00 | i don't really have a good debian-installer test environment for ltsp at the moment.
| |
| 02:01 | <sep> vagrantc, i could try making a cd, but it would be easier waiting for it to hit lenny since i then just could use the debian-edu lenny dvd
| |
| 02:01 | <vagrantc> sep: it may be a long wait, the way mips buildd's are going ...
| |
| 02:03 | <sep> vagrantc, could ofcourse uploading it to debian-edu lenny local,
| |
| 02:04 | but ill try making a lenny cd with sid ltsp
| |
| 02:11 | Q-FUNK has joined #ltsp | |
| 02:24 | <vagrantc> build in a lenny chroot, or is sid chroot ok?
| |
| 02:33 | indradg has joined #ltsp | |
| 02:36 | Nuba1 has left #ltsp | |
| 02:48 | <daduke> vagrantc: howdy!
| |
| 03:11 | soneyka has quit IRC | |
| 03:14 | soneyka has joined #ltsp | |
| 03:28 | mikkel has joined #ltsp | |
| 03:47 | Q-FUNK has quit IRC | |
| 03:48 | Q-FUNK has joined #ltsp | |
| 04:29 | Q-FUNK has quit IRC | |
| 04:58 | uioreoiwr has joined #ltsp | |
| 04:59 | <uioreoiwr> Hi, I am getting "client isn't authorized to connect to server" in ltsp
| |
| 04:59 | Have tried updating the keys and image as per the forums
| |
| 05:00 | ace_suares has joined #ltsp | |
| 05:03 | * ogra_cmpc wonders what the forum say ... i doubt ant dev reads them to verify its correct ... can you describe what you did yet ? | |
| 05:05 | <uioreoiwr> I ran ltsp-update-sshkeys and ltsp-update-image on the server.
| |
| 05:05 | <ogra_cmpc> and your ssh server is running properly ?
| |
| 05:06 | <uioreoiwr> Yes, pk logon and password logon both functional.
| |
| 05:06 | <ogra_cmpc> hmm, which release is that ?
| |
| 05:06 | <uioreoiwr> tftpboot works, everything is ok up to gdm. This is where I get the message.
| |
| 05:06 | <ogra_cmpc> s/gdm/ldm
| |
| 05:06 | (we dont use gdm :) )
| |
| 05:07 | <uioreoiwr> Running multiple archs: ltsp-update-image -a i386
| |
| 05:07 | <ogra_cmpc> right
| |
| 05:07 | <uioreoiwr> This may well do the trick. I think I found my problem, i.e. Architecture of this image. Default is arch of the host.
| |
| 05:07 | Server is AMD64.
| |
| 05:09 | <vagrantc> 6
| |
| 05:09 | <ogra_cmpc> can you check that each /opt/ltsp/$ARCH/etc/ssh/ssh_known_hosts contains a key for the server
| |
| 05:09 | sounds like a multiarch bug with ltsp-update-sshkeys or so
| |
| 05:12 | lexa_ has joined #ltsp | |
| 05:12 | soneyka has quit IRC | |
| 05:13 | lexa_ has quit IRC | |
| 05:14 | soneyka has joined #ltsp | |
| 05:17 | ace_suares has quit IRC | |
| 05:37 | <uioreoiwr> ogra, all happily working. The image MUST be generated for every arch.
| |
| 05:38 | I think filing a but report is unnecessary
| |
| 05:38 | ogra_cmpc, thanks for helping. People like you give community software a good name.
| |
| 05:38 | <ogra> no, file it, i'd like to fix it ... (probably not for hardy, but a reminder bug helps to not forget about it)
| |
| 05:38 | uioreoiwr has quit IRC | |
| 05:39 | <ogra> meh
| |
| 05:39 | <laga> heh :)
| |
| 05:43 | Guaraldo has joined #ltsp | |
| 06:01 | K_O-Gnom has joined #ltsp | |
| 06:02 | Q-FUNK has joined #ltsp | |
| 06:03 | mhterres has joined #ltsp | |
| 06:10 | Guaraldo has left #ltsp | |
| 06:30 | meduxa has joined #ltsp | |
| 06:53 | jammcq has quit IRC | |
| 07:05 | cdealer has joined #ltsp | |
| 07:05 | <cdealer> good morning
| |
| 07:05 | elisboa has joined #ltsp | |
| 07:07 | <cdealer> I have set the TMP, TMPDIR, TEMP, TEMPDIR env in the ltsp server to point to /tmp/${USER}_ltsp but seens that these folder arent being used... how can I set to ltsp to use these folders as the clients temp dir ??
| |
| 07:09 | im using /etc/bash.bashrc no /opt/ltsp/i386/etc/bash.bashrc
| |
| 07:09 | *not
| |
| 07:13 | <vagrantc> i think /etc/X11/Xsession will unset those variables
| |
| 07:13 | which is used when you log in
| |
| 07:14 | many programs refuse to respect those variables, as there are some negative security implications
| |
| 07:15 | <ogra> additionally bashrc isnt read by X at all
| |
| 07:15 | use /etc/environment instead
| |
| 07:15 | <vagrantc> though arguably, it prevents better security by having each user using a different temporary directory
| |
| 07:15 | <ogra> vagrantc, up early ?
| |
| 07:15 | <vagrantc> be sure to "export" the variables as well ...
| |
| 07:16 | ogra: late becomes early
| |
| 07:16 | <ogra> heh
| |
| 07:16 | <vagrantc> i should have turned in at least 4 hours ago
| |
| 07:18 | <cdealer> we use an web application that works with java and user session, on ltsp the users constantly lost connection this does not happen on users using ubuntu local ...
| |
| 07:18 | <vagrantc> ogra: i think i have network booting code for mips and arm ... and a tiny sub-set of mipsel
| |
| 07:18 | <cdealer> so I thought in the ideia of testing trying to separate the users temp dir ... to see if I get rid of these lost connections problem
| |
| 07:19 | <ogra> vagrantc, whee ... how do you test that ?
| |
| 07:19 | <vagrantc> ogra: test?
| |
| 07:19 | <ogra> yes
| |
| 07:19 | i mean, how do you know it works
| |
| 07:19 | <vagrantc> ogra: i just adapted it from debian-installer's netboot image generation code
| |
| 07:19 | <ogra> ah
| |
| 07:19 | cool
| |
| 07:20 | <vagrantc> and i'm actually having luck with qemu-system-mips and qemu-system-mipsel ... :)
| |
| 07:20 | * ogra still hasnt solved the grub thing properly | |
| 07:21 | <ogra> the code we have in ubuntu-vm-builder is so scary i dont think i have the balls to touch that ...
| |
| 07:21 | dd'ing a mbr together ... bytewise from grubs stage 1 and stage 2 files
| |
| 07:22 | <cdealer> you know if a shared environment like ltsp provides can bring problems with session and remote application usage experience, specially with java? We are up to pay for support if is need to get rid of this problem on our ltsp server...
| |
| 07:23 | <ogra> well, as long as you use the debian way to use the java stuff and dont set crap like JAVA_HOME etc it should just work
| |
| 07:23 | <cdealer> this "web application" is the main app used here by the users... if this start geting problems is like we trowed $10k on the trash
| |
| 07:23 | <ogra> i wonder if its display related
| |
| 07:24 | * vagrantc is building a mipsel ltsp chroot from debian-installer ... | |
| 07:24 | <cdealer> ogra, display ?
| |
| 07:24 | <ogra> cdealer, wel, you said its only happening on ltsp ...
| |
| 07:24 | <cdealer> ogra, yeap... on the local installations no problem
| |
| 07:24 | never
| |
| 07:24 | <ogra> the only real difference here is the display the screen is shown on ..
| |
| 07:25 | <cdealer> but with ltsp it constantly drops the connection
| |
| 07:25 | the client is still up with server but this application send a "lost connection with server" and then the user have to login again
| |
| 07:25 | <ogra> sounds really like an app problem to me ...
| |
| 07:26 | did you talk to the devs there ?
| |
| 07:26 | i cant imagine how ltsp should have any influence on the connection
| |
| 07:27 | <cdealer> ogra, its an oracle application, trhough ias server ...its automatically generated and they demand us to use java version 1.4.0.6
| |
| 07:28 | <ogra> do you have any debugging output, logs etc from the app ?
| |
| 07:28 | exodos has joined #ltsp | |
| 07:28 | <ogra> 1.4 ?
| |
| 07:28 | thats not even supported upstream anymore
| |
| 07:28 | (we just dropped it from hardy)
| |
| 07:28 | (because of that fact)
| |
| 07:29 | but still, i dont see a reason why ltsp should be able to influence the connection
| |
| 07:29 | <cdealer> ogra, its because is the java version that oracle have build support for this ias application
| |
| 07:29 | <ogra> doe the app have a check that you cant connect multiple times from the same machine or so ?
| |
| 07:29 | <cdealer> I realy dont like the ideia of using an old java version
| |
| 07:29 | but we having any choice
| |
| 07:30 | ogra, I start thinking that this could be a possibility
| |
| 07:30 | <ogra> dont forget all your user sessions come from the same ip
| |
| 07:30 | <cdealer> yeah... this come to my head friday
| |
| 07:31 | we asked they to look if there are any maximum connection on the server or something like that... no answer yeat
| |
| 07:31 | ogra, do you think its possibly to the ltsp is overwriting some sessions ? Or this isnt a possible think to be happen ?
| |
| 07:32 | <ogra> ??
| |
| 07:32 | <cdealer> like
| |
| 07:32 | <ogra> can you rephrase that
| |
| 07:32 | <cdealer> yea
| |
| 07:34 | like... imagine if a temp file with the same name is being write for the user when he logs in the application, then other user logs in too and so his session is overwritten setting a new "timeout" and then the other user, the first one... stays of a zombie session that was overwritten by the user that logged after him ... this was the main reason why I though in setting separeted temp dirs for the users
| |
| 07:34 | <ogra> ah
| |
| 07:35 | <vagrantc> a very poorly written app...
| |
| 07:35 | <ogra> well, tat might be the issue then, how about prefixing the app call with the variable to test that ?
| |
| 07:35 | <cdealer> I start thinking why only the ltsp client of the app are having this strange connection loss problem
| |
| 07:36 | <ogra> if you have such temp files to steer the session, it probably puts the display in there .. indeed that changes with every new login
| |
| 07:37 | <cdealer> Hmmm
| |
| 07:37 | <ogra> put a little wrapper script around it
| |
| 07:37 | that makes sure the var is set and the dir exists
| |
| 07:38 | <cdealer> sorry, didnt gotcha...
| |
| 07:38 | <ogra> wrap your app in a shellscript that sets TEMPDIR and makes sure the dir is existing before the app starts up
| |
| 07:38 | and test isf that helps you
| |
| 07:39 | (its horrible to hear tat someone gto 10k for such badly written things)
| |
| 07:39 | *got
| |
| 07:40 | <cdealer> well ... let see if I understand right... you said to me to set in my ltsp a shellscript to set the tempdir of the user (the original idea) or to set in the APP code ?
| |
| 07:40 | ogra, 10K is our ltsp server.. the application it self is a investiment of almost 1 million ...
| |
| 07:41 | <ogra> heh
| |
| 07:41 | even worse
| |
| 07:41 | <cdealer> yea
| |
| 07:41 | the problem is that one are being the first state to change our entire users environment to ltsp ...
| |
| 07:42 | <ogra> well, they might not have had such scenarios in mind when creating the app
| |
| 07:42 | <cdealer> so every problem we get with that we are most part of time alone.. trying to prove that the problem arent of our system
| |
| 07:42 | <ogra> but its very likely an app issue not a ltsp one
| |
| 07:43 | <cdealer> ogra, so you think that some in the app like to use a $user/session could help ?
| |
| 07:45 | gonzaloaf has joined #ltsp | |
| 07:45 | meduxa has quit IRC | |
| 08:02 | <ogra> cdealer, no idea, just a guess for you to test :)
| |
| 08:04 | <cdealer> ogra, yeah... we have send this issue to the developers... they are going to take a look and make some tests there...
| |
| 08:05 | cliebow_ has joined #ltsp | |
| 08:22 | <cdealer> ogra, /etc/environment doesnt accept vars... I can set /tmp/${USER}_ltsp ... O.o
| |
| 08:23 | <ogra> did you try with a wrapper script as i said above ?
| |
| 08:23 | vagrantc already told you it gets unset in Xsession :)
| |
| 08:24 | <cdealer> ogra, but you told after to use /etc/environment ... I just dont get it where to set the wrapper script...
| |
| 08:25 | <ogra> mv /usr/bin/app /usr/bin/app.orig
| |
| 08:25 | vi /usr/bin/app
| |
| 08:25 | make it a shellscript, export the vars etc .. and call /usr/bin/app.orig at the bottom
| |
| 08:25 | <cdealer> ogra, ah! the app is a web application ... using a java applet
| |
| 08:25 | <ogra> well, even easier
| |
| 08:26 | edit /usr/bin/firefox :)
| |
| 08:26 | <cdealer> Hmmm
| |
| 08:26 | <ogra> its only a script
| |
| 08:26 | <cdealer> so .. you realy are smart lol
| |
| 08:26 | =X
| |
| 08:42 | jammcq has joined #ltsp | |
| 08:44 | <cliebow_> jammcq!!!!
| |
| 08:44 | <Lumiere> hi jammcq *runs*
| |
| 08:47 | plamengr has joined #ltsp | |
| 08:52 | ccherret1 has joined #ltsp | |
| 08:53 | ccherrett has quit IRC | |
| 08:55 | <cliebow_> see jammcq run?
| |
| 08:58 | <jammcq> cliebow_: howdie
| |
| 08:58 | hey Lumiere
| |
| 08:59 | <cliebow_> jammcq:always good to see you..
| |
| 08:59 | <jammcq> cliebow_: hey, carrying a little tail today, eh?
| |
| 09:00 | <cliebow_> ohhh..i guess so..not sure why..
| |
| 09:02 | * ogra doesnt see that as "tail" specifically :P | |
| 09:02 | <ogra> (its rather at the fron than on the back)
| |
| 09:02 | *front
| |
| 09:02 | hi jammcq
| |
| 09:03 | <cliebow_> reprihensible....err...prehensile tail
| |
| 09:09 | <jammcq> ogra: I guess it depends on which direction his name is going
| |
| 09:09 | <ogra> nah
| |
| 09:09 | the words appear at the right side ... thats where his mouth must face then :)
| |
| 09:09 | <jammcq> so it's a tongue
| |
| 09:09 | <ogra> so _cliebow would be a tail ... ;)
| |
| 09:09 | mccann has joined #ltsp | |
| 09:10 | <cliebow_> i am left handed though
| |
| 09:10 | <ogra> indeed ... i didnt mean to suggest anything nasty :)
| |
| 09:10 | <jammcq> that screws up everything
| |
| 09:10 | toscalix has joined #ltsp | |
| 09:20 | cliebow_ is now known as cliebow____ | |
| 09:20 | <cliebow____> ther
| |
| 09:20 | e
| |
| 09:21 | <ogra_cmpc> lol
| |
| 09:23 | cliebow____ is now known as cliebow__ | |
| 09:27 | <ogra_cmpc> jammcq, any news from scottie ?
| |
| 09:27 | !seen sbalneav
| |
| 09:27 | <ltspbot> ogra_cmpc: sbalneav was last seen in #ltsp 2 weeks, 5 days, 0 hours, 28 minutes, and 21 seconds ago: <sbalneav> What are we looking at?
| |
| 09:27 | bobby_C has joined #ltsp | |
| 09:27 | <jammcq> umm, nope
| |
| 09:28 | <ogra_cmpc> not that he's specifically needed atm, the community currebtly greatly provides us with patches for ldm bugs
| |
| 09:29 | so all he was urgently needed for is taken care of for the moment
| |
| 09:29 | but i wouldnt like to start implementing localapps without him around for hardy+1 ... its his brainchild
| |
| 09:29 | <jammcq> indeed
| |
| 09:29 | I hope he frees up soon
| |
| 09:30 | <ogra_cmpc> still that busy ?
| |
| 09:30 | (did you talk to him some more ?)
| |
| 09:30 | <jammcq> last time was about 2 weeks ago
| |
| 09:30 | his last words were something like: You gonna be around tonight? I'll call you
| |
| 09:31 | <ogra_cmpc> ah, thats the time he was around and telling me about his mail crashes
| |
| 09:31 | seems he had a hard time switching people to thunderbird or so
| |
| 09:31 | <jammcq> but it sounded like he got that all worked out
| |
| 09:32 | <ogra_cmpc> but given the amount of time he invested here the last two years i would understand if his boss wants him to do more inhouse now :)
| |
| 09:33 | <jammcq> well, over the 9 years I've known him, I've seen him dissappear for months at a time. then he comes back ready to get busy again
| |
| 09:33 | <ogra_cmpc> yeah
| |
| 09:34 | <jammcq> I see you are going to Prague for UDS
| |
| 09:34 | <ogra_cmpc> indeed
| |
| 09:34 | <jammcq> how far is that from you?
| |
| 09:34 | <ogra_cmpc> no ltsp sponsoring planned though :(
| |
| 09:34 | <jammcq> yeah, I figured
| |
| 09:34 | <ogra_cmpc> not sure but must be less than 800km
| |
| 09:35 | prague is the non german european city i was most in my life yet
| |
| 09:35 | i drove there two times by car already, so its not that far
| |
| 09:35 | <jammcq> you've been there?
| |
| 09:35 | wow
| |
| 09:35 | I've heard it's a beautiful city
| |
| 09:35 | <ogra_cmpc> five times
| |
| 09:36 | sadly it turned into the bordello of europe since the wall fell
| |
| 09:36 | i was there two times before the iron courtain went down
| |
| 09:37 | and its sad to see what capitalism did to it
| |
| 09:37 | <jammcq> when I was a kid, I used to actually envision a real curtain made of Iron
| |
| 09:38 | <ogra_cmpc> the inner city turned into a fair after that ...
| |
| 09:38 | but its still the home of art deco
| |
| 09:38 | one of the most beautiful cities i know
| |
| 09:40 | if i would ever marry i'd have my honeymoon there ;)
| |
| 09:43 | Nubae has joined #ltsp | |
| 09:43 | <Nubae> hi, I know I've seen this error before, but I can't remember what I did to fix it nor is there anything on the web about it:
| |
| 09:44 | mount: Mounting /rofs on /root/rofs failed: Invalid argument
| |
| 09:44 | cp: unable to open '/root/etc/': Is a directory
| |
| 09:44 | <ogra_cmpc> your nbd server is down or something like that
| |
| 09:44 | the actual error is above
| |
| 09:44 | thats only a result
| |
| 09:45 | <Nubae> nbd cant be down, because I'm on a thin client
| |
| 09:45 | I meant started up from one
| |
| 09:45 | but then another won't start
| |
| 09:45 | its a different chroot though
| |
| 09:45 | <ogra_cmpc> well, its definately not getting nbd from the server
| |
| 09:46 | <Nubae> i checked inetd.conf and that seems correct
| |
| 09:46 | <ogra_cmpc> matches the entries in the pxe config ?
| |
| 09:46 | <Nubae> yep
| |
| 09:46 | <ogra_cmpc> do you see it connecting in the server logs ?
| |
| 09:46 | <Nubae> yep
| |
| 09:46 | <ogra_cmpc> nbd server usually tells you
| |
| 09:47 | did you fiddle with the initramfs in any kind for the chroot that doesnt work ?
| |
| 09:47 | <Nubae> nope
| |
| 09:48 | <ogra_cmpc> weird
| |
| 09:48 | its either not having nbd or it cant mount the squashfs
| |
| 09:48 | thats gutsy i suppose ?
| |
| 09:49 | <Nubae> Feb 25 16:41:31 mayserve nbdrootd[12524]: connect from 192.168.0.3 (192.168.0.3)
| |
| 09:49 | Feb 25 16:41:31 mayserve nbd_server[12525]: connect from 192.168.0.3, assigned file is /opt/ltsp/images/fati386.img
| |
| 09:49 | heron
| |
| 09:49 | <ogra_cmpc> ah
| |
| 09:49 | <Nubae> ah :-) ?
| |
| 09:50 | <ogra_cmpc> well, there might be issues with lzma, i havent checked the last ltsp build yet
| |
| 09:50 | its hardy :)
| |
| 09:50 | <Nubae> but my main image works
| |
| 09:50 | <ogra_cmpc> suppoosed to be in flux and brak fromj time to time
| |
| 09:50 | when did you build your main image and did you upgrade ltsp-server inbetween ?
| |
| 09:51 | <Nubae> maybe its because of the way I did it... to cut time, I copied and pasted /opt/ltsp/i386 to /opt/ltsp/fati386
| |
| 09:51 | <ogra_cmpc> note that i uploaded a new version pretty recently (feb 13th)
| |
| 09:51 | <Nubae> I installed a regular ubuntu and then installed ltsp-server-standalong ssh-server
| |
| 09:51 | <ogra_cmpc> that shouldnt matter as long as you never touched /opt/ltsp/i386
| |
| 09:52 | <Nubae> i didn't
| |
| 09:52 | <ogra_cmpc> if you tewaked that before copying it it might cause probs indeed
| |
| 09:52 | hmm
| |
| 09:52 | <Nubae> the regular i386 loads up perfetly
| |
| 09:53 | i guess creating another chroot and testing would be the next step, but why can't it see the image, I dont get it
| |
| 09:53 | <ogra_cmpc> mv the working image out of the way and run ltsp-update-image again ...
| |
| 09:53 | test if it works then
| |
| 09:53 | <Nubae> that I did too
| |
| 09:53 | same thing happened
| |
| 09:53 | <ogra_cmpc> i dropped the -nolzma option in the recent upload
| |
| 09:53 | same thing means ?
| |
| 09:53 | it worked ?
| |
| 09:53 | <Nubae> no
| |
| 09:53 | doesnt
| |
| 09:54 | <ogra_cmpc> yeah, then its liukely the lzma change
| |
| 09:54 | <Nubae> moving the image, then redoing ltsp-update-image has same effect
| |
| 09:54 | I'm not sure what that is, is there a way I can fix that?
| |
| 09:54 | <ogra_cmpc> dpkg -l squashfs-tools
| |
| 09:54 | what does that give you
| |
| 09:55 | <Nubae> squashfs-tools 1:3.3-1ubuntu2
| |
| 09:55 | <ogra_cmpc> hmm
| |
| 09:55 | that has the fix...
| |
| 09:55 | (was added in 1:3.3-1ubuntu1)
| |
| 09:56 | <Nubae> could it be the size of my image?
| |
| 09:56 | is there a limit?
| |
| 09:56 | <ogra_cmpc> nope
| |
| 09:56 | well, general linux partition size would be the limit
| |
| 09:56 | but that should be in the terabyte area
| |
| 09:56 | <Nubae> heh, my image is not that big ;-)
| |
| 09:57 | <ogra_cmpc> it has apparently nothing to do with your chroot
| |
| 09:57 | since it breqaks as well with the normal chroot
| |
| 09:57 | rjune has quit IRC | |
| 09:57 | <Nubae> well, no, my /opt/ltsp/i386 loads fine
| |
| 09:57 | its just the other chroot
| |
| 09:58 | <ogra_cmpc> you just said it doesnt if you rebuild it
| |
| 09:58 | <ogra_cmpc> mv the working image out of the way and run ltsp-update-image again ...
| |
| 09:58 | <ogra_cmpc> test if it works then
| |
| 09:58 | <Nubae> that I did too
| |
| 09:58 | <Nubae> same thing happened
| |
| 09:58 | <Nubae> the /opt/ltsp/fati386
| |
| 09:58 | that is
| |
| 09:58 | <ogra_cmpc> so please do as i said
| |
| 09:59 | and tell me if it breaks with that as well
| |
| 09:59 | <Nubae> I'm doing ltsp-update-image like this ltsp-update-image -a fati386 -b /opt/ltsp
| |
| 09:59 | ok, I'll move the regular one and rebuild
| |
| 10:00 | <ogra_cmpc> right
| |
| 10:00 | and see if that breaks too, then i know where to look
| |
| 10:00 | also check in busybox if the error occurs what /proc/mounts contains
| |
| 10:00 | and if nbd-client is running
| |
| 10:01 | <Nubae> so... backup/move /var/lib/tftpboot/ltsp/i386, right?
| |
| 10:01 | <ogra_cmpc> err
| |
| 10:01 | nope
| |
| 10:02 | mv /opt/ltsp/images/i386.img /opt/ltsp/images/i386.img.bak
| |
| 10:02 | sudo ltsp-update-image
| |
| 10:02 | reboot a client that uses that image
| |
| 10:03 | rjune has joined #ltsp | |
| 10:04 | <Nubae> hmmm, well I never did mv /opt/ltsp/images/fati386.img, I thought the image was linked from /var/lib/tftpboot/ltsp/
| |
| 10:05 | <ogra_cmpc> thats the pxe stuff, not the filesystem image
| |
| 10:05 | kernel and initramfs
| |
| 10:05 | <Nubae> ah ok...
| |
| 10:05 | <ogra_cmpc> you usually dont need to mv it :) it just gets overwritten
| |
| 10:05 | <Nubae> so they are bootstrap images
| |
| 10:05 | <ogra_cmpc> i just want to prevent you from losin the working one
| |
| 10:05 | <Nubae> I'm still learning all this
| |
| 10:05 | well, that worked fine
| |
| 10:06 | moving then updating the image
| |
| 10:06 | <ogra_cmpc> if you boot a client: it broadcasts a pxe request, gets answer, pulls kernel, pulls initramfs and unpacks and executes both ....
| |
| 10:06 | the initramfs is a mini linux ...
| |
| 10:07 | <Nubae> yeah I get it now
| |
| 10:07 | <ogra_cmpc> inside the initramfs we have scripts that mount the image from /opt/ltsp/images as rootfs
| |
| 10:07 | <Nubae> would u be able to (maybe this is a dumb question) load a windows xp image via pxe?
| |
| 10:08 | <ogra_cmpc> i dont think windows supports that
| |
| 10:08 | technically it would be possible (from a pxe POV)
| |
| 10:08 | <Nubae> and loading a vmware/virtualbox image via pxe?
| |
| 10:08 | <ogra_cmpc> you might need some special imaging software for win
| |
| 10:53 | ccherret1 is now known as ccherrett | |
| 10:59 | mccann has quit IRC | |
| 11:06 | mccann has joined #ltsp | |
| 11:09 | mccann has quit IRC | |
| 11:12 | mikkel has quit IRC | |
| 11:14 | staffencasa has joined #ltsp | |
| 11:27 | exodos has quit IRC | |
| 11:51 | otavio has quit IRC | |
| 11:59 | Nubae has quit IRC | |
| 12:03 | spectra has joined #ltsp | |
| 12:10 | nicoAMG has joined #ltsp | |
| 12:11 | Q-FUNK has quit IRC | |
| 12:15 | mccann has joined #ltsp | |
| 12:24 | mccann has quit IRC | |
| 12:35 | mccann has joined #ltsp | |
| 12:36 | otavio has joined #ltsp | |
| 12:37 | plamengr has quit IRC | |
| 13:01 | cesar_ has joined #ltsp | |
| 13:01 | <cesar_> hi people
| |
| 13:01 | I try use local devices
| |
| 13:01 | in a client terminal
| |
| 13:01 | buy
| |
| 13:01 | pardom
| |
| 13:01 | but
| |
| 13:02 | in terminal appeared the icon for the floppy disk
| |
| 13:02 | and when I try access
| |
| 13:02 | at the floppy
| |
| 13:03 | it is 0 bytes
| |
| 13:03 | in the TS I try start
| |
| 13:03 | ./lbus-start.sh
| |
| 13:04 | and get a error
| |
| 13:04 | Use of uninitialized value in substitution (s///) at /usr/sbin/lbussd line 46.
| |
| 13:04 | Use of uninitialized value in concatenation (.) or string at /usr/sbin/lbussd line 62.
| |
| 13:05 | Couldn't establish a connection to :9202: IO::Socket::INET: Bad hostname ':9202'
| |
| 13:05 | <johnny> cesar_, you're going to find much less help with 4.2 than 5 here
| |
| 13:05 | <cesar_> I found in google for something that help me
| |
| 13:05 | yes
| |
| 13:06 | I am using LTSP 4.2 update 3
| |
| 13:06 | on Debian
| |
| 13:06 | Linux ltsp 2.6.18-5-amd64
| |
| 13:06 | <ogra_cmpc> especially on debian
| |
| 13:07 | ltsp 4.2 isnt been developed for more than two years, current devs wont know much about the old 4.2
| |
| 13:07 | <cesar_> ups..
| |
| 13:07 | <ogra_cmpc> cesar_, your best hope is that sbalnev shows up again or jammcq finds some time to walk you through it
| |
| 13:08 | <cesar_> :-/
| |
| 13:08 | <ogra_cmpc> but in the end i'd suggest to use ltsp5 .... *especially* on ubuntu or debian
| |
| 13:09 | (wher ltsp5 is the default since two years)
| |
| 13:09 | <vagrantc> well, a year and a half
| |
| 13:09 | <cesar_> yes, I install ltsp from package
| |
| 13:09 | debian package
| |
| 13:09 | <vagrantc> actually, not even a year
| |
| 13:09 | heh
| |
| 13:09 | <ogra_cmpc> vagrantc, 5.10 was my first release shipping ltsp5
| |
| 13:10 | <cesar_> but in repositories not found ltsp5
| |
| 13:10 | <ogra_cmpc> cesar_,
| |
| 13:10 | !debian
| |
| 13:10 | <ltspbot> ogra_cmpc: "debian" is is a GNU/Linux based operating system that makes an excellent LTSP server. You can find it at http://www.debian.org. for information about LTSP on debian see http://wiki.debian.org/LTSP
| |
| 13:10 | <cesar_> ok
| |
| 13:10 | thanks
| |
| 13:10 | <ogra_cmpc> vagrantc, ocy 2005, thats nearly three years :)
| |
| 13:10 | err
| |
| 13:10 | oct
| |
| 13:10 | <vagrantc> ogra_cmpc: first debian to have an ltsp5 was last april ... i think ... although debian-edu actually had one before 5.10
| |
| 13:11 | <ogra_cmpc> sarge ?
| |
| 13:11 | i think that was released at the same time
| |
| 13:11 | <vagrantc> debian-edu's sarge-based release was slightly before 5.10, if i remember correctly.
| |
| 13:11 | <ogra_cmpc> deec 05 or so
| |
| 13:11 | <cesar_> ok... a try install ltsp5
| |
| 13:11 | but .. again start all the process
| |
| 13:12 | :-(
| |
| 13:12 | <vagrantc> cesar_: i'd also recommend the backported packages if you want local devices.
| |
| 13:12 | * vagrantc forgot to sleep | |
| 13:12 | <johnny> vagrantc, :(
| |
| 13:13 | * vagrantc makes a late breakfast (and extremely late dinner) | |
| 13:13 | <cesar_> uff..
| |
| 13:14 | bye bye
| |
| 13:29 | one question
| |
| 13:29 | I am downloading the package for ltsp5 on Debian
| |
| 13:30 | I'm currently have installed ltsp4.2 on the TS
| |
| 13:31 | and it's working .. only not work local devices
| |
| 13:32 | <vagrantc> cesar_: you'll need to follow the instructions for backports at the bottom of http://wiki.debian.org/LTSP/Howto
| |
| 13:32 | <cesar_> if I install ltsp5 I have make a lot of changes in
| |
| 13:32 | dhcp
| |
| 13:32 | tftp
| |
| 13:32 | <vagrantc> you'll also have to move /opt/ltsp/i386 aside ... and configure dhcpd and maybe tftp
| |
| 13:33 | <cesar_> ok
| |
| 13:33 | well
| |
| 13:33 | not is necesary a lot of changes
| |
| 13:33 | <vagrantc> and if there's any server-side ltspfs stuff, you'll need to remove it
| |
| 13:33 | Guaraldo has joined #ltsp | |
| 13:34 | <cesar_> I don't understand very well
| |
| 13:34 | <Guaraldo> Hi, all...
| |
| 13:34 | <vagrantc> cesar_: you'll need to remove all the stuff you added for ltsp 4.x
| |
| 13:34 | <cesar_> ah..
| |
| 13:34 | ok
| |
| 13:34 | <Guaraldo> I'm heaving some trobles with LTSPFS... Can anyone help me?
| |
| 13:34 | <vagrantc> Guaraldo: linux distro and release?
| |
| 13:35 | <Guaraldo> vagrantc: Ubuntu Gutsy with LTSP4.2
| |
| 13:35 | <vagrantc> Guaraldo: and just go ahead and start asking your question
| |
| 13:35 | <cesar_> I have installed on TS this packages
| |
| 13:35 | ii ltsp-utils 0.25-1 Linux Terminal Server Project (LTSP) adminis
| |
| 13:35 | ii ltspfs 0.5.0~bzr20080109-3 Fuse based remote filesystem for LTSP thin c
| |
| 13:35 | <vagrantc> Guaraldo: you might have a hard time finding help with that
| |
| 13:36 | <Guaraldo> When any client plugs a pen-drive, I get this error message: "Couldn't read LTSPFS_TOKEN atom."
| |
| 13:36 | <vagrantc> cesar_: if you install the backports, it should remove ltsp-utils
| |
| 13:36 | <cesar_> then I need uninstall this two packages
| |
| 13:36 | ok
| |
| 13:36 | thanks
| |
| 13:36 | <vagrantc> Guaraldo: the server-side ltspfs is incompatible with ltspfs in ltsp 4.x
| |
| 13:36 | <cesar_> ltspfs isn't necesary uninstall?
| |
| 13:36 | <vagrantc> cesar_: you're running lenny or sid?
| |
| 13:37 | <cesar_> Linux ltsp 2.6.18-5-amd64 #1 SMP Sat Dec 22 20:43:59 UTC 2007 x86_64 GNU/Linux
| |
| 13:37 | <Guaraldo> Oh!... What does you sugest, vagrantc?
| |
| 13:37 | ops... What do you sugest, vagrantc?
| |
| 13:37 | <vagrantc> Guaraldo: well, ubuntu has been ltsp5 since the breezy release ... 5.10
| |
| 13:38 | Guaraldo: that's over two years ago...
| |
| 13:38 | <cesar_> vagrantc: I think it's lenny version
| |
| 13:38 | but.. I don't sure
| |
| 13:39 | <vagrantc> cesar_: ok, you'll want to install ltsp-server-standalone from sid, and build a sid ltsp environment.
| |
| 13:39 | cesar_: it's the only version in debian right now.
| |
| 13:39 | <Guaraldo> vagrantc: Yes... But on a network with over 1000 clients I cant change to LTSP5 yet! It's to slow to get up...
| |
| 13:40 | <vagrantc> Guaraldo: well, if you really want to switch to ltsp 4.x on gutsy, you're going to have to remove all the ltsp5 related packages and install ltsp 4.2 ... and hope it works.
| |
| 13:44 | <Guaraldo> Thanks vagrantc... I'll try it...
| |
| 13:45 | <vagrantc> Guaraldo: what part of ltsp5 is too slow?
| |
| 13:47 | Guaraldo: is it just the boot process, or the actual use? LDM_DIRECTX can improve performance at the cost of security (about the same resources as ltsp 4.x with startx/xdmcp)
| |
| 13:48 | <Guaraldo> booting ts
| |
| 13:49 | vagrantc: When we are talning about 1000 terminals booting at the same time, LTSP4.2 makes a big diferance...
| |
| 13:49 | talnin=talking
| |
| 13:51 | <vagrantc> Guaraldo: how does your electrical system even handle 1000 machines booting at the very same time
| |
| 13:51 | :)
| |
| 13:52 | <Guaraldo> vagrantc: That's a big network, over 10 buildings, conected by optical fiber...
| |
| 13:54 | The servers handle all them together, but testing LTSP5 in a little network (over 5 clients), I've got over 2 minutes to boot a client...
| |
| 13:55 | So, I can imagine what would be with 1000 clients booting together...
| |
| 13:55 | radoeka has joined #ltsp | |
| 13:56 | radoeka has left #ltsp | |
| 13:59 | <lns> Guaraldo, sounds like there's something missing with your setup - LTSP5 has major boot speed improvements
| |
| 14:00 | <vagrantc> lns: it's still slow as molasses compared to ltsp 4.x
| |
| 14:00 | <Guaraldo> lns: But is still slower than ltsp4.2
| |
| 14:00 | <lns> vagrantc, you mean boot?
| |
| 14:00 | <vagrantc> lns: yes
| |
| 14:01 | <lns> wow
| |
| 14:01 | i think it's pretty damn fast myself
| |
| 14:01 | <Guaraldo> lns: Don't forget that I'm talking about 1000 clients...
| |
| 14:01 | <lns> maybe 20sec to boot up total
| |
| 14:01 | Guaraldo, i know - how many servers?
| |
| 14:01 | i'm hoping you have some pretty crazy ethernet bonding/clustering going on
| |
| 14:01 | for 1k clients
| |
| 14:01 | <Guaraldo> lns: 9 Linux and 5 Windows
| |
| 14:02 | <lns> not bad, ~100 clients per linux server
| |
| 14:02 | <Guaraldo> All them have 2 Xeon 64 DuoCore or QuadCore...
| |
| 14:03 | <lns> Guaraldo, amd64 ubuntu or i386 (on the server)?
| |
| 14:03 | <Guaraldo> AMD64 Gutsy
| |
| 14:03 | <lns> how much ram?
| |
| 14:03 | <Guaraldo> 8 GB in each...
| |
| 14:03 | <lns> sounds like my setup almost to a T
| |
| 14:04 | i have five 2x dualcore xeon 1.6GHz w/8GB ram (i386 server though, thanks to adobe)
| |
| 14:04 | and a single 2x quadcore xeon 3.0ghz
| |
| 14:04 | of course that's serving labs + classrooms of ~50-60 total at each site
| |
| 14:05 | Guaraldo, are the servers serving specific clients or are they clustered?
| |
| 14:05 | <Guaraldo> AMD64 runs perfectly Adobe Reader i386...
| |
| 14:05 | <johnny> flash..
| |
| 14:05 | not adobe reader..
| |
| 14:05 | <Guaraldo> johnny: Yep... i386 firefox...
| |
| 14:06 | <lns> yack..i was in that mess a while ago
| |
| 14:06 | took ogra's advice and re-build the servers with i386
| |
| 14:06 | <Guaraldo> lns: I've solved this installing firefox i386...
| |
| 14:06 | <lns> Guaraldo, did you solve the printing problems too w/i386 ff and amd64 cups libs?
| |
| 14:07 | unless that's been fixed in the code since i had the issue
| |
| 14:07 | <Guaraldo> lns: I did not have this problems...
| |
| 14:08 | <lns> heh, you're lucky then ;)
| |
| 14:08 | vagrantc, what's up with ltsp5 being slower than 4.2? is there a simple explanation or is it just that there's code to be optimized?
| |
| 14:09 | <vagrantc> lns: it's mostly using binaries built for a desktop system
| |
| 14:09 | lns: it's using straight ubuntu/debian (soon to be fedora) binaries
| |
| 14:09 | <lns> vagrantc, so the distro integration
| |
| 14:09 | yea
| |
| 14:09 | catch 22 there =p
| |
| 14:09 | <vagrantc> it's also using a recent kernel
| |
| 14:10 | <lns> i never really used 4.2 much but i did really like the console-based ltspadmin
| |
| 14:10 | <vagrantc> but, it gets security updates and it's much easier to install client-side software
| |
| 14:10 | <lns> exactly
| |
| 14:11 | i just got thin-client-manager working the other day - sooo nice
| |
| 14:11 | <vagrantc> yeah, nobody's gotten around to writing a replacement for ltspadmin ... ogra_cmpc's worked on a few projects towards that, but i don't think any of them ever got ready really.
| |
| 14:12 | <lns> ogra's got too many things he's doing, when i start getting enough income from my ltsp-based clients i want to hire at least a part-time ltsp coder
| |
| 14:12 | or find out whatever the best way would be to pay someone to help out
| |
| 14:12 | <johnny> too bad you're not nearby.
| |
| 14:12 | <lns> johnny, ?
| |
| 14:13 | <johnny> to know somebody who works nearby with ltsp
| |
| 14:13 | <lns> location is irrelevant when you have vnc over ssh ;) cept for the setup part of course
| |
| 14:14 | <johnny> i mean working diretly with the hardware to see what is happenin
| |
| 14:14 | which is useful
| |
| 14:14 | to be in the deployed environment
| |
| 14:14 | <lns> yeah
| |
| 14:15 | well there's always ups ;)
| |
| 14:15 | and youtube..i've done a troubleshooting video over yt before
| |
| 14:15 | and/or stickam, or ekiga/skype
| |
| 14:18 | cdealer has quit IRC | |
| 14:19 | Guaraldo has left #ltsp | |
| 14:23 | indradg has quit IRC | |
| 14:30 | <cliebow__> cesar_:first thing Scottie would ask is..have you gone carefully thru the troubleshooting 12 step in wiki.ltsp.org..
| |
| 14:32 | <cesar_> :-|
| |
| 14:33 | what?
| |
| 14:34 | <vagrantc> for ltsp4.2 localdev ... there's ...
| |
| 14:34 | !checklist
| |
| 14:34 | <ltspbot> vagrantc: "checklist" is The checklist for debugging problems with local device access is at http://wiki.ltsp.org/twiki/bin/view/Ltsp/LTSP-42-LocalDev#Troubleshooting. Please work through all 12 steps, record the results, and paste the results to the pastebot at http://pastebot.ltsp.org
| |
| 14:34 | <cesar_> yes..
| |
| 14:35 | I saw this steps
| |
| 14:35 | in http://wiki.ltsp.org/twiki/bin/view/Ltsp/LTSP-42-LocalDev#Troubleshooting
| |
| 14:36 | <vagrantc> some of them are applicable to ltsp5 and localdev, but some of it is just misleading for ltsp5
| |
| 14:36 | <cesar_> but.. I found the error in "step 8"
| |
| 14:37 | the program "lbussd" not workind in terminal client
| |
| 14:37 | Q-FUNK has joined #ltsp | |
| 14:39 | <vagrantc> yeah, lbusd is something not present in ltsp5
| |
| 14:39 | <cesar_> and.. I not found the correct response for this error
| |
| 14:39 | ufff.
| |
| 14:40 | if lbussd not is present
| |
| 14:40 | in ltsp5
| |
| 14:40 | is the same for me use ltsp4.2 or ltsp5
| |
| 14:40 | because..
| |
| 14:41 | alekibango has quit IRC | |
| 14:44 | Egyptian[Home] has quit IRC | |
| 14:45 | Egyptian[Home] has joined #ltsp | |
| 15:00 | mhterres has quit IRC | |
| 15:04 | Guaraldo has joined #ltsp | |
| 15:07 | cliebow__ has quit IRC | |
| 15:07 | <warren> vagrantc, here's the latest idea:
| |
| 15:08 | option root-path "192.168.0.254:/opt/ltsp/i386";
| |
| 15:08 | this syntax has been used for years already
| |
| 15:08 | vagrantc, option root-type "nbd";
| |
| 15:08 | vagrantc, option root-path "192.168.0.254:2000";
| |
| 15:08 | <vagrantc> the syntax is actually "<ip:>PATH<,options>"
| |
| 15:08 | ip and options being... optional
| |
| 15:09 | <warren> ,options can be things like "noatime"?
| |
| 15:09 | <vagrantc> whatever mount options you care to pass
| |
| 15:10 | warren: so, a machine boots with that eand tries to mount /2000 on your server ... ?
| |
| 15:10 | <warren> vagrantc, it was only a suggestion, I do dislike the idea of reusing root-path for this.
| |
| 15:10 | <vagrantc> warren: the point you had made was to avoid using root-path for anything it isn't already established for
| |
| 15:10 | <warren> vagrantc, the other idea was to define something new like nbd-root-path
| |
| 15:11 | <vagrantc> warren: i think the second idea is better
| |
| 15:11 | Guaraldo has left #ltsp | |
| 15:12 | <vagrantc> warren: you pretty much convinced me by the time i finished typing my complaint
| |
| 15:13 | <warren> convinced of what?
| |
| 15:13 | vagrantc, btw, with bzr is there a way to say exactly which files you want to checkin changes but not others?
| |
| 15:13 | <vagrantc> warren: that we should use some newly defined option
| |
| 15:14 | warren: bzr ci files/i want/to/commit
| |
| 15:14 | <warren> ah
| |
| 15:14 | <vagrantc> warren: i also make use of bzr shelve from bzrtools a lot
| |
| 15:15 | warren: to set aside changes within a file that don't belong in a single commit
| |
| 15:18 | <warren> vagrantc, I'm personally preferring nbd-root-path, but there is the possibility that we're simply overblowing the danger of redefining root-path.
| |
| 15:19 | <vagrantc> warren: it's not really a path, though ...
| |
| 15:19 | warren: anyways, i think the options are merely numbers client-side ...
| |
| 15:19 | warren: the server-side human-readable names i think are merely in dhcpd.conf
| |
| 15:20 | i could be wrong on that ...
| |
| 15:22 | <warren> pjones argues convincingly that a client that screws up due to IP:port isn't going to work anyway.
| |
| 15:22 | So this really isn't a danger.
| |
| 15:23 | <vagrantc> on any network where you have clients that need the traditional NFS root, and you also have clients with NBD root, you'll have to configure it in dhcpd.conf anyways ...
| |
| 15:24 | if you want both to work
| |
| 15:24 | Guaraldo has joined #ltsp | |
| 15:24 | <vagrantc> i can't really think of a case where it would really, truely be harmful
| |
| 15:26 | Guaraldo has left #ltsp | |
| 15:28 | <warren> yeah
| |
| 15:29 | <vagrantc> then we could have a heuristic determine if it's NFS or NBD based on the content
| |
| 15:30 | although, the way initramfs-tools is designed, that won't work so well ....
| |
| 15:30 | it kind of assumes you know if you're doing a hard drive, nfs or FOO type boot
| |
| 15:31 | but whatever. we'll figure it out eventually
| |
| 15:31 | hmmm...
| |
| 15:32 | well, we could a ltsp script that just sources the appropriate NFS/NBD/FOO scripts ... not so ugly, i guess.
| |
| 15:33 | <laga> for initramfs?
| |
| 15:34 | <vagrantc> yes
| |
| 15:34 | <laga> isn't that already done for debian? eg, you have different scripts for nfs/"normal"/ltsp_nbd..
| |
| 15:35 | <vagrantc> yes, but you have to hard-code or define at the boot prompt which to use
| |
| 15:35 | i want to get that information from dhcp
| |
| 15:36 | or at least, be able to.
| |
| 15:37 | <laga> that sounds great
| |
| 15:39 | <vagrantc> maybe i'll call this meta-script "dhcp" ... then you can say boot="dhcp" at the boot prompt or BOOT="dhcp" in the configuration file, it'll make a dhcp request and source the local (hard drive) script if it doesn't get any promising information, and figure out if it should use NFS or NBD and source the appropriate scripts if needed
| |
| 15:39 | and possibly other scripts ...
| |
| 15:41 | warren: i also want NBD root to be more than just unions+squashfs+NBD ... i tested NBD+squashfs+tmpfs bind mounts once and it worked well
| |
| 15:42 | NBD+FILESYSTEM(s)+WRITE_METHOD(s)
| |
| 15:42 | that's what i'd like to be able to support in the long run.
| |
| 15:43 | warren: what are you looking at using? neither unionfs or squashfs are in the mainline kernel, are they?
| |
| 15:43 | warren: NBD + tmpfs bind mounts ?
| |
| 15:44 | <warren> vagrantc, initially readonly root with fedora's readonly-root mode, which does tmpfs bind mounts automatically.
| |
| 15:44 | vagrantc, a little later dm-snap for block-level changes instead of unionfs.
| |
| 15:44 | vagrantc, looks like our people were correct in believing unionfs will never hit upstream anytime soon
| |
| 15:44 | didn't hit 2.6.25 like the media said it would
| |
| 15:45 | <vagrantc> warren: NBD + $filesystem + readonly-root ?
| |
| 15:45 | <warren> LKML has some very harsh criticisms remaining of unionfs
| |
| 15:45 | vagrantc, NBD + squashfs + readonly-root mode at first, already works
| |
| 15:45 | <vagrantc> warren: squashfs is in kernel now?
| |
| 15:45 | <warren> vagrantc, good question
| |
| 15:46 | * warren looks | |
| 15:46 | <laga> nicoAMG: i currently use NBD + aufs and it's working great.
| |
| 15:46 | err, vagrantc i meant. sorry nicoAMG
| |
| 15:46 | <warren> vagrantc, we switched to squashfs from something else because the something else couldn't handle images above a certain size
| |
| 15:46 | <vagrantc> i've been focusing mostly on ltspfs and ldm lately ... haven't really looked forward to messing with the underlying filesystem too much.
| |
| 15:47 | <nicoAMG> laga: NP :)
| |
| 15:47 | <warren> vagrantc, oh I see. squashfs isn't usptream either.
| |
| 15:48 | K_O-Gnom has quit IRC | |
| 15:48 | <vagrantc> warren: that's what i meant ... that always seemed to be a major issue for you
| |
| 15:48 | <warren> vagrantc, squashfs is considered to be less crack filled though. So we're only partially hypocritical.
| |
| 15:48 | cesar_ has quit IRC | |
| 15:48 | <warren> vagrantc, we are still very careful about what we put into the kernel
| |
| 15:49 | vagrantc, squashfs has little chance of causing some unexpected failure, while unionfs still has known cases where it can fail spectacularly (which is why it continues to undergo heavy revision and review upstream)
| |
| 15:49 | <notting> squashfs, being a read-only filesystem, tends to avoid many of the races and deadlocks that unionfs is subject to
| |
| 15:49 | <vagrantc> sure.
| |
| 15:49 | <warren> So yes we are hypocritical
| |
| 15:49 | but just only slightly
| |
| 15:49 | <vagrantc> choose your battles wisely :)
| |
| 15:50 | i'm somewhere between idealist and pragmatist :)
| |
| 15:50 | sometimes i swing heavily one way or the other
| |
| 15:50 | <warren> oh nice, we have an engineer upstreaming squashfs
| |
| 15:50 | <vagrantc> ok, so qemu-system-mips works reasonably well. yay.
| |
| 15:51 | hopefully i can actually test some of this mips hardware now.
| |
| 15:51 | easier to network boot than install an OS :)
| |
| 15:57 | <warren> really?
| |
| 15:57 | how fast?
| |
| 16:00 | <vagrantc> i've got it running in a xen instance on a dual 2.4GHz xeon
| |
| 16:00 | it feels a little sluggish
| |
| 16:01 | although qemu-system-mips is written to take advantage of multiple procs as far as i can tell ... unless there's a commandline option
| |
| 16:02 | rcy` has joined #ltsp | |
| 16:03 | <vagrantc> both mips and mipsel seem to work reasonably well in debian sid
| |
| 16:03 | in qemu
| |
| 16:04 | nicoAMG has quit IRC | |
| 16:06 | <warren> cool
| |
| 16:14 | gonzaloaf has quit IRC | |
| 16:18 | pawsmacker has joined #ltsp | |
| 16:21 | jammcq has quit IRC | |
| 16:22 | mccann has quit IRC | |
| 16:32 | mccann has joined #ltsp | |
| 16:36 | toscalix has quit IRC | |
| 16:44 | rcy` has quit IRC | |
| 16:45 | rcy` has joined #ltsp | |
| 16:47 | rcy` has joined #ltsp | |
| 16:51 | pawsmacker has left #ltsp | |
| 17:05 | bobby_C has quit IRC | |
| 17:12 | <vagrantc> warren: you deleted a couple revisions from the ltsp-trunk branch.
| |
| 17:12 | <warren> vagrantc, huh?
| |
| 17:12 | vagrantc, i did a bzr pull first
| |
| 17:13 | :q
| |
| 17:13 | oops
| |
| 17:13 | <vagrantc> warren: you changed the order of commits
| |
| 17:13 | <warren> your commits?
| |
| 17:13 | <vagrantc> hrm. i don't quite understand what happened.
| |
| 17:14 | <warren> vagrantc, all I did was bzr pull, it told me to use merge, it said everything merged fine (we didn't touch any files in common)
| |
| 17:14 | <laga> the missing revisions probably show up in the changelog.
| |
| 17:14 | <vagrantc> warren: unfortunately, this is where bzr gets a little brain-dead
| |
| 17:14 | <warren> I was trusting bzr too much?
| |
| 17:15 | I did this several times before
| |
| 17:15 | did I lose other things?
| |
| 17:15 | * vagrantc investigates | |
| 17:15 | <vagrantc> i thought i set a flag so that wouldn't happen anymore...
| |
| 17:15 | i got an email sainy 2 revisions were removed from the branch ... now the question is ... which two
| |
| 17:16 | <warren> all I did was bzr pull, bzr merge, bzr push
| |
| 17:16 | <vagrantc> warren: ok, so what happened is you clobbered my 561 and 562
| |
| 17:16 | warren: yes, and that will cause this to happen
| |
| 17:16 | <warren> what should I have done?
| |
| 17:17 | <vagrantc> pull and push need to be used with care.
| |
| 17:17 | <warren> I have more changes to push soon
| |
| 17:18 | <vagrantc> warren: what should happen is it should refuse to allow you to push if you're overwriting revisions ...
| |
| 17:18 | this almost makes me want to abandon bzr entirely.
| |
| 17:18 | way more than performance issues.
| |
| 17:18 | <warren> no, I mean what shoudld I have done locally to ensure that I don't clobber your changes?
| |
| 17:18 | I've done this a few other times so I wonder if I clobbered other things.
| |
| 17:18 | vagrantc, note... launchpad seems to be a really slow place to host bzr
| |
| 17:18 | vagrantc, bzr on fedora's servers are WAY faster
| |
| 17:18 | <vagrantc> warren: rather than merge the upstram changes into your branch, you should merge your changes into upstream.
| |
| 17:19 | i honestly don't care much about the performance issues with bzr at all.
| |
| 17:19 | <warren> vagrantc, so I made local changes, I should use what commands?
| |
| 17:19 | vagrantc, I clobbered your actual changes or only the changelogs?
| |
| 17:19 | <vagrantc> warren: so instead of merging ltsp-trunk into your branch, you should have grabbed a new copy of ltsp-trunk and merged your changes into it.
| |
| 17:20 | warren: yoclobbered the commit history.
| |
| 17:20 | <warren> OK, I didn't know this before.
| |
| 17:20 | <vagrantc> warren: what was previously revisions 561 and 562 are now your merge 563
| |
| 17:20 | <warren> cd ltsp-trunk; bzr pull ../ltsp-warren; bzr merge; bzr push?
| |
| 17:21 | vagrantc, like that?
| |
| 17:21 | vagrantc, I guess git has rebase for this purpose...
| |
| 17:21 | <vagrantc> warren: cd ltsp-trunk ; bzr pull ; bzr merge ../ltsp-warren ; bzr push
| |
| 17:21 | pull and push is where the revision history will get overwritten.
| |
| 17:22 | <warren> OK, I didn't know this before, I'll be more careful in the future.
| |
| 17:22 | <vagrantc> and i frequently throw a few "bzr missing" in for good measure.
| |
| 17:22 | J45p3r has joined #ltsp | |
| 17:24 | <vagrantc> warren: thing is... you should have to worry about a Version Control System cloberring ... Version information.
| |
| 17:24 | s,should,shouldn't,
| |
| 17:25 | <warren> vagrantc, this wasn't malicious intent. I've never used a VCS that behaves in this way before.
| |
| 17:25 | It seems that bzr is missing anything like git-rebase
| |
| 17:25 | which seems stupid
| |
| 17:25 | <vagrantc> warren: git does it all the time.
| |
| 17:25 | every time you rebase, it changes the revision history
| |
| 17:26 | it's not like the commits are gone, but how the history of how they entered the repository is lost.
| |
| 17:26 | pwd
| |
| 17:26 | ls
| |
| 17:26 | and so the revision where you merged changes has unrelated changes in a single commit, which i generally don't like.
| |
| 17:26 | <warren> vagrantc, I now know what to do
| |
| 17:27 | vagrantc, there's no need to be upset and continue to remind me of the mistake I made. I had no way of knowing.
| |
| 17:27 | I thought you even stopped this from happening on the server side
| |
| 17:27 | <vagrantc> warren: i'm *not* blaming you!
| |
| 17:27 | i'm blaming BZR
| |
| 17:27 | this is my most hated "feature" of bzr.
| |
| 17:27 | <warren> launchpad is so slow....
| |
| 17:28 | <vagrantc> i thought i stopped this from happening too, but clearly there's something wrong.
| |
| 17:28 | <warren> are your revision history things actually gone
| |
| 17:28 | didn't it just rename it?
| |
| 17:29 | <vagrantc> warren: what was previously 561 and 562 are now both mushed into 563
| |
| 17:29 | and in revision 563 you can see the two separate commits
| |
| 17:29 | <warren> vagrantc, if you bzr pull from your previous tree it isn't able to step to the current contents on the server?
| |
| 17:30 | <vagrantc> warren: not without re-writing history
| |
| 17:30 | <warren> (are you sure it didn't just rename the revision numbers?)
| |
| 17:30 | <vagrantc> warren: what do you mean by rename?
| |
| 17:30 | <warren> Maybe it is designed to rename the revision numbers
| |
| 17:30 | it didn't actually lose it
| |
| 17:31 | <vagrantc> the content of the commits is still there, but the revision history is changed.
| |
| 17:31 | <warren> maybe append-only actually is working
| |
| 17:31 | bzr is just designed to rename the revision numbers
| |
| 17:31 | nothing is actually lost?
| |
| 17:31 | <vagrantc> so if i tell someone "look at the changes introduced in revision 531" and they'll be looking at a totally different set of changes
| |
| 17:31 | <warren> I don't know, just guessing.
| |
| 17:32 | <vagrantc> append-only is *supposed* to prevent it from mucking with the revision history ... but it doesn't work if your branch format isn't recent enough
| |
| 17:32 | that's probably what it is
| |
| 17:32 | Q-FUNK has quit IRC | |
| 17:33 | * warren pushing more | |
| 17:34 | * laga also loves how bzr frequently breaks backwards compatibility by introducing new branch formats | |
| 17:35 | <vagrantc> yeah, it's been stable for like 3 whole months!
| |
| 17:35 | <laga> oh, neat.
| |
| 17:35 | i felt bad when i created a new branch and forced someone from my team to upgrade his bzr install
| |
| 17:36 | <vagrantc> probably about time to go through a swift period of a couple new formats with each release
| |
| 17:36 | <laga> sure. gotta keep those users on their toes ;)
| |
| 17:37 | ah well, it could be worse. :)
| |
| 17:40 | johnny_ has joined #ltsp | |
| 18:09 | iMav has quit IRC | |
| 18:09 | twinprism has quit IRC | |
| 18:26 | alekibango has joined #ltsp | |
| 18:43 | iMav has joined #ltsp | |
| 18:43 | twinprism has joined #ltsp | |
| 18:48 | alekibango has quit IRC | |
| 18:51 | mistik1_ has joined #ltsp | |
| 18:56 | alekibango has joined #ltsp | |
| 18:59 | staffencasa has quit IRC | |
| 19:02 | ogra_cmpc_ has joined #ltsp | |
| 19:03 | ogra_cmpc has quit IRC | |
| 19:03 | ogra_cmpc_ is now known as ogra_cmpc | |
| 19:05 | mistik1 has quit IRC | |
| 19:05 | mistik1_ is now known as mistik1 | |
| 19:46 | alekibango has quit IRC | |
| 19:46 | alekibango has joined #ltsp | |
| 19:54 | johnny_ has quit IRC | |
| 20:02 | rmxnoc has joined #ltsp | |
| 20:02 | rmxnoc has joined #ltsp | |
| 20:09 | Q-FUNK has joined #ltsp | |
| 20:20 | elisboa_ has joined #ltsp | |
| 20:21 | spectra has quit IRC | |
| 20:21 | rmxnoc has quit IRC | |
| 20:23 | elisboa_ has quit IRC | |
| 20:23 | elisboa_ has joined #ltsp | |
| 20:25 | elisboa_ has quit IRC | |
| 20:25 | elisboa_ has joined #ltsp | |
| 20:31 | iMav has quit IRC | |
| 20:42 | vagrantc has quit IRC | |
| 21:03 | J45p3r has quit IRC | |
| 21:14 | Q-FUNK has quit IRC | |
| 21:22 | otavio has quit IRC | |
| 21:23 | otavio has joined #ltsp | |
| 21:39 | ogra has quit IRC | |
| 21:39 | ogra_cmpc has quit IRC | |
| 21:40 | ogra has joined #ltsp | |
| 21:40 | ogra_cmpc has joined #ltsp | |
| 21:44 | alekibango has quit IRC | |
| 21:48 | mccann has quit IRC | |
| 22:17 | mccann has joined #ltsp | |
| 22:28 | BGomes has joined #ltsp | |
| 22:46 | <warren> sigh, launchpad is very slow for me
| |
| 23:13 | <johnny> warren, how's the port goin?
| |
| 23:13 | mccann has quit IRC | |