1171325416 M * doener Bertl: did you see containers v7 on lkml? (or my wiki entry for it)
1171325498 M * doener you didn't appear on CC, so I thought I'll better ask...
1171325556 M * Bertl hmm, have to check it, but I guess I saw it
1171325823 Q * bonbons Quit: Leaving
1171326462 M * Bertl doener: what is your opinion on the containers stuff?
1171326507 M * doener I didn't follow it since about start of december.
1171326611 M * doener in part because I somehow had the impression of various groups going into different directions with a lack of cooperation, then going in circles and finally trying to push their own ideas over and over again... but then again, I did really just glance over the threads most of the time, due to lack of time, so many I missed important stuff...
1171326638 M * doener s/many/maybe/
1171326709 M * Bertl yeah, IMHO the containers stuff reminds me too much of ckrm, which definitely was a disaster :)
1171326766 M * doener I never really got into the whole ckrm stuff, I heard about some LV+ckrm integration, then I heard less about it, and then I heard that ckrm sucks... And that's about it :)
1171326787 M * dhansen Bertl: ckrm existed for probably two years before you even heard of it! :)
1171326788 Q * Aiken_ Read error: Connection reset by peer
1171326795 M * dhansen I _hope_ containers isn't going in that direction
1171326810 J * Aiken_ ~james@ppp109-15.lns2.bne4.internode.on.net
1171327143 M * Bertl dhansen: well, it looks like it is going there to me, no?
1171327196 M * Bertl dhansen: cpusets as basic framework for a container, hierarchical structures, complicated multilevel accounting
1171327222 M * Bertl dhansen: please correct me if I'm wrong here ...
1171327253 M * dhansen Bertl: My personal feeling was that all of the CKRM development was done behind closed doors
1171327263 M * dhansen we're trying to be as open as possible with containers
1171327301 M * dhansen I wish the accounting was simple, but I'm quite sure that it isn't as twisted as CKRM's ;)
1171327316 M * Bertl okay, let me put it the other way round, is there somebody using the container stuff in real world aplications atm?
1171327355 M * dhansen The existing code?  
1171327366 M * Bertl i.e. somebody who will provide feedback like, "it doesn't work on my machine", or "how can I do this and that"
1171327476 M * dhansen I wish we had more.  But, we have a bit of a chicken-and-egg problem if we require that
1171327490 M * dhansen IBM's customers don't like running bits and pieces cobbled together from mainline :(
1171327525 M * Bertl dhansen: wish we had more implies you have at least some of them, yes?
1171327545 M * Bertl dhansen: could you make a contact to somebody using this framework, I'd be really interested in a chat
1171327578 M * dhansen I wish we had people willing to do that!!
1171327587 M * dhansen I'm not aware of anybody actually using it in production
1171327603 M * dhansen the closest we probably have are the OpenVZ folks
1171327616 M * Bertl but it will be the future IBM container solution? :)
1171327641 M * dhansen I sure hope so
1171327954 M * Bertl interesting ...
1171328186 P * stefani I'm Parting (the water)
1171329384 Q * dna Quit: Verlassend
1171331205 Q * pflanze Ping timeout: 480 seconds
1171331609 J * olivierk ~olivier@olivierk.org
1171331719 Q * olivierk_ Ping timeout: 480 seconds
1171333930 M * Bertl daniel_hozac, doener: ping?
1171333967 M * doener pong
1171334026 M * Bertl I'm wondering, regarding the disk limits, would it make sense to auto-add hashes (disk limit hashes) for tagged files, which are not there?
1171334079 M * Bertl i.e. if you configure dlimits for a guest, accounting will run independant of the guest's lifetime (unless you take down the hash at startup)
1171334098 M * Bertl (note: that is the current behaviour)
1171334138 M * Bertl so, it might make sense to have those hashes kind of auto allocated when the first file with an unknown xid is encountered
1171334276 M * doener sounds reasonable. But I still have no clue about the whole disklimits system. That and the syscall switch "command id" macros are the two areas I always avoided ;)
1171334508 M * Bertl well, it is quite simple actually .. it all boils down to having tuples (superblock, tag) with some accounting struct associated
1171334557 M * Bertl whenever an inode is created or destroyed, or a block is added or removed, the accounting is updated
1171334585 M * Bertl setting limits there, will simply block that allocation when over limit
1171334796 M * doener ok.
1171335917 J * ensc ~irc-ensc@p54B4FF89.dip.t-dialin.net
1171336434 Q * hardwire Ping timeout: 480 seconds
1171340087 J * FireEgl Proteus@2001:5c0:84dc:1:211:9ff:feca:b042
1171340735 M * daniel_hozac Bertl: well, recent util-vserver (0.30.213) will remove the disk limit on stop, after saving it.
1171340756 M * Bertl daniel_hozac: is that a good approach?
1171340771 M * daniel_hozac only sane way i can think of...
1171340773 M * Bertl i.e. wouldn't it be better to keep it running?
1171340780 M * daniel_hozac how would you otherwise remove a disk limit?
1171340802 M * Bertl hmm, good point
1171340838 M * Bertl daniel_hozac: got a moment for neuralis?
1171340854 M * daniel_hozac sure.
1171340857 M * Bertl he is trying to build util-vserver 0.30.213 on ubuntu
1171340883 M * neuralis daniel_hozac: line 721, file 'functions', stock: "exec &>>$ttyname" syntax errors. changing to "exec >>$ttyname&" fixes the problem.
1171340918 M * Bertl hmm, isn't &> short for 2> 1>&2 or so?
1171340967 M * Bertl daniel_hozac: btw, the main issue is that it segfaults (even for testme.sh)
1171340974 M * neuralis bertl: possibly, it's not a familiar form to me
1171340990 M * daniel_hozac yeah. so &>> is not valid?
1171341043 M * daniel_hozac Ubuntu is the one with the broken gcc/diet combo, right?
1171341051 M * neuralis krstic@aeryn:~$ echo bla &>>blup
1171341051 M * neuralis bash: syntax error near unexpected token `>'
1171341051 M * neuralis krstic@aeryn:~$ echo bla >>blup&
1171341052 M * neuralis [1] 1944
1171341068 M * daniel_hozac yeah, i see your point.
1171341071 M * Bertl neuralis: yes, but that is not what is intended here
1171341077 M * neuralis Bertl: right
1171341107 M * Bertl dd if=/dev/null bs=1 count=1 &>/dev/null
1171341116 M * Bertl does that work for you or give an error?
1171341126 M * neuralis that works fine.
1171341141 M * Bertl so the &>> seems to be the issue
1171341143 M * neuralis the &>> construct is the problem
1171341145 M * neuralis yeah.
1171341158 M * daniel_hozac so i guess it needs to be exec >>, exec 2>&1
1171341160 M * Bertl okay, guess it wont hurt to use >> and 2>&1 then ...
1171341177 M * Bertl you can put that on one line actually
1171341183 M * Bertl exec >>file 2>&1
1171341199 M * neuralis mm
1171341207 M * neuralis you're trying to get stderr output to also wind up in the file?
1171341224 M * Bertl yes, that is what I think was meant with &>> :)
1171341247 M * neuralis then >>file 2>&1 shouldn't work; order matters
1171341263 M * neuralis 2>&1 >>file should be fine, though
1171341268 M * Bertl the order is correct here, no wrong
1171341277 M * neuralis duh, sorry
1171341297 M * Bertl I'm doing a lot of bash redirection :)
1171341310 M * neuralis yep, and i'm tired :/
1171341314 M * Bertl np
1171341330 M * Bertl daniel_hozac: so any ideas to the gcc/diet issue?
1171341337 M * Bertl is there a known workaround? patches?
1171341343 M * neuralis daniel_hozac: so ubuntu builds dietlibc without ssp and with -fno-stack-protector
1171341347 M * neuralis which doesn't work
1171341354 M * daniel_hozac IIRC recompiling with stackgap instead is what fixes it.
1171341364 M * neuralis okay, i'll try that now.
1171341473 M * neuralis okay, enabled stackgap, disabled want_ssp, and -fno-stack-protector for build flags
1171341495 M * daniel_hozac (someone really ought to add the solution to Installation on Ubuntu...)
1171341633 M * neuralis rebuilding util-vserver..
1171341815 M * neuralis interesting. still segfaults.
1171341850 M * daniel_hozac and you compiled with the new diet?
1171341869 M * neuralis yep.
1171341899 M * Bertl IIRC, we have some (non Linux-VServer related) test program for that?
1171341920 M * Bertl daniel_hozac: do you have that at hand?
1171341950 M * daniel_hozac int main(int argc, char *argv[]) { char buf[16]; strcpy(buf, "a"); printf("%s\n", buf); return 0; }
1171341980 M * neuralis sec.
1171341990 M * neuralis want to try one more thing.
1171342222 M * Bertl https://wiki.ubuntu.com/GccSsp btw
1171342442 M * neuralis hm. it works neither with stackgap but without ssp, nor without both.
1171342471 M * Bertl did you try with the one liner?
1171342477 M * neuralis trying now.
1171342538 M * daniel_hozac if you can't get the one-liner to work with Ubuntu's dietlibc, you really ought to file a bug.
1171342566 M * Bertl I assume your util-vserver build isn't done with the proper dietlibc, btw
1171342589 M * Bertl (i.e., not with the one you think it is using :)
1171342659 M * neuralis it is.
1171342770 M * daniel_hozac you are building util-vserver/test programs/etc. with -fno-stack-protector now too, right?
1171342793 M * Bertl (and of course with diet prepended :)
1171342795 M * neuralis the default ubuntu build compiles dietlibc with -fno-stack-protector and without ssp.
1171342824 M * neuralis adding stackgap didn't fix the issue.
1171342836 M * neuralis would either of you like a shell on this machine?
1171342893 M * daniel_hozac well, i have to leave soon so i wouldn't be able to do anything anyway.
1171342950 M * neuralis i can catch you tomorrow, if you'd like. for the time being, i'll compile from upstream dietlibc sources and see if that fixes anything.
1171342994 M * daniel_hozac you might want to check the IRC logs.
1171342999 M * daniel_hozac around 2007-02-01T03:23:00+
1171343071 M * Bertl http://irc.13thfloor.at/LOG/2007-02/LOG_2007-02-01.txt
1171343072 M * daniel_hozac hmm, nevermind, doesn't seem to be a solution in there.
1171343144 M * Bertl ah, right, we concluded that it is an ubuntu issue, and should be fixed upstream
1171343154 M * Bertl s/upstream/distro side/
1171343178 M * neuralis hm
1171343190 M * Bertl did you get the simple test case working?
1171343204 M * neuralis i should be able to build 0.30.212-1 from feisty on edgy, and that should in theory work
1171343228 M * Bertl if that doesn't give the segfault issues, yes
1171343362 M * neuralis interestingly, edgy ships with a util-vserver package that contains 0.30.210-10 built against glibc, and this seems to work
1171343371 M * Bertl nope
1171343385 M * Bertl it will neither work (as expected) nor be secure with glibc
1171343395 M * Bertl unless compiled completely static, which I doubt they do
1171343406 M * daniel_hozac plus 0.30.210 is rather old by now.
1171343415 M * Bertl i.e. this is just wrong and untested IMHO
1171343420 M * neuralis right. so lemme see about this dietlibc mess. i'll figure this out and report tomorrow.
1171343451 M * Bertl okay, TIA
1171343547 M * neuralis the weird thing is that there just isn't that much to be broken, unless the upstream version used is broken
1171343569 M * neuralis the debian patches are very light, and mostly concern mips, hppa, and ia64
1171343591 M * neuralis i'll try with an unpatched version.
1171343592 M * daniel_hozac if the test case breaks, you have stack protector issues.
1171343651 M * Bertl well, I guess, the main patch involved here _is_ the gcc stack protection stuff :)
1171343672 M * neuralis no, the debian patch disables the stack protection.
1171343686 M * Bertl in gcc?
1171343707 M * neuralis it disables WANT_SSP in dietfeatures.h, and the build flags are already set to use -fno-stack-protector
1171343726 M * Bertl I'm not talking about dietlibc, I'm talking about the toolchain
1171343764 M * daniel_hozac well, i gotta run, good luck!
1171343770 M * Bertl daniel_hozac: cya and tx!
1171343818 M * neuralis daniel_hozac: thanks, cheers
1171344393 J * DoberMann_ ~james@AToulouse-156-1-65-253.w90-16.abo.wanadoo.fr
1171344499 Q * DoberMann[ZZZzzz] Ping timeout: 480 seconds
1171345072 Q * infowolfe_ Quit: Leaving
1171345742 J * infowolfe ~infowolfe@c-67-164-195-129.hsd1.ut.comcast.net
1171347297 J * hardwire ~hardwire@rdbck-5111.wasilla.mtaonline.net
1171347685 N * DoberMann_ DoberMann
1171348188 M * neuralis Bertl: still around?
1171348246 M * Bertl yep
1171348274 M * neuralis so, the dietlibc was a wild goose chase; the ubuntu version is perfectly fine
1171348285 M * Bertl ah, how so?
1171348287 M * neuralis the problem is the edgy gcc, which does not properly respect -fno-stack-protector
1171348310 M * Bertl hmm, wasn't that what I said? i.e. toolchain issue?
1171348336 M * Bertl could you resolve it?
1171348338 M * neuralis well, but it's not clear to me yet that it's not some screwedness in the util-vserver build setup
1171348349 M * Bertl the test code works?
1171348356 M * neuralis because building the oneliner test with the ubuntu dietlibc, and gcc -fno-stack-protector indeed disables ssp fully
1171348359 M * neuralis and the test works
1171348379 M * Bertl okay, then try the same with util-vserver
1171348397 M * neuralis have already. after adding -fno-stack-protector to the util-vserver CFLAGS, the built vnamespace binary still gets built with ssp.
1171348407 M * Bertl lol
1171348433 M * Bertl there is another -f option IIRC
1171348436 M * neuralis i just built util-vserver with gcc-3.3 (and no -funit-at-a-time in CFLAGS, since 3.3 doesn't recognize it)
1171348450 M * Bertl something like -fno-stack-protector-all
1171348471 M * neuralis sec, i'll try that.
1171348479 M * Bertl (maybe the ubuntu gcc has some smart logic to en/disable the protector)
1171348489 M * Bertl (which horribly fails here :)
1171348530 M * Bertl note, building the tools on mandriva with gcc 4.1.x works perfectly fine
1171348551 M * Bertl (so it is not a gcc issue per se, IMHO)
1171348584 M * neuralis right, it's an ubuntu being stupid issue: http://lkml.org/lkml/2006/7/29/27
1171348632 M * Bertl nice :)
1171348650 M * neuralis building with gcc-3.3 works fine, but testme.sh still fails, will paste output in a second
1171348814 M * neuralis http://pastie.caboo.se/39940
1171348840 M * Bertl sec
1171348854 M * Bertl could you do testme.sh -d too?
1171348915 M * neuralis reload the page
1171348974 M * neuralis should dynamic contexts be enabled?
1171348997 M * Bertl I _think_ the testme.sh should figure that
1171349012 M * Bertl let me give that a try here, sec
1171349048 M * neuralis sure
1171349179 M * Bertl you can do a test run with -vvv in the meantime
1171349306 M * Bertl do you get any messages in dmesg?
1171349320 M * neuralis [11692.090000] dynamic contexts disabled.
1171349343 M * Bertl okay, that is actually fine
1171349349 M * neuralis hmm
1171349358 M * neuralis the gcc version that testme.sh -vvv reports -- what's that version from?
1171349378 M * neuralis it should _not_ be the gcc version used to build the util-vserver binaries, i hope
1171349412 M * Bertl ahem, yes, it will be the one reported by the tools
1171349426 M * neuralis grumble. hang on.
1171349432 M * Bertl try 'vserver-info - SYSINFO'
1171349485 M * neuralis oh, ok, that's fine. i changed the makefile directly, the version strings just persisted from the configure stage.
1171349535 M * Bertl test kernel should be ready shortly
1171349678 M * neuralis are any of these utilities written in c++?
1171349694 M * neuralis (why on earth would they be?)
1171349698 M * Bertl yes, some are, but you should not hit those with testme.sh
1171349711 M * Bertl i.e. 95% are plain C now
1171349731 M * Bertl maybe all of them in recent versions, I do not remember
1171349763 M * neuralis root@grinch:/tmp# ./testme.sh -d -vvv 2>&1 | grep gcc
1171349763 M * neuralis (gcc version 4.1.2 20060928 (prerelease)
1171349768 M * neuralis root@grinch:/tmp# vserver-info - SYSINFO | grep gcc CC: gcc, gcc (GCC) 3.3.6 (Ubuntu 1:3.3.6-13ubuntu2)
1171349800 M * neuralis (there's a line break after 'grep gcc')
1171349806 M * Bertl just upload the -d -vvv somewhere, maybe I can tell you what causes the difference
1171349838 M * neuralis reload the paste
1171349839 M * Bertl I should have disabled reiser, gfs2 and ocfs2 on this test build :) 
1171349862 M * neuralis he
1171349864 M * neuralis *heh
1171349929 M * Bertl while the paste looks quite strange :)
1171349941 M * Bertl I guess you are seeing the kernel gcc here
1171349955 M * neuralis yes, that's what i was thinking.
1171349975 M * Bertl okay, kernel is almost done
1171350171 M * Bertl works fine here with 0.30.212 and all legacy stuff disabled (testme.sh-0.17)
1171350183 M * Bertl will now compile and test with the 0.30.213-rc2
1171350194 M * neuralis okay.
1171350267 M * Bertl http://paste.linux-vserver.org/1151
1171350451 M * neuralis so what gives?
1171350473 M * neuralis can it be that the ubuntu gcc is screwing up the kernel? that seems unlikely.
1171350631 M * Bertl everything is possible ...
1171350640 M * Bertl but the kernel is probably fine once it boots
1171350645 M * neuralis right, exactly
1171350660 M * neuralis so i'm out of plausible theories at this point
1171350669 M * neuralis it's not the stack protector
1171350686 M * neuralis any other ideas?
1171350695 M * neuralis i can rebuild the kernel with gcc-3.3 to be sure, i suppose
1171350715 M * Bertl sec, building the tools
1171350718 M * neuralis sure
1171350777 M * Bertl my devel machine is not the fastest :)
1171350849 N * DoberMann DoberMann[PullA]
1171350889 M * neuralis np
1171351036 M * Bertl you could try to compile the 0.30.212 in the meantime
1171351048 M * Bertl (so that we can compare that too)
1171351083 M * neuralis working on it already :)
1171351087 M * neuralis you used rc5?
1171351263 J * gab ~gab@158.36.45.236
1171351293 M * Bertl that was what I had compiled inside the emulation
1171351304 M * Bertl welcome gab!
1171351459 M * neuralis 212 works fully.
1171351485 M * Bertl okay, so I presume it has to do with a change in the tools, will ccheck here in a few seconds
1171351505 M * neuralis sure. i'll try to build the fc5 guest in the meantime.
1171351521 M * Bertl make that, should work now
1171351705 J * DavidS ~david@vpn.uni-ak.ac.at
1171351713 M * Bertl morning DavidS!
1171351727 M * DavidS hey bertl! 
1171351875 J * olivierk_ ~olivier@olivierk.org
1171351985 Q * olivierk Ping timeout: 480 seconds
1171352097 M * Bertl okay, this will take a little longer, my disk space is exhausted ...
1171352378 M * neuralis when running the vserver build, two out of three times, the command errors out on vc_ctx_migrate(): no such process, then it succeeds
1171352404 M * Bertl that is very strange
1171352536 M * Bertl you did patch a vanilla kernel, yes?
1171352600 M * neuralis yep.
1171352648 M * neuralis this is a new machine, nothing on there, so i'm happy to open it up if you want to perform an autopsy on all the edge cases i've seem to hit :)
1171352672 M * neuralis also, is there an easy way to make the build verbose? -v and --verbose don't work.
1171352695 M * neuralis ah, nevermind. it spews out to stdout after it gets the package lists.
1171352699 M * Bertl --debug
1171352745 M * neuralis and vyum happily pauses for 5 seconds every so often to warn me i should go complain about yum. heh.
1171352804 M * Bertl yes, patches should be available with the tools
1171352844 M * Bertl ah, did you specify a --context on guest creation?
1171352875 M * neuralis yeah
1171352898 M * Bertl which number?
1171352904 M * neuralis 1005
1171352925 M * Bertl okay, that should be fine, make sure that unique for each guest
1171352949 M * neuralis right
1171352971 M * neuralis okay, so it got built, start/enter works fine
1171352976 M * neuralis woo.
1171353044 M * neuralis now to figure out networking and package installation.
1171353123 M * Bertl installation is via vyum, as mentioned
1171353137 M * Bertl (or you can internalize the package management)
1171353154 M * waldi # vserver fc6 build -m apt-rpm -- -d fc6         
1171353154 M * waldi mount: mount point /etc/rpm does not exist
1171353156 M * waldi hrm
1171353169 M * neuralis waldi: mkdir /etc/rpm solved it here.
1171353191 M * neuralis Bertl: anything special needed for internalizing it?
1171353216 M * Bertl hmm, when you install rpm
1171353217 Q * puck Read error: Connection reset by peer
1171353225 M * Bertl that dir should be created/installed too
1171353230 M * waldi nope
1171353243 M * Bertl it isn't or it shouldn't ?
1171353267 M * waldi both
1171353277 M * waldi the primary config is /etc/rpmrc
1171353298 M * neuralis Bertl: will simply installing rpm and yum into the guest be enough?
1171353298 M * Bertl since when?
1171353317 M * Bertl neuralis: basically installing yum should suffice
1171353325 M * Bertl neuralis: it will drag in all dependancies
1171353331 M * Bertl waldi: since when?
1171353336 M * waldi Bertl: dunno
1171353357 M * Bertl waldi: I consider that a debian oddity too
1171353396 M * Bertl all rpm based distros have /etc/rpm, none of them has rpmrc
1171353396 M * waldi it was retired for /etc/rpm/macros
1171353472 M * waldi # vserver fc6 build -m apt-rpm -- -d fc6
1171353473 M * waldi E: Type 'rpm' is not known on line 8 in source list /etc/vservers/fc6/apps/pkgmgmt/base/apt/etc/sources.list
1171353484 M * waldi it tries to use the real apt for rpm based
1171353487 J * meandtheshel1 ~markus@85-124-175-56.dynamic.xdsl-line.inode.at
1171353496 J * ema ~ema@lart.galliera.it
1171353548 J * puck ~puck@leibniz.catalyst.net.nz
1171353564 M * Bertl older tools? missing tools on the host?
1171353564 M * Bertl apt-rpm is working?
1171353564 Q * ruskie Quit: Disconnecting from stoned server.
1171353582 M * waldi i have a real apt
1171353610 M * Bertl check with daniel_hozac when he's back, but IIRC, debian has no working apt-rpm
1171353628 M * Bertl so it is probably better to use yum instead
1171353660 M * Bertl vserver foo5 build -m yum --context 1005 --hostname=foo5.debian.org --interface eth0:192.168.0.1/24 -- -d fc5
1171353666 M * Bertl s/5/6/ for fc6
1171353715 Q * puck Read error: Connection reset by peer
1171353751 J * ruskie ruskie@ruskie.user.oftc.net
1171353824 M * neuralis hm. vyum complains about http://fedora.cat.pdx.edu/linux/core/5/i386/os/repodata/repomd.xml: [Errno 4] IOError: <urlopen error (-3, 'Temporary failure in name resolution')>  --- curl happily fetches the same file immediately.
1171353859 J * puck ~puck@leibniz.catalyst.net.nz
1171353880 M * Bertl probably a yum issue on ubuntu ...
1171353894 M * neuralis well, but building the server worked fine
1171353907 M * Bertl did you use a patched yum now?
1171353921 M * neuralis nope, same stock yum in edgy
1171353937 M * neuralis i didn't bother patching it since i want to do package management within the guest
1171353941 M * Bertl okay, then you might hit one of the half inside half outside resolver issues
1171353957 M * Bertl try to setup resolv.conf inside the guest first
1171353969 M * neuralis oh, i assumed vyum operated fully on the outside
1171353986 M * Bertl yes, when the patched yum knows how to handle chroots :)
1171354007 M * neuralis oh. so, i need resolv.conf inside, and nat the ip on the host?
1171354029 M * Bertl if you used the local IP I used as example, probably
1171354047 M * Bertl (you will need that anyway, once yum is active inside)
1171354076 M * neuralis right.
1171354099 M * Bertl you can also change the ip of the guest to a public one
1171354111 M * neuralis yup.
1171354113 M * Bertl in this case you do not need to setup nat
1171354135 Q * rob-84x^ Ping timeout: 480 seconds
1171354136 M * neuralis by the way, what's the standard way of controlling who can enter a guest? 
1171354170 M * Bertl only root on the host can. period.
1171354201 M * Bertl well, actually everybody having CAP_CONTEXT in theory can
1171354218 M * Bertl and probably CAP_SYS_ADMIN, for the namespaces and such
1171354243 M * neuralis eh, i'm fine with just running ssh in the guests.
1171354265 M * Bertl then whoever has the proper credentials can ssh into it
1171354273 M * neuralis yep.
1171354311 M * neuralis even with the guests having public ips, i can still firewall them on the host, correct?
1171354340 M * Bertl yes, all networking is done on the host
1171354358 M * Bertl the guest just 'borrows' the right to use the ips assigned to it
1171354391 M * neuralis right.
1171354403 M * neuralis (sorry for all the questions -- basically, this is my crash course through all of this.)
1171354424 M * Bertl np
1171354448 M * neuralis where is the out of bound per-guest data stored, such as the ip allocations?
1171354466 M * Bertl /etc/vservers/*
1171354488 M * Bertl entire config tree is in a directory per guest
1171354798 N * DoberMann[PullA] DoberMann
1171354815 J * litage ~nick@203.220.55.70
1171354818 M * litage hi guys
1171354828 M * Bertl hey litage!
1171354852 M * litage i just upgraded some packages on my vserver host, and luckily enough, it now kernel panics!  ;)
1171354870 M * Bertl sounds good, what kernel/patch version?
1171354877 M * litage Bertl: just about to paste it  ;)
1171355063 M * litage Bertl: some of the packages that were upgraded:  http://rafb.net/p/xgWglq32.html
1171355113 M * Bertl 1.9.5.6? you consider that update?
1171355133 M * litage Bertl: hahah i know, i know. but that's what's in Debian Stable
1171355154 M * Bertl sorry, we abandoned the 1.9 branch over two years ago
1171355166 M * litage hrmm
1171355186 M * Bertl it was the test branch before we made the first 2.0 release
1171355272 M * Bertl let me see if I can still fine the patch, to tell the actual date
1171355308 M * Bertl 2nd april 2005 was the last update of the 1.9.x branch
1171355361 M * Bertl around 21st of may 2005 was the 2.0 release
1171355377 M * Bertl so it's actually almost two years, not more than two years :)
1171355409 M * Bertl litage: do you have the panic somewhere?
1171355417 Q * ema Quit: leaving
1171355457 M * litage Bertl: yep, just typing it up
1171355474 M * Bertl ah, no serial console or photo camera?
1171355518 M * litage heh nope
1171355551 M * litage Bertl: panic: http://rafb.net/p/DknJoM64.html
1171355591 M * litage Bertl: there're some cd-rom problems nestled amongst those messages, but i didn't bother to include'em
1171355597 M * Bertl hmm, that is not Linux-VServer related at all
1171355612 M * Bertl it seems that devfs is not known to this kernel
1171355632 M * Bertl and so the entire system fails to do anything with devices
1171355659 M * Bertl maybe devfs was enabled before that, and is disabled/removed now?
1171355674 M * litage sec, let me check the rest of the list of packages that were updated
1171355676 M * Bertl you probably need to rebuild the initrd or so then
1171355747 M * litage Bertl: would libdevmapper1.01 have anything to do with it?
1171355793 M * Bertl unlikely, but it could, it's used for lvm2
1171355802 M * Bertl (and evms, IIRC)
1171355855 M * litage maybe it's time i upgraded to the latest linux-vserver release..
1171355871 M * litage will it be much of a headache to upgrade from my version to the current release?
1171355888 M * Bertl Linux-VServer wise? probably not
1171355903 M * Bertl the rest of your host system will have troubles with newer kernels I guess
1171355940 M * litage well i can upgrade to a newer kernel
1171355958 M * Bertl neuralis: okay, I can confirm the vc_ctx_migrate(): No such process issues with legacy disabled and 0.30.213-rc2
1171355985 M * Bertl litage: I'd suggest to get your host booting with 2.6.19.3 (vanilla, no Linux-VServer patches)
1171356008 M * Bertl once that works as expected, build a 2.6.19.3-vs2.2.0 kernel with the legacy stuff enabled
1171356025 M * Bertl get the 0.30.212 tools, enable legacy there too and everything should work
1171356038 M * harry god dammit!
1171356053 M * litage Bertl: why do you recommend 2.6.19.3?
1171356058 M * Bertl (the next step would be upgrading to a new style config, and disabling the legacy stuff)
1171356077 M * Bertl litage: because it is the most recent stable kernel for Linux-VServer
1171356103 M * harry : 09:41 lois ~ ;lsof -i :5900
1171356103 M * harry COMMAND  PID  USER   FD   TYPE DEVICE SIZE NODE NAME
1171356103 M * harry kded    3036 harry   18u  IPv6  12182       TCP *:5900 (LISTEN)
1171356103 M * harry : 09:41 lois ~ ;lsof -i :5900
1171356103 M * harry Segmentation fault (core dumped)
1171356106 M * harry : 09:41 lois ~ ;lsof -i :5900
1171356109 M * harry COMMAND  PID  USER   FD   TYPE DEVICE SIZE NODE NAME
1171356111 M * harry kded    3036 harry   18u  IPv6  12182       TCP *:5900 (LISTEN)
1171356114 M * harry : 09:41 lois ~ ;file core.4580
1171356116 M * harry core.4580: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'lsof'
1171356119 M * harry : 09:41 lois ~ ;gdb /usr/sbin/lsof core.4580
1171356122 M * harry ......
1171356123 M * litage harry: stop flooding
1171356124 M * harry "/root/core.4580" is not a core dump: File format not recognized
1171356127 M * harry wtf?
1171356135 M * litage harry: use a pastebin site, like http://rafb.net/paste/
1171356155 M * harry bleh!
1171356165 M * harry get a bigger terminal :p
1171356185 M * Bertl neuralis: it seems to be a kernel bug, at first glance .. investigating now
1171356255 M * Bertl harry: looks like gdb doesn't know this dump format?
1171356292 M * harry Bertl: dont you think that's strange?
1171356341 M * Bertl no, we had the ubuntu toolchain today, and I know that addr2line was broken for half a year, so no, not really :)
1171356415 M * harry hmm...
1171356418 M * harry linux sucks
1171356424 M * harry win++ :p
1171356445 M * harry at least windows crashes reliably!
1171356462 M * harry you can't do anything useful with it...b ut at least you know that in advance!
1171356467 M * Bertl I can provide a patch for the Linux kernel, if that is your preference
1171356483 M * Bertl (the reliable crash part)
1171356601 M * harry hehe
1171356888 Q * bj_ synthon.oftc.net nobelium.oftc.net
1171356888 Q * [PUPPETS]Gonzo synthon.oftc.net nobelium.oftc.net
1171356996 J * [PUPPETS]Gonzo gonzo@langweiligneutral.deswahnsinns.de
1171356996 J * bj_ ~bj@insanefactory.com
1171357210 M * neuralis Bertl: hm. i start the context, sshd gets launched in it, i enter it, and sshd is not on the process list?
1171357398 M * Bertl neuralis: just means that your startup script was wrong
1171357409 M * Bertl i.e. it reported sshd did start, while it didn't
1171357422 M * Bertl the reason for this is, that you have sshd running on the host
1171357438 M * Bertl which binds to 0.0.0.0, so the guest sshd cannot bind the guest ip(s)
1171357458 M * Bertl solution: restrict the host to host only ips with the Listen directive
1171357654 M * Bertl neuralis: gcc 3.3.x on your side, right?
1171357700 M * neuralis sshd    4328   root    3u  IPv6  54537       TCP *:ssh (LISTEN)
1171357703 M * neuralis you're right, as usual :)
1171357717 M * Bertl okay, the kernel is fine, userspace is broken
1171357725 M * neuralis ii  gcc-3.3                       3.3.6-13ubuntu2         The GNU C compiler
1171357725 M * Bertl and it is partially my fault
1171357760 M * Bertl we replaced the syscall wrapper recently, because of many gcc 4.0/4.1 issues
1171357779 M * Bertl and I just verified, the new wrapper miscompiles on i386 with gcc 3.3.6
1171357810 M * bXi Bertl: http://pastebin.ca/353335
1171357813 M * bXi my box :)
1171357840 M * bXi and still uberly stable
1171357850 M * Bertl nice :)
1171357905 M * bXi i wonder if there are newer versions available in gentoo now
1171358229 J * dlezcano ~dlezcano@blueice4n2.uk.ibm.com
1171358260 M * Bertl wb dlezcano!
1171358312 J * bonbons ~bonbons@83.222.37.103
1171358384 J * Val ~val@v41.org
1171358412 M * Val Hi
1171358432 M * Bertl welcome Val!
1171358454 M * Val Hi Bertl :)
1171358499 M * Val Bertl : are we close to vs2.2.0 ?
1171358513 J * dna ~naucki@192-250-dsl.kielnet.net
1171358594 M * Val and... can we get a vs2.2.0 backport for 2.6.18 kernel sources ? =)
1171358614 M * Val (yes it will be tested carefully : that's for stable debian kernel)
1171358645 M * Val as you know debian freezed etch with 2.6.18 kernel
1171358756 M * Bertl well, I don't think so, as 2.2.0 is using the namespaces
1171358762 M * Bertl which are not part of 2.6.18
1171358772 M * Val arg :(
1171358776 M * dlezcano hi all
1171358805 M * Val because i got some kernel bugs with vs patch wich is included in debian sources
1171358810 M * Val wait...
1171358826 M * Bertl well, that is not unexpected
1171358849 M * Bertl 2.6.18-3, right?
1171358858 M * Val right
1171358861 M * Val hu
1171358868 M * Val 2.6.18-4
1171358874 M * Bertl was reported and fixed around december 10th
1171358915 M * Val well, i'm usgin new 2.6.18.dfsg.1-10
1171358924 M * Val future echt ones
1171358925 M * Val -s
1171358934 M * Bertl no idea what that is :)
1171358938 M * Val ok
1171358956 M * Bertl maybe they copied the broken debian ekrnel?
1171359252 M * Val :)
1171359572 M * Val Bertl : http://zbla.net/bugs.txt (search for unhash_vx_info), is there the bugs you talk about ?
1171359714 M * Val (latest 2.6.18 with vs2.0.2.2-rc9)
1171359738 M * Val (util-vserver 0.30.211-6)
1171359771 M * Bertl times out here
1171359787 M * Val how
1171359792 M * Val that's right
1171359799 M * Val ...
1171360054 M * Bertl neuralis: okay, this will take longer, probably needs a special exception for gcc 3.3 or so
1171360069 M * Bertl I really hate how gcc is handling inline asm
1171360083 M * Bertl and I'm off to bed now ... will check it in the evening
1171360090 M * Bertl have a good one everyone! cya!
1171360096 N * Bertl Bertl_zZ
1171360247 M * Val http://paste.linux-vserver.org/1152
1171360254 M * Val ... too late :)
1171360868 J * rob-84x^ ~rob@submarine.ath.cx
1171361749 J * lilalinux ~plasma@80.69.41.2
1171366981 Q * shedi Remote host closed the connection
1171367604 J * __blue119__ root@twaren2226.niu.edu.tw
1171368065 Q * __blue119__ Quit: leaving
1171368266 Q * ElectricElf Remote host closed the connection
1171370108 Q * DreamerC Quit: leaving
1171370125 J * DreamerC ~dreamerc@125-225-101-89.dynamic.hinet.net
1171370914 J * cy_ ~fool@office.adfinis.com
1171371495 Q * hardwire Ping timeout: 480 seconds
1171371882 Q * mire Quit: Leaving
1171373112 Q * cdrx Ping timeout: 480 seconds
1171373290 Q * Aiken_ Quit: Leaving
1171374365 J * cdrx ~legoater@blueice4n2.uk.ibm.com
1171375822 Q * comfrey_ Ping timeout: 480 seconds
1171375835 M * sid3windr hmz
1171375850 M * sid3windr the areca raid status tool doesn't seem to work on 2.6.20-vs2.3.0.9
1171375854 Q * comfrey Ping timeout: 480 seconds
1171375856 M * sid3windr but I can't say if it's caused by vs or not
1171375857 M * sid3windr hmm
1171376016 A * sid3windr compiles plain 2.6.20
1171376990 M * sid3windr okay, it's not vs breaking it, sorry for the nosie :)
1171376992 M * sid3windr *nosie
1171376996 M * sid3windr goddamnit, noise!
1171377079 J * shedi ~siggi@dsl-149-109-85.hive.is
1171377939 J * Piet hiddenserv@tor.noreply.org
1171378236 J * pflanze ~chris@84-73-56-44.dclient.hispeed.ch
1171378566 M * derjohn hi, is it usual that a guest does not respect the resolv.conf within the guest? It seems to query the server that are mention in the hosts resolv.conf
1171378596 M * bonbons daniel_hozac: is it possible to configure guest with just process context but no network context using util-vserver?
1171378696 M * bonbons derjohn: it should have no access to the host's one... are you sure it's a guest app that you see using "wrong" resolv.conf data?
1171378722 M * derjohn bonbons, hm, yes it seems i have a broken bind9 cache ....
1171379563 Q * DavidS Quit: Leaving.
1171382226 J * marcfiu ~mef@aegis.CS.Princeton.EDU
1171383307 Q * cy_ Quit: QUITSPLIT
1171383754 J * stefani ~stefani@flute.radonc.washington.edu
1171384358 J * hardwire ~hardwire@rdbck-5111.wasilla.mtaonline.net
1171384943 N * Bertl_zZ Bertl
1171384983 M * Bertl morning folks!
1171385103 M * bonbons hey Bertl!
1171385226 M * stefani bom dia 
1171385767 M * Bertl bonbons: if you specify 0.0.0.0 as only ip, the network namespace should not restrict, but IIRC, it will still be created!
1171385808 M * Bertl stefani: portuguese ... nice! :)
1171385822 M * bonbons I would prefer it not being created :), an same option for all other namespaces
1171385863 M * Bertl it would make sense to add that in a generic way to util-vserver (maybe something is already there, didn't check)
1171385910 M * bonbons yep, I've seen nothing that would look like it, but didn't do an extensive search either
1171385932 M * Bertl if added, it should probably handle uts, ipc, pid, xid, nid and other upcoming spaces
1171385954 M * Bertl currently the only one you can 'disable' is the mnt/vfs namespace
1171385980 M * Bertl okay, have to run now ... back later ...
1171385983 M * bonbons yep, that's my though, being able to combine namespaces as desired would be nice, especially with all namespaces being introduced in mainline
1171386049 M * Bertl yeah, just mainline doesn't care about handling the separate namespaces ... atm, you might want to join lkml and container list discussions on that to emphasize on the importance
1171386054 M * Bertl okay, gone now ...
1171386058 N * Bertl Bertl_oO
1171386191 M * bonbons I tried to join lkml some months ago, but somehow did not get through with the subscribing email, will have to try once again (maybe with other provider)
1171387233 N * DoberMann DoberMann[PullA]
1171387664 Q * shedi Quit: Leaving
1171387737 Q * michal` Ping timeout: 480 seconds
1171387769 J * michal` ~michal@www.rsbac.org
1171387832 M * bXi yo
1171387840 M * bXi if i have 1 box
1171387873 M * bXi with mutliple guest with multiple httpds 
1171387913 M * bXi now i want to give this box 1 ip on the internet
1171387919 M * bXi but then i probably cant use all those httpds
1171387936 M * bXi unless its somehow possible to bind a subdomain to a vhost
1171387964 M * bXi s/vhost/vserver/
1171387969 M * Val ssl allow you only one virtualhost
1171387994 M * bXi i'm not using ssl
1171388002 M * Val so you can't user multiple fqdn with one https access
1171388012 M * Val i saw "httpds"
1171388015 M * bXi now i have 192.168.0.[173-179]
1171388018 M * bXi httpd's
1171388021 M * bXi like so :)
1171388022 M * Val oh
1171388023 M * Val ok
1171388111 M * Val build one new httpd guest that access other httpds then make it available with your public ip
1171388121 M * Val using mod_proxy
1171388147 M * bXi thats called reverse proxying right?
1171388221 M * Val right
1171388230 M * bXi okay i'll investigate that
1171388277 Q * ntrs__ Read error: Operation timed out
1171389175 Q * cdrx Read error: Connection reset by peer
1171389424 Q * Val Ping timeout: 480 seconds
1171389661 J * bronson ~bronson@adsl-75-36-145-145.dsl.pltn13.sbcglobal.net
1171389972 N * DoberMann[PullA] DoberMann
1171390318 J * MR^ChArMeR charmer@202.70.153.206
1171390344 P * MR^ChArMeR 
1171390506 Q * dlezcano Read error: Connection reset by peer
1171390572 N * DoberMann DoberMann[VSL]
1171390730 N * _Medivh Medivh
1171391370 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net
1171391820 J * comfrey ~comfrey@70.91.185.84
1171392130 J * comfrey_ ~comfrey@70.91.185.84
1171392192 J * rw23 squid@wwwbox.uni-mb.si
1171392263 J * comfrey__ ~comfrey@70.91.185.84
1171392312 M * rw23 ./testfs.sh tells me: iunlink chmod /mnt/file_6284: [^^^:]\n [116]# faild. what does this mean? is it a important feature?
1171392429 Q * comfrey Ping timeout: 480 seconds
1171392487 M * daniel_hozac rw23: 2.0 kernel?
1171392498 M * rw23 no 2.6
1171392520 M * daniel_hozac vserver version, i mean.
1171392604 M * daniel_hozac bonbons: no, no way to do that right now.
1171392633 M * rw23 2.6.16.29 vserver version 2.0.2-rc22
1171392644 M * daniel_hozac ... why on earth?
1171392649 M * daniel_hozac that's a really old version.
1171392707 M * rw23 its cause xen uses a 2.6.16.29 kernel and its the closest version to this xen version
1171392715 M * rw23 i have a kernel with xen and linux-vserver
1171392771 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/patch-2.6.16.38-vs2.0.3-rc1.1.diff
1171392843 M * rw23 is my problem a known bug?
1171392881 M * daniel_hozac current testfs fails on 2.0, yes.
1171392918 M * rw23 so maybe all is working korrectly?
1171392949 M * daniel_hozac 2.0.2-rc22 has a number of known bugs.
1171392965 M * daniel_hozac one of which will guests escape from their chroot.
1171393002 M * rw23 thanks for your advice
1171393049 M * rw23 i will try to get a inofficial xen patch f?or a newer kernel version
1171393061 M * rw23 and patch it with a later version of linux-vserver
1171393068 M * daniel_hozac patch above should work for 2.6.16.
1171393112 M * rw23 okay
1171393171 M * daniel_hozac but a newer version would probably be a good idea.
1171393349 M * derjohn daniel_hozac, any + or - reports about http://vserver.13thfloor.at/Experimental/patch-2.6.20-vs2.3.0.9.diff ?
1171393375 M * derjohn daniel_hozac, does 2.2.0 have capa masking ? maybe i'll go for that one then.
1171393387 M * daniel_hozac 2.2.0 has all the 2.1 features, except device mapping.
1171393388 M * derjohn does the v6 patch apply to patch-2.6.20-vs2.3.0.9.diff ?
1171393406 M * daniel_hozac there is none for it yet.
1171393412 M * derjohn does the v6 patch apply to 2.2.0 ?
1171393421 M * daniel_hozac yes.
1171393436 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/k/patch-2.6.19.2-vs2.2.0-rc9.ipv6.diff
1171393439 M * derjohn sounds like i'll like 2.2.0 ...  :)
1171393956 P * marcfiu 
1171393975 J * akaihola ~akaihola@dsl-aur-fecff800-7.dhcp.inet.fi
1171395607 J * Piet_ hiddenserv@tor.noreply.org
1171396029 Q * Piet Ping timeout: 480 seconds
1171396069 J * shedi ~siggi@ftth-237-144.hive.is
1171398363 J * marcfiu ~mef@aegis.CS.Princeton.EDU
1171398912 N * Piet_ Piet
1171400108 Q * shedi Quit: Leaving
1171401970 J * Aiken ~james@ppp109-15.lns2.bne4.internode.on.net
1171402879 Q * Piet Ping timeout: 480 seconds
1171404407 J * muuhDBX ~foo@a213-22-7-89.cpe.netcabo.pt
1171406292 J * mire ~mire@205-166-222-85.adsl.verat.net
1171406729 N * Bertl_oO Bertl
1171406739 M * Bertl evening folks!
1171406772 M * daniel_hozac evening Bertl!
1171406800 M * Bertl daniel_hozac: we have a 'new' problem with shiny15 :)
1171406809 M * daniel_hozac the gcc 3.3 one?
1171406814 M * daniel_hozac or yet another one?
1171406824 M * Bertl yup, not sure it only affects gcc 3.3 though
1171406854 M * daniel_hozac how does it miscompile?
1171406868 Q * marcfiu Quit: Download Gaim: http://gaim.sourceforge.net/
1171406881 M * Bertl thing is, gcc does not realize that the registers are used
1171406905 M * Bertl i.e. constraint says, put stuff in eax,ecx,edx (for example)
1171406908 M * daniel_hozac ah.
1171406972 M * Bertl and then, we do %1,%eax %2,%ecx ...
1171406987 M * Bertl and depending on what registers gcc did choose, things like
1171406997 M * Bertl edx = eax, eax = edx will happen
1171407006 M * daniel_hozac okay.
1171407154 Q * lilalinux Remote host closed the connection
1171407579 Q * duckx Read error: Connection reset by peer
1171408007 M * Bertl daniel_hozac: so I will try _another_ workaround today :)
1171408359 M * Bertl I had the idea to use a struct for the critical arguments
1171408366 M * Bertl so I will test that now :)
1171408884 N * DoberMann[VSL] DoberMann[ZZZzzz]
1171409084 Q * ensc Killed (NickServ (GHOST command used by ensc_))
1171409094 J * ensc ~irc-ensc@p54B4F956.dip.t-dialin.net
1171409279 M * baldy Bertl: 1 minute time?
1171409295 M * Bertl sure ...
1171409320 M * baldy http://paste.linux-vserver.org/1154 any idea how it tell me this?
1171409330 M * baldy i ran the same system i a other location
1171409337 M * baldy config is 1:1 the same
1171409522 P * stefani I'm Parting (the water)
1171409532 M * Bertl different kernel config I guess
1171409559 M * Bertl check with /proc/virtual/status
1171409597 M * baldy opBrainhall:~# cat /proc/virtual/status
1171409597 M * baldy #CTotal:        0
1171409597 M * baldy #CActive:       0
1171409597 M * baldy #NSProxy:       0       17 0 0 0
1171409606 M * baldy what i can see here?
1171409637 M * Bertl sorry, I meant the info :)
1171409648 M * Bertl /proc/virtual/info, compare it between the machines
1171409713 M * baldy both the same
1171409798 M * baldy maybe i need to install some other tools?
1171409967 M * Bertl okay, if they are the same, then your userspace tool config must differ
1171409980 M * Bertl check vserver-info - SYSINFO 
1171409990 M * Bertl (compare it again)
1171410027 M * baldy o usedother gcc versions
1171410072 M * Bertl well, I'm more concerned about the ABIs
1171410084 M * Bertl Available APIs: v13,net,v21
1171410131 M * Bertl is this the same on both systems? if so, then you must have missed a difference in the info, or your systems are identical and will behave identical
1171410160 M * baldy the one host syst is an etch system
1171410164 M * baldy debian etch 
1171410167 M * baldy the other is stable
1171410192 M * Bertl doesn't matter if you use the same tools ... does it?
1171410246 M * baldy http://paste.linux-vserver.org/1155
1171410308 M * baldy i use now 2.6.19.3 but the same error when i try it with test.sh
1171410314 J * shedi ~siggi@ftth-237-144.hive.is
1171410324 M * Bertl oh, my ...
1171410339 M * Bertl first, you should really read the output :)
1171410345 M * Bertl              Use dietlibc: no (you have been warned)  
1171410360 M * Bertl second, those are definitely different, no?
1171410364 M * Bertl            Available APIs: v13,net  
1171410368 M * Bertl            Available APIs: compat,v11,fscompat,v13,net,oldproc,olduts  
1171410388 M * Bertl so, no wonder the one works, while the other doesnt ...
1171410426 M * Bertl (actually, there is not much both have in common :)
1171410467 M * baldy strange
1171410476 M * baldy dont now why it is
1171410519 M * Bertl but I'm optimistic, if you select the missing APIs, it will work
1171410538 M * Bertl try to configure with --enable-apis=NOLEGACY
1171410698 M * baldy ii  dietlibc                 0.30-4                          diet libc shared libraries - a libc optimize
1171410701 M * baldy ii  dietlibc-dev             0.30-4                          diet libc - a libc optimized for small size
1171410704 M * baldy strange.. is installed
1171410744 M * Bertl well, maybe you did disable it with configure?
1171410769 M * Bertl if not, upload the config.log somewhere, so that we can check that
1171410876 M * baldy why i allwys find only Available APIs: v13,net
1171410906 M * Bertl did you add --enable-apis=NOLEGACY ?
1171410925 M * litage Bertl: yesterday, you suggested i "build a 2.6.19.3-vs2.2.0 kernel with the legacy stuff enabled". what do you mean by "with the legacy stuff enabled"?
1171410950 M * baldy erm noipe.. but now hehe
1171410954 M * baldy looks good
1171410994 M * Bertl litage: CONFIG_VSERVER_LEGACY, CONFIG_VSERVER_LEGACYNET, CONFIG_VSERVER_LEGACY_VERSION
1171411015 M * Bertl (if you want to stay with the old tools, otherwise forget the CONFIG_VSERVER_LEGACY_VERSION)
1171411038 M * baldy chcontext is working.
1171411038 M * baldy chbind: kernel does not provide network virtualization
1171411038 M * baldy chbind: kernel does not provide network virtualization
1171411039 M * baldy chbind failed!
1171411044 M * baldy same error
1171411070 M * Bertl daniel_hozac: btw, can we make some kind of chart, which API is working with what kernel config and what tools? as I completely lost the overview ...