1131321610 M * Bertl dos000: it is the stable branch, so it contains only fixes over 2.0 1131321762 M * Bertl dos000: of course, the 2.0 release probably was tested more than the 2.0.1 rc ... 1131321820 M * dos000 Bertl, is the rc1 linked anywhere .. or one has to get via cvs 1131321837 M * Bertl no cvs, the url above :) 1131321876 M * dos000 that patch would be aplied after the 2.0 patch then ? 1131321893 M * Bertl no, the patch is ontop of vanilla 2.6.14 ... 1131321900 M * dos000 good 1131321976 M * dos000 is there a .config file you could share ? 1131321989 M * Bertl sure, what do you need it for? 1131322023 M * Bertl http://vserver.13thfloor.at/Stuff/QEMU/2.6.13-vs2.0.1.config 1131322049 M * dos000 this is for a dell poweredge machine. just standard stuff. but i need one with sata,raid support as well 1131322059 M * Greek0 Bertl: Documentation/vserver/debug.txt contains non-ascii chars, line 95 or so. The 2 french quotes. is this intended? 1131322072 M * Bertl dos000: well, then I won't use the one above, which works great in QEMU :) 1131322115 M * dos000 Bertl, testing with qemu must be a pain ! 1131322123 M * Bertl Greek0: yes, and your aptch contains them as UTF8 :) 1131322141 M * dos000 Bertl, did you try the new vmware freeware player 1131322142 M * Greek0 hmm, I already noticed the diff 1131322144 M * Bertl dos000: no, it's great! 1131322162 M * Bertl dos000: QEMU has a lot of features vmware hasn't 1131322168 M * dos000 i never tried qemu 1131322188 M * Bertl dos000: so why do you assume that vmware is better then? 1131322237 M * dos000 i guess based on false assumption 1131322258 M * Bertl ah, okay .. :) 1131322335 M * Greek0 well, IMHO it just depends on what you want to do with your vm. if you want to run windows or something thelike, vmware is probably a better idea then qemu. for kernel testing and lowlevel stuff qemu is really nice due to the good gdb integration 1131322374 M * Bertl and not to forget the console mode! := 1131322423 M * Greek0 Bertl: It took me several hours to figure out how your qemu config worked and how I could use it sanely with qemu. then it rocked however ;) 1131322506 M * Greek0 but, what I wanted to ask, don't you want to get rid of those french quotation marks? 1131322513 M * michal_ qemu is great for kernel developing ! 1131322589 M * Greek0 - 1131322597 M * Bertl Greek0: no, I don't have anything against the french ... 1131322607 M * Bertl ... quotation marks :) 1131322613 M * Greek0 hehe 1131322634 M * Bertl no, seriously, they are a good choice for string delimiters 1131322650 M * Bertl (in debug messages) 1131322684 M * Greek0 hmm so since they are in debug messages you don't really care if they show up perfectly in every locale i guess? 1131322743 M * Bertl no, but in iso 8859-1 and -15 they are fine 1131322787 M * Greek0 yep, ok 1131322789 M * Bertl Greek0: if you have a better suggestion, please be my guest 1131322919 M * Greek0 well, they are non-ascii which is a bit disturbing (and apparently they got converted to unicode here for some strange reason), but your're right that they make good string delimiters, and I don't have a spontanous idea what to use instead 1131323040 M * Bertl dos000: oh, and I forgot, qemu supports many different platforms 1131323290 M * dos000 aha 1131323313 M * Bertl i.e. I can run a ppc kernel on x86 and vice versa ... 1131323382 M * Aiken finally, Linux pebbles.bedrock 2.6.14-vs2.1.0-rc6 #1 Mon Nov 7 10:17:44 EST 2005 alpha Unknown Alcor GNU/Linux 1131323390 M * Bertl ah, great! 1131323442 M * Aiken I think you mentioned testing something with guests, a real guest or will a cow guest suffice? 1131323457 M * Bertl both should be fine, it's the sem accounting 1131323473 M * Bertl should show up in /proc/virutal/*/limits 1131323491 M * Bertl and I guess you have debugging enabled, yes? 1131323538 M * Aiken debugging is enabled 1131323672 M * Aiken SEMA: 0 0 9223372036854775807 0 1131323673 M * Aiken SEMS: 0 0 9223372036854775807 0 1131323828 M * Bertl hmm, does -1 look so funny for all limits? 1131323923 M * Aiken http://pastebin.com/420050 1131323962 M * Bertl aha, tx, looks like an alpha or 64bit issue ... checking now 1131324097 M * Bertl Aiken: do you know, did that happen before too? 1131324107 M * Bertl (I mean with older kernels) 1131324132 M * Aiken is pre5 old enough? easy enough to check 1131324146 M * Bertl no wait, give me minute to check myself 1131324394 M * Bertl yup, seems to be since ever ... 1131324478 M * Bertl aside from that, you guests seem not to use any semaphores, yes? 1131324496 M * Bertl no apache running inside? 1131324534 M * Aiken syslogd and sshd 1131324550 M * Bertl okay, that explains the 0 sem 1131324625 M * Aiken 1023 49152 hoppy ? S 0:00 syslogd -m 0 1131324626 M * Aiken 1032 49152 hoppy ? S 0:00 sshd 1131324639 J * lonewolf1 ~lonewolff@host86-128-133-145.range86-128.btcentralplus.com 1131324646 M * Bertl welcome lonewolf1! 1131324710 M * Bertl Aiken: interesting: procfs shows: 7FFFFFFFFFFFFFFF (9223372036854775807) but CRLIM_INFINITY is defined as (~0ULL) 1131324742 M * Bertl and I'm pretty sure (~0ULL) != 7FFFFFFFFFFFFFFF, even on alpha :) 1131324757 M * Aiken pre5 is the same 1131324773 M * Aiken SHM: 0 0 9223372036854775807 0 1131324793 M * Bertl yep, the interesting detail is: 1131324806 M * Bertl I use VX_LIMIT_FMT ":\t%10d\t%10ld\t%10ld\t%6d\n" 1131324816 M * Bertl which uses %d (i.e. signed) 1131324821 Q * lonewolff Ping timeout: 480 seconds 1131324920 M * Bertl Aiken: do you want to investigate? 1131325035 M * Aiken just trying older kernels I still have 1131325113 M * matti Bertl: Hi. 1131325119 M * Bertl hey matti! 1131325150 M * matti Bertl: I cannot enable HT on that machine, what we spoke of yesterday :< 1131325186 M * Bertl hmm, no bios option? 1131325205 M * matti Yep. Seems so. 1131325205 M * matti ;/ 1131325219 M * Bertl maybe a bios update? 1131325221 M * Aiken 2.6.13.3-vs2.1.0-rc4 http://pastebin.com/420072 1131325277 M * matti Bertl: There's no newest version available. 1131325287 M * matti Bertl: I've the lastest. 1131325317 M * matti s/lastest/latest/ 1131325324 M * matti Gosh, I'll kill my cat. 1131325355 M * Bertl that would be a cat-astrophy :) 1131325374 M * matti ;-p 1131325385 M * michal_ ;p 1131325387 M * Bertl Aiken: okay, if you like to investigate, let's add a printk 1131325394 M * Aiken ok 1131325395 M * matti Oh, michal_ :) 1131325402 M * michal_ matti: your cat almost eat few people ;] 1131325411 M * matti michal_: Including you, IIRC. 1131325412 M * matti :> 1131325414 M * michal_ yep 1131325418 M * michal_ she gave up ;p 1131325433 M * Bertl Aiken: kernel/vserver/limit_proc.h vx_info_proc_limit() ~line 29 1131325440 M * michal_ including bitting dsoul leg 1131325449 M * Bertl Aiken: right after vx_limit_fixup(limit); 1131325463 M * Bertl let's add the following: 1131325464 M * michal_ and including jumping straight on his head ;p 1131325501 M * matti michal_: Oh well. 1131325536 M * matti michal_: I nerver said, that my cat is mentally healthy. 1131325539 M * michal_ Bertl: btw, have done quick (well, ok, everything but ont quick, 22 reject fixed by hand with vim :/) hack, rsbac + vserver. it managed to boot and i think it was even working (not had too much time to test it and i have broke my rsbac instalation) 1131325586 M * matti michal_: I am not mentally healthy, so... ;-p 1131325588 J * sannes ~ace@simula-dhcp-084.simula.no 1131325599 M * michal_ well, you are... yourself ;p 1131325616 M * matti Bertl: I'll try downgrade BIOS to previous version. 1131325618 M * Bertl printk(" ld=%ld, lu=%lu - ld=%ld, lu=%lu\n", limit->rmax[RLIMIT_AS], limit->rmax[RLIMIT_AS], CRLIM_INFINITY, CRLIM_INFINITY); 1131325771 M * Aiken whereis CRLIM_INFINITY defined? 1131325782 M * Aiken kernel/vserver/limit_proc.h:30: error: `CRLIM_INFINITY' undeclared (first use in this function) 1131325843 Q * monrad Remote host closed the connection 1131325854 M * Aiken got it compiled 1131325863 M * Bertl hmm, okay, you need to include linux/vserver/limit_cmd.h 1131325869 M * Bertl *sorry* 1131325870 M * Aiken already have :) 1131325904 M * Aiken grep CRLIM_INFINITY include/ -r told me what I needed to know 1131325975 J * ntrs ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com 1131326303 J * Aiken_ ~james@tooax6-029.dialup.optusnet.com.au 1131326331 M * Aiken_ ld=2131, lu=2131 - ld=-1, lu=18446744073709551615 1131326332 M * Aiken_ ld=2131, lu=2131 - ld=-1, lu=18446744073709551615 1131326351 M * Bertl ah, damn, got it wrong :/ 1131326372 M * Bertl *sorry again* 1131326389 M * Bertl we want limit->rlim instead of limit->rmax 1131326497 M * Bertl but it clarifies that the value is written correctly 1131326527 M * Aiken_ what about 18446744073709551615? 1131326537 M * Bertl that's the unsigned version 1131326548 M * Bertl FF...FFF 1131326553 M * Aiken_ ok 1131326563 J * jazzanova foobar@S0106000f3d018f36.vc.shawcable.net 1131326564 M * jazzanova hi 1131326570 M * Bertl welcome jazzanova! 1131326626 M * jazzanova i want to install vserver on ubuntu 1131326626 Q * Aiken Ping timeout: 480 seconds 1131326635 M * jazzanova do i need to compile a kernel ? 1131326647 M * mnemoc yes 1131326662 M * mnemoc linux-vserver is a kernel patch 1131326663 M * jazzanova http://linux-vserver.org/UbuntuVserverHowTo 1131326668 M * jazzanova these instructions ? 1131326691 M * mnemoc seem so 1131326743 M * Aiken_ ld=9223372036854775807, lu=9223372036854775807 - ld=-1, lu=18446744073709551615 1131326744 M * Aiken_ ld=9223372036854775807, lu=9223372036854775807 - ld=-1, lu=18446744073709551615 1131326790 M * Bertl okay, so the value is truncated somewhere ... 1131326855 M * Bertl ah, no ... lol, interesting ... 1131326891 M * Bertl 0 include/asm-alpha/resource.h 18 #define RLIM_INFINITY 0x7ffffffffffffffful 1131326891 M * Bertl 1 include/asm-generic/resource.h 57 #define RLIM_INFINITY (~0UL) 1131326891 M * Bertl 2 include/asm-mips/resource.h 31 #define RLIM_INFINITY 0x7fffffffUL 1131326891 M * Bertl 3 include/asm-sparc/resource.h 22 #define RLIM_INFINITY 0x7fffffff 1131326913 M * Bertl so 'some' archs define infinity different ... 1131326931 M * Bertl probably because of easier comparisons ... 1131326961 M * Bertl let me work out a proper mapping/output for that ... 1131327140 M * jazzanova i have 2.6.10 kernel running. 1131327148 M * Greek0 Bertl: iirc there were some comments about compatibility or so, as reason for the 7f* stuff 1131327151 M * jazzanova should i stick to it, or get 2.6.11 as perdirections ? 1131327172 M * Aiken_ but there are even different values used for COMPAT_RLIM_INFINITY 1131327656 M * jazzanova so what kernel do i need to have to use the latest version of patches ? 1131328050 M * Bertl Greek0: pointers? 1131328071 M * Bertl Aiken_: let#s try something on the running alpha kernel, shall we? 1131328134 M * Bertl if so, prepare the following: a) two consoles, one with an ssh logon to a running guest, the other on the host 1131328166 M * Aiken_ yes 1131328180 M * Bertl b) a simple limited forkbomb 1131328199 M * Bertl (i.e. soemthing which forks 10 times, but stops then) 1131328223 M * Bertl guess a bash loop like that should do the trick: 1131328242 M * Bertl for n in `seq 1 10`; do sleep 10 & done 1131328302 M * Aiken_ guest, host, both? 1131328310 M * Bertl just for the guest 1131328316 M * Bertl and don#t start it yet :) 1131328362 M * Bertl then use the vlimit command to set the limit for nproc to unlimited 1131328409 M * Bertl vlimit --xid -H --nproc inf 1131328426 M * Bertl (should work) 1131328432 M * Greek0 Bertl: include/asm-alpha/resource.h for example 1131328448 M * Bertl Aiken_: check with /proc/virtual/*/limits that it now shows -1 1131328468 M * Bertl (the vlimit on the host) 1131328478 M * Aiken_ 9223372036854775807 1131328488 M * Aiken_ proc -1 1131328506 M * Bertl ah, so the proc now shows -1 ? 1131328510 M * Aiken_ yes 1131328519 M * Bertl excellent, now let's try the fork bomb 1131328546 M * Bertl (inside the guest) 1131328555 M * Aiken_ already don't that, nothing stage happened 1131328576 M * Aiken_ no errors, no strange behaviour 1131328578 M * Bertl okay, great, so the limit doesn't hurt the checks 1131328603 M * Bertl in which case we simply switch from the RLIMIT default to the CRLIM one 1131328651 M * Bertl Greek0: any ideas if the same would hurt mips? 1131328774 M * Bertl or should we add _another_ mapping to the proc print? 1131328794 M * Bertl personally I don't see a good reason for doing so ... 1131328806 M * Bertl (the 'backwards' compatibility does not affect us) 1131328947 M * Greek0 so you wouldn't use the official RLIM_INFINITY constant for all the vserver limit/accounting stuff but instead CRLIM_INFINITY, which is vserver-only? 1131328961 M * Bertl yep 1131328974 M * Bertl 5 places currently 1131329033 M * Bertl one of them would be eliminated 1131329034 M * Greek0 don't see why that would hurt 1131329091 M * Bertl okay, then let's do that, wanna do the patch? 1131329251 M * Greek0 ok 1131329845 Q * lonewolf1 Read error: Connection reset by peer 1131329871 M * Greek0 hmm 1131329909 M * Greek0 rlim/rmax sind unsigned long, da kann ich nicht wirklich n' CRLIM_INFINITY reinpacken 1131329916 M * Greek0 außer ich mach uint64_t draus 1131329950 M * Greek0 arg sorry for the language 1131330027 M * Bertl translation: "rlim/rmax are unsigned long, no chance to store a CRLIM_INFINITY there 1131330029 M * Greek0 the problem is that rlim/rmax are defined as unsigned long, while CRLIM_INFINITY is defined as ~0ULL -> unsigned long long. 1131330084 M * Bertl shouldn't ~0ULL be converted to the proper value? 1131330098 M * Bertl hmm, probably not ... 1131330105 J * lonewolff ~lonewolff@host86-128-133-145.range86-128.btcentralplus.com 1131330132 M * Greek0 I think if I do unsigned long i = (unsigned long long)-1; I get at least a compiler warning 1131330230 M * Greek0 a.c:4: warning: large integer implicitly truncated to unsigned type 1131330235 M * Bertl yep 1131330244 M * Bertl well, we could explicitely trucate it 1131330257 M * Bertl but we should do that in a define, no? 1131330279 M * Greek0 #define CRLIM_INFINITY (~0UL)? 1131330293 M * Bertl no, that would break the userspace interface 1131330299 M * Bertl I though about something like: 1131330329 M * Bertl #define RRLIM_INFINITY ((unsigned long) CRLIM_INFINITY) 1131330335 M * Aiken_ Greek0 I don't get a compiler warning with that statement, a std gcc 3.3.6 1131330360 M * Bertl or probably better #define RRLIM_INFINITY (~0UL) 1131330378 M * Greek0 Aiken_: I do on 3.3, 3.4 and 4.0 1131330386 M * Bertl but that would require an additional mapping so I guess that's not the best idea 1131330387 M * Greek0 3.3.6 too 1131330388 M * Aiken_ correction, on x86 I get the warning, on alpha no warning 1131330398 M * Bertl Aiken_: yes, alpha is 64bit long 1131330433 M * Greek0 got to buy amd64 soon now, I want a 64bit arch too 1131330498 M * Bertl Greek0: okay, so we now know _why_ it's a bad idea to do so :) 1131330570 M * Bertl let's think about alternative solutions 1131330588 M * Bertl if possible, avoiding the complete userspace mapping 1131330653 M * Bertl if we define the RLIM_INFINITY as -1ULL 1131330671 M * Bertl (just for our cases) what would the compiler say? 1131330680 M * Bertl sorry -1LL 1131330684 M * Greek0 hmm. the only problem with the current implementation using RLIM_INFINITY are that it looks nasty in /proc and in the debug outputs, or am I missing something? 1131330705 M * Bertl Greek0: also missing checks for 'over' limit on back conversion 1131330728 M * Bertl and of course, setting the limit to inf (as aiken did via usersapce) will screw up INF checks 1131330743 M * Greek0 hu? 1131330760 M * Bertl from userspace, you can set it to CRLIM_INFINITY 1131330771 M * Bertl which is != RLIM_INFINITY 1131330775 M * Greek0 mm 1131330788 M * Bertl so we need a mapping there too 1131330797 M * Bertl basically it could be done with two mappings 1131330813 M * Bertl one from CRLIM_INFINITY -> RLIM_INFINITY (on set) and the other way on proc 1131330818 M * Greek0 is _vx_limit part of the userspace api? 1131330838 M * jazzanova trying to compile vserver tools: 1131330839 M * jazzanova checking for C++ compiler default output file name... configure: error: C++ compiler cannot create executables 1131330839 M * jazzanova See `config.log' for more details. 1131330846 M * jazzanova thats a ./configure error. 1131330859 M * Bertl Greek0: no, but changing it to uint64_t is not a good idea 1131330860 M * Greek0 jazzanova: can you put config.log online somewhere? 1131330876 M * Bertl jazzanova: what g++ do you have installed? 1131331042 M * jazzanova http://cambie.boris.reitman.name:9988/~boris/config.log 1131331065 M * jazzanova 3.3 1131331074 M * jazzanova ii g++-3.3 3.3.5-8ubuntu2 The GNU C++ compiler 1131331080 M * jazzanova kernel compilers fine. 1131331094 M * Bertl well, the kernel is not c++ .. :) 1131331101 M * jazzanova ah :) 1131331106 M * Bertl but the gcc should be fine 1131331128 M * Bertl maybe a gcc lib is missing? stdlibc++? 1131331134 A * Greek0 realizes that config.log is a lot less informative that I had hoped 1131331154 M * Bertl g++: command not found 1131331160 M * Bertl that's pretty descriptive :) 1131331183 M * Greek0 and that's even while I'm wearing my glasses 1131331185 M * Greek0 *sigh* 1131331190 M * matti jazzanova: Dude, do you have compiler? 1131331219 M * Bertl jazzanova: try c++ and g++ on the commandline 1131331239 M * matti jazzanova: Core tests in your log shows, that you don't have such one. 1131331254 M * jazzanova bah :) 1131331262 M * jazzanova weird. 1131331267 M * matti Maybe. 1131331270 M * jazzanova i dont have it 1131331288 M * jazzanova how can this be ? dpkg is broken ? 1131331299 M * matti jazzanova: Debian? 1131331305 M * Bertl jazzanova: hmm, maybe you removed them? 1131331311 M * jazzanova it sais 'ii' 1131331325 M * matti jazzanova: Even more. 1131331343 M * matti jazzanova: You don't have any tool that is required to compile anything. 1131331390 M * Greek0 jazzanova: it could depend on what version of ubuntu you have 1131331393 M * Bertl matti: now that you say it, looks pretty funny ... 1131331394 M * jazzanova ok, working now. 1131331406 M * matti Bertl: Hm? 1131331419 M * Bertl jazzanova: what was the reason? 1131331425 M * Greek0 if g++-4.0 is already your default compiler, the g++-3.3 package doesn't ship the /usr/bin/g++ symlink any more 1131331443 M * jazzanova now the error is that it can't find vconfig tool. 1131331455 M * jazzanova i thought thats why I am compiling it, to get the vconfig tool. 1131331458 M * Bertl which is probably not installed 1131331468 M * Bertl no vconfig is not part of util-vserver 1131331475 M * jazzanova ah 1131331477 M * Bertl it is part of the vlan tools 1131331481 M * matti Yeah. 1131331524 M * Bertl jazzanova: so what was the issue before? 1131331524 M * matti Greek0: Does Ubuntu provide gcc-config? 1131331544 M * jazzanova i didn't have g++, althought dpkg reported thati have it. 1131331550 M * matti ;-p 1131331556 M * jazzanova ah... 1131331563 M * jazzanova greek: i see. 1131331574 M * jazzanova i had g++-3.3 but nto the g++ package. 1131331579 M * jazzanova symlink thing. 1131331634 M * Greek0 jazzanova: ah yea. g++ ships the /usr/bin/g++ symlink, so you need that too, not only the actual compiler package 1131331652 M * jazzanova ok, it looks i need the kernel withthe patch before I can compile the vserver tools. 1131331677 M * Bertl actually, no, util-vserver 0.30.209 should compile without, no? 1131331678 M * matti :) 1131331734 M * Bertl jazzanova: but it doesn't hurt to compile it with the proper kernel 1131331826 M * Greek0 Bertl: well, vc_get_rlimit already has the RLIM->CRLIM mapping. vc_set_rlimit however doesn't 1131331915 M * Greek0 which is quite interesting, since in vc_set_rlimit vc_data.maximum is just stored into rlim.. 1131331951 M * Bertl yup, that's what I meant 1131332114 M * Bertl okay, I'll prepare a patch ... 1131332114 M * jazzanova i have to do a blind reboot onthe machine 1131332122 M * jazzanova with the newly compiled kernel. 1131332125 M * Bertl that's never good ... 1131332144 A * Aiken_ is an example of that 1131332145 M * jazzanova i just did one, upgrading from 6.10 to 6.11 and got lucky 1131332158 N * Aiken_ Aiken 1131332161 M * jazzanova now, 6.11 to 6.11 vserver 1131332163 M * Bertl no serial console? at least add panic=60 or so, and make sure that your bootloader has a fallback/one time only boot 1131332166 M * Greek0 what would be the big drawback of making _vx_limit.rlim ull? except of being generally nasty on 32 bit archs? (slower, more mem?) 1131332177 J * jebba ~jebba@c-67-172-138-172.hsd1.co.comcast.net 1131332187 M * jazzanova Bertl: oh, interesting. 1131332191 M * Bertl welcome jebba! 1131332195 M * jazzanova it is a grub thing ? 1131332201 M * Bertl Greek0: especially the slower part on _every_ check 1131332217 M * jazzanova it is a collocated server. 1131332225 M * jazzanova dedicatednow.com 1131332239 M * Bertl grub and lilo both are able to do a one time boot 1131332246 M * jazzanova very good deal, 80$ a month, for dedicated 2.2 ghz 1131332246 M * Bertl although it's easier with lilo 1131332272 M * Greek0 Bertl: mm. so I guess a mapping on set/proc+debug output would be the cleanest thing, or? 1131332281 M * Bertl yep 1131332320 M * Greek0 I'm off to bed for now, should I look into it tomorrow or are you going to do it? 1131332333 M * Bertl I'll do it, but check the patch tomorrow 1131332346 M * Bertl (because of gcc 4.x) 1131332385 M * Greek0 ok, good night 1131332394 M * Bertl night! 1131332444 M * jebba hey Bertl thx :) 1131332470 M * jebba i'm just poking around to see if I can figure out how to install a fedora/centos vserver inside a debian host. 1131332498 M * Bertl just copy it there, and start it ... 1131332510 M * Bertl creation might be a little trickier ... 1131332513 M * jebba ya, but building it, i guess is the bigger chore 1131332541 M * Bertl yep, if you succed getting apt-rpm or yum working on debian, let us know 1131332566 M * jebba ;) 1131332702 M * jazzanova this panic=60 is a kernel option, or grub/lilo option ? 1131332731 M * Bertl a kernel option, it instructs the kernel to reboot 60 seconds after a panic 1131332764 M * jebba /etc/sysctl.conf <---- jazzanova 1131332835 M * jazzanova ah, ok. cool. 1131332951 M * jazzanova kernel.panic = 06 ? 1131332963 M * Bertl ahem, I guess that won't really work :) 1131333004 M * Bertl it's basically a causality issue, so you need a different universe to make that work :) 1131333017 M * jebba jazzanova, ya (60, probably) 1131333023 M * jebba you may want to also add: 1131333033 M * jebba kernel.panic_on_oops = 60 too 1131333043 M * Bertl bootloader -> kernel boot -> fails -> panic -> reboot 1131333061 M * Bertl where does the sysctl fit in? 1131333080 M * jebba Bertl, good point for that scenario. 1131333104 M * Bertl so 'just' plain and simple specify it at the kernel command line as panic=60 (as suggested) 1131333150 M * jebba y 1131333172 M * Bertl Aiken: will have a patch in a few minutes 1131333202 M * Aiken ok 1131333215 M * Bertl just trying to make it 'smart' 1131333230 M * jazzanova bertl: kernel command line means that i need to add it inthe grub config file. 1131333240 M * Bertl yes 1131333252 M * jazzanova thats a cool feature. 1131333283 M * jazzanova i wonder how it is coded. 1131333301 M * jazzanova an interrupt is set before any operation ? 1131333304 M * Bertl well, the kernel writes the panic, then waits N seconds and reboots 1131333312 M * jazzanova :) 1131334552 M * Bertl Aiken: okay, test compiling now 1131334609 M * jazzanova is 2.2 celeron an fast enough machine to run 5 vservers ? 1131334614 M * jazzanova 1gig ram 1131334617 M * Bertl definitely 1131334627 M * jazzanova is vserver faster than xen ? 1131334635 M * Bertl depends on the setup 1131334642 M * Bertl for one guest, probably not 1131334651 M * jazzanova for 5 ? 1131334665 M * Bertl well, you save the overhead of 5 other kernels :) 1131334680 M * jazzanova what about the loaded dlls ? 1131334749 M * Bertl shared libraries, if configured properly (unification is the magic word) can improve performance and reduce memory footprint too 1131334749 M * jazzanova do i save there ? 1131334751 M * Bertl yes, if all guest use the same libraries and executables 1131334757 M * jazzanova is it better to run guest same as server ? 1131334776 M * jazzanova yeah, i think i will have them all ubuntu. 1131334789 M * Bertl not unless you unify the guest with the host and/or have many services running on the host 1131334813 M * Bertl basically the host should only run sshd ... 1131334828 M * Bertl (well and hardware related stuff) 1131334864 M * jazzanova is it going to be safe for a production server, to have a vserver serve web requests ? 1131334886 M * Bertl define safe? 1131334904 M * jazzanova i was thinking to keep vservers are playground machines, with the host the live machine. 1131334918 M * Bertl why? 1131334920 M * jazzanova safe - doesn't crash. 1131334933 M * jazzanova dunno, its a new thing for me. 1131334936 M * Bertl ah, well, guests 'crash' as often as the host crashes ... 1131334958 M * Bertl because there is only one kernel, it's all or nothing :) 1131334976 M * jazzanova well,for one, it means that i can't upgrade the kernel no thelive system unless it is vserver supported. 1131334992 M * jazzanova s/no/on 1131335009 M * Bertl there is basically no _known_ distro which doesn't work with current vserver kernels 1131335018 M * jazzanova i don't mind loosing develpment machines temporarily, but not thelive one. 1131335026 M * Bertl I don't suspect that to change soon ... 1131335049 M * jazzanova you mean that future kernels will have vserver ? 1131335072 M * Bertl no, I meant, the future kernel (with or without linux-vserver) will work for all distros 1131335131 M * jazzanova so I have to move all my apache setup and stuff to the vserver that I am about to create ? 1131335142 M * jazzanova and have sshd on the host, eh ? 1131335143 M * Bertl jazzanova: look at it like that .. a guest is a distro without a kernel 1131335157 M * Bertl a distro which is 99% hardware independant 1131335183 M * jazzanova this damn kernel takes forever to compile.. 1131335188 M * Bertl and no, you do not _have_ to do that ... but it would be advantageous to do so 1131335211 M * jazzanova i see. then i will. 1131335216 M * Bertl because, for example in case you change the machine, you 'simply' move the guest to a new one 1131335229 M * Bertl no need to change anything on the distro 1131335238 M * jazzanova and yo uhave also mentions something about run-once or boot-once for the boot loader 1131335246 M * jazzanova i cant find it for grub. i found 'fallback'. 1131335248 J * dddd44 dhb55@218.111.178.108 1131335267 M * Bertl yes, for lilo it's the -R option, IIRC, for grub it's a little more complicated 1131335287 M * Bertl dddd44: ping! ping! 1131335371 M * Bertl jazzanova: well, it would be also good (not right now, but in the future) to trim down the kernel to your hardware 1131335392 M * Bertl (this speeds up kernel compile and increases performance) 1131335656 M * Bertl jazzanova: for grub it's a combination of savedefault and --once 1131335663 M * Bertl (if your grub supports it) 1131335682 M * Bertl otherwise it's a more tricky exchange of boot menues 1131335917 M * Bertl Aiken: http://vserver.13thfloor.at/Experimental/delta-limit-fix01.diff 1131335948 M * jazzanova ok, lem me read about it 1131335960 M * Bertl Aiken: (works on x86, please check on alpha and if possible x86_64, regarding compile warnings) 1131335986 M * Aiken no x86_64 here :( 1131335993 M * Bertl ah, okay, np 1131336010 M * Bertl will put it through a cross compile on my side ... 1131336017 M * Aiken Hunk #1 succeeded at 22 (offset 6 lines). 1131336027 M * Bertl that's fine ... 1131337965 Q * dddd44 Read error: Connection reset by peer 1131338001 M * dos000 Bertl, when i compiled 2.6.4 it is complaining that it cannot find my /dev/hdc drive :-) any help ? 1131338014 M * dos000 2.6.14 with patches ! 1131338134 M * Bertl the compile complained? 1131338174 M * Aiken http://pastebin.com/420253 1131338216 M * dos000 no the reboot has a pnic 1131338234 M * Bertl Aiken: hmm, k, that needs adjustment too, are those the only warnings? 1131338248 M * Bertl dos000: boot log? 1131338259 M * Aiken yes 1131338292 M * Aiken http://pastebin.com/420255 1131338305 M * Bertl ah, great! 1131338335 M * Bertl okay, if you change the #define VX_LIMIT_FMT":\t%10d\t%10ld\t%10ld\t%6d\n" 1131338337 M * Bertl to 1131338339 M * dos000 it is panicing so if i reboot to working kernel how do i get the logs 1131338355 M * Bertl Aiken: #define VX_LIMIT_FMT ":\t%10d\t%10ld\t%10lld\t%6d\n" 1131338366 M * Bertl (third %d gets another 'l' ) 1131338386 M * Bertl dos000: not easy without remote console ... 1131338400 M * Bertl dos000: what host distro? 1131338424 M * Aiken compiling 1131338474 M * Aiken In file included from kernel/vserver/proc.c:33: 1131338475 M * Aiken kernel/vserver/limit_proc.h: In function `vx_info_proc_limit': 1131338475 M * Aiken kernel/vserver/limit_proc.h:31: warning: long int format, long long unsigned int arg (arg 4) 1131338475 M * Aiken kernel/vserver/limit_proc.h:31: warning: long unsigned int format, long long unsigned int arg (arg 5) 1131338522 M * dos000 Bertl, i have debian sarge 1131338539 M * Bertl is the rootfs accessible without the initrd? 1131338567 M * dos000 that is what i am wondering .. but wait ! 1131338577 M * jebba I have something a bit baffling here. I have a FC3 vserver set up. I am trying to get sshd going. If I run it in "no detach" (-D) mode it works. But if I just run `/usr/sbin/sshd` it returns immediately--no errors and no sshd process is left running. Ideas? :) 1131338600 M * jebba it's also not the pam issue mentioned in the archives, fwiw 1131338674 M * Bertl jebba: does it return an error code? 1131338686 M * Bertl dos000: if possible avoid an initrd ... 1131338699 M * Bertl dos000: debian gets the initrd wrong with recent kernels 1131338846 M * Bertl Aiken: hmm, some of them were there before, no? 1131338852 M * Aiken no 1131338866 M * Bertl strange ... 1131338873 M * anonymousc Bertl: I'm running the sysstat package to collect overall system performance counters (i don't really care about per-vserver at the moment) - I changed the cron job to launch the sa1 program into context 1 but it only sees the processes running in the host vserver - is this a /proc unhiding issue or something else - for example /proc/net/rpc doesn't exist in context 1) ? I'm happy to dig further to provide more info. 1131338877 M * jebba Bertl, it returns no errors. 1131338888 M * Bertl Aiken: okay, verifying again ... 1131338927 M * Bertl anonymousc: could you uplaod the output of testme.sh please? 1131339025 M * Aiken compile log before the VX_LIMIT_FMT change http://pastebin.com/420262 1131339066 M * Aiken compile log after the VX_LIMIT_FMT change http://pastebin.com/420263 1131339114 M * Aiken #define VX_LIMIT_FMT ":\t%10d\t%10ld\t%10lld\t%6d\n" as far as I can see it is the same as what you said to change it to 1131339140 M * Bertl hmm, yes, sec 1131339325 M * jazzanova i am missing grub-set-default on my system. 1131339575 M * Bertl jebba: try strace -fF -o sshd.trace 1131339586 M * Bertl jebba: (before the sshd) 1131339591 Q * lilo Quit: bbiab 1131339607 M * Bertl jebba: out of the blue, I'd opt for a missing ssh user 1131339736 M * jebba Bertl, sshd user there (and it's homedir). did an strace earlier. i'll run the one you suggest. I'm double-checking /dev for foo-ness 1131339744 M * jazzanova ok, figured it out 1131339822 M * jazzanova rebooting.. 1131339959 M * jazzanova reboot worked :) 1131340001 M * Bertl good :) 1131340075 M * jazzanova should i now make it default ? 1131340096 M * Bertl if it works, yes 1131340096 M * jazzanova or leave it be. 1131340107 J * lilo ~lilo@lilo.usercloak.oftc.net 1131340131 M * Bertl Aiken: did the change recompile almost the entire kernel for you too? 1131340246 M * Aiken did originally seem to compile quite a bit fo the kernel but afterwards while trying with/without the change it only did what I put on pastebin 1131340282 M * jazzanova rebooting... 1131340283 M * jazzanova :) 1131340300 M * Bertl Aiken: okay, I fixed something, but not sure it will work for you 1131340310 M * Bertl uploading in a moment 1131340404 M * Bertl http://vserver.13thfloor.at/Experimental/delta-limit-fix02.diff 1131340431 M * Bertl Aiken: please in addition to that, add the following 1131340446 M * Bertl right after the #if(RLIM_INFINITY == VLIM_INFINITY) 1131340464 M * Bertl #warning wrong for alpha ... 1131340541 M * jazzanova ext2fs headers were not found, or they are not usable. This can have 1131340542 M * jazzanova the following reasons: 1131340550 M * jazzanova thats the error i get from configure 1131340560 M * Bertl well, install them (i.e. do what it says :) 1131340597 M * Aiken that change go in include/linux/vserver/limit.h ? 1131340607 M * Bertl yep 1131340649 M * Aiken that lot has triggered a big compile 1131340681 M * Bertl as soon as you get the warning, you can stop 1131340706 J * lilo_ ~lilo@lilo.usercloak.oftc.net 1131340801 Q * lilo Ping timeout: 480 seconds 1131340841 N * lilo_ lilo 1131340857 M * Aiken I change it to #error so it should stop 1131341002 M * Bertl k 1131341200 M * Aiken up to drivers/scsi and all I have had is 1131341202 M * Aiken In file included from kernel/vserver/proc.c:33: 1131341202 M * Aiken kernel/vserver/limit_proc.h: In function `vx_info_proc_limit': 1131341202 M * Aiken kernel/vserver/limit_proc.h:31: warning: long int format, long long unsigned int arg (arg 4) 1131341202 M * Aiken kernel/vserver/limit_proc.h:31: warning: long unsigned int format, long long unsigned int arg (arg 5 1131341320 M * Aiken have to go for a bit 1131341391 M * Bertl okay, np, I'll leave that for tomorrow 1131341403 M * Bertl I have no idea what would be wrong ... 1131341432 M * Bertl (I mean, compared to before) 1131341523 M * jazzanova ok, the doc says i need to disable x25 protols in aliases file. 1131341528 M * jazzanova do I comment those lines out ? 1131341539 M * jazzanova or uncomment 1131341540 M * jazzanova alias net-pf-3 ax25 1131341546 M * jazzanova doc says to un-comment 1131341553 M * jazzanova which i don't understand. 1131341578 M * Bertl that was fixed some time ago 1131341587 M * Bertl should not apply to 2.6.14 kernels 1131341632 M * Bertl okay, off to bed now ... back later ... 1131341640 M * Bertl have a good whatever everyone ... 1131341647 N * Bertl Bertl_zZ 1131341688 M * Aiken just did a full compile, the #error was not triggered 1131341689 M * jazzanova also, the manual says to add to rc.d vprochide, but i only have vprocunhide 1131341704 Q * FireEgl Ping timeout: 481 seconds 1131342648 Q * dos000 Quit: Leaving 1131343063 M * jazzanova can someone help me with the network configuration of my first vserver ? 1131343075 M * jazzanova i gave it a public ip, during the build stage. 1131344010 J * FireEgl Atlantica@Atlantica.US 1131344247 Q * lonewolff helium.oftc.net strange.oftc.net 1131344247 Q * shedi helium.oftc.net strange.oftc.net 1131344247 Q * cryo helium.oftc.net strange.oftc.net 1131344247 Q * mnemoc helium.oftc.net strange.oftc.net 1131344247 Q * yungyuc helium.oftc.net strange.oftc.net 1131344247 Q * Hollow helium.oftc.net strange.oftc.net 1131344247 Q * gerrit helium.oftc.net strange.oftc.net 1131344247 Q * iprone helium.oftc.net strange.oftc.net 1131344247 Q * Greek0 helium.oftc.net strange.oftc.net 1131344247 Q * mrec_ helium.oftc.net strange.oftc.net 1131344349 J * lonewolff ~lonewolff@host86-128-133-145.range86-128.btcentralplus.com 1131344356 J * mnemoc ~amery@200.75.27.9 1131344547 J * Hollow ~hollow@home.xnull.de 1131344547 J * mrec ~revenger@p54B028BB.dip0.t-ipconnect.de 1131344547 J * Greek0_ ~greek0@85.255.145.201 1131344547 J * shedi ~siggi@inferno.lhi.is 1131344547 J * iprone ~iprone@adsl-065-012-167-027.sip.asm.bellsouth.net 1131344547 J * cryo ~say@212.86.233.146 1131344547 J * gerrit ~gerrit@c-24-22-41-133.hsd1.or.comcast.net 1131344815 J * yungyuc ~yungyuc@220-135-53-220.HINET-IP.hinet.net 1131348397 Q * Aiken Quit: Leaving 1131348574 Q * shedi Quit: Leaving 1131349515 J * vip-vs ~vince@wc-178.r-195-85-188.essentkabel.com 1131351869 J * Pazzo ~Pazzo@host130-250.pool8172.interbusiness.it 1131353554 N * lonewolff Guest110 1131354462 J * shedi ~siggi@tolvudeild-205.lhi.is 1131355385 J * Graveworm ~wilmreich@dslb-084-060-004-239.pools.arcor-ip.net 1131355542 J * Johnnie ~john@acs-24-154-53-217.zoominternet.net 1131355629 M * Graveworm hello, i have some strange things happen on my vservers. i have multiple vservers running on my host and if i enter vserver#1 i can see all the processes running on all servers. also the vserver got a wrong hostname. what goes wrong :) 1131355684 M * vip-vs Hi Graveworm, just installed them? 1131355700 M * Graveworm no running without problems for about a half year 1131355721 M * vip-vs hmmzz then I don't know :) 1131355730 M * vip-vs What version? 1131355768 M * Graveworm kernel 2.6.10 vs1.9.4 1131355793 M * vip-vs Does anyone know if the current stable vserver kernel patches should work on kernel 2.6.14? Several hunks are failing when I try to patch. 1131355837 M * vip-vs nopez, I just started with v2.0, no experience with previous releases .. at least.. not 1.9.4 1131356305 Q * Johnnie oxygen.oftc.net strange.oftc.net 1131356305 Q * Pazzo oxygen.oftc.net strange.oftc.net 1131356305 Q * yungyuc oxygen.oftc.net strange.oftc.net 1131356305 Q * cryo oxygen.oftc.net strange.oftc.net 1131356305 Q * Hollow oxygen.oftc.net strange.oftc.net 1131356305 Q * gerrit oxygen.oftc.net strange.oftc.net 1131356305 Q * iprone oxygen.oftc.net strange.oftc.net 1131356305 Q * Greek0_ oxygen.oftc.net strange.oftc.net 1131356305 Q * mrec oxygen.oftc.net strange.oftc.net 1131356565 J * Johnnie ~john@acs-24-154-53-217.zoominternet.net 1131356565 J * Pazzo ~Pazzo@host130-250.pool8172.interbusiness.it 1131356565 J * yungyuc ~yungyuc@220-135-53-220.HINET-IP.hinet.net 1131356565 J * Hollow ~hollow@home.xnull.de 1131356565 J * mrec ~revenger@p54B028BB.dip0.t-ipconnect.de 1131356565 J * Greek0_ ~greek0@85.255.145.201 1131356565 J * iprone ~iprone@adsl-065-012-167-027.sip.asm.bellsouth.net 1131356565 J * cryo ~say@212.86.233.146 1131356565 J * gerrit ~gerrit@c-24-22-41-133.hsd1.or.comcast.net 1131357516 Q * cryo Remote host closed the connection 1131357516 Q * TheSeer Read error: Connection reset by peer 1131357616 J * raym ~ray@lasting-damage.oucs.ox.ac.uk 1131357640 P * raym Leaving 1131357881 J * prae ~prae@ezoffice.mandriva.com 1131357966 Q * Graveworm Ping timeout: 480 seconds 1131358011 J * Graveworm ~wilmreich@dslb-084-060-016-236.pools.arcor-ip.net 1131359161 M * daniel_hozac vip-vs: http://vserver.13thfloor.at/Experimental/ has patches for 2.6.14 1131359185 M * daniel_hozac Graveworm: what xids for the guests? unless they're the same, that just shouldn't happen. 1131359274 M * Graveworm what do you mean with xids? 1131359415 J * _Kara_ ~Kashira@ip-80-226-237-57.vodafone-net.de 1131359419 M * Graveworm and what does S_CONTEXT in the vserver conf? 1131359468 M * _Kara_ good morning. anybody here to tell me, which patch would best be used for 2.6.14 sources? 1131359532 J * logger ~rs@84.244.0.15 1131359550 M * daniel_hozac S_CONTEXT would be the xid. 1131359552 M * daniel_hozac the context id. 1131359571 M * daniel_hozac _Kara_: http://vserver.13thfloor.at/Experimental/ has patches for 2.6.14. 1131359581 M * _Kara_ thx a lot! 1131359585 M * Graveworm ah ok, that option had no value 1131359658 M * Graveworm "New security context is 49155" is one of the messages on vserver boot, with S_CONTEXT i can set this by hand right? 1131359666 M * daniel_hozac yes. 1131359675 M * daniel_hozac dynamic contexts should be avoided. 1131359747 M * Graveworm does it matter which numbers i set or do they just have to differ? 1131359828 M * daniel_hozac it must be in the range of 2-49151 1131359839 M * daniel_hozac but other than that, it doesn't matter. 1131359893 M * Graveworm ok that solved the problem, thanks 1131360297 J * cryo ~say@212.86.233.146 1131362285 N * Greek0_ Greek0 1131363280 J * erwan_taf ~erwan@81.80.43.77 1131363289 Q * erwan_taf Quit: 1131364363 M * shedi I'm trying to run "nfs userspace server" within a guest, but I get this particular error "unable to register (mountd, 1, udp)" 1131364395 M * shedi has anybody here tried to run this service within a guest? 1131364464 M * shedi it seems to be related to some portmap problems 1131364521 M * shedi this beautiful error occurs prior to the nfsd error "portmap[22210] SIOCGIFADDR: Cannot assign requested address" 1131364549 Q * iprone Ping timeout: 480 seconds 1131364570 M * shedi "portmap[22210]: cannot find any active local network interfaces" 1131364608 Q * Graveworm Quit: 1131364622 M * shedi I do not remember this portmap error from within a guest 1131364661 M * shedi maybe it has something to do the guest running on a vlan interface? 1131364669 M * shedi with\ 1131365285 Q * logger Ping timeout: 480 seconds 1131365290 J * logger ~rs@84.244.0.15 1131368464 M * vip-vs daniel_hozac: thanks! 1131368552 J * blackfire blackfire@nat1.radiostrada.pl 1131368559 J * mrec_ ~revenger@p54B00890.dip0.t-ipconnect.de 1131368572 M * blackfire hello, anybody alive? :) 1131368974 Q * mrec Ping timeout: 480 seconds 1131369291 M * daniel_hozac shedi: does ifconfig work in the guest (i.e. show the interface with an IP)? 1131369351 M * daniel_hozac portmap uses the same obsolete interface. http://daniel.hozac.com/stuff/portmap-4.0-getifaddrs.patch fixes that. 1131369592 M * blackfire did anybody encounter problems with htb class shaping on vservers? 1131370455 M * Greek0 Bertl_zZ: I think delta-limit-fix01.diff is broken. There's one IMHO rather ugly aspect in-kernel and what's more important, it breaks the userspace API afaics. 1131370595 M * Greek0 both come from the #define CRLIM_INFINITY VLIM_INFINITY. In-kernel VRLIM_INFINITY is defined in another header file without that being included in limit_cmd.h. The much more serious problem however is that you define VLIM_INFINITY inside an #ifdef __KERNEL__, while the CRLIM_INFINITY definition is outside, and so part of the userspace API 1131370644 M * Greek0 so afaics that will result in something like "unkown identifier VLIM_INFINITY" as soon as someone wants to use CRLIM_INFINITY in userspace 1131370841 Q * vip-vs Remote host closed the connection 1131371329 Q * _Kara_ Ping timeout: 480 seconds 1131371570 J * harry ~harry@d515321D1.access.telenet.be 1131371590 J * menomc ~amery@200.75.27.45 1131371696 Q * mnemoc Ping timeout: 480 seconds 1131371696 N * menomc mnemoc 1131372011 J * ComplexHo ~ComplexHo@cpc1-brig3-6-0-cust194.brig.cable.ntl.com 1131372042 J * Doener doener@i5387FC67.versanet.de 1131372075 M * shedi daniel_hozac, ifconfig displays the vlan interface but no ip number 1131372295 M * harry than the if is not up imho 1131372321 M * harry nono... not imho... normally! 1131372494 M * mnemoc shedi: don't use ifconfig, use ip from iproute2 1131373021 M * shedi "ip" displays the address 1131373154 M * FaUl yes :-) 1131373588 M * mnemoc shedi: ifconfig was obsoleted last century! 1131374546 Q * yungyuc Remote host closed the connection 1131374855 J * monrad ~monrad@213083190130.sonofon.dk 1131375512 J * terr ~gilles@ip-80-236-218-117.dsl.scarlet.be 1131375538 Q * terr Quit: leaving 1131375715 J * Breaker_uk ~flopsy@host81-134-146-163.in-addr.btopenworld.com 1131377649 M * daniel_hozac mnemoc: right, but portmap uses the same deprecated interface, unless patched. 1131378440 Q * blackfire Quit: Lost terminal 1131378505 M * mnemoc daniel_hozac: sad to know :\ 1131378563 Q * lazystoner Read error: Connection reset by peer 1131378764 Q * monrad Quit: Leaving 1131378846 J * n0ne`theNIggaALover ~niger@tor-irc.dnsbl.oftc.net 1131379254 Q * shedi Quit: Leaving 1131379475 Q * Doener Quit: Leaving 1131379759 Q * Breaker_uk Quit: 1131379769 J * Breaker_uk ~flopsy@host81-134-146-163.in-addr.btopenworld.com 1131379951 Q * tchan Remote host closed the connection 1131379989 J * tchan ~tchan@c-67-174-18-204.hsd1.il.comcast.net 1131379993 J * Viper0482 ~Viper0482@p54976CEB.dip.t-dialin.net 1131380140 Q * lilo Quit: bbiab 1131380956 Q * jazzanova Quit: Connection reset by pear 1131380995 Q * Breaker_uk Ping timeout: 480 seconds 1131381106 J * Breaker_uk ~flopsy@host81-134-146-163.in-addr.btopenworld.com 1131381737 J * lilo ~lilo@lilo.usercloak.oftc.net 1131382022 J * stefani ~stefani@superquan.apl.washington.edu 1131382042 Q * Breaker_uk Quit: 1131382119 Q * prae Quit: Execute Order 69 ! 1131382287 N * Bertl_zZ Bertl 1131382293 M * Bertl morning folks! 1131382389 M * stefani morgen. 1131382499 M * Bertl hey stefani! everything fine? 1131382533 M * stefani mostly yes. 1131382538 M * stefani but i'm behind on things. 1131382572 M * Bertl who isn't? :) 1131382626 J * Breaker_uk ~flopsy@host81-134-146-163.in-addr.btopenworld.com 1131382701 M * stefani y. 1131382713 M * Bertl welcome Breaker_uk! 1131382723 M * Bertl okay, off for dinner now .. back shortly 1131382730 N * Bertl Bertl_oO 1131382807 M * FaUl yea, finally got that fscking ospf-openvpn problem :-) 1131383522 Q * Breaker_uk Quit: 1131383623 N * Bertl_oO Bertl 1131383631 M * Bertl back now .. 1131383890 M * Bertl FaUl: ospf-openvpn issue? 1131383913 J * lilo_ ~lilo@lilo.usercloak.oftc.net 1131383932 M * FaUl Bertl: yes, i figured out that the quagga-ospfd does not work proberly with tun-devices with more then one client 1131383944 M * FaUl now i used tap-devices 1131383951 M * FaUl seems to work quite well 1131383956 M * Bertl aha .. interesting .. 1131383970 M * FaUl but i need some more ram for my border-router, that bgp-tables are to big :-) 1131384005 Q * lilo Ping timeout: 480 seconds 1131384710 J * lilo ~lilo@lilo.usercloak.oftc.net 1131384773 J * squirel ~squirel@osiris.physics.auth.gr 1131384782 M * squirel greetings all... 1131384789 Q * lilo_ Ping timeout: 480 seconds 1131384790 M * squirel just a question... 1131384802 M * squirel is it possible to use vserver on sparc? 1131384804 J * prae ~benjamin@sherpadown.net 1131384805 M * Bertl welcome squirel! 1131384813 M * Bertl squirel: yes, it should work fine 1131384824 M * Bertl (was not tested for some time now) 1131384839 M * squirel ok 1131384843 M * squirel thanks... 1131384879 M * Bertl squirel: if you try, and something doesn't work as expected, let us know 1131384889 M * Bertl and feel free to hang around ... 1131384903 M * squirel yes 1131384910 M * squirel i just installed gentoo on it 1131384939 M * squirel and i fount out that there is no spark keyword on vserver-sources 1131384964 M * squirel anyway i'll come back when it is finished... 1131385028 M * Bertl k 1131385127 Q * squirel Quit: Leaving 1131385298 J * terr ~gilles@ip-80-236-203-206.dsl.scarlet.be 1131385899 Q * Guest110 Quit: leaving 1131386018 J * lonewolff ~lonewolff@host86-128-133-145.range86-128.btcentralplus.com 1131386123 M * Bertl welcome terr! 1131386412 M * terr Hi. 1131386586 M * terr Did you have a look at my last mail? 1131386650 M * Bertl not yet 1131386664 M * Bertl (unless you did send it before 8am CET) 1131386769 M * terr No, I sent it at 4PM. 1131386784 M * Bertl okay, then give me a few minutes 1131386922 M * daniel_hozac terr: is your guest's initscript setting the hostname? 1131387048 M * terr I don't think so (but I'm not sure). 1131387130 M * Bertl daniel_hozac: good point :) 1131387271 M * daniel_hozac terr: and do you have i386 in uts/machine? 1131387341 M * terr I have "i386.harfang.homelinux.org" in "uts/nodename" 1131387366 M * Bertl yeah, we know that :) 1131387526 M * terr The guest indeed contains an "/etc/hostname" file with "dusk" in it. 1131387660 M * Bertl fascinating ... 1131387709 M * terr :-} 1131387760 M * terr The eternal problem of finding out the bits to be removed from a guest... 1131387764 M * Bertl terr: but don't worry, you can disable the feature 1131387775 M * Bertl just take away the necessary ccap 1131387883 M * terr Now, for the "machine" name; just any value can be set there? 1131387905 M * daniel_hozac uts/machine is what would be returned from uname -m 1131387945 M * Bertl terr: just any name up to 65 chars 1131387995 M * terr In fact, I've asked debootstrap to create an "--arch i386" guest/chroot. 1131388015 M * Bertl what it probably did, no? 1131388056 M * terr And I thought I could compile kernel inside the guest for a Pentium machine. 1131388065 M * terr Does it make sense? 1131388070 M * daniel_hozac why not? 1131388093 M * Bertl terr: yup, makes sense 1131388116 M * terr I was wondering whether the tools/compiler were looking at the "machine" name. 1131388127 M * terr Or something else? 1131388159 M * Bertl could be, yes .. don't know your tools 1131388170 M * Bertl that's why you can 'fake' it too 1131388194 M * terr Because when I tried on the host, "make gconfig" didn't allow for other architectures. 1131388333 M * terr So, just setting i386 in uts/machine is enough to make the kernel scripts happy? 1131388356 J * shedi ~siggi@inferno.lhi.is 1131388398 M * Bertl terr: well, specifying ARCH=i386 would do so too :) 1131388417 M * Bertl terr: the kernel build system is prepared for cross building 1131388576 M * terr Oh, I read complicated things about setting a cross-compiling environment... 1131388589 M * terr Probably out-dated! 1131388598 M * Bertl hmm, that's only to scare away newcomers ... 1131388625 A * Bertl is cross building for 14 archs atm ... 1131388668 Q * mnemoc Quit: leaving 1131388753 M * terr Well, I wanted to try something else in a vserver, and get some advice on how to handle it. 1131388759 M * Hollow Bertl: seems like we'll get vserver supported on x86 amd64 ppc sparc and alpha on gentoo in the future :) 1131388774 M * Bertl Hollow: great! 1131388801 M * terr Namely install "Skype"... 1131388856 M * Bertl Greek0: I guess that's not the only thing which is broken ... Aiken had the strangest warning messages ... 1131389067 M * terr I imagine there will be some devices to set up (/dev/dsp and others). 1131389085 M * terr Suggestions? 1131389132 M * Bertl terr: no idea, where is the source? :) 1131389251 M * terr Well, if it were me, I wouldn't touch the thing... But I've been forcefully asked to install it so we can talk with the family abroad... 1131389364 M * terr I've just set uts/machine, and it still shows x86_64 within the guest! 1131389380 M * Bertl did you restart the guest? 1131389403 M * Bertl an what tool version do you use? 1131389406 M * terr Yes; is there some script similar to "hostname.sh"... 1131389439 M * Bertl no, there should not be 1131389461 M * terr Version is 0.30.209 (as you requested in your mail :-) 1131389471 M * Bertl excellent! 1131389519 M * Bertl let's try with the vuname tool 1131389549 M * terr No, wait... I didn't restart the guest. Sorry!!! 1131389586 M * terr It's fine. 1131389612 Q * FireEgl Ping timeout: 480 seconds 1131389616 M * terr Thanks! 1131389626 M * Bertl okay, great! :) 1131389694 M * terr I'm away for now. All, have a nice evening. Bye. 1131389757 M * Bertl okay, cya! 1131389826 Q * sladen Ping timeout: 480 seconds 1131389983 J * sladen paul@starsky.19inch.net 1131390012 P * terr 1131390661 J * mnemoc ~amery@200.75.27.63 1131390757 M * Bertl welcome mnemoc! 1131390912 M * mnemoc hi Bertl 1131392751 J * huck ~huck@p54BCA0F4.dip0.t-ipconnect.de 1131392790 M * Bertl welcome huck! 1131392840 M * huck hi 1131392968 N * huck huck_finn 1131393071 M * huck_finn sry bertl, i've seen this nick was registerd 1131393097 M * Bertl np 1131393669 M * Bertl okay, off for a longer bath ... 1131393675 N * Bertl Bertl_oO 1131393709 Q * gerrit Ping timeout: 480 seconds 1131394217 P * huck_finn Leaving 1131394483 J * Aiken ~james@tooax6-169.dialup.optusnet.com.au 1131394971 Q * jebba Ping timeout: 480 seconds 1131395396 Q * STaN Ping timeout: 480 seconds 1131395565 J * jebba ~jebba@ip-216-17-203-198.rev.frii.com 1131395854 Q * Greek0 Read error: Connection reset by peer 1131395875 J * Greek0 ~greek0@85.255.145.201 1131396484 J * gerrit ~gerrit@bi01p1.co.us.ibm.com 1131397106 N * Bertl_oO Bertl 1131397112 M * Bertl back now ... 1131397122 M * Bertl evening Greek0! hey gerrit! 1131397444 J * monrad ~monrad@213083190130.sonofon.dk 1131397537 M * Bertl welcome monrad! 1131397624 M * monrad hi 1131398307 J * Greek0_ ~greek0@217.19.46.18 1131398308 M * Greek0_ hi 1131398315 M * Greek0_ sorry for the clone, I have some network problems at home 1131398350 M * Greek0_ Bertl: ping? 1131398458 M * Bertl pong! 1131398476 M * Bertl already back home? 1131398501 M * Greek0_ in vienna at the debian meeting 1131398529 M * Greek0_ my dad played around with the router at home so I can't connect to my server at home to do things like.. chat or read email 1131398537 M * Greek0_ so I'm pretty pissed off :-/ 1131398554 M * Bertl ah, ok, well, don't be 1131398589 M * Greek0_ did you see my comment on the patch above? did I miss something? 1131398604 M * Bertl yep, maybe 1131398616 M * Bertl it's not the only broken thing in that patch 1131398623 M * Greek0_ ah ;) 1131398640 M * Bertl but we didn't continue without you :) 1131398671 M * Bertl no, actually Aiken experienced strange gcc messages, and I need some clues there 1131398744 M * Bertl Greek0_: http://pastebin.com/420263 1131398854 M * Bertl the important part is, without the patches, no such message is issued 1131398956 M * daniel_hozac are they long longs without the patch? 1131398994 M * Bertl hmm, no, just longs 1131399039 M * Bertl what I don't get is the following: 1131399055 M * Bertl the print* line in question has 4*12 arguments 1131399056 M * Greek0_ it's actually pretty clear 1131399085 M * Bertl (or something like that) 1131399085 M * Bertl all generated by the same macro 1131399092 M * Bertl hmm ... now that I think of it ... maybe a missing parenthesis? 1131399136 M * Greek0_ I'm not sure about warning with arg5 1131399141 M * Greek0_ bit with arg4 it's clear 1131399158 M * Bertl yes? please elaborate! 1131399204 M * Greek0_ ,limit->rlim[r] (which is ul) becomes VX_VLIM(limit->rlim[r]) (which is ull), but VX_LIMIT_FORMAT isn't changed 1131399224 M * Greek0_ #define VX_LIMIT_FMT ":\t%10d\t%10ld\t%10ld\t%6d\n" should be #define VX_LIMIT_FMT ":\t%10d\t%10ld\t%10lld\t%6d\n" 1131399226 M * Bertl it is changed 1131399240 M * Bertl that's part of the patche_s_ 1131399256 M * Greek0_ yep, only looked at the first, sorry 1131399265 M * Greek0_ haven't compile-tested them yet 1131399269 M * Bertl and the result is with _both_ patches 1131399283 M * Bertl what makes me wonder is, it should look like this: 1131399289 M * Aiken Greek0_ the change to VX_LIMIT_FMT is what gives that compile warning 1131399290 M * Bertl http://pastebin.com/420262 1131399302 M * Bertl hey Aiken! 1131399309 M * Bertl if we have a bug in the format 1131399315 M * Aiken hi 1131399373 M * Aiken that last warning set looks famillar, I have that in my screen now because I just tried the define how it originally was 1131399527 M * Greek0_ Aiken: what compiler, what arch? 1131399535 M * Greek0_ I don't get the errors here when compiling for i386 1131399546 M * Greek0_ s/errors/warnings/ 1131399568 M * Aiken alpha, gcc 3.3.6 1131399591 Q * gerrit Ping timeout: 480 seconds 1131399603 M * Bertl Greek0_: it has to be alpha, cross compiling is fine 1131399692 M * Greek0_ cross compiling for alpha works, but compiling it native gives the error? 1131399713 M * Bertl nope 1131399721 M * Bertl error should be in both cases 1131399731 M * Bertl haven't checked the alpha cross results yet 1131400313 J * gerrit ~gerrit@bi01p1.co.us.ibm.com 1131400346 M * Aiken that was the cross compile case, I could have native compile results somewhere > 1 hour 1131400515 M * Bertl I do not think that would change anything ... 1131400544 Q * Johnnie Quit: G'bye! 1131400552 M * Aiken neither do I but it eliminates one thing 1131400562 M * Bertl ok, tx 1131400965 Q * Viper0482 Quit: bin raus, 1131401478 M * Aiken Berlt what were the delta patches to apply? 1131401498 M * Aiken I forgot to copy them off /tmp before I shut this thing down last night :( 1131401507 M * Aiken Bertl even 1131401522 M * Bertl sec 1131401561 M * Bertl http://vserver.13thfloor.at/Experimental/delta-limit-fix01.diff 1131401569 M * Bertl http://vserver.13thfloor.at/Experimental/delta-limit-fix02.diff 1131402091 M * Aiken I tried again with a clean tree and it is fine now 1131402117 M * Aiken all I can think of is something happened to include/linux/vserver/limit.h with all the patching yesterday 1131402135 J * Johnnie ~john@acs-24-154-53-217.zoominternet.net 1131402153 J * Johnsie ~john@acs-24-154-53-217.zoominternet.net 1131402164 M * Bertl Aiken: okay, well, that really is good news :) 1131402191 M * Aiken I would like to know why because the offending bit in limit.h looks the same 1131402213 M * Bertl now we just have to clean up the VLIM stuff ... 1131402229 M * Bertl Greek0_: what do you think about 'just' using the old definition for userspace? 1131402709 M * Bertl Greek0_: still here? 1131402997 M * Bertl doesn't seem so .. well he'll come back sooner or later ... 1131404562 M * mef bertl: dcc 1131404571 M * mef if you have a minute 1131404627 M * Bertl sure 1131404657 Q * mef Remote host closed the connection 1131404668 J * mef ~mef@targe.CS.Princeton.EDU 1131404673 M * mef yuk 1131405061 Q * mef Remote host closed the connection 1131405795 M * Aiken Bertl just found why I was getting that warning yesterday but not today 1131405824 M * Bertl and? 1131405846 M * Aiken yes remember you asked me to put a printk in kernel/vserver/limit_proc.h? 1131405857 M * Bertl hmm, yes? 1131405864 M * Bertl that was the one? 1131405872 M * Aiken I also had to #include for the printk to compile 1131405890 M * Aiken I just put those 2 lines back in and I get the warnings again 1131405909 M * Bertl okay, if you _remove_ the printk line, it's gone permanently? 1131405918 M * Bertl (jsut the printk) 1131405948 M * Aiken remove just the printk and the warning is gone 1131405960 M * Bertl okay, didn't think of that ... 1131405979 M * Aiken it was really bugging me on why no warning today 1131405988 M * Bertl good, so we are fine with a minor change ... will upload a third fix shortly 1131406014 M * Aiken clean tree + pre6 + the 2 deltas and I have a clean compile 1131406045 M * Bertl okay, great, let me fix up the thing for userspace too 1131406096 M * Aiken have to admit yesterday I did not consider the printk either, only found it because I was trying to work out what was different today 1131406112 M * Bertl yeah, well, good that it is resolved now ... 1131406666 Q * gerrit Ping timeout: 480 seconds 1131406731 M * Bertl http://vserver.13thfloor.at/Experimental/delta-limit-fix03.diff 1131406738 M * Bertl (ontop of fix01+fix02) 1131407052 M * Aiken have to remember to use patch -l for the white spaces 1131407086 M * Aiken with -l it applied and trigged what looks like a full rebuild 1131407103 M * Aiken no errors or warnings in kernel/vserver/* 1131407187 Q * Johnnie Quit: G'bye! 1131407211 N * Johnsie Johnnie 1131407351 M * Bertl Aiken: excellent, thanks a lot! 1131407428 Q * Johnnie Quit: G'bye! 1131407445 J * Johnnie ~john@acs-24-154-53-217.zoominternet.net 1131407617 J * Greek0__ ~greek0@217.19.46.19 1131407650 M * Bertl wb Greek0__ :) 1131407717 J * gerrit ~gerrit@bi01p1.co.us.ibm.com 1131407791 M * Bertl welcome gerrit! 1131407814 P * stefani I'm Parting (the water) 1131407820 Q * Greek0_ Ping timeout: 480 seconds