1103068815 M * rpetre i cloned another vserver that was used for tests 1103068851 M * Bertl okay, then just to make sure, remove those two entries, and let's try again (don't think they are related)... 1103068905 M * rpetre so i'll comment that line altogether or set S_CAPS to "" ? 1103068916 M * Bertl yeah, set it to "" 1103068920 M * rpetre ok 1103068939 M * rpetre any other ideas? i wouldn't like to reboot the machine too often 1103068979 M * Bertl well, you can try to send signals like SEGFAULT and such to the process 1103068995 M * Bertl from inside the context _and_ from outside (i.e. xid=1) 1103069181 M * rpetre no effect 1103069198 Q * monrad Quit: Leaving 1103069203 N * locksy_AFK locksy 1103069205 M * locksy With the new iptables --vnet match, what are the flags for? 1103069222 M * Bertl rpetre: try to strace the kill ... (and upload the strace) 1103069233 M * rpetre vkill or kill ? 1103069236 M * Bertl locksy: they are not used atm ... 1103069245 M * Bertl rpetre: both 1103069284 M * locksy Ahh! Just to confuse eh... :) 1103069377 M * Bertl just to make sure ;) 1103069517 M * rpetre http://www.pastebin.com/129767 1103069674 M * rpetre anything peculiar? 1103069679 M * Bertl sec 1103069785 M * Bertl strange .. I would ask you to compile a 2.4.28 + vs1.29 kernel and try again if this happens there too, if so .. then we move to QEMU and a virtualized testbed ... 1103069908 M * rpetre whoa, that is a bit overwhelming 1103069918 M * rpetre i'll make a test machine tomorrow 1103069922 M * rpetre and try again 1103069948 M * rpetre i really can't mess up that one (at least not too much) 1103069957 M * Bertl okay, please keep me informed ... 1103069970 M * rpetre i will, thanks for the patience 1103069978 M * Bertl you're welcome! 1103070385 M * tnichols Bertl, I'm around now... :-) (t) 1103070392 N * tnichols tn 1103070624 M * Bertl tn: did you try something like http://vserver.13thfloor.at/Experimental/TOOLS/vflags-0.01.tar.bz2 ? 1103070638 M * Bertl does this compile for you? 1103070656 M * tn I'll try now 1103070671 M * tn yep it compiles 1103070686 M * tn hmm 1103070688 M * tn internal vflags-0.01 # ./vflags 1103070688 M * tn vc_set_flags: Function not implemented 1103070698 M * tn Linux internal 2.6.9-vs1.9.3 #1 SMP Tue Dec 14 15:08:27 CST 2004 x86_64 AMD Opteron(tm) Processor 246 AuthenticAMD GNU/Linux 1103070764 M * Bertl please try to adjust the hardcoded 273 to 236 in the include file 1103070810 M * tn internal vflags-0.01 # ./vflags 1103070810 M * tn vc_set_flags: No such process 1103070877 M * Bertl okay, that looks better, now please explain the issues you have once again ... 1103070977 M * tn I have compiled util-vserver by #including linux/autoconf.h in src/secure-mount.c and by commenting out the nice() call in the unistd wrapper header 1103071003 M * tn I get these two segfaults when trying to start a vserver 1103071004 M * tn secure-mount[21668]: segfault at 00000001bffff9a8 rip 0000000000401726 rsp 0000007fbffff6e0 error 4 1103071005 M * tn vuname[21683]: segfault at 00000004bffff8f0 rip 0000000000401f46 rsp 0000007fbfffe5d0 error 4 1103071051 M * tn (obviously it doesn't start the vserver) 1103071090 M * Bertl you have the kernel source tree at hand (with the compiled vmlinux)? 1103071095 M * tn infowolfe spent a lot of time yesterday trying to get it to go better... he tried compiling a 32bit version of util-vserver without success 1103071097 M * tn yes 1103071118 M * Bertl what is the output of 'objdump -d vmlinux | head -6 | tail -1' 1103071137 M * tn ffffffff80100000 : 1103071156 M * Bertl okay, so the segfault happens in userspace ... 1103071196 M * Bertl do you use the dietlibc? 1103071213 M * tn the only way i could get it to compile was using dietlibc and the hacks as above 1103071233 M * Bertl okay, you do not use the 'broken' dietlibc, do you? 1103071248 M * tn which one is that? :-) 1103071267 M * Bertl hmm, well, I'd say for x86_64 any, but the most recent one ... 1103071290 M * tn it is the most recent one atm (0.27) 1103071305 M * tn assuming thats the lastest ... 1103071321 M * Bertl okay, let's check anyways ... sec digging out the issue 1103071350 M * tn without my hacks it has the error: /usr/include/asm/pda.h:26: error: `CONFIG_X86_L1_CACHE_SHIFT' undeclared here (not in a function) 1103071350 M * tn -- the linux/autoconf.h defines this (hence the fix) 1103071498 M * Bertl ah, you are the lucky one with the broken kernel headers? 1103071521 M * tn its possible - a gentoo box 1103071523 M * Bertl okay, let's check that first, what does ls -la /usr/include/linux say? 1103071536 M * Bertl hmm, elt's use 1103071543 M * tn drwxr-xr-x 15 root root 16384 Dec 14 21:21 /usr/include/linux 1103071554 M * Bertl okay, that looks fine ... 1103071625 M * Bertl and after you added this, it compiles ... 1103071642 M * tn the next error is 1103071643 M * tn vserver-start/main.o(.text+0x568): In function `main': 1103071643 M * tn : undefined reference to `nice' 1103071673 M * tn so I commented out the call to nice() - dietlibc doesn't define it under x86_64 1103071675 M * Bertl looks like a totally broken setup ... 1103071680 M * tn *then* it compiles :-) 1103071703 M * Bertl okay, to me it looks like your dietlibc is outdated ... 1103071731 M * Bertl I remember that we tracked down a dietlibc issue with env being badly defined ... 1103071809 M * tn ok 1103071822 M * tn dietlibc.org is timing out, but as far as i can tell 0.27 is the latest version 1103071840 M * Bertl sec looking in the archives ... 1103071899 M * tn looking through the code of dietlibc there is no __NR_nice defined under x86_64/syscalls.h meaning nice() isn't defined as a syscall -- every other platform has it as #34 1103071923 M * Bertl well, it is supposed to be there ... 1103071994 M * tn the linux 2.6.9 kernel header asm-x86_64/unistd.h doesn't have it either 1103072000 M * tn yet every other platform defines it 1103072048 M * Bertl include/asm-x86_64/ia32_unistd.h:#define __NR_ia32_nice 34 1103072071 M * Bertl but nice() is not the syscall itself 1103072079 M * Bertl it's the libc wrapper around that ... 1103072089 M * tn ah *nod* 1103072152 M * Bertl okay, let's try to get the segfault with vuname 1103072175 M * Bertl try chcontext --ctx 100 sleep 100 & 1103072185 M * Bertl does this work or segfault? 1103072216 M * tn yep that works 1103072222 M * tn and it created the context in vserver-stat 1103072261 M * Bertl okay, then let's do vuname with appropriate arguments 1103072313 M * Bertl vuname --xid 100 -t nodename=hansi 1103072327 M * Bertl vuname --xid 100 -g nodename 1103072362 M * Bertl (within the 100s of the sleep) 1103072395 M * tn hmm 1103072402 M * tn no segfaults but it didnt work 1103072409 M * tn internal linux # vuname --xid 100 -g nodename 1103072410 M * tn internal 1103072475 M * Bertl try to find/produce a coredump with the normal startup, then look with file/gdb for the arguments 1103072492 M * Bertl ah, if it is the env issue it needs the command ... 1103072496 M * Bertl so let's try 1103072503 M * Bertl vuname --xid 100 -t nodename=hansi -- /bin/true 1103072530 M * tn Tag '/bin/true' not recognized 1103072554 M * Bertl vuname -s --xid 100 -t nodename=hansi -- /bin/true 1103072566 M * tn internal linux # vuname -s --xid 100 -t nodename=hansi -- /bin/true 1103072567 M * tn Segmentation fault 1103072567 M * tn bingo 1103072581 M * Bertl so it is the _still_ unfixed env issue 1103072599 M * tn a known problem eh? 1103072610 M * Bertl known _and_ reported ... 1103072658 M * tn anything I can do to assist debugging ..? 1103072685 M * Bertl we did already debug it .. there should be a patch somewhere ... 1103072694 M * tn ok cool 1103072955 M * tn any ideas where the patch is? :-) 1103073014 M * Bertl but I have no idea where that patch is atm, and I can't find it in the archives right now ... 1103073028 M * tn yeah I had a look myself 1103073035 M * Bertl I can give you some hints 1103073040 M * tn ok 1103073067 M * Bertl it was related to env being defined in such way that it is clobbered by another entry 1103073093 M * Bertl which has quad size but quad is wrongly defined for x86_64 as bein 4 instead of 8 bytes 1103073117 M * Bertl after adding the appropriate include file, this could be fixed 1103073147 M * tn ahh that makes sence 1103073224 M * Bertl nm -S vuname | grep env 1103073226 M * tn is this in util-vserver or kernel needed? 1103073245 M * Bertl it is needed in the dietlibc source 1103073262 M * Bertl (it's a dietlibc bug) 1103073289 M * tn right 1103073310 M * Bertl if you search the irc logs (older ones) and the mailing list archives, you might find the relevant information(and probably the aptch) 1103073322 M * tn hmm its stripped 1103073339 M * Bertl use the one in the build directory 1103073385 M * tn 0000000000504c28 0000000000000004 V __environ 1103073385 M * tn 0000000000504c28 0000000000000004 V environ 1103073385 M * tn 0000000000401f00 0000000000000098 T getenv 1103073393 M * pusling is there any nice tool to keep a debian server with multiple vservers updated? 1103073447 M * Bertl okay, I'm off for now .. back tomorrow ... 1103073458 M * tn ok thanks bertl :-) 1103073484 M * Bertl cya 1103073488 N * Bertl Bertl_zZ 1103081470 Q * sannes Read error: Connection reset by peer 1103081540 Q * grecea Ping timeout: 480 seconds 1103082404 M * tn internal dietlibc-0.27 # vuname --xid 100 -g nodename 1103082405 M * tn hansi 1103082407 M * tn woohoo 1103082484 M * tn for the record the fix is shown in this diff 1103082485 M * tn http://www.linuxtv.org/cgi-bin/cvsweb.cgi/dietlibc/syscalls.s/environ.S.diff?r1=1.9&r2=1.10 1103084121 Q * ensc Ping timeout: 480 seconds 1103084578 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de 1103085905 J * nox- ~vps@c207107.adsl.hansenet.de 1103085905 Q * nox Read error: Connection reset by peer 1103085965 N * nox- nox 1103086074 M * tn hmm freaky, to get a 32-bit environment vserver working as expected, you gotta do linux32 vserver enter 1103086093 M * tn same with starting, although is there a nice init script way of starting it in 32-bit mode by default 1103086705 M * infowolfe tn: did you get it working? 1103088272 J * DuckMaster ~Duck@dyn-83-154-82-185.ppp.tiscali.fr 1103088435 J * sannes ~ace@home.skarby.no 1103088559 Q * DuckKing Ping timeout: 480 seconds 1103089508 M * tn infowolfe, yes! 1103089523 M * tn sorry for the delay - was out having a coffe/smoke 1103089605 M * tn [root$internal]::root> vserver test start 1103089606 M * tn [root$internal]::root> vserver test status 1103089606 M * tn Vserver 'test' is stopped 1103089607 M * tn thats confusing 1103091398 M * tn rm /vservers/test/var/lib/init.d/started/* 1103091968 J * grecea ~grecea@h-195-22-237-74.mdl.net 1103093317 J * sebd_ ~konversat@lesdeveloppementsdurables.org 1103093318 Q * sebd Read error: Connection reset by peer 1103094560 Q * tchan Ping timeout: 480 seconds 1103098756 Q * nox Quit: Getting off stoned server - dircproxy 1.0.5 1103098758 J * nox- ~vps@c207107.adsl.hansenet.de 1103098810 N * nox- nox 1103099079 Q * sladen Quit: jdub 1103099265 J * sladen paul@starsky.19inch.net 1103100117 Q * berni Remote host closed the connection 1103100546 Q * nox jupiter.oftc.net neutron.oftc.net 1103100546 Q * sannes jupiter.oftc.net neutron.oftc.net 1103100546 Q * DuckMaster jupiter.oftc.net neutron.oftc.net 1103100546 Q * ensc jupiter.oftc.net neutron.oftc.net 1103100546 Q * tn jupiter.oftc.net neutron.oftc.net 1103100546 Q * lilo jupiter.oftc.net neutron.oftc.net 1103100546 Q * anonymous-coward jupiter.oftc.net neutron.oftc.net 1103100546 Q * matti jupiter.oftc.net neutron.oftc.net 1103100546 Q * TheSeer jupiter.oftc.net neutron.oftc.net 1103100546 Q * cereal|away jupiter.oftc.net neutron.oftc.net 1103100546 Q * SiD3WiNDR jupiter.oftc.net neutron.oftc.net 1103100546 Q * Plug jupiter.oftc.net neutron.oftc.net 1103100546 Q * chand jupiter.oftc.net neutron.oftc.net 1103100546 Q * UFOczek jupiter.oftc.net neutron.oftc.net 1103100546 Q * Snow-Man jupiter.oftc.net neutron.oftc.net 1103100546 Q * weasel jupiter.oftc.net neutron.oftc.net 1103100600 J * nox ~vps@c207107.adsl.hansenet.de 1103100600 J * sannes ~ace@home.skarby.no 1103100600 J * DuckMaster ~Duck@dyn-83-154-82-185.ppp.tiscali.fr 1103100600 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de 1103100600 J * tn ~tnichols@202.191.111.12 1103100600 J * lilo ~lilo@lilo.usercloak.oftc.net 1103100600 J * anonymous-coward ~nwalsh@shaggy.internode.com.au 1103100600 J * matti matti@linux.gentoo.pl 1103100600 J * TheSeer ~theseer@border.office.salesemotion.net 1103100600 J * cereal|away ~cereal@217.20.127.85 1103100600 J * SiD3WiNDR luser@bastard-operator.from-hell.be 1103100600 J * weasel ~weasel@weasel.noc.oftc.net 1103100600 J * Plug ~plug@datadot.net 1103100600 J * chand ~chand@cancun.aspic.com 1103100600 J * UFOczek ufoczek@hood.openbug.net 1103100600 J * Snow-Man ~sfrost@snowman.net 1103102607 J * jsambrook ~jsambrook@aelfric.plus.com 1103104648 J * tchan ~tchan@c-24-13-81-164.client.comcast.net 1103105617 J * Duckx ~duckx@195.75.27.158 1103106130 Q * grecea Read error: Connection reset by peer 1103106179 J * grecea ~grecea@h-195-22-237-74.mdl.net 1103106286 N * Bertl_zZ Bertl_oO 1103106457 J * t__ ~tnichols@CPE-139-168-210-50.sa.bigpond.net.au 1103106782 Q * t_ Ping timeout: 480 seconds 1103106798 J * peca ~Petr@gw001466.nsys.cz 1103108533 J * _are_ ~are@gateway-dsl.lihas.de 1103108537 M * _are_ hi 1103108786 J * berni ~berni@obelix.ipv6.birkenwald.de 1103109754 M * Duckx hy ou !) 1103111379 N * t__ t 1103111848 M * meebey more and more servers are converted to vservers 1103111850 M * meebey I love it 1103111863 M * meebey all your server are belong to vservers! 1103111885 M * _are_ oh, I just build up a new one and while I am at it I migrate in a few old ones 1103112240 Q * sannes Read error: Connection reset by peer 1103112959 N * Bertl_oO Bertl 1103112967 M * Bertl morning folks! 1103113166 M * Loki|muh morning bertl 1103113173 M * Loki|muh everything's fine again? 1103113199 M * Bertl almost perfect .. (80%) 1103113222 M * Bertl thanks for asking! 1103113267 M * Loki|muh :) 1103114966 T * * http://linux-vserver.org/ | latest stable 1.29, devel 1.3.9, 1.9.3 1103114966 T * Bertl - 1103115335 M * Bertl Eyck: are the networks on the same wire or reachable via some gateway? 1103115361 M * Bertl hmm .. have to leave now .. back later ... 1103115367 N * Bertl Bertl_oO 1103115650 M * Eyck Bertl: nope, multiple VPNs 1103117477 M * _are_ btw: the vserver-development patch 1.9.3 compiled (2.6.9 kernel) and booted fine on a dual opteron. currently setting up first vserver there 1103118930 J * monrad ~monrad@213083190130.sonofon.dk 1103119202 J * sannes ~ace@home.skarby.no 1103119418 N * Bertl_oO Bertl 1103119424 M * Bertl back now ... 1103119460 M * Bertl Eyck: if you want the vserver to 'participate' in such a network, it has to have an ip in that network ... 1103119486 M * Bertl _are_: could you try the 2.6.10-rc3-vs1.9.3.11 too? 1103119656 M * Eyck Bertl: I thought about NAT... oh well.. 1103119678 M * Bertl sure, you can do snating on the host 1103119692 M * Bertl in this case you have to setup a route for that too 1103119705 M * _are_ Bertl: yes, can try 1103119735 M * Bertl excellent! 1103121088 M * Eyck bertl: problem is, SNAT works in POSTROUTING.. 1103121100 M * Bertl that is why you need a separate route ;) 1103121102 M * Eyck hmm, oh, wait. right. 1103121119 M * Eyck there's something wrong with me lately :( 1103121121 J * phyt ~phyt@carevo-8.comnet.bg 1103121127 M * Bertl welcome phyt! 1103121139 M * Eyck rephyt! 1103121191 Q * phyt Quit: 1103121203 M * Eyck byephyt! 1103121279 M * Eyck ooh, cowloop, shiny! 1103121690 Q * sannes Read error: Connection reset by peer 1103122006 J * brc bruce@201008050118.user.veloxzone.com.br 1103122010 M * brc bertl alive ? 1103122012 M * Bertl welcome brc! 1103122019 M * brc bertl, long time nos een :) 1103122021 M * brc i've been sick again 1103122022 M * brc always 1103122022 M * brc heheh 1103122033 M * Bertl well, me too .. :/ 1103122034 M * brc I think i found abug: 1103122034 M * BWare morning 1103122042 M * brc vserver psyc start 1103122042 M * brc vcontext: vc_create_context(): File exists 1103122044 M * Bertl morning BWare! 1103122059 M * _are_ hmpf, seems I need the alpha vserver utils. ran into /proc error. 1103122073 M * Bertl brc: just means that the context already exists ... 1103122076 M * brc i had to stop all vservers, then when i try to start them i get this errors. 1103122078 M * brc I know 1103122079 M * BWare Is ng7 still (known) buggy, or is it me that can't get it to work :) 1103122082 M * brc but it doesn't 1103122089 M * brc At least, shouldn't 1103122115 M * brc [root@localhost archives]# cat /etc/vservers/psyc/context 1103122116 M * Bertl BWare: ng7.2 is highly experimental, don't expect a _normal_ vserver setup to work with it .. 1103122116 M * brc 110 1103122123 M * brc [root@localhost archives]# vserver-stat | grep 110 1103122124 M * brc 1104 14 38M 3.6K 0m19s18 0m16s77 1d39h29 c7g 1103122124 M * brc 1109 28 995.9M 8.7K 3m58s49 2m42s41 2d48h45 luiz 1103122124 M * brc [root@localhost archives]# 1103122130 M * BWare I don't even get host connectivity :) 1103122147 M * Bertl brc: cat /proc/virtual//status 1103122163 M * BWare trying to add a default route (route add / ip add route ) result in RT_UNREACHABLE 1103122173 M * brc [root@localhost archives]# cat /proc/virtual/110/status 1103122173 M * brc UseCnt: 3 1103122173 M * brc RefCnt: 1 1103122173 M * brc Flags: 0000000200000010 1103122173 M * brc BCaps: ffffffffd44c04ff 1103122175 M * brc CCaps: 0000000000000101 1103122175 M * brc Ticks: 0 1103122177 M * Bertl BWare: might happen, try with serial console or local access 1103122178 M * brc Bertl: but i stopped that vserver 1103122202 M * Bertl brc: cat /proc/virtual/110/limit 1103122239 M * BWare Bertl: I have local access, but no way to get further than the lan; eg.: I can ping the gw, but can't add a route 1103122249 M * brc [root@localhost archives]# cat /proc/virtual/110/limit 1103122249 M * brc PROC: 0 22 -1 0 1103122249 M * brc VM: 1098 40914 -1 0 1103122249 M * brc VML: 0 0 -1 0 1103122249 M * brc RSS: 0 12882 -1 0 1103122251 M * brc FILES: 21 35 -1 0 1103122251 M * brc SOCK: 0 0 -1 0 1103122253 M * brc [root@localhost archives]# 1103122282 M * Bertl BWare: okay, did you try the vnet3 script to setup a local lan connection for a context? 1103122306 M * Bertl brc: 2.6.9 kernel? 1103122307 M * BWare I have to get a vserver on it first, to try 1103122317 M * BWare but I can run the script 1103122318 M * Bertl BWare: no need to ... 1103122324 M * brc 2.6.9-vs1.9.3 1103122325 M * Bertl (the vserver part) 1103122345 M * Bertl brc: I'd try to upgrade to 2.6.10-rc3 some task related issues where fixed 1103122363 M * brc ok :) 1103122367 M * Bertl brc: you can alos try the following: mount -o remount,rw /proc 1103122380 M * brc this has hapepend with all vserver, what i am doing is changing their context 1103122383 M * brc so that i can start them 1103122420 M * Bertl if it still happens with 2.6.10-rc3-vs1.9.3.11, we'll investigate ... 1103122477 M * BWare Bertl: vnet3_setup.sh ? It creates the contexts AFAICT but complains about nonexistent devices on line 12 + 13 1103122558 M * Bertl 13 is an empty line here ... 1103122592 M * BWare hang on... let me get next to the machine, it is now a few meter away 1103122679 M * brc Bertl: ok, i will just change cntext right now, i am trying to have a big uptime.I am really happy we already have 26 days:) 1103122686 M * BWare right, line 11 + 12 1103122733 M * Bertl but the script continues fine otherwise? 1103122771 M * BWare oke, I noticed mistake one; I had to copy vnet-0.02/vnet to /tmp 1103122793 M * BWare now to patch iptables 1103122809 M * Bertl yeah, or change the path in the script 1103122816 J * sizo janek@huggz.com 1103122822 M * sizo hi 1103122838 M * Bertl welcome sizo! 1103122844 M * sizo ej Bertl :-) 1103122936 M * sizo hm is it possible that outgoing icmps from a vserver are using the vservers sourceaddr instead of the master server? 1103122950 M * Bertl yes 1103122985 M * sizo point me to a piece of docu or tell me how, please ;) 1103123022 M * Bertl hmm .. actually no (atm) because you have to define every ip you want to use inside a vserver on the host, so it's alway the sourceaddress of the host (one of them) 1103123072 M * Bertl sizo: what type of icmp do you think of? 1103123076 M * sizo ping 1103123086 M * Bertl using -I will help there ... 1103123103 M * sizo okay i'll try, thanks 1103123115 M * Bertl you're welcome 1103123270 M * sizo where do i have to specify that -I ? 1103123291 M * Bertl in the ping command ... like this : ping -I 192.168.0.2 192.168.0.1 1103123295 M * sizo ah ok 1103123464 M * sizo same..:/ 1103123498 M * Bertl ahem, we are talking about 2.6/1.9 or 2.4/1.2? 1103123514 M * sizo 2.4/1.23 1103123515 M * sizo -3 1103123523 M * sizo 2.4.26-vs1.28 1103123525 M * Bertl hmm, ping is disabled there ... 1103123543 M * sizo hm 1103123545 M * sizo ok 1103123552 M * sizo anyway thanks! 1103123557 M * Bertl but let me check what happens if you add CAP_NET_RAW 1103123566 M * Bertl (what you actually do) 1103123573 M * sizo S_CAPS="CAP_NET_RAW" 1103124014 M * BWare Bertl: oke had some issues patching iptables, but got that going ... script now runs and finishes with 4x vc_add_vndev: Invalid argument 1103124055 M * Bertl sizo: works here .. setup: 1103124067 M * Bertl # ip addr ls 1103124073 M * Bertl 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 1103124073 M * Bertl link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff 1103124073 M * Bertl inet 10.0.0.2/8 brd 10.255.255.255 scope global eth0 1103124073 M * Bertl inet 192.168.0.2/8 brd 10.255.255.255 scope global eth0:XXXX 1103124093 M * Bertl vserver has 192.168.0.2 1103124116 M * Bertl [root@vserver:XXXX /]ping 192.168.0.1 1103124116 M * Bertl PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 1103124116 M * Bertl 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=4.87 ms 1103124132 M * Bertl 16:19:55.766370 52:54:0:12:34:56 0:ff:a8:82:aa:7f 0800 98: 192.168.0.2 > 192.168.0.1: icmp: echo request (DF) (ttl 64, id 0, len 84) 1103124136 M * Bertl 16:19:55.766449 0:ff:a8:82:aa:7f 52:54:0:12:34:56 0800 98: 192.168.0.1 > 192.168.0.2: icmp: echo reply (ttl 64, id 6918, 1103124149 M * Bertl of course ... 1103124156 M * Bertl [root@vserver:XXXX /]ping 10.0.0.1 1103124169 M * Bertl will use 10.0.0.2 if not told otherwise 1103124177 M * Bertl 16:20:13.185654 52:54:0:12:34:56 0:ff:a8:82:aa:7f 0800 98: 10.0.0.2 > 10.0.0.1: icmp: echo request (DF) (ttl 64, id 0, len 84) 1103124181 M * Bertl 16:20:13.185739 0:ff:a8:82:aa:7f 52:54:0:12:34:56 0800 98: 10.0.0.1 > 10.0.0.2: icmp: echo reply (ttl 64, id 57248, len 1103124190 M * Bertl [root@vserver:XXXX /]ping -I 192.168.0.2 10.0.0.1 1103124202 M * Bertl again uses 192.168.x.x 1103124211 M * Bertl 16:20:24.945259 52:54:0:12:34:56 0:ff:a8:82:aa:7f 0800 98: 192.168.0.2 > 10.0.0.1: icmp: echo request (DF) (ttl 64, id 0, len 84) 1103124214 M * Bertl 16:20:24.945402 0:ff:a8:82:aa:7f 52:54:0:12:34:56 0800 98: 10.0.0.1 > 192.168.0.2: icmp: echo reply (ttl 64, id 6919, len 84) 1103124242 M * Bertl BWare: invalid argument means you got something wrong either with the setup or patching ... 1103124288 M * BWare Bertl: I didn't get that error the first run - after copying vnet to /tmp 1103124301 M * Bertl ah, so you started it twice? 1103124304 M * BWare yep 1103124318 M * Bertl well, that's not working yet ;) 1103124325 M * BWare I know 1103124330 M * BWare rebooting as we speak :) 1103124393 M * BWare still odd that local routing is not working ... 1103124412 M * Bertl well, the routing tables are modified somewhat 1103124419 M * BWare ah 1103124425 M * Bertl and I'm pretty sure there are bugs all over .. 1103124437 M * BWare oke, script runs without errors... 1103124451 M * Bertl it's more a kind of 'working' prototype ... 1103124469 M * Bertl you can now do 'chcontext --ctx 100 /bin/bash 1103124483 M * Bertl and play around with ifconfig and ping ... 1103124514 M * Bertl udp and tcp should work too ... but not tested yet 1103124535 M * BWare so I should be able to ping the host itself from within the context ? 1103124557 M * Bertl the network you configured, maybe the host too (unlikely) 1103124597 M * Bertl look at it like a bunch of completely separated servers just using the same nic 1103124609 M * Bertl they do not know of eachother atm ... 1103124646 M * BWare I get 2 interfaces ; lo and en0 1103124658 M * Bertl yep, the ones created with vnet ... 1103124671 M * Bertl you can rename them as you like (nameif) 1103124694 M * BWare I can ping the local interface 1103124709 M * Bertl yep, it's also accounted accordingly 1103124717 M * BWare but I don't get an arp from the remote end (.1 ) 1103124744 M * Bertl is that a separate machine or the host? 1103124755 M * BWare which should be the host if i understand it correctly 1103124774 M * Bertl nope, host will not respond to packets from/to vservers and vice versa 1103124782 Q * logger Ping timeout: 480 seconds 1103124787 M * BWare oke, so that behaviour changed :) 1103124808 M * Bertl it's because we need some kind of virtual switch to do that 1103124823 M * Bertl which handles the arp stuff and the reflection 1103124828 M * BWare shweet 1103124837 M * BWare proxy-arping on the host ? 1103124837 M * _are_ vserver-utils-0.30.196 are a bit unwilling to compile for 64bit Opterons, it seems. and with the old tools /proc is claimed to be broken. None in here has a binary 64bit version by chance? 1103124864 M * Bertl nope, but should succeed with 0.30.196 if you do the following: 1103124867 M * BWare brb ... 1103124912 M * Bertl _are_: get the latest dietlibc, get the patch mentioned a few hours ago, patch and build it ... then add missing/wrong/required include files where appropriate 1103124938 M * Bertl (dietlibc seems broken on x86_64 in several ways) 1103124942 M * _are_ uhm, I actually don't want to run dietlibc 1103124948 M * _are_ and atm i don't. 1103124968 M * Bertl well, then you have to fix whatever is broken with your glibc ;) 1103124974 M * _are_ :-> 1103124992 M * _are_ src/keep-ctx-alive.c: In function `doit': 1103124992 M * _are_ src/keep-ctx-alive.c:144: error: `__arr' undeclared (first use in this function) 1103125043 M * Bertl 144 FD_ZERO(&fd_set); 1103125051 M * Bertl where is FD_ZERO defined? 1103125104 M * _are_ at least not in utilvserver source.... 1103125110 M * Bertl man 2 select 1103125142 M * Bertl /usr/include/sys/select.h 1103125201 M * _are_ would not have looked in manpages, but found same file with find|xargs grep 1103125203 M * Bertl so once you got working headers .. or know how to make them work ... then the tools will compile fine ... 1103125273 M * Bertl I really don't know why x86_64 is _so_ broken ... 1103125373 Q * peca Quit: Quit 1103125464 M * _are_ gnnn, it is another define and that one is again in /usr/include/i386-linux/asm/posix_types.h, which is not excatly same as amd64 1103125497 M * Bertl well, I wouldn't use the i386 assembler code if you are compiling 64 bit 1103125517 M * Bertl (best would be to use the C version) 1103125575 M * _are_ uhm? Have not been coding/debugging in that area before. how can I use a C version? any keyword to look for? 1103125602 M * Bertl IIRC .. /usr/include/bits/select.h includes a C fallback 1103125634 M * Bertl but maybe that fallback is used here ... the _arr would point in this direction 1103125657 M * Bertl maybe it just hasn't been updated, or requires another include 1103125665 M * _are_ /usr/include/bits/select.h has no #include statement at all here 1103125788 M * BWare Bertl any suggestions on how to get routing going with ng7 ? ip route add default via 192.168.0.x fails with RTNETLINK answers: Network is unreachable 1103125814 M * Bertl forget it for now, if possible keep local ... 1103125820 M * BWare Which is the same on the host itself 1103125831 M * BWare so no networking at all on the box then 1103125845 M * Bertl should work for the local lan 1103125870 M * BWare well, sort off ;) I can ping LAN workstations from the host itself 1103125880 M * BWare but routing is a no go 1103125906 M * Bertl sec 1103125978 M * BWare btw I started with the provided config - kernel-ng5.config 1103126237 N * cereal|away cereal 1103126249 M * Bertl aloha cereal! 1103126525 M * Bertl BWare: changing the line 456 in net/ipv4/fib_semantics_ngnet.c 1103126533 M * Bertl to: .nfxid = current->xid }; 1103126537 M * BWare oke 1103126549 M * Bertl will fix that issue for the host ... not sure about the vservers 1103126576 M * Bertl okay, leaving now .. back later, thanks for testing! 1103126583 M * BWare no problem 1103126587 M * BWare later :) 1103126606 M * Bertl btw, a list of stuff which _doesn't_ work would be nice to have ... 1103126627 M * BWare hehehe 1103126639 M * BWare I'll see what I can find and post it to the list 1103126641 M * Bertl okay, cya ... 1103126645 M * BWare cya 1103126651 N * Bertl Bertl_oO 1103127084 M * _are_ hmm, that is strange, I renamed all variables in 'doit()' from fd_set to fd_set1 (they are type fd_set) and whooops, it compiles. 1103127146 M * BWare Bertl: local routing seems to work again after the change 1103127994 J * L-away ~Fr3D@dust.hfc.tvsatbg.net 1103128123 P * L-away 1103128444 J * logger ~rs@vds.pas-mal.com 1103128656 J * sannes ~ace@home.skarby.no 1103128730 J * The_Eye ~kblackwel@tusk-234.speedsite.com 1103128760 M * The_Eye Anyone know of a tool to copy a vserver and the tool changes the IP address? 1103128982 Q * logger Ping timeout: 480 seconds 1103129041 M * _are_ The_Eye: I understand vserver-debiantools have things like that. (though I am still at my first vserver, copying will happen tomorrow) 1103129418 J * logger ~rs@vds.pas-mal.com 1103129626 J * grecea_ ~grecea@h-195-22-237-74.mdl.net 1103129627 Q * grecea Read error: Connection reset by peer 1103130060 M * The_Eye thanks, Ill take a look at that 1103130096 M * _are_ just tried it, dupvserver is the command from the package 1103130102 M * _are_ and it even worked ;) 1103130457 Q * tchan Ping timeout: 480 seconds 1103130694 J * smekkawi ~smekkawi@ip37net160.skylogicnet.it 1103130838 J * ni ~ni@riva.ni.fr.eu.org 1103130886 M * ni hi 1103130886 Q * sannes Read error: Connection reset by peer 1103131027 J * tchan ~tchan@c-24-13-81-164.client.comcast.net 1103131199 M * The_Eye _are_ you running debian? 1103131204 M * _are_ yes 1103131252 M * The_Eye stable? 1103131270 M * _are_ i run dual-Operons with pure64 -> sid atm 1103131289 M * The_Eye _are_ no debian stable, unstable, testing? 1103131298 M * _are_ sid=unstable 1103131307 M * _are_ pure64 = code for amd64 architecture 1103131315 M * The_Eye Yea, verserver-debiantools is only unstable 1103131329 M * _are_ well, you can get it anyway as source an dbuild it 1103131335 M * The_Eye hmmm 1103131376 M * _are_ running stable i would love, but no way to do it eficiently with these opterons 1103131463 M * The_Eye Thanks sometime my brain aint working 1103131556 M * _are_ ah well, i tried and boot with the ia64 netboot first and wondered why it said unbootable CD :-> 1103131792 Q * tchan Remote host closed the connection 1103132114 J * tchan ~tchan@c-24-13-81-164.client.comcast.net 1103132466 Q * grecea_ Quit: Leaving 1103132889 M * The_Eye _are_ possible you can let me know what command line args u used to run depvserver? 1103132946 M * _are_ uhm, sure 1103132985 M * _are_ dupvserver --from master --to source --ip 10.1.1.4 1103133006 M * _are_ source is the new name (the special compile server for the other vservers sotwrae) 1103133033 M * The_Eye _are_ what about the args for hostname and domain? Did u use those? 1103133170 M * _are_ uhm, not in that call 1103133178 M * _are_ thought i used them :-) 1103134033 N * cereal cereal|badewanne 1103134422 N * cereal|badewanne cereal|away 1103135342 J * ni_ ~schodet@gw-labos-infos.efrei.fr 1103135355 M * ni_ hi again 1103135419 M * ni_ rs: There is no more PTY on my VDS, wasn't the problem fixed? 1103135444 M * rs ni_: thre is a problem on a filer 1103135592 Q * Duckx Quit: Leaving 1103135874 M * ni_ rs: so it is not the same problem than before? 1103136180 Q * smekkawi Quit: Leaving 1103136486 Q * _are_ Quit: Disconnecting 1103136925 M * rs ni_: no 1103136939 M * rs this time it's an hardware issue, now fixed 1103136943 M * rs should work now 1103136963 M * ni yes, it works, thanks 1103138073 J * sannes ~ace@home.skarby.no 1103138498 M * sizo moin 1103139126 Q * rs Ping timeout: 480 seconds 1103139794 J * mhepp ~mhepp@r72s22p13.home.nbox.cz 1103141447 Q * ni_ Quit: leaving 1103141481 M * ni bye 1103141591 P * ni 1103142451 Q * jsambrook Ping timeout: 480 seconds 1103144619 Q * mhepp Quit: mhepp caught signal: Autobus error 1103144890 N * Bertl_oO Bertl 1103144922 M * Bertl evening folks! 1103145176 Q * The_Eye Quit: BitchX: the OTHER white meat 1103148199 Q * monrad Quit: Leaving 1103150809 M * tn howdy all 1103150824 M * tn Bertl, I got my amd64 vservers working 1103150824 Q * sannes Read error: Connection reset by peer 1103150851 M * Bertl tn: excellent ... fixed the dietlibc bug? 1103150857 M * tn yeah 1103150877 J * _Plug ~plug@datadot.net 1103150888 M * sizo n8 1103150897 M * tn the fix was *real* simple 1103150940 Q * Plug Ping timeout: 480 seconds 1103150972 M * tn http://www.linuxtv.org/cgi-bin/cvsweb.cgi/dietlibc/syscalls.s/environ.S.diff?r1=1.9&r2=1.10&f=u 1103150999 M * tn apply that patch to dietlibc and it fixes the segfaults for util-vserver, after patching util-vserver slightly 1103151030 M * Bertl okay, could you please put that together in an email to the ml? 1103151045 M * Bertl (maybe with a patch for util-vserver) 1103151140 M * tn I'll do that shortly... but there is one question i have about util-vserver 1103151156 M * Bertl let's hear ... 1103151162 M * tn for 32-bit vservers ideally it would be good to include a call to linux32 before chrooting 1103151167 M * tn so it gets the i686 in uname 1103151180 M * tn the best spot I can see from the scripts is: 1103151181 M * tn [root$internal]::util-vserver> grep EXTRA_CMDS * 1103151181 M * tn vserver.functions:declare -a VSERVER_EXTRA_CMDS=() 1103151181 M * tn vserver.start: "${VSERVER_EXTRA_CMDS[@]}" \ 1103151189 M * tn except i can't see where that is defined :-) 1103151214 M * Bertl well, the 'declare' defines the array here ... 1103151226 M * Bertl and the ${VSERVER_EXTRA_CMDS[@]} executes them ... 1103151277 M * tn yeah, but how do i fill the array? 1103151303 M * Bertl VSERVER_EXTRA_CMDS=( true false ) 1103151332 M * Bertl I guess it has to be in the environment or so 1103151484 M * Bertl but in any case I would send this suggestion to the mailing list, with a cc to enrico ... 1103151575 M * tn ok :-) 1103151917 J * _are_ ~are@dsl-082-083-150-234.arcor-ip.net 1103151920 M * _are_ hi 1103151942 M * Bertl hey _are_! 1103152043 M * _are_ Bertl: made the vserver-utils compile by a trick i don't understand. 1103152062 M * Bertl hmm .. tn succeeded too .. 1103152076 M * _are_ as it continued complaining about this symbol, I just renamed the variable within that function 1103152079 M * _are_ then it worked. 1103152093 M * Bertl hmm, from __arr to ? 1103152094 M * _are_ just appended a 1 everywhere. :*) 1103152137 M * Bertl interesting .. well, never understood those glibc headers ... 1103152147 M * Bertl basically __ denotes a local variable/type 1103152159 M * Bertl so it should not matter what you use there ... 1103152226 M * _are_ nope, fd_set fd_set1; 1103152237 M * _are_ had been a declaraction of fd_set as type fd_set 1103152282 M * _are_ so i renamed the variable to fd_set1 in that function (src/keep-ctx-alive.c, doit(), line ~150) 1103152289 M * _are_ and whoops it worked fine 1103152301 M * Bertl hmm ... interesting ... 1103152318 M * _are_ in my understanding it should not make a difference unless i found a compiler bug. 1103152430 M * Bertl could you try the following: 1103152443 M * Bertl cat >test.c 1103152446 M * Bertl typedef int karli; 1103152450 M * Bertl intmain(int argc, char *argv[]) 1103152457 M * Bertl int main(int argc, char *argv[]) 1103152461 M * Bertl { 1103152468 M * Bertl int karli = 7; 1103152474 M * Bertl exit(karli); 1103152478 M * Bertl } 1103152483 M * Bertl CTRL-D 1103152490 M * Bertl then compile and 1103152496 M * Bertl ./a.out ; echo $? 1103152538 M * Bertl (or did I get it wrong?) 1103152577 M * _are_ # ./a.out ; echo $? 1103152577 M * _are_ 7 1103152601 M * Bertl okay, so that works fine ... what did I miss? 1103152611 M * _are_ different situation 1103152620 M * _are_ kali kali would be the right definition 1103152647 M * _are_ but the error doesn't occur there, either 1103152661 M * Bertl yeah, should work fine too ;) 1103152690 M * _are_ typedef int karli; 1103152690 M * _are_ int main(int argc, char *argv[]) 1103152690 M * _are_ { 1103152690 M * _are_ karli karli = 7; 1103152692 M * _are_ exit(karli); 1103152692 M * _are_ } 1103152708 M * _are_ this is for me same situation as in util-vserver 1103152716 M * _are_ but here the error doesn't occur 1103152769 M * Bertl okay, anyway you fixed it for now, maybe enrico can shed some light on this issue ... just post the details to the ml, as hopefully tn will do ... 1103152775 M * _are_ hmm, it is &fd_set1 ther mostly 1103152791 M * _are_ eeek, not yet on the ml. :-) 1103152920 M * _are_ changed it back now and it is broken again. 1103152936 M * _are_ guess worth a bug report indeed 1103153739 M * Bertl okay off for today ... 1103153752 M * Bertl have a nice one everyone! cya tomorrow! 1103153768 N * Bertl Bertl_zZ 1103155177 J * rs ~rs@imhotep.rhapsodyk.net