--- Log opened nie maj 23 00:00:33 2004 00:10:48< Bertl> hey shuri, intested in something new? 00:27:00< shuri> Bertl? 00:27:22< Bertl> well, you are testing/using 1.9. atm, right? 00:27:25< shuri> yes 00:27:43< Bertl> I have a new patch for 1.9.1, with a new feature ... 00:28:01< shuri> ok i can test it 00:28:17< shuri> what is the new feature? 00:28:40< Bertl> well, I almost have it ... and it will allow ping to work ;) 00:28:56< shuri> good 00:37:53< Bertl> http://vserver.13thfloor.at/Experimental/delta-2.6.6-vs1.9.1-vs1.9.1.1.diff 00:38:29< Bertl> actually fixes a small bug with netstat display ... and adds the VXC_RAW_ICMP flag 00:38:51< cypromis> :) 00:39:09< shuri> good 00:42:36>> Doener` [~doener@pD9E12698.dip.t-dialin.net] has joined #vserver 00:42:51< Bertl> evening Doener`! 00:46:09< Bertl> okay, enough for me for today ... night everyone! 00:46:21>> Bertl is now known as Bertl_zZ 00:47:33< shuri> gnite 00:47:45< shuri> i will test the patchs 00:49:43>> Doener [~doener@p5082DFC6.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 01:48:03>> surriel [~riel@imladris.surriel.com] has joined #vserver 01:48:44>> surriel is now known as riel 02:16:44>> riel [~riel@riel.netop.oftc.net] has left #vserver [Client exiting] 02:33:42>> Napalm [~napalm@host81-7-26-228.adsl.v21.co.uk] has joined #vserver 02:35:06< Napalm> hello everyone 02:35:11< Napalm> anyone awake? 02:41:11< Napalm> does anyone have the download URLs for util-vserver-0.29.214 02:45:18>> chaosle [~yvan@port-212-202-168-55.dynamic.qsc.de] has quit [Quit: Leaving] 02:49:13>> Napalm [~napalm@host81-7-26-228.adsl.v21.co.uk] has quit [Ping timeout: 480 seconds] 02:59:32>> Napalm [~napalm@host81-7-26-228.adsl.v21.co.uk] has joined #vserver 03:10:45>> Napalm [~napalm@host81-7-26-228.adsl.v21.co.uk] has quit [Quit: ] 04:14:45>> Shotygun [shotgun@shotygun.com] has joined #vserver 05:16:14>> serving [~serving@213.186.189.12] has quit [Read error: Connection reset by peer] 06:38:19>> pflanze [~chris@gate.wyona.com] has quit [Ping timeout: 480 seconds] 07:08:28>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Quit: http://base2091.com] 07:12:16>> serving [~serving@213.186.189.12] has joined #vserver 07:29:50>> tchan [~tchan@c-24-13-81-164.client.comcast.net] has quit [Remote host closed the connection] 07:30:02>> tchan [~tchan@c-24-13-81-164.client.comcast.net] has joined #vserver 08:41:24>> Khahan [~Filbert@D57745B4.kabel.telenet.be] has joined #vserver 09:54:28>> Filbert- [~Filbert@D5E0628B.kabel.telenet.be] has joined #vserver 10:01:42>> Khahan [~Filbert@D57745B4.kabel.telenet.be] has quit [Ping timeout: 480 seconds] 10:26:30>> Khahan_ [~Filbert@D57745B4.kabel.telenet.be] has joined #vserver 10:28:56>> Khahan_ is now known as Khahan 10:33:49>> Filbert- [~Filbert@D5E0628B.kabel.telenet.be] has quit [Ping timeout: 480 seconds] 11:33:42>> Lior [~Lior@bzq-166-68.dsl.bezeqint.net] has joined #vserver 11:34:42< Lior> hey guys, right here (http://vserver.13thfloor.at/Stuff/Cross/compile.info) it says linux 2.4.26-ia64 compiled with vserver, but here i cannot do that 11:35:07< Lior> are there any special patches i need (apart from the kernel.org -ia64 patches) 11:41:45>> serving [~serving@213.186.189.12] has quit [Read error: Connection reset by peer] 12:14:26>> Lior [~Lior@bzq-166-68.dsl.bezeqint.net] has quit [Quit: Leaving] 12:15:20>> cereal [~cereal@pD9EAB701.dip.t-dialin.net] has joined #vserver 12:29:12>> Bertl_zZ is now known as Bertl 12:29:31< Bertl> I'm off for breakfast/lunch but I'm abck in 20 or so ... 12:29:41>> Bertl is now known as Bertl_oO 12:35:46>> Khahan [~Filbert@D57745B4.kabel.telenet.be] has quit [Ping timeout: 480 seconds] 12:46:21>> Lior [~Lior@bzq-166-68.dsl.bezeqint.net] has joined #vserver 12:54:32>> Bertl_oO is now known as Bertl 12:54:43< Bertl> hey Lior, you are testing on ia64? 12:55:01< Lior> Bertl: the idea is running on ia64, not just testing:) 12:55:45< Lior> did anyone report a single working version of vserver on ia64 on any kernel tree? 12:56:06< Lior> i see the crosscompilation results, which are nothing like the real thing 12:56:13< Bertl> no, nobody did test/run on ia64 yet, IIRC 12:56:15< Shotygun> I'm about to do it soon myself, but not yet. 12:56:21< Shotygun> Morning everyone 12:56:47< Shotygun> Oh bert sorry for the delay, will finish the bot soon, had some rough weekend ;) 12:56:48< Bertl> Lior: and the cross compiles are for vanilla kernel ;) 12:56:49< Lior> Shotygun: morning:), 2.6.6 doesnt patch, error in sysctl.c 12:57:20< Lior> Bertl: thats right, 2.4-ia64 needs special patches 12:57:25< Bertl> Shotygun: no problem there ... logging works, right? 12:57:29< Lior> 2.6 doesnt, but it still doesnt compile right 12:57:36< Shotygun> Yeah logging works but the bot is in the test chan. 12:57:54< Bertl> so we have no logging yet? :( 12:57:56< Shotygun> It's just the help thingy 12:58:06< Lior> i tryed compiling 2.6.3, which is supposed to work on ia64 - but it was a no go 12:58:08< Shotygun> Hmm I will join it 12:58:30< Lior> is ther anyone working on a ia64 port at all, or is the patch just a collection of hacks? 12:58:32< Bertl> Lior: does 2.6.6 (vanilla) compile and work on ia64? 12:59:31< Lior> yes, im running it atm 12:59:44< Lior> 2.6.3+vserver didnt work 12:59:49< Bertl> vserver is _really_ arch agnostic, so only small adjustments might be required ... 12:59:53< Lior> but without it, i even configured it 13:00:09< Lior> yeah, maybe so, but my kernel programming is very weak 13:00:13< Bertl> could you get 1.9.1 and compile it, and report any errors/warnings? 13:00:21< Lior> sure 13:00:24< Lior> 1 sec 13:00:31< Bertl> 21 ... 13:00:36< Lior> how/where should be? 13:00:42< Shotygun> I suspended the help code for now 13:00:43>> vserver-log [shotgun@212.199.206.70.forward.012.net.il] has joined #vserver 13:00:45< Lior> *should the report be that is 13:00:48< Shotygun> I will continue develop it soon over another bot. 13:01:00< Bertl> could you upload the output somewhere? 13:01:01< Lior> hosted in israel?:) 13:01:02< Lior> nice 13:01:08< Shotygun> Ken habibi =) 13:01:13< Lior> nehmad:) 13:01:16< Shotygun> ;) 13:01:41< Lior> now 2.4.26 + ia64 patches wont compile 13:01:43< Lior> weak&&ugly 13:02:03< Shotygun> It's nice to hear somebody is having the ia64 pain before I have to do go through it soon =D 13:02:12< Bertl> okay, 2.4.26 requires ia64 patches, right? and they themselves do not compile? 13:02:12< Shotygun> 2.6.6 compiled smoothly tho right? 13:02:18< Lior> so Bertl, i should make a /usr/bin/script of the compilation process/ 13:02:40< Lior> Bertl: yaah, something like "drivers/hotplug/vmlinux-obj.o(.text+0x6932): In function `pci_print_IRQ_route': 13:02:41< Lior> /usr/src/linux-2.4.26/drivers/hotplug/cpqphp_core.c:203: undefined reference to `pcibios_get_irq_routing_table' 13:02:41< Lior> " comes in 13:02:45< Bertl> how are you compiling 2.6.6? please describe the process ... 13:02:55< Lior> configuring, than i make compressed 13:02:58< Lior> :) 13:03:09< Lior> but ill make a whole report later on today from home 13:03:14< Lior> and post it to the mailing list 13:03:16< Shotygun> Is the hotplug necessary? 13:03:31< Lior> Shotygun: uhuh 13:03:36< Bertl> Lior: okay, for example the error above is _not_ vserver related at alll 13:04:24< Bertl> (but that is 2.4.26 and disabling the hotplug stuff might help) 13:04:37< Shotygun> Yep I think so too 13:05:00< Lior> Bertl: i know, i didnt patch with vserver at all. it was just an example:) 13:05:17< Bertl> http://www.13thfloor.at/vserver/project/ 13:05:23< Bertl> http://www.13thfloor.at/vserver/d_rel26/overview/ 13:05:31< Bertl> http://www.13thfloor.at/vserver/d_rel26/v1.9.1/ 13:05:37< Bertl> this is the latest release ... 13:05:40< Lior> i know 13:05:45< Bertl> and you can add the following patch: 13:05:47< Lior> downloaded and patched with them already 13:05:53< Bertl> http://vserver.13thfloor.at/Experimental/delta-2.6.6-vs1.9.1-vs1.9.1.1.diff 13:06:11< Lior> ok, i will try 13:06:44< Lior> there are alot of kernel unaligned access errors 13:07:00< Shotygun> Bert who did the benchmarking over the ml ? 13:07:02< Bertl> okay, if you find an hour or so, where we can improve that interactively ... let me know ... 13:07:02< Lior> but thats because of some borked user space apps, running debian on it 13:07:25< Bertl> Shotygun: ryan did the benchmarking (taxcollector) 13:07:50< Shotygun> It would be nice to see benchmarking comparing to other projects as well, just for the sports; ) 13:08:02< Lior> Bertl: apply the delta patcha fter the latest 1.9.1, right? 13:08:11< Bertl> yep, correct ... 13:08:42< Bertl> Shotygun: I agree, but everybody can do so ... also kernbench results would be interesting ... 13:08:52< Bertl> especially in UML and vserver ... 13:08:58< Bertl> (maybe even freevps?) 13:09:20< Shotygun> I don't remember who but somebody reported that he failed to make freevps behave.. 13:09:27< Shotygun> UML will be interesting tho.. 13:09:28< Lior> lol 13:10:02< Lior> yeah, it was slow last time i used it 13:10:14< Shotygun> Lior if you can I would like to hear if you managed to work out vserver right over ia64, as I'm considering to buy one for vserver usage.. 13:10:19< Lior> but still better than vmware:) 13:10:21>> Khahan [~Filbert@D57745B4.kabel.telenet.be] has joined #vserver 13:10:30< Shotygun> Hmmmmmmm hang on a minute I will show you something: 13:10:38< Lior> Shotygun: sure mate, i will report errors too 13:10:42< Bertl> morning Khahan! 13:10:49< Shotygun> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/performance.html 13:10:51< Lior> im working off a lappy right now, so its abit buggered. not at home 13:11:15< Lior> yeah Shotygun, seen that 13:11:49< Lior> xen is i386 only, so i didnt bother trying it on that rx4610 box 13:12:29< Shotygun> I'm wondering how stable is it anyway.. 13:12:44< Bertl> probably very stable, it's low level emulation 13:12:55< Lior> me too, i have a p4+ht at home, will check it out 13:13:11< Bertl> thing is, you have to run a specialized linux on that, so it will make the kernel unstable ;) 13:13:30< Shotygun> Hmm 13:13:53< Bertl> well less stable is better here ;) 13:14:06< Shotygun> They got this DEMO iso, downloading 13:14:14< Shotygun> and downloaded v1.2 13:15:06< Lior> Bertl: 2.6.6 with delta patch has same errors: 13:15:17< Lior> arch/ia64/mm/fault.c: In function `expand_backing_store': 13:15:18< Lior> arch/ia64/mm/fault.c:40: error: parse error before "return" 13:15:48< Bertl> could you put the log (output) on a web server? 13:16:09< Lior> ok 13:16:44< Lior> making a typescript 13:17:57< Bertl> hmm, typo, pleas add a ')' at the end of line 40 in arch/ia64/mm/fault.c 13:19:18< Lior> yeah, was editing it while you typed that 13:19:44< cereal> hi bertl :) 13:19:59< Bertl> morning Sebastian, eh cereal! 13:20:28< cereal> oh 13:20:31>> cereal is now known as Sebastian 13:20:37< Lior> :) 13:20:38< Shotygun> Ok now that was dumb. I downloaded xeno*tgz and it was a single tar with no gzip. 13:20:47< Sebastian> sebastian is the right one 13:21:24< Lior> Shotygun: they wanted to just group the files together? 13:21:34< Shotygun> Yeah but why naming it tgz and not tar then. 13:21:44 * Lior shrugs 13:21:49< Shotygun> Somebody forgot to run the gzip over there =P 13:21:50 * Bertl .oO( wasn't there something called `Sin with Sebastian`? ) 13:24:01< Bertl> Lior: okay, any other warnings errors so far? 13:24:13< Lior> nope, compiles... for now 13:24:51< Shotygun> Lior OOT: Shavohot evening is tommorow right? lost track of time.. 13:25:08< Shotygun> Or tuesday? ^_- 13:25:10< Lior> no clue, let me ask the secretary in my boss` office 13:25:19< Bertl> Lior: is this single cpu? 13:25:31< Lior> tuesday eve 13:25:33< Lior> Bertl: quad 13:25:35< Shotygun> Okie 13:25:43 * Shotygun wants quad ia64 too. 13:25:53< Lior> its an rx4610 server, ancient 13:26:07< Bertl> and my postal address is ... 13:26:12< Lior> lol 13:26:15< eyck> me, i'd be satisfied with dual amd64 13:26:16< Shotygun> I'm from israel too 13:26:18< Shotygun> Delivery will be cheaper =) 13:26:25< Lior> Shotygun: lol!:) 13:26:33< Lior> i have a pic of it 13:26:33< Lior> sec 13:26:54< Lior> http://void.eclipse.org.il/alex/pictures/.itanium/ 13:27:19< Lior> another error ba 13:27:28< Lior> *Bertl 13:27:38< Bertl> yep, where and what? 13:27:48< Lior> kernel/vserver/proc.c: In function `proc_virtual_info': 13:27:49< Lior> kernel/vserver/proc.c:60: error: `__NR_vserver' undeclared (first use in this function) 13:27:53< Lior> on couple of lines 13:28:30< Bertl> hmm, yeah ... 13:28:33< Bertl> sec 13:28:35< Lior> uhuh 13:30:21< Bertl> hmm, thing is ia64 maintainers didn't reserve a syscall yet ... so which one shall we take ... 13:31:40< Lior> pick a number 13:31:50< Bertl> seems ia64 syscalls start at 1000 or so ... 13:32:58< Bertl> okay, let's pick 1273 then .. but you'll have to adjust the tools ... 13:33:21< Bertl> #define __NR_vserver 1273 13:33:35< Bertl> add this line to include/asm-ia64/unistd.h (line 260) 13:33:36< Lior> adding 13:33:40< Lior> :) 13:34:07< Bertl> probably the syscall table length needs changing to 274 too 13:35:49< Lior> hm 13:36:00< Bertl> where is the ia64 syscall table located? 13:36:31< Lior> no cluie 13:36:34< Bertl> arch/ia64/kernel/entry.S 13:36:39< Lior> the ia32 is known, ia 64 not:) 13:36:43< Lior> ah, sec 13:37:21< Bertl> okay, 1273 isn't used ... 13:37:41< Bertl> data8 sys_ni_syscall // 1270 13:37:41< Bertl> data8 sys_ni_syscall 13:37:41< Bertl> data8 sys_ni_syscall 13:37:41< Bertl> data8 sys_vserver 13:37:41< Bertl> data8 sys_ni_syscall 13:37:44< Bertl> data8 sys_ni_syscall // 1275 13:37:46>> serving [~serving@213.186.189.12] has joined #vserver 13:37:55< Bertl> this is what we want ... in arch/ia64/kernel/entry.S around 1501 13:38:01< Bertl> 1510 I mean ... 13:38:48< Lior> ok, will make clean and recompile 13:39:03< Bertl> hmm, userspace will be ia64, right? 13:39:07 * Lior nods 13:39:23< Bertl> no make clean required btw 13:39:39< Bertl> (only takes more time, the build system can handle this) 13:40:26< Lior> arch/ia64/kernel/entry.S: Assembler messages: 13:40:26< Lior> arch/ia64/kernel/entry.S:1527: Error: attempt to move .org backwards 13:40:49< Lior> where is NR_syscalls 13:41:03< Bertl> include/asm-ia64/unistd.h 13:41:12< Bertl> i changed it to 274 13:41:41< Bertl> maybe 276 or 277 would be the correct one ... 13:43:02< Lior> says 256 here, changed it to 257 13:43:26< Bertl> that is probably insufficient ... but let's see ... 13:43:27< Lior> cool, compiled 13:43:40< Lior> (pass sentry.S) 13:43:46< Lior> *passed 13:43:53< Lior> bah, not used to a laptop keyboard 13:44:14< Lior> anyways, Shotygun, where are you from? 13:44:27< Shotygun> *sleepy* Rishon. 13:44:39 * Lior is in Haifa atm 13:44:50< Shotygun> Sec phone 13:44:58< Lior> i live in Pardes Hana though, thats near hadera 13:45:29< Shotygun> Yeah I know where is that, I once lost myself there on my way to Karkor =) 13:45:36< Shotygun> Karkur* 13:46:08< Lior> hehe:) 13:46:10< Shotygun> And I didn't enjoy it specially in the mid of the night driving drunk people=) 13:46:30< Lior> hehe, unpleasent indeed 13:46:41< Shotygun> So no country experience for me or whatever I supposed to experience=P 13:46:45< Lior> not much police there, lost of people allow themselves to drive drunk 13:46:49< Bertl> okay, verified 257 should be fine, they start their syscall table at 1025?! 13:46:50< Lior> lol 13:47:10< Lior> Bertl: no clue, probably to still keep the ia32 compatibility 13:47:27< Bertl> well, ia32 syscalls are at 0-280 13:47:35< Lior> i know 13:47:36< Lior> :) 13:47:51< Bertl> ah, 1024 that is the magic number ;) 13:47:54< Lior> hehe 13:48:01< Bertl> finally all makes sense ... 13:48:39< Bertl> now probably our syscall number is wrong .. but I'll check that ... 13:49:41< Bertl> hmm, not more wrong than the others ... 13:53:15 * Shotygun thinks he should head to Haifa to give Lior personal assistance with his quad.. hrm.. 13:54:02< Lior> lol 13:54:14< Lior> Shotygun: are you a vserver developer? 13:54:18< Shotygun> Nope 13:54:40< Sebastian> Bertl: i can´t subscribe me on the mailing list since 2 week´s 13:54:49< Sebastian> the mailing list is alway showing a bug ^^ 13:56:12< Bertl> hmm, you should mention this to marlow, he said he fixed it ;) 13:56:41< Sebastian> i send this to marlow but i see he don´t fixed it ;) 13:56:46< Shotygun> This god damn phone won't stop ringing.. 13:57:06< Bertl> Sebastian: send it again, if it starts annoying him, he'll probably fix it ;) 13:57:11< Sebastian> ok 13:57:20< Bertl> and cc to the ml ... ;) 13:57:56< Bertl> Lior: any other errors so far? 14:01:02< Sebastian> Bertl: was this the e-mail adress? martin@list-petersen.se 14:01:20< Bertl> yep, sounds good .. shall I check? 14:02:44< Sebastian> no thx 14:03:01< Sebastian> i send it to him with a short description 14:07:22< Lior> Bertl: nope, compiling 14:09:10< Lior> its not as fast as it sounds, its a quad itanium 800mhz each 14:09:38< Lior> its a relativly old box. it has nice hardware and alot of ram, thus my boss wants it working 14:10:22< Bertl> well, it is intersting as it's the first ia64 (SMP) we have ... 14:10:40< Bertl> hmm, is this SMP at all? 14:12:07< Lior> yes, 4 cpus 14:12:24< Bertl> yeah, but are they symmetric? 14:12:32< Lior> im compiling with one thread so i dont have to look in the buffer for the errors, it takes a while as you can imagine 14:12:38< Bertl> (sorry don't know the ia64 details) 14:12:57< Lior> i think they are, the option in the kernel says SMP:) 14:13:06< Lior> Linux zeus 2.6.6 #1 SMP Sat May 22 20:08:39 IDT 2004 ia64 GNU/Linux 14:14:07< Bertl> arg! 2.6.7-rc1 is released, but not on kernel.org ... 14:14:08< Lior> make -j20 compressed beats any box ive seen compiling so far, even a lab 2.4 p4 w/ ht i have for testing 14:20:29< Lior> compiled, no errors:) 14:20:31< Lior> lets boot it 14:21:01< Bertl> sounds good ... 14:21:07< Bertl> ... so far ;) 14:21:22< Lior> yeah 14:21:26< Lior> booting is what will show 14:22:12< Lior> i can even provide benchmarks, from this beast. its going to be a while before we deploy it 14:22:30< Bertl> sounds good .... 14:23:11< Bertl> I'd appreciate some testing of the various features on ia64, some archs make private copies of stuff like utsname etc, and sometimes we miss that ... 14:23:33< Lior> it takes like 10 minutes for this box to finish its POST, so i will go to get a glass of water in the meantime 14:24:04< Lior> Bertl: i could hook you up with a shell i think, depends what you want to do with it 14:24:45< Bertl> to be honest, I'd prefer somebody else to do the testing ... 14:26:59< Lior> Linux zeus 2.6.6-vs1.9.1 #1 SMP Sun May 23 15:19:53 IDT 2004 ia64 GNU/Linux 14:27:00< Lior> hehe 14:27:27< Bertl> okay, you got any util-vserver installed/compiled? 14:27:51< Lior> nope, one sec 14:28:45< Bertl> guess that one will take longer, check which syscall number the tools assume .. and specify it by hand if it's wrong (which probably is the case) 14:30:01< Lior> yeah 14:30:28< Lior> checking for number of syscall 'vserver'... 273/default 14:30:31< Lior> that has to be changed 14:31:01< Lior> its in the Makefile, right? 14:31:02< Bertl> yep but I'm not sure that 1273 is a good choice here ... might be ... 14:31:13< Bertl> you can specify it at configure IIRC 14:32:02< Lior> noep 14:32:11< Lior> *nope, nothing in ./configure --help about it 14:32:26< Bertl> which version? 14:33:01< Lior> util-vserver-0.29.5 14:33:24< Bertl> hmm, get 0.29.214 14:33:56< Lior> ok 14:35:12< Bertl> and/or set CPPFLAGS='-D__NR_vserver=' environment when calling configure 14:35:23< Bertl> that's the magic required to change it on configure ;) 14:35:28< Lior> mkay 14:39:01< Lior> should i install dietlibc? 14:39:25< Bertl> would be better (according to enrico) but is not strictly required 14:39:54< Lior> mkay, im installing it now, apt get is cool:) 14:40:47< Lior> done 14:41:01< Lior> compiling 14:41:29>> Lior is now known as flock 14:42:03>> flock is now known as flock_ 14:42:11< flock_> dont remember my pass 14:42:25< flock_> done compiling 14:43:18< flock_> hm 14:43:23< flock_> vserver-stat 14:43:24< flock_> Illegal instruction 14:43:36< Bertl> let's try with something simple first ... 14:43:47< Bertl> you know my testme.sh? 14:43:52< flock_> nope 14:44:20< Bertl> http://vserver.13thfloor.at/Stuff/testme.sh 14:44:55< Bertl> what c/c++ compiler? 14:45:01< flock_> gcc 14:45:03< flock_> 3.2 14:45:12< flock_> eh, strace goes like: 14:45:14< flock_> execve("/usr/local/sbin/vserver-stat", ["vserver-stat"], [/* 15 vars */]) = 0 14:45:14< flock_> getpid() = 29756 14:45:14< flock_> --- SIGILL (Illegal instruction) @ 4000000000004fb2 (4000000000004fb2) --- 14:45:14< flock_> +++ killed by SIGILL +++ 14:45:25< Bertl> hmm, any chance to get at least 3.3 better 3.4? 14:45:45< flock_> sorry, gcc (GCC) 3.3.3 (Debian 20040401) 14:45:55< Bertl> okay, that one should be fine ... 14:46:06< flock_> what do you want me to paste/ 14:46:15 * Bertl .oO( although there is debian written beside that ;) 14:46:29< flock_> lol 14:46:33< Bertl> what does the testme.sh say? 14:46:59< flock_> well, i didnt want to put redhat on it, so i went for the debian provided by hp for that machiene and distupgraded to shrink 14:47:08< flock_> Linux-VServer Test [V0.07] (C) 2003-2004 H.Poetzl 14:47:08< flock_> /usr/local/sbin/chcontext: line 102: 29772 Illegal instruction $_VSERVER_INFO - FEATURE migrate 14:47:08< flock_> chcontext failed! 14:47:08< flock_> chbind failed! 14:47:08< flock_> Linux 2.6.6-vs1.9.1 ia64/0.29.214/0.29.214 [Ea] 14:47:09< flock_> --- 14:47:12< flock_> 14:47:23< flock_> *machine 14:47:26< Bertl> hmm, looks impressively bad ... 14:47:32< flock_> really? 14:47:57< Bertl> let's try 14:48:04< Bertl> vserver-info - SYSINFO 14:48:22< flock_> Versions: 14:48:23< flock_> Kernel: 2.6.6-vs1.9.1 14:48:23< flock_> VS-API: Illegal instruction 14:48:24< Bertl> /msg me in private 14:48:28< flock_> yeah:) 14:51:11< flock_> :) 14:51:44< Bertl> http://vserver.13thfloor.at/Experimental/killer-03.c 14:51:53< Bertl> compile this one, it's actually a vserver test ... 14:52:05< Bertl> (you have to adjust the syscall number) 14:52:13< flock_> np 14:54:39< flock_> hm 14:54:41< flock_> killer-03.c:13: error: parse error before "sys_vserver" 14:54:41< flock_> killer-03.c:13: warning: data definition has no type or storage class 14:55:18< Bertl> sec 14:55:25>> Shotygun [shotgun@shotygun.com] has quit [Quit: Leaving] 14:56:21< Bertl> http://vserver.13thfloor.at/Stuff/vflags-0.01.tar.bz2 14:56:22>> FD_LIMIT [~fdlimit@212.143.247.3] has joined #vserver 14:56:54< flock_> also, with glibc: 14:56:56< flock_> src/keep-ctx-alive.c: In function `doit': 14:56:56< flock_> src/keep-ctx-alive.c:143: error: `__arr' undeclared (first use in this function) 14:56:56< flock_> src/keep-ctx-alive.c:143: error: (Each undeclared identifier is reported only once 14:56:56< flock_> src/keep-ctx-alive.c:143: error: for each function it appears in.) 14:56:56< flock_> make[2]: *** [src/keep-ctx-alive.o] Error 1 14:56:58< Bertl> get this one, and change the __NR_vserver in vswitch.h 14:57:07< Bertl> hi FD_LIMIT! 14:57:14< FD_LIMIT> hey 14:57:25< Bertl> big day, what? 14:58:27< flock_> sec 14:59:31< flock_> hm 14:59:51< flock_> vswitch.h:9: error: parse error before "vserver" 14:59:52< flock_> vswitch.h:9: warning: type defaults to `int' in declaration of `_syscall3' 14:59:52< flock_> vswitch.h:9: warning: data definition has no type or storage class 14:59:52< flock_> vflags.c: In function `main': 14:59:52< flock_> vflags.c:100: warning: implicit declaration of function `vserver' 15:00:00>> Shotygun [shotgun@shotygun.com] has joined #vserver 15:00:27< Bertl> obviously syscall isn't defined in ia64, at least not at the places included so far ;) 15:00:47< flock_> yeaj 15:00:49< flock_> *yeah 15:01:02< Bertl> try to find the _syscall3 definition in your includes ... 15:01:04< flock_> i linked /lib/modules/`uname -r`/build properly 15:01:32< flock_> hm, which includes/ 15:01:36< flock_> kernel ones? 15:01:48< Bertl> no, normal /usr/include/ includes 15:01:55< Bertl> /usr/include/syscall.h 15:02:41< Bertl> that normally pulls in sys/syscall and then asm/unistd.h 15:03:01< flock_> yeah 15:03:20< Bertl> and /usr/include/asm/unistd.h 15:03:25< flock_> not this time, if you compile with gcc, its in /usr/include/bits/syscall.h 15:03:31< Bertl> should contain the definitions for _syscall3 15:04:16< flock_> yeah, modified it 15:04:32< Bertl> hum, what? 15:05:00< flock_> uh, modified bits/syscall.h, added an extra #define SYS_vserver __NR_vserver 15:05:13< Bertl> no, please don't do that ... 15:05:19< flock_> ok 15:05:23< Bertl> besides it doesn't change anything 15:05:48< flock_> yeah, saw that:/ 15:05:50< Bertl> does the /usr/include/syscall.h include 15:05:53< cypromis> bertl: ryan is lost in space and time it seems 15:05:54< Bertl> sys/syscall.h 15:06:04< cypromis> any idea what could cause the lack of proc entries ? 15:06:11< Bertl> cypromis: some folks got a real life ;) 15:06:24< flock_> /usr/include/syscall.h has only one line: "#include 15:06:24< flock_> " 15:06:28< cypromis> lol 15:06:49< Bertl> no, I don#t know the RHEL patch and it's modifications ... 15:07:12< Bertl> flock_: okay what's in /usr/include/sys/syscall.h ? 15:07:18< Bertl> what get's included there` 15:07:43< flock_> #ifndef _SYSCALL_H 15:07:43< flock_> #define _SYSCALL_H 1 15:07:48< flock_> #include 15:07:48< flock_> #ifndef _LIBC 15:07:55< flock_> # include 15:07:55< flock_> #endif 15:07:55< flock_> #endif 15:08:05< Bertl> okay, let's have a look at /usr/include/asm/unistd.h 15:08:27< Bertl> do you see a _syscall* definition there? 15:09:03< Bertl> something like this: 15:09:04< Bertl> #define _syscall3(type,name,type1,arg1,type2,arg2,type3,arg3) \ 15:09:47< flock_> extern long __ia64_syscall (long a0, long a1, long a2, long a3, long a4, long nr); 15:10:15< Bertl> that's all? 15:10:38< flock_> yup 15:10:50>> pflanze [~chris@gate.wyona.com] has joined #vserver 15:10:57< Bertl> well, what should I say ... looks like no syscalls for ia64?! 15:11:58< flock_> dont know 15:11:59< Bertl> is there a special glibc required? 15:12:14< flock_> no clue, its the one that comes with debian 15:12:21< flock_> no idea if its special or not 15:12:46>> pflanze [~chris@gate.wyona.com] has quit [Quit: ] 15:12:46< flock_> but i know ia32 apps work without recompilation, so there must be a way 15:13:07< Bertl> well, they probably use the ia32 interface then ... 15:13:45< Bertl> what does grep -r syscall3 /usr/include/* report? 15:14:03< flock_> nothing 15:14:24< Bertl> hmm, not much ... 15:15:14< flock_> hm, how is this working in ia32 without modifying the headers? 15:15:49< Bertl> my headers (i386) include that definitions ... 15:15:59< Bertl> /usr/include/asm/unistd.h:#define _syscall3(type,name,type1,arg1,type2,arg2,type3,arg3) \ 15:17:14< flock_> hm 15:17:27< flock_> http://www.gelato.unsw.edu.au/linux-ia64/0212/4382.html 15:18:50< flock_> do you think i should patch the headers with that patch? 15:19:30< Bertl> your headers do not even contain syscall and friends or am I wrong? 15:20:12< flock_> depends, therse an ia64_syscall definition there, as i pasted above 15:20:31< Bertl> #define _syscall0(type,name 15:20:46< Bertl> do you see that in /usr/include/asm/unistd.h? 15:21:49< flock_> nope 15:22:07< Bertl> see, that patch assumes that the definitions are there ... 15:22:43>> Sebastian is now known as Sebastian^aw 15:23:29< flock_> maybe my headers are broken/incomplete/ 15:23:41< Bertl> probably they are debianized ;) 15:24:09< flock_> yeah, probably 15:26:18< flock_> what am i to do 15:26:51< Bertl> complain to debian? 15:27:05< flock_> yeah, might do that 15:27:14< flock_> dont have a clue what other distro i can install here 15:27:18>> netrose [netrose@SP2-24.207.228.55.charter-stl.com] has quit [Ping timeout: 480 seconds] 15:27:20< Bertl> #define vserver(cmd, id, data) \ 15:27:20< Bertl> syscall((long)cmd, (long)id, (long)data, \ 15:27:22< Bertl> (long)0, (long)0, __NR_vserver) 15:27:31< Bertl> try that instead of the 15:27:33< Bertl> _syscall3(long, vserver, uint32_t, cmd, uint32_t, id, void *, data); 15:27:41< Bertl> in vswitch.h 15:29:56< flock_> compiled 15:29:59< flock_> but when run: 15:30:05< Bertl> hum, but it is broken ... 15:30:09< flock_> vc_set_ccaps: Function not implemented 15:31:00< Bertl> comment out this definition and use 15:31:03< Bertl> #define vserver(cmd, id, data) \ 15:31:04< Bertl> syscall(__NR_vserver, cmd, id, data) 15:31:08< Bertl> instead ... 15:32:10< flock_> same thing 15:32:11< Bertl> then try 'vflags -V' 15:32:33< Bertl> __NR_vserver is now defined as? 15:32:41< Bertl> (in this very same file) 15:33:32< flock_> 1273, the way it was supposed to 15:33:48< Bertl> okay, still with vflags -V you get? 15:34:15< flock_> vc_get_version: Function not implemented 15:34:15< flock_> vc_set_flags: Function not implemented 15:34:29< Bertl> so something is blocking the syscall then ... 15:34:39< Bertl> sec, investigating ... 15:35:28< flock_> i could write a small asm util to just int 0x80 the 1237 syscall, see if were getting somewhere 15:35:44< Bertl> no, ia64 syscalls are obviously different ... 15:36:00< Bertl> 1237?? 1273 I hope? 15:36:40< flock_> yeah, stupid laptop keyboard 15:36:53< flock_> *1273* 15:37:37< sladen> flock_: what's strace/ptrace give you? 15:38:28< flock_> SYS_1273(0x34020000, 0, 0x60000fffffffb890, 0xc00000000000040c, 0x2000000000240200, 0x1, 0x60000fffffffbce8, 0x2a0) = -1 ENOSYS (Function not implemented) 15:38:29< flock_> dup(2) = 3 15:38:29< flock_> fcntl(3, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE|0x8000) 15:38:29< flock_> brk(0) = 0x6000000000004000 15:38:29< flock_> brk(0x6000000000028000) = 0x6000000000028000 15:38:29< flock_> brk(0) = 0x6000000000028000 15:38:31< flock_> fstat(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0 15:38:33< flock_> mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2000000000290000 15:38:35< flock_> lseek(3, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) 15:38:37< flock_> write(3, "vc_set_flags: Function not imple"..., 39vc_set_flags: Function not implemented 15:38:39< flock_> ) = 39 15:38:41< flock_> close(3) = 0 15:38:43< flock_> munmap(0x2000000000290000, 65536) = 0 15:38:45< flock_> exit_group(0) = ? 15:38:47< Bertl> I'd say the glibc handles the syscall() and it blocks it for syscall > NR_syscall there ... 15:38:47< flock_> oops 15:38:49< flock_> -ENOSYS 15:39:11< flock_> yeah, where is it happening? 15:39:38< Bertl> let's try to use the __ia64_syscall 15:39:45< flock_> ok 15:39:48< Bertl> instead, with the previous definition 15:40:32< Bertl> #define vserver(cmd, id, data) \ 15:40:32< Bertl> __ia64_syscall((long)cmd, (long)id, (long)data, \ 15:40:32< Bertl> (long)0, (long)0, __NR_vserver) 15:41:02< Bertl> which strace is this? 15:41:07< Bertl> (which version) 15:43:07< flock_> ok 15:43:50< flock_> 1 sec, phone 15:44:17< yarihm> i know this is a strange question to ask, but since it is still interesting to know maybe someone can help: how do the developers feel about the 2.6-tree of vserver? i mean how stable and "productive" is it compared to 2.4 / 1.27? can it be risked to run on a production machine or not yet? 15:44:49< Bertl> 'the developers' feel confident ;) 15:44:53< yarihm> :) 15:45:09< yarihm> is it just you who develops bertl? there is a team i guess, no? 15:45:41< Bertl> a team of me, myself and 3 cats atm ;) 15:46:19< Bertl> and a bunch of penguins watching over it ... 15:46:42< flock_> lol 15:46:45< flock_> back 15:47:19< flock_> Bertl: it wont link... 15:47:36< Bertl> hmm, any statement why? 15:47:39< flock_> vflags.c:100: warning: implicit declaration of function `__ia64_syscall' 15:47:40< flock_> /tmp/cceqceaI.o(.text+0x432): In function `main': 15:47:40< flock_> /root/vflags-0.01/vflags.c:111: undefined reference to `__ia64_syscall' 15:47:40< flock_> /tmp/cceqceaI.o(.text+0x4d2):/root/vflags-0.01/vflags.c:46: undefined reference to `__ia64_syscall' 15:47:43< flock_> kind of... 15:48:01< Bertl> hmm, didn't you mentions something like this in the unistd.h? 15:48:28< flock_> like what?\ 15:48:34< Bertl> extern long __ia64_syscall (long a0, long a1, long a2, long a3, long a4, long nr); 15:49:10< flock_> yea, BTW, the number if syscalls in /usr/local/asm/unistd.h is still one less than the kernel unistd.h 15:49:33< Bertl> yeah, forget that ... 15:49:53< Bertl> so when this is defined in unistd.h why doesn't it exist? 15:50:19 * Bertl .oO( looks like another debian improvement ) 15:50:41< FD_LIMIT> haha 15:50:44< Shotygun> Bert loves debian =P 15:50:48< flock_> lol 15:50:54< flock_> haha@improvement 15:50:58< Bertl> I learned to love it ... 15:51:00< flock_> they modify headers/ 15:51:29< Bertl> especially the attitude of the debian vserver maintainer ... 15:52:41< Bertl> My policy on releasing debian vserver patches is the following: 15:52:41< Bertl> * Patches against new kernel versions will be uploaded as soon as I can 15:52:41< Bertl> find some spare time to do that, or if enough people complain. They 15:52:41< Bertl> will be tested if I can find some time for that. Usually reports will 15:52:41< Bertl> come farily quickly. 15:53:18< Bertl> (citat Ola Lundqvist) 15:53:40< sladen> berrl: is that any different to your own method, Linus' method, anyone's method? 15:54:09< Bertl> yep, it is, at least we try to compile the patches, right? 15:55:52< Bertl> and btw, every 'release' I do, has at least passed basic testing ... if not extensive testing ... 15:56:48< flock_> lol@policy 15:58:56 * sladen fails to find what's so funny about 15:59:17< sladen> Bertl: point taken about testing them... 15:59:42< Bertl> especially as I see absolutely no reason for debian to have a separate vserver kernel ... 16:00:22< Bertl> so when they insist on having a special debianized version, they should at least test it .. and not act like M$ ... 16:01:45< Bertl> flock_: okay, as I see it, either you find the source/lib for __ia64_syscall or the correct name for it, or you recompile the glibc with a higher syscall number ... 16:02:35< Bertl> (or whatever the reason is that syscall() doesn't call it ... 16:02:46< Bertl> btw, what did you say is the version of your strace? 16:03:08< flock_> strace -- version 4.5.3 16:03:29< Bertl> So I extracted sysdep.o from libc.a 16:03:29< Bertl> and I compiled my program with it. This works fine. 16:03:44< Bertl> might be a good idea to try this ... 16:04:39< flock_> hm, i have no clue what does he mean by "extract sysdep.o from libc.a" 16:05:05< Bertl> .a is a library archive, consisting of .o files ... 16:06:23< Bertl> ar can be used to extract the .o files ... 16:06:42< flock_> ok, so i link against that object/ 16:06:56< Bertl> obviously that's what he did ... 16:07:07< Bertl> but I'm still confused about the first message 16:07:14< Bertl> 15:47 < flock_> vflags.c:100: warning: implicit declaration of function 16:07:14< Bertl> `__ia64_syscall' 16:07:34< flock_> yeah 16:07:40< Bertl> because as _you_ said, this is defined in /usr/include/asm/unistd.h ... 16:08:03< Bertl> which is included (around many corners) by the vswitch.h ... 16:14:50< flock_> yeah 16:15:01< flock_> all headers are included properly, i have no clue hats up 16:15:09< flock_> *whats up 16:15:18< flock_> ill check it out when i get back home, i have a major headache 16:15:27< flock_> ill bug the guys from debian about it too 16:15:47< Bertl> okay, let me know if you discover something ... 16:15:57< flock_> alright 16:16:11< flock_> youll be seeing me around alot:P 16:17:43< Shotygun> Bert has anyone tested vserver over non-debian-amd64 ? 16:18:04< Bertl> amd64 was tested some time ago, but I do not know the distro ... 16:18:11< Shotygun> Did it work? 16:18:30< Bertl> yep, IIRC Simon did some testing, we made it work in a few hours ... 16:19:17< Shotygun> I'm debating if I should go with dual amd64 or dual xeon for server I plan to run vservers on.. 16:19:49< Bertl> tough decision ... 16:20:14< Bertl> dual xeon will be 'more' compatible ut dual amd64 might be faster if used properly ... 16:20:23< Shotygun> Exactly 16:20:41< flock_> Bertl: define properly 16:20:57< Bertl> 64bit userspace and libs for example ... 16:20:59< Shotygun> Compiled everything in 64bit 16:21:15< Shotygun> amd64 can be real sweet over LFS/gentoo./ 16:21:16< Shotygun> amd64 can be real sweet over LFS/gentoo. 16:21:45< Shotygun> I got a friend who just bought amd64 and installed gentoo over it, trying to make him test it out =P 16:39:35< flock_> :/ 16:39:39< flock_> see you soon guys 16:39:54< Bertl> cya 16:40:12>> flock_ [~Lior@bzq-166-68.dsl.bezeqint.net] has quit [Quit: Leaving] 16:40:47< Shotygun> Debian should annouce their own OS sooner or later.. 16:40:55< Bertl> yarihm: how do you feel about the 2.6 release? 16:43:45>> click [click@gonnamakeyou.com] has quit [Remote host closed the connection] 16:47:06< Bertl> anybody running 1.9.x here on the channel? 16:49:39< Shotygun> Nope but I was about to test it sooner or later, so I guess I will try it now 16:49:46< Shotygun> downloading 16:51:48< Shotygun> Where did you place the configuration options bert? 16:52:07< Bertl> they are below kernel hacking 16:52:16< Bertl> (actually the next line) 16:53:24< Shotygun> Yeah found it =) 16:53:41< Shotygun> Compiling 16:59:08>> Napalm [~napalm@host81-7-26-228.adsl.v21.co.uk] has joined #vserver 16:59:14< Napalm> hi bert 16:59:21< Bertl> hello Napalm! 16:59:23< Napalm> ive sorted the server out now 16:59:34< Napalm> i need to install the tools now yea? 16:59:50< Napalm> i can't locate the 214 tools? 17:00:01< Bertl> look at the alpha util-vserver page 17:00:27< Bertl> http://linux-vserver.org/ 17:00:34< Bertl> http://www.linux-vserver.org/index.php?page=alpha+util-vserver 17:00:41< Bertl> http://www-user.tu-chemnitz.de/~ensc/util-vserver/alpha/ 17:01:01< Bertl> (and as tar and rpms on the download page where you got the kernel patch ;) 17:01:42< Napalm> the 13thfloor site only has downlaods for 213 17:02:04< Napalm> http://www.13thfloor.at/vserver/d_rel26/v1.9.0/ 17:02:11< Napalm> i just foudn them on there 17:02:12< Napalm> sorry 17:02:26< Bertl> http://www.13thfloor.at/vserver/d_rel26/v1.9.1/ 17:03:25< Napalm> yep 17:03:32< Napalm> i just saw them, sorry 17:03:37< Bertl> np 17:03:50< Napalm> Bert: whats the rpmbuild options to take a tar-bz2 to rpm 17:04:00< Bertl> rpm -tb 17:04:04< Napalm> ty 17:08:03< Bertl> sladen: hmm, any things left in your 'missing stuff for vserver' list? 17:17:21< Napalm> Bert: this is'nt working too many dependencies 17:17:23< Doener`> Bertl: is there a functional replacement for ping that works w/o CAP_NET_RAW? 17:18:21< Bertl> yep, hping2 and ploink (or how it is called) ... 17:18:37< Bertl> but the latest vserver patch allows ping to work ;) 17:18:55< Doener`> hmm... hping2 didn't work 17:19:05< Napalm> Bert: does 1.9.0 let ping work? 17:19:07< Bertl> http://vserver.13thfloor.at/Experimental/delta-2.6.6-vs1.9.1-vs1.9.1.1.diff 17:19:22< Bertl> (with this patch yes) 17:19:48< Bertl> I#m not sure it is secure, but it looks fine to me (for now) 17:20:39< Doener`> [open_sockraw] socket(): Operation not permitted 17:20:39< Doener`> [main] can't open raw socket 17:20:44< Doener`> hping2 on 1.27... 17:21:02< Bertl> try with tcp option ... 17:21:59< Bertl> hmm, tcp seems default ... strange ... 17:25:19< Bertl> they obviously improved it ;) 17:28:09< Bertl> Doener`: anyway if you volunteer to test a patch for 1.27 (regarding security and sniffing) I'm willing to adapt the 1.9.x patch ... 17:29:54< Doener`> hmmm... will probably have to setup another box for production soon anyway... could use that one to test a little... but not before thursday... 17:30:20< Bertl> okay, just let me know ... 17:31:04< Napalm> Bert: im having problems building utils 214 would it be worth instead building 213, whats the advantages between the 2 17:31:27< Bertl> does 213 work for you (the compile)? 17:33:18>> monrad [~monrad@213.83.190.229] has joined #vserver 17:33:34< Bertl> welcome monrad! 17:36:02< Napalm> bert: i hav'nt tried installing 213? should i. Whats the differences? 17:36:27< Bertl> so why do you think that 213 will compile better then? 17:38:44< Napalm> bert: because it may not need the dependencies that 214 has 17:39:05< Bertl> ah I see, wild guessing .. well then try it ... 17:40:00< Napalm> nope 17:40:26< Napalm> its still failing out with 'xalan-j' dependency 17:40:44< Bertl> xalan-j ? 17:40:51< Bertl> sounds interesting ... 17:40:55< Napalm> its seems to be some sort of xml-java framework? im thinking what the hell does vserve utils need that for? 17:41:09< Napalm> its created by apache 17:41:13< Bertl> no idea ... but maybe documentation ... 17:41:23< Napalm> http://xml.apache.org/xalan-j/ 17:41:44< Bertl> but I'm sure that I do not have this beast, and the rpms compiled fine here ... 17:43:10< Napalm> bert: should i try the rpms from 13thfloor 17:43:21< Bertl> yes .. please do so ... 17:43:49< Napalm> do i need all the rpms? 17:44:00< Bertl> only the source rpm (src.rpm 17:44:15< Bertl> you ahve to rebuild it anyway ... 17:45:10< Napalm> then do i have to issue the command 'rpmbuild -tb util-vserver-0.29.214-1mdk.src.rpm' 17:45:27< Bertl> here it is rpm --rebuild <*src.rpm> 17:45:50< Napalm> rpm --rebuild util-vserver-0.29.214-1mdk.src.rpm 17:45:50< Napalm> --rebuild: unknown option 17:45:52< Napalm> lol 17:46:03< Napalm> what else can go wrong :'( 17:46:05< Bertl> redhat 'now' calls it rpmbuild 17:46:49< sladen> Bertl: grep out from /proc/mounts anything that isn't in the local chroot (makes lsof and friends nicer) 17:47:43< Bertl> yep, I know, just atm, we have no way of telling which mounts are for the vserver and which not ... 17:48:11< Bertl> namespaces and the flag to disable /proc/mounts at all should ease that for now ... 17:50:00< Bertl> anything else? 17:50:35< sladen> someway of handling binfmt_misc (to be able to run Mono/.Net code) 17:50:55< Bertl> hmm, is there anybody able to test this? 17:51:29< sladen> test which? 17:51:38< Bertl> binfmt_misc stuff 17:51:53< sladen> apt-get install mono 17:52:01< Napalm> bert its worked 17:52:05< Bertl> $ apt-get install mono 17:52:05< Bertl> bash: apt-get: command not found 17:52:11< Bertl> ;) 17:52:50< Napalm> bert: whats the command to create a vserver 17:52:51< sladen> just like Java, it runs if you do java ./program.java but you can't do ./program.java and have the kernel detect it is a java exec and file up the JVM 17:53:48< Bertl> yeah, I know what_ it is, but I have no use for that ... so I'm currently not willing to test that stuff, maybe I should ask, anybody able _and_ willing to do so? 17:57:22< sladen> I can /test/ it yes. Have it installed on a machine somewhere 17:57:47< sladen> the question is how to allows contexts to maintain their own binfmt views 17:57:47>> chaosle [~yvan@port-212-202-168-55.dynamic.qsc.de] has joined #vserver 17:57:56< chaosle> hi all 17:58:01< Bertl> evening chaosle! 17:58:26< Bertl> sladen: okay any example how you setup the binfmt stuff atm? 17:59:49>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 17:59:54< shuri> hello 18:00:04< Bertl> evening shushushu... 18:00:14< shuri> Bertl got an erreor with your patch 18:00:22< Bertl> yeah, which one? 18:00:58< shuri> delta-2.6.6-vs1.9.1-vs1.9.1.1.diff 18:01:12< Bertl> and which error? 18:01:25< shuri> compil error 18:01:33< shuri> 2 sec 18:03:31< Bertl> you did apply the patch _ontop_ of vs1.9.1, right? 18:04:13< shuri> yes 18:04:26< shuri> but wait it seam to compile fine now 18:06:48 * Bertl .oO( self repairing patches ... wow I'm good ;) 18:08:01< shuri> woot 18:08:02< shuri> :P 18:08:26< Bertl> I have to get that patented immediately ;) 18:09:29< Bertl> okay sladen, any short example for the binfmt setup? 18:11:47>> tanjix [tanjix@c-180-204-102.n.dial.de.ignite.net] has joined #vserver 18:11:50< tanjix> hi together 18:11:53< Bertl> evening tanjix! 18:12:06< Napalm> bert: i think there might be a memory leek in the utils 18:12:26< Bertl> in the utils? 18:12:44< Napalm> since i've installed the tools the memory usage has gone from 17% used to 95% 18:12:59< Napalm> and i have done nothing to the server 18:13:11< Bertl> ah, I see ;) maybe cached files? 18:13:31< Napalm> cached files? 18:13:33< Napalm> ?? 18:13:57< Bertl> well, the linux kernel tends to cache files you accessed ... 18:14:18< Napalm> hmm 18:14:18< Bertl> what does cat /proc/meminfo report? 18:14:29< Napalm> just going to take a look 18:20:13< Napalm> yep everythings fine 18:20:53< Napalm> with the new alpha tools, how do you build a vserver? 18:21:48< Bertl> on the linux-vserver.org page, following the link to the alpha utils ... 18:22:01< Bertl> ... I read: 18:22:12< Bertl> # vserver build -m apt-rpm * -- -d fc1 # for FC1 18:22:19< Bertl> # vserver build -m debootstrap * -- -d sarge # or woody 18:22:42< Napalm> theres no files in /etc/vservers/ at the moment 18:22:42< Bertl> and a little further down .. there is an example for that ... 18:37:47>> Plug [~plug@datadot.net] has joined #vserver 18:38:08< Bertl> aloha Plug! 18:38:12< Plug> hi 18:38:17< Bertl> dinner time ... back in 20 ... 18:38:21>> Bertl is now known as Bertl_oO 18:39:34< Napalm> hi plug 18:41:12< Plug> hi 18:46:58>> Sebastian^aw is now known as Sebastian 18:59:33>> Bertl_oO is now known as Bertl 18:59:52< Napalm> wb Bert 19:00:05< Bertl> tx Napalm! 19:00:42< Napalm> my friend Plug is in the channel 19:00:49< Napalm> hes the guy that rebuild the kernel 19:01:03< Bertl> wow, plug, you can rebuild a kernel? 19:02:08< Napalm> well you know what i mean bert 19:02:44< Napalm> he recompiled it sucessfully, unlike me :$ 19:02:46< FD_LIMIT> i Will cut off your johnson Shotygun!! you left my production with samba running!!! :) 19:03:16< Bertl> FD_LIMIT: but sharing is nice, isn't it? 19:04:08< FD_LIMIT> haha 19:04:27< FD_LIMIT> i am running out of descriptors here ;=P 19:06:07>> FD_LIMIT is now known as fdlimit 19:06:34< fdlimit> that cap sure made it look ugly 19:07:19< Bertl> definitely but I mentioned that earlier (just not so directly) 19:14:02< fdlimit> ohaa, i just didnt watch it sorry mate 19:14:26< Bertl> nothing to be sorry about ... we have free choice of nicks here ;) 19:19:19< Sebastian> hi Bertl 19:20:23< Bertl> hey Sebastian! 19:23:30>> click [click@gonnamakeyou.com] has joined #vserver 19:23:38< shuri> Bertl compil almost finish 19:23:47< shuri> 200 Mhz 19:23:47< shuri> lol 19:26:05< shuri> rebbot 19:26:06< shuri> brb 19:27:08>> Napalm [~napalm@host81-7-26-228.adsl.v21.co.uk] has quit [Ping timeout: 480 seconds] 19:29:56>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Quit: http://base2091.com] 19:30:07>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 19:30:16< shuri> re 19:30:19< shuri> PING yahoo.com (66.218.71.114): 56 data bytes 19:30:19< shuri> 64 bytes from 66.218.71.114: icmp_seq=0 ttl=49 time=95.0 ms 19:30:19< shuri> 64 bytes from 66.218.71.114: icmp_seq=1 ttl=49 time=92.9 ms 19:30:20< shuri> :P 19:30:33< shuri> congratulation Bertl 19:30:40< Bertl> thankyou! 19:31:17< eyck> what happened just now? 19:32:19< Bertl> magic, done by myself, tested by shuri ;) 19:32:31< shuri> haha 19:33:19< eyck> well, I expected nothing less then magic... 19:33:47< Bertl> I did a tiny patch to allow ping to work inside a context ... 19:33:57< Sebastian> does anyone now if vserver acutally run on the ia64 system from this morning? 19:34:15< eyck> hmm, so I don't need to package poink anymore? 19:34:17< Bertl> yep, and the answer is not-yet 19:34:38< Bertl> eyck: no, it is untested, it might be a security hole ,... 19:34:39< eyck> hmm, how does this tiny patch work then? 19:34:56< Bertl> Sebastian: yep, and the answer is not-yet 19:34:58< eyck> hmm, - you're not allowing raw sockets? 19:35:09< Sebastian> yes Bertl i´m read it :) thx 19:35:16< Bertl> eyck: I'm allowing raw icmp sockets ... 19:35:37>> Napalm [~napalm@host81-7-20-161.adsl.v21.co.uk] has joined #vserver 19:35:40< eyck> this is for 2.6.6 and 1.9 ? 19:35:46< shuri> yep 19:35:56< Bertl> yep, but it also works on 1.27 ... 19:36:27>> _id [~id@pD9E6122D.dip.t-dialin.net] has quit [Ping timeout: 480 seconds] 19:42:24< shuri> Bertl 19:42:39< shuri> do you know how to make suse rc init work 19:46:02>> _id [~id@pD9E6109E.dip.t-dialin.net] has joined #vserver 19:46:23< Bertl> shuri: no idea ... 19:49:18< shuri> :( 19:56:41>> iceberg [~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net] has joined #vserver 19:58:29>> iceberg [~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net] has left #vserver [] 20:00:21< shuri> so nobody use suse 9.1 as vserver 20:02:31< maharaja> i only know 1 who is using suse for something 20:04:14< shuri> k 20:04:23< shuri> and how he di that 20:04:51< maharaja> how did he do what.. 20:04:59< maharaja> he installed the os and is using it 20:05:23< shuri> vserver suse start 20:05:30< shuri> pen(): No such file or directory 20:05:30< shuri> secure-mount: chdir("proc"): No such file or directory 20:05:30< shuri> Failed to mount fstab-line beginning with 'none' 20:05:30< shuri> secure-mount: chdir("tmp"): No such file or directory 20:05:30< shuri> Failed to mount fstab-line beginning with 'none' 20:05:31< shuri> secure-mount: chdir("dev/pts"): No such file or directory 20:05:31< shuri> Failed to mount fstab-line beginning with 'none' 20:05:33< shuri> find: var/run: Aucun fichier ou répertoire de ce type 20:05:33< shuri> fakerunlevel: open("/var/run/utmp"): No such file or directory 20:05:38< shuri> Failed to start vserver 'suse' 20:05:57< maharaja> no, i ment that i don't know anyone who is using suse in any way - except for one guy 20:06:25< maharaja> for most ppl i know think that other distributions are a better choice 20:06:48< maharaja> but it seems like you miss some proc stuff 20:07:07< maharaja> which seems like a setup proble, 20:07:11< maharaja> problem 20:07:33>> _shuri_ [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 20:07:39< _shuri_> arff 20:07:42< maharaja> you should check if proc is correctly mounted and /dev/pts and /var/run exists 20:07:46< maharaja> 05/23 20:05:57| no, i ment that i don't know anyone who is using suse in any way - except for one guy 20:07:46< maharaja> 05/23 20:06:25| for most ppl i know think that other distributions are a better choice 20:07:46< maharaja> 05/23 20:06:48| but it seems like you miss some proc stuff 20:07:46< maharaja> 05/23 20:07:06| which seems like a setup proble, 20:07:48< maharaja> 05/23 20:07:11| problem 20:07:52>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Read error: Connection reset by peer] 20:07:52>> _shuri_ is now known as shuri 20:07:53>> fdlimit [~fdlimit@212.143.247.3] has quit [Read error: Connection reset by peer] 20:08:00>> fdlimit [~fdlimit@212.143.247.3] has joined #vserver 20:08:14< shuri> An error occured while executing the vserver startup sequence; when 20:08:14< shuri> there are no other messages, it is very likely that the init-script 20:08:14< shuri> (/etc/rc.d/rc 3) failed. 20:08:33< shuri> Common causes are: 20:08:33< shuri> * /etc/rc.d/rc on Fedora Core 1 and RH9 fails always; the 'apt-rpm' build 20:08:33< shuri> method knows how to deal with this, but on existing installations, 20:08:33< shuri> appending 'true' to this file will help. 20:08:39< shuri> that is the prblem 20:09:09< maharaja> i can only guess that your setup went wrong 20:09:23< maharaja> and your missing /dev/xxxxx and other files/directories 20:09:32< maharaja> gotta go 20:17:31< Bertl> cya maja 20:26:26>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Read error: Connection reset by peer] 20:52:49< Bertl> cdub: hmm, are you around? 21:01:32< Sebastian> bertl do you know the problem from yesterday with the primary and secondary ip? 21:01:53< Bertl> hmm, it wasn't a problem, but yes ... 21:01:58< Sebastian> now i have a server when i add an ip as an "dummy" it will also be only a secondary ip 21:02:47< Bertl> yep, secondaries are good ... primaries are bad .... 21:03:41< Sebastian> hmmm ok mom 21:08:04< Bertl> ahh, I see heping tanjix a little ... ;) 21:08:51< Sebastian> ;) 21:15:01< yarihm> Bertl: sorry, was gone for some hours ... i can't say much about 2.6 and vserver, i've not yet tested it. i run vserver on 2 machines, one to old to need 2.6 and the other to important to try 2.6 ... but so what, i gonna test it. someone has to provide feedback after all ;) 21:15:32< Bertl> that's the spirit! 21:37:08>> infowolfe [~infowolfe@pcp04891550pcs.frnkmd01.md.comcast.net] has quit [Read error: Connection reset by peer] 22:10:28>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 22:10:38< shuri> re 22:10:54< shuri> anybody use alpha tools here 22:10:57< Bertl> wb shuri! 22:11:20< shuri> thx Bertl 22:11:46< shuri> Bertl do use understand why NAt connection stop after stoping a vserver 22:12:32< Bertl> if I parse you right, you have some issues with nat not working after a vserver is taken down, right? 22:12:45< shuri> yes 22:13:08< shuri> if i parse you right lol 22:13:10< Bertl> is this nat related to that specific vserver, or is it on the same interface for whatever reason? 22:13:13< shuri> this is funny 22:13:43< shuri> same interface yes 22:13:55< shuri> but the nat rules are in the host. 22:14:20< shuri> this only happen with alpha 22:14:26< Bertl> certainly ... the question is, might this be the 'well known' vserver gets primary address problem? 22:16:46< shuri> well with aplha you got to specified dev and ip 22:17:39< Bertl> okay, I assume you can 'reproduce' this with rebooting your machine, taking down a specific vserver and loosing nat, right? 22:17:45< Bertl> -o 22:17:59< shuri> yes 22:18:32< Bertl> okay, just before you take down the vserver, could you do a 'ip addr show' and /msg it to me inprivate? 22:22:23>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Quit: http://base2091.com] 22:22:34>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 22:26:33>> Sebastian [~cereal@pD9EAB701.dip.t-dialin.net] has quit [Quit: ] 22:26:58>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has quit [Quit: ] 22:27:09>> shuri [~shushushu@cpu183.adsl.qc.bellglobal.com] has joined #vserver 22:33:35< Napalm> hi bert 22:33:45< Bertl> hi Napalm, what's up? 22:55:19< Napalm> i dont think the vserver utils have installed correctly 22:55:35< Bertl> hmm, how did you install them? 22:55:43< Bertl> and did you remove 'old' leftovers? 22:55:51< Napalm> yes 22:57:02< Napalm> ok im removing the rpms and going again with verbose 22:57:31< Bertl> you recompiled the mdk rpms right? 22:57:35< Napalm> yes 22:57:49< Bertl> this is on redhat, or? 22:57:56< Napalm> redhat9 22:58:18< Bertl> it might be that the layout isn't correct .. but basically it should work ... 22:58:34< Bertl> what issues do you see with the tools anyway? 22:59:09< Napalm> give me a moment to look at these things 22:59:21< Bertl> okay, take your time ... 23:00:15>> tanjix [tanjix@c-180-204-102.n.dial.de.ignite.net] has quit [Quit: ] 23:02:28< Napalm> the util-vserver-alpha install has created /etc/vservers.conf and /vservers directory 23:04:19< Napalm> and the util-vserver-alpha extra files have been installed to /usr/lib/util-vserver 23:05:05< Bertl> sounds good to me so far ... 23:05:45< Napalm> where would i change the vservers root ? from /vservers to /vs 23:05:56< Napalm> i cant seem to find util-vserver-vars 23:06:12< Napalm> i guess its a different file in the latest alpha tools 23:06:37< Bertl> should be there in /usr/lib/util-vserver/util-vserver-vars 23:06:59< Bertl> # rpm -qf /usr/lib/util-vserver/util-vserver-vars 23:06:59< Bertl> util-vserver-core-0.29.214-1mdk 23:07:07< Napalm> found it 23:07:29< Napalm> i was'nt looking hard enough 23:07:38< Bertl> np 23:07:56< Napalm> ok should there be any other default config files 23:08:47< Bertl> like? 23:10:06< Napalm> hmm 23:12:36< Napalm> so this command should work 'vserver fd915 build -m apt-rpm --hostname fd915.mydomain.com -- -d rh9' 23:13:50< Bertl> yep, if rh9 is a known build system, and you do not want any ips ... 23:14:26< Bertl> rh9 seems valid 23:14:33< Bertl> (had to look it up) 23:15:35< Napalm> oopsy 23:15:36< Napalm> k 23:16:24< Napalm> so 'vserver fd915 build -m apt-rpm --hostname fd915.mydomain.com --netdev eth0 --interface -- -d rh9' 23:17:05< Bertl> yep, using a static context would also be a good idear ... 23:17:16< Bertl> --context 100 for example ... 23:33:10< Napalm> bert: do you think that glibc would be resolved by updating to the latest version 23:33:17< Napalm> current i have glibc-2.3.2-27.9.7 installed 23:33:33< Bertl> resolved by what? apt-rpm? 23:34:38< Napalm> i mean install the latest glibc build onto the host server 23:34:54< Napalm> has 'vserver build' errors out with 'E: Couldn't find package glibc' 23:35:24< Bertl> on a vserver build the dependancies are from the apt-rpm repository only ... 23:36:33< Napalm> so where is the error coming from? 23:37:00< Bertl> most likely from a bad dependancy in the apt-rpm repository ... 23:37:07< Napalm> i'll try building a skeleton vserver 23:40:23< Napalm> now i get '/usr/lib/util-vserver/distributions/rh9/initpost: line 53: sysconfig/network: No such file or directory' 23:40:34< Napalm> this seems nothing but a nightmare 23:40:34< Napalm> lol 23:41:00< Bertl> you are now using 1.9.x? 23:41:08< Napalm> yep 23:41:21< Napalm> uname -r give back 2.6.6-vs1.9.0 23:41:37< Bertl> start with the stable tools, then try to understand the new alpha tools, then switch to using them ... 23:42:43< Napalm> ive used the stable tools? 23:43:06< Bertl> this is now 0.29.214 right? 23:43:12< Napalm> yes 23:43:29< Bertl> start with 0.29.5 (old style, you should know them already, right?) 23:43:36< Napalm> yes 23:43:40< Napalm> ok --- Log closed pon maj 24 00:00:49 2004