1164759513 M * Schaka yes. nothing works. kein bock mehr. asdf! dieser kack-exim bringt mich jedes mal zur weißglut. ich geh pennen. 1164759540 M * Schaka thx anyway 1164760308 M * derjohn Schaka, hf and think about postfix :) 1164760422 Q * praeR Quit: Quitte 1164761393 Q * cuerva Ping timeout: 480 seconds 1164761423 J * cuerva ~soatola42@82.153.18.114 1164761988 J * _mcp ~hightower@wolk-project.de 1164762065 Q * mcp Read error: Connection reset by peer 1164762070 N * _mcp mcp 1164764902 J * marcfiu ~mef@68.39.177.97 1164765041 Q * sc0tt Ping timeout: 480 seconds 1164765122 Q * lylix Ping timeout: 480 seconds 1164765211 J * sc0tt ~scott@209.51.169.84 1164765357 Q * Wonka Ping timeout: 480 seconds 1164765374 J * A-liyaoshi ~asdf@220.248.100.66 1164767277 Q * A-liyaoshi 1164768301 Q * bronson_ Ping timeout: 480 seconds 1164768754 Q * dna_ Quit: Verlassend 1164769226 Q * meandtheshell Ping timeout: 480 seconds 1164769241 J * sally ~sally@222.92.109.226 1164769333 Q * Schaka Ping timeout: 480 seconds 1164769592 P * marcfiu 1164769942 J * meandtheshell ~markus@85-124-37-118.dynamic.xdsl-line.inode.at 1164770784 Q * meebey lithium.oftc.net testlink-alpha.oftc.net 1164770784 Q * harry_ lithium.oftc.net testlink-alpha.oftc.net 1164770784 Q * bon lithium.oftc.net testlink-alpha.oftc.net 1164770784 Q * doener lithium.oftc.net testlink-alpha.oftc.net 1164770784 Q * tokkee lithium.oftc.net testlink-alpha.oftc.net 1164770805 J * doener ~doener@host.magicwars.de 1164770834 J * tokkee tokkee@casella.verplant.org 1164770846 J * bon bon@blij.in-de.eu 1164770849 J * harry ~harry@d54C2508C.access.telenet.be 1164770868 J * meebey meebey@booster.qnetp.net 1164770977 Q * DreamerC_ Quit: leaving 1164770999 J * DreamerC ~dreamerc@61-224-132-241.dynamic.hinet.net 1164771278 N * Bertl_oO Bertl 1164771300 M * Bertl back now ... got a little later than expected 1164773139 J * _mcp ~hightower@wolk-project.de 1164773145 Q * mcp Read error: Connection reset by peer 1164773155 N * _mcp mcp 1164774781 J * Wonka produziert@chaos.in-kiel.de 1164774821 M * Bertl wb Wonka! 1164776902 J * bronson_ ~bronson@adsl-75-36-144-172.dsl.pltn13.sbcglobal.net 1164777543 J * Loki|muh_ loki@satanix.de 1164777543 Q * Loki|muh Read error: Connection reset by peer 1164777556 N * Loki|muh_ Loki|muh 1164778335 J * mire ~mire@179-167-222-85.adsl.verat.net 1164779138 J * Piet hiddenserv@tor.noreply.org 1164779421 Q * bronson_ Ping timeout: 480 seconds 1164779693 Q * mire Ping timeout: 480 seconds 1164780714 J * mire ~mire@243-166-222-85.adsl.verat.net 1164781950 M * Bertl night everyone! I'm off to bed now ... 1164781956 N * Bertl Bertl_zZ 1164784310 Q * fs Quit: changing servers 1164784320 J * fs fs@213.178.77.98 1164787095 M * Wonka grmpf. internet outage for several hours, apparently 1164789001 J * dna_ ~naucki@248-210-dsl.kielnet.net 1164789068 M * borgfish good morning 1164789288 Q * Aiken Quit: Leaving 1164789324 Q * eyck Ping timeout: 480 seconds 1164790595 J * Torsti76 tkurbad@gate.iwm-kmrc.de 1164790919 J * prae ~Benjamin@host.187.57.23.62.rev.coltfrance.com 1164792105 J * DavidS ~david@chello062178045213.16.11.tuwien.teleweb.at 1164794458 J * cdrx ~legoater@cimai.net4.nerim.net 1164794531 Q * sally Quit: Leaving 1164794693 Q * daniel_hozac Ping timeout: 480 seconds 1164794877 M * sid3windr Wonka: nah, internet was fine 1164795649 Q * DavidS Ping timeout: 480 seconds 1164796962 J * soatolaEspera ~soatola42@82.153.18.114 1164797017 J * hansi33 ~chatzilla@85-125-205-34.work.xdsl-line.inode.at 1164797318 Q * cuerva Ping timeout: 480 seconds 1164797349 J * eyck ~eyck@nat-old.nowanet.pl 1164797422 Q * Johnnie Ping timeout: 480 seconds 1164797602 J * lilalinux ~plasma@dslb-084-058-195-063.pools.arcor-ip.net 1164798396 J * Schaka schak@dslc-082-082-086-052.pools.arcor-ip.net 1164798966 Q * eyck Read error: Connection reset by peer 1164799001 J * eyck ~eyck@nat-old.nowanet.pl 1164799153 Q * cdrx Ping timeout: 480 seconds 1164799175 Q * hansi33 Read error: Connection reset by peer 1164799381 J * marcfiu ~mef@c-68-39-177-97.hsd1.nj.comcast.net 1164800792 J * klausk ~klausk@200-232-244-96.dsl.telesp.net.br 1164801300 J * hansi33 ~chatzilla@85-125-205-34.work.xdsl-line.inode.at 1164801310 J * Johnnie ~jdlewis@jdlewis.org 1164801334 Q * eyck Read error: Connection reset by peer 1164801346 J * eyck ~eyck@nat-old.nowanet.pl 1164801618 Q * ensc Killed (NickServ (GHOST command used by ensc_)) 1164801628 J * ensc ~irc-ensc@p54B4D45E.dip.t-dialin.net 1164801700 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net 1164801714 Q * soatolaEspera Ping timeout: 480 seconds 1164802525 J * eyck_ ~eyck@nat-old.nowanet.pl 1164802526 Q * eyck Read error: Connection reset by peer 1164803256 M * Wonka sid3windr: there was a local disturbance in the force... 1164803286 M * sid3windr :) 1164803484 M * Wonka power loss at a PBX, I heard 1164803497 Q * eyck_ Read error: Connection reset by peer 1164803827 J * daniel_hozac ~daniel@c-2c1472d5.010-230-73746f22.cust.bredbandsbolaget.se 1164805264 M * borgfish and now my sun enterprise died 1164805714 Q * marcfiu Ping timeout: 480 seconds 1164806199 J * Blissex ~Blissex@82-69-39-138.dsl.in-addr.zen.co.uk 1164806897 J * DavidS ~david@vpn.uni-ak.ac.at 1164808917 J * marcfiu ~mef@aegis.CS.Princeton.EDU 1164810316 J * kugg kugg@illvilja.org 1164810388 M * kugg hi guys, do you guys have any nice manual/guide on how to set up secure networking in vserver, using iptables for instance= 1164810392 M * kugg ? 1164810443 M * daniel_hozac not really, but just setup the tables on the host as you would if you had multiple services on it that you wanted to protect from eachother. 1164810466 M * kugg ah ok 1164810471 M * kugg dreamhack tomorrow :) 1164810518 M * daniel_hozac ah, yes, it's that time of the year... 1164810601 M * kugg http://www.dreamhack.org/dhw06/se.64.html <- in swedish 1164812051 Q * kir Quit: Leaving 1164812366 J * dreamind ~dreamind@C2107.campino.wh.tu-darmstadt.de 1164812413 M * dreamind Hi folks :) 1164812719 M * daniel_hozac hello 1164812729 M * dreamind hi daniel_hozac :) 1164812737 M * dreamind daniel_hozac: anything new about git? ;) 1164812801 M * daniel_hozac seems to work quite fine now, thanks. 1164812961 M * dreamind :) 1164812977 M * dreamind if you have any question about git i'll do my best to answer them ;) 1164813039 Q * Adrinael lithium.oftc.net europa.oftc.net 1164813039 Q * derjohn lithium.oftc.net europa.oftc.net 1164813075 J * Adrinael adrinael@hoasb-ff0edd00-43.dhcp.inet.fi 1164813185 J * derjohn ~derjohn@80.69.37.19 1164813611 J * Piet_ hiddenserv@tor.noreply.org 1164813801 Q * Piet Remote host closed the connection 1164817488 N * Bertl_zZ Bertl 1164817495 M * Bertl morning folks! 1164817615 M * daniel_hozac morning Bertl! 1164817889 Q * djrise Quit: Quitte 1164817967 M * matti Bertl: Hi, how are you? 1164818168 J * Guy- ~korn@chardonnay.math.bme.hu 1164818170 M * Guy- hi 1164818205 M * Guy- I just compiled my first vserver kernel: 2.6.18.3-vs2.1.1.2, and the util-vserver tools are segfaulting 1164818218 M * Guy- is this normal? 1164818231 M * Guy- (aren't they supposed to work with the development version anymore?) 1164818854 Q * DavidS Ping timeout: 480 seconds 1164819071 M * Bertl Guy-: nope, that's not normal 1164819087 M * Bertl Guy-: what arch you are on? 1164819421 M * Bertl matti: fine, and you? 1164819428 J * michael ENETDOWN@fw-ext.konaktiva.tu-darmstadt.de 1164819430 M * michael hi 1164819430 M * dreamind Hi Bertl :) 1164819434 M * dreamind gi michael :) 1164819446 M * Bertl welcome michael! 1164819748 Q * jayeola Quit: leaving 1164820326 J * bonbons ~bonbons@83.222.39.117 1164820621 Q * michael Quit: michael 1164820848 M * dreamind well have to go, bbl :) 1164820850 M * Bertl okay, back later ... 1164820858 M * dreamind :) 1164820858 N * Bertl Bertl_oO 1164820862 Q * dreamind Quit: dreamind 1164821745 Q * prae Quit: Quitte 1164822436 P * Torsti76 1164822571 M * micah daniel_hozac: i'm wondering your opinon on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23400044 -- its a problem with the vserver bash completion, the fix suggested is to modify the util-vserver/functions 1164822721 M * daniel_hozac right... well, i guess it gets the job done. 1164822979 M * micah hehe, sure, but is there a better way? 1164822987 M * micah I dont really understand what the issue is 1164823016 M * micah but I managed to reproduce the error 1164823022 M * daniel_hozac declare -r makes the variables read-only. 1164823040 M * daniel_hozac so when you resource the script, it tries to set them again. 1164823093 M * micah yeah I think I managed to reproduce it because i've got the completion sourced when I login, and then when I sudo -s, it gets sourced again 1164823130 M * daniel_hozac sounds possible, although sudo -s really should start with a fresh environment... 1164823209 M * micah yeah, I just turned bash completion on system-wide to get it 1164825131 Q * duckx Quit: Client exiting 1164825237 M * Guy- Bertl_oO: i386 1164825306 M * Guy- for the late arrivals, I'll reiterate that I'm getting segfaults with 2.6.18.3-vs2.1.1.2 and util-vserver 0.30.211-4 1164825327 J * duckx ~Duck@tox.dyndns.org 1164825329 M * Guy- the /etc/init.d/util-vserver script reports a bunch of segfaults when I run it 1164825381 M * Guy- execve("/usr/sbin/setattr", ["/usr/sbin/setattr", "-x", "--!hide", "/proc/version"], [/* 14 vars */]) = 0 1164825384 M * Guy- --- SIGSEGV (Segmentation fault) @ 0 (0) --- 1164825384 M * Guy- like this 1164825489 M * Guy- anything specific I should try/look for? recompiling util-vserver didn't help 1164825503 M * daniel_hozac does dmesg have anything in it? 1164825508 M * Guy- no 1164825532 M * Guy- well, yes 1164825537 M * Guy- but nothing that looks related 1164825537 M * Guy- set_rtc_mmss: can't update from 55 to 2 1164825567 M * Guy- also "INFO: possible recursive locking detected" 1164825576 M * daniel_hozac what dietlibc version are you using? 1164825586 M * Guy- I'm using dietlibc? 1164825587 M * daniel_hozac hmm, just that? no trace or anything attached? 1164825596 M * Guy- yes, sure, but it's about g++ and jfs 1164825608 M * Guy- so not setattr 1164825625 M * Guy- I'm not using dietlibc 1164825637 M * Guy- (at least not deliberately) 1164825644 M * daniel_hozac you should. 1164825677 M * daniel_hozac you should get quite a few warnings during ./configure if you use glibc. 1164825681 M * micah it looks like he is using the debian package 1164825690 M * daniel_hozac me too. 1164825693 M * micah note 0.30.211-4 (the -4) is the latest one 1164825704 M * Guy- yes, I am using the Debian package 1164825713 M * Guy- (Ubuntu, actually, but they're the same) 1164825714 M * micah did you build it yourself? 1164825723 M * Guy- at first, no; now, yes 1164825751 M * micah Guy-: apt-cache policy dietlibc-dev 1164825759 M * daniel_hozac micah: -4 is the one with the -rc1 patch? 1164825763 M * micah daniel_hozac: yes 1164825767 M * Guy- Installed: 0.30-1ubuntu3 1164825767 M * Guy- Candidate: 0.30-1ubuntu3 1164825784 M * micah Guy-: how did you compile it yourself (and why?) 1164825798 M * Guy- micah: apt-get source; apt-get build-dep; dpgk-buildpackage 1164825824 M * Guy- micah: I thought maybe some API changed in the development version of vserver and recompiling the userspace tools would pick up the new kernel headers 1164825831 M * Guy- it was just a shot in the dark 1164825832 M * daniel_hozac no it won't. 1164825849 M * daniel_hozac util-vserver carries its own version of the kernel headers. 1164825854 M * micah i'm surprised ubuntu has this version already 1164825869 M * Guy- it's feisty, fwiw 1164825892 M * micah it was only 2 days ago I uploaded 1164825895 M * daniel_hozac Guy-: do you have a backtrace or anything? 1164825920 M * Guy- daniel_hozac: a backtrace of what? 1164825926 M * Guy- daniel_hozac: the binary won't even start 1164825927 M * daniel_hozac of the failing setattr. 1164825933 M * Guy- I pasted an strace 1164825938 M * daniel_hozac i saw. 1164825942 M * Guy- but well, I can try with gdb 1164825984 M * daniel_hozac btw, you probably should use 2.6.18.3-vs2.1.1.2.3. 1164825993 M * Guy- (gdb) bt 1164825993 M * Guy- #0 0x080485ce in ?? () 1164825993 M * Guy- #1 0x00000000 in ?? () 1164826004 M * Guy- not much of a backtrace, as such :) 1164826014 M * daniel_hozac well, is that a debuggable binary? 1164826015 M * micah you need to recompile with debugging turned on 1164826019 M * micah the binary is stripped 1164826023 M * Guy- right 1164826036 M * micah Guy-: remove dh_strip from debian/rules 1164826076 M * Guy- and add --enable-lib-debug? 1164826100 M * micah that I'm not sure about 1164826110 M * ensc first question which should be answered is, whether program is linked against dietlibc 1164826121 M * ensc if so, it smells like a dietlibc problem 1164826139 M * ensc (e.g. the stackguard stuff causes such early segfaults) 1164826151 M * Guy- it's statically linked 1164826163 M * Guy- I'll check debian/rules for --configure options 1164826164 M * micah ensc: its linked against dietlibc 1164826185 M * Guy- yes 1164826192 M * Guy- should I try with glibc instead? 1164826204 M * Guy- or see what the backtrace says on the unstripped binary? 1164826209 M * micah no, build it without stripping the binary and then do the backtrace 1164826211 M * ensc you must not use stuff like '-fstack-guard' (neither when compiling dietlibc, nor when compiling the program) 1164826355 M * Guy- it's certainly not enabled during the util-vserver compile 1164826408 M * ensc dunno about debian, but under Fedora, it is enabled by default for all package builds 1164826444 M * daniel_hozac and Ubuntu seems to like to change the _compiler_ default, so it's possible you need some -fno-stack-guard or similar. 1164826452 M * Guy- (gdb) bt 1164826453 M * Guy- #0 processFile (path=0xbf87fea6 "/proc/version") at src/fstool.c:150 1164826453 M * Guy- #1 0x08048991 in main (argc=4, argv=0xbf87e614) at src/fstool.c:232 1164826528 M * Guy- daniel_hozac: we're not talking about -mstack-guard, are we? 1164826541 M * Guy- daniel_hozac: my man gcc doesn't mention -fstack-guard or -fno-stack-guard 1164826554 M * ensc sorry, -fstack-protector 1164826558 M * daniel_hozac i don't know what the exact option is, it's -fstack-protector in Fedora. 1164826673 M * Guy- micah: not sure if you should care, but dpatch complains about 08_rsyncbuild_namespace_clone_naddress 1164826687 M * Guy- micah: when I try to rebuild, it fails to deapply that patch 1164826841 M * Guy- anyway, am now trying to build with -fno-stack-protector 1164826885 M * Guy- do I need that in CXXFLAGS too or will CFLAGS suffice? 1164826923 M * daniel_hozac i don't think there's anything C++ left, so CFLAGS should suffice. 1164826987 M * Guy- adding -fno-stack-protector had no effect 1164826991 M * Guy- same segfault, same backtrace 1164826994 M * micah Guy-: thats a problem, you definately want that to deapply 1164827014 M * Guy- micah: I removed the directory and did a fresh dpkg-source -x 1164827083 M * daniel_hozac Guy-: as ensc said, if dietlibc is compiled with it, you'll get problems anyway. 1164827102 M * Guy- OK, checking dietlibc now 1164827149 M * ensc WANT_SSP must be disabled in dietlibc 1164827162 M * ensc see http://cvs.fedora.redhat.com/viewcvs/rpms/dietlibc/devel/dietlibc.spec?root=extras&rev=1.24&view=auto 1164827167 M * ensc (the 2nd sed) 1164827357 M * Guy- it's disabled in debian/ubuntu 1164827368 J * _dmax ~semaj@bl9-226-114.dsl.telepac.pt 1164827373 J * s0undt3ch_ ~s0undt3ch@bl9-226-114.dsl.telepac.pt 1164827390 M * Guy- this patch is applied to dietfeatures.h before building: 1164827391 M * Guy- -#define WANT_SSP 1164827391 M * Guy- +/* #define WANT_SSP */ 1164827441 M * Guy- I'm now rebuilding dietlibc with an explicit -fno-stack-protector in CFLAGS 1164827701 Q * dmax Ping timeout: 480 seconds 1164827703 N * _dmax dmax 1164827793 Q * s0undt3ch Ping timeout: 480 seconds 1164827834 N * s0undt3ch_ s0undt3ch 1164827838 M * Guy- ensc: this didn't help either 1164827883 M * Guy- ensc: I rebuilt dietlibc with -fno-stack-protector, with WANT_SSP undefined, and then rebuild util-vserver with -fno-stack-protector against the 'new' dietlibc, and am still getting the same segfault 1164827887 M * micah ensc: what is the purpose of WANT_SSP? 1164827938 M * Guy- micah: it says /* Include support for ProPolice/SSP, calls guard_setup */ 1164828002 M * ensc it adds the stack-check function and does some special things during _init 1164828013 M * Guy- anyway, what now? should I rebuild the kernel with vserver debugging turned on (would we see more that way)? 1164828018 M * ensc unfortunately, it makes some assumptions which are not valid with gcc 4.1 anymore 1164828048 M * ensc when your strace does not show anything after execve(), it is not a vserver thing 1164828083 M * ensc what is your stack limit? 1164828093 M * Guy- ulimit -s? 8192 1164828117 M * micah the gdb backtrace seems to be dying at src/fstool.c 1164828118 M * Guy- but it segfaults with unlimited too 1164828313 N * Bertl_oO Bertl 1164828339 M * Guy- does it make sense to try building against glibc? 1164828508 M * Bertl Guy-: could you elaborate on the recursive lock part? 1164828517 M * Bertl (from dmesg) 1164828537 M * Bertl i.e. maybe upload the stuff to paste.linux-vserver.orgt 1164828541 M * Bertl *org 1164828689 M * Guy- sure 1164828764 M * Guy- Bertl: http://pastebin.ca/261667 1164828768 M * Bertl tx 1164828850 M * Bertl did that happen only once? 1164828863 M * Guy- yes 1164828872 M * Bertl do you use jfs? 1164828899 M * Guy- yes 1164828916 M * Guy- I just noticed it happened once more, about an hour earlier, with gcc 1164828926 M * Guy- but I'm not sure I was already running the vserver kernel then 1164828932 M * Bertl did you upgrade from 2.6.17 to 2.6.18? 1164828947 M * Guy- yes 1164828975 M * Guy- in the sense that I switched from a canned ubuntu 2.6.17 kernel to a 2.6.18.2 kernel I built myself 1164828980 M * Bertl well, I stumbled over that some time ago, and avoided jfs for 2.6.18 1164829004 M * Bertl because the recursive loclk thingy doesn't look too good 1164829025 M * Bertl and obviously it happend when you did compile something 1164829029 M * Guy- for me that would mean avoiding 2.6.18 :) 1164829030 M * Guy- yes 1164829066 M * Bertl well, or at least jfs for the compilation 1164829090 M * Guy- it's actually to do with ccache - it keeps its cache files on the jfs volumes 1164829126 M * Guy- but what's the worst that could happen? a deadlock, right? 1164829160 M * Bertl a miscompilation which causes segfaults :) 1164829239 M * Bertl the thing is, the deadlock was detected, and the cpu was killed 1164829245 M * Bertl s/cpu/task/ 1164829274 J * jpachec ~justin@74.116.143.188 1164829281 M * jpachec hey everyone 1164829297 M * Guy- Bertl: you think it's worth trying to recompile without the cache? 1164829305 M * jpachec whats the option that i pass to the kernel to create more /dev/vroot devices? 1164829331 M * Bertl Guy-: definitely 1164829358 M * Bertl jpachec: max_vroot= or maxvroot= 1164829366 M * jpachec thx 1164829369 M * Bertl (I don't remember exactly) 1164829477 M * Guy- OK, seeing that it doesn't even compile with --disable-dietlibc, I'll try without ccache now :) 1164829922 M * Guy- Bertl: nope, still same segfault 1164829935 M * Guy- Bertl: but the pre-built debian/ubuntu package segfaults the same way 1164829937 M * Bertl with/without dietlibc? 1164829943 M * Guy- with 1164829960 M * Bertl hum the ubuntu prebuilt segfaults too? 1164829961 M * Guy- can't build without, offsetof is undefined (or something like that, I didn't bother to check very much) 1164829965 M * Guy- yes 1164829977 M * Bertl sure your machine is fine? 1164830022 M * Guy- otherwise, yes 1164830029 M * Guy- I mean, I compiled at least two kernels today 1164830041 M * Bertl with ccache? 1164830045 M * Guy- yes 1164830054 M * Bertl well, they might be broken too 1164830070 M * Guy- but I didn't get any recursive locking warnings then 1164830093 M * Guy- and wouldn't they be more spectacularly broken than this? 1164830125 M * Bertl well, I can offer you to upload your kernel somewhere, and if I can boot it (in QEMU) I can test it for you 1164830142 M * Guy- OK, hang on 1164830194 M * Guy- Bertl: http://dzsessz.tmit.bme.hu/vmlinuz-2.6.18.3-vs2.1.1.2-dzsessz 1164830205 M * Guy- would you also like the .config? 1164830235 M * Bertl not required for booting it :) 1164830256 M * Guy- sure, but perhaps for finding the option I should have enabled but didn't, or vice versa :) 1164830285 M * daniel_hozac there should be no "break userspace" option ;) 1164830301 M * Guy- maybe it's hidden :) 1164830346 Q * Piet_ Quit: Piet_ 1164830593 M * Bertl Guy-: did you compile in serial console? 1164830627 M * Guy- Bertl: I should have 1164830638 M * Bertl great, should help 1164830647 M * Guy- yes, I did 1164830669 M * Bertl yep, boots 1164830691 M * Guy- great 1164830744 M * Bertl okay, works fine with my tests here, what commands do segfault for you? 1164830764 M * Bertl 2.6.18.3-vs2.1.1.2-dzsessz #5 SMP PREEMPT :) 1164830796 M * Bertl util-vserver 0.30.211 1164830847 M * Guy- setattr -x --!hide /proc/version 1164830883 M * Bertl works like a charm here 1164830899 M * Bertl so it must be related to your c++ toolchain, I'd say 1164830916 M * Guy- c++? 1164830932 M * Bertl well, I'd say so, the kernel is fine 1164830945 M * Bertl but the tools segfault 1164830957 M * Guy- someone just said there wasn't anything c++ left in there 1164830961 M * Guy- just C 1164830967 M * Guy- that's why I asked 1164830986 M * Bertl daniel_hozac: all c++ gone by now? 1164830989 M * Guy- but seeing that the pre-built ubuntu/debian package also segfaults, I'm still not entirely convinced 1164831006 M * Guy- anyway, let me reboot - the segfault pattern did change over time, maybe we'll get something different :) 1164831047 M * Bertl Guy-: well, it could be a miscompiled library or a broken toolchain in ubuntu 1164831068 M * Bertl and finally, it could be some issue between util-vserver and the toolchain 1164831070 M * Guy- I guess, but it's strange that util-vserver seems to be the only package affected 1164831087 M * Bertl don't forget, we are pushing the limits 1164831096 M * Guy- is /etc/init.d/util-vserver start idempotent? 1164831110 M * Bertl there is no glibc/dietlibc support for vserver syscalls for example 1164831139 M * Bertl with what? 1164831169 M * daniel_hozac Bertl: i haven't verified, but IIRC the last time we checked there was nothing left. 1164831191 M * Bertl ah, good, just wondered, because the autoconf still lists c++ IIRC 1164831211 M * Bertl that should be removed then, I guess (if I'm not completely wrong) 1164831223 M * Guy- Bertl: I mean, should /etc/init.d/util-vserver start work the second and third time? 1164831231 M * Guy- or just on boot? 1164831270 M * Bertl actually, that script is not part of the tools, IIRC 1164831293 M * Bertl but daniel_hozac has the details there 1164831324 M * daniel_hozac it's the Debian initscript. 1164831419 M * daniel_hozac isn't there a way to get gdb to list the exact asm instruction that caused the SIGSEGV? 1164831435 M * Guy- I, alas, don't know 1164831445 M * Bertl sure, that's simple, sec 1164831452 M * Guy- disasm or something? 1164831469 M * Bertl that will give you the entire subroutine 1164831484 M * Bertl which should not hurt, $EIP is pointing to the instruction 1164831508 M * Bertl you can get the registers with 'show registers' or 'info registers' 1164831570 M * Guy- in the meantime, I downgraded to 0.30.210-10 (ubuntu edgy) 1164831572 M * Guy- and this version works 1164831585 M * ensc Guy-: does 'make check' work with the dietlibc version? 1164831601 M * Guy- ensc: trying 1164831766 M * Guy- 0x080485ca : push %ebx 1164831766 M * Guy- 0x080485cb : sub $0x64,%esp 1164831766 M * Guy- 0x080485ce : mov %gs:0x14,%eax 1164831770 M * Bertl hey ensc! how are you doing? 1164831777 M * Guy- the last instruction caused the segfault 1164831778 M * Guy- eip points there 1164831784 M * ensc that's the stack protector stuff 1164831790 M * Guy- gs is 0x0 1164831827 M * Guy- and make test fails too (segfaults) 1164831842 M * ensc http://thread.gmane.org/gmane.linux.lib.dietlibc/989/focus=990 1164831857 M * jpachec bertl: its max_vroot jic u wanted to be sure 1164831881 M * Guy- ensc: maybe I should recompile with gcc-4.0? 1164831905 M * Bertl jpachec: ah, tx, will try to remember :) 1164831941 M * ensc Bertl: good; but I waste too much time with working 1164831974 M * ensc Guy-: try to figure out, how to disable the stack protector 1164831976 M * Bertl you mean, working on the wrong stuff, I guess :) 1164831997 M * ensc Bertl: this stuff which gives money ;) 1164832017 M * Guy- ensc: I don't know how to disable it any more than I already did :) 1164832069 M * ensc Guy-: the code above will be generated only when the stack protector is enabled 1164832126 M * Guy- ensc: I believe you, but I don't know how to get rid of it, other than add -fno-stack-protector and comment out WANT_SSP 1164832137 M * Guy- ensc: I did these things but it didn't help, apparently 1164832154 M * Guy- am now trying to build with gcc-4.0 1164832289 M * ensc Guy-: build the utilities and look with 'ps axfuwwww' which options are used 1164832303 M * ensc or: what gives 'gcc -dumpspecs | grep -i stack' 1164832326 M * Guy- %{fstack-protector:} 1164832326 M * Guy- %{!fno-stack-protector:-fstack-protector} 1164832339 M * Guy- but I did add -fno-stack-protector 1164832354 M * Guy- I know this because gcc-4.0 just complained that it didn't know that option :) 1164832599 M * Guy- it doesn't compile with gcc-4.0 though... 1164832600 M * Guy- gcc-4.0 -Wall -g -O2 -std=c99 -Wall -pedantic -W -funit-at-a-time -o src/vcontext src/vcontext.o src/vlogin.o lib/libvserver.a lib_internal/libinternal-diet.a 1164832603 M * Guy- src/vlogin.o: In function `do_vlogin': 1164832606 M * Guy- src/vlogin.c:216: undefined reference to `openpty' 1164832698 M * daniel_hozac hmpf. 1164832708 M * daniel_hozac that's supposed to be fixed. 1164832765 M * daniel_hozac what util-vserver version is that? 1164832771 M * Guy- 0.30.211 1164832790 M * Guy- should I check out something newer from somewhere? 1164832826 M * daniel_hozac 0.30.211 should have the fix. 1164832835 M * daniel_hozac you're doing a glibc build, right? 1164832841 M * Guy- no, dietlibc 1164832850 M * Guy- it worked with gcc-4.1 but not with gcc-4.0 1164832859 M * daniel_hozac then why isn't diet in that command line? 1164832865 M * Guy- search me 1164832875 M * Guy- I did debian/rules binary CC=gcc-4.0 1164832892 M * jpachec is it possible to limit a guest to a certain % of the cpu? 1164832934 M * Bertl sure, that is what the hard cpu scheduler is for 1164832960 M * jpachec could you point me to a howto describing how to enable such a feature? 1164832992 M * marcfiu hello 1164833007 M * marcfiu Bertl: did you have a chance to eyeball the patch I sent you? 1164833103 M * Bertl not yet 1164833162 M * Guy- daniel_hozac: debian/rules binary CC='diet -Os gcc-4.0' did compile 1164833203 M * Bertl jpachec: http://oldwiki.linux-vserver.org/Scheduler 1164833220 M * Guy- et voila... segfault is gone 1164833226 M * Bertl jpachec: http://oldwiki.linux-vserver.org/Scheduler+Parameters 1164833294 M * Guy- micah: looks like the problem is caused by compiling with gcc-4.1 - somehow the stack protector thing creeps in; if I compile with gcc-4.0, the segfaults are gone 1164833375 M * Guy- micah: I'm telling you because maybe the debian package needs to be changed somehow 1164833587 M * Bertl yes, I think gcc 4.1 also requires significant changes to dietlibc 1164833608 M * Bertl at least recent versions change the inline asm behaviour significantly 1164833647 M * Guy- anyway, thanks for all the help 1164833657 M * Guy- I don't think I would have been able to figure this out on my own 1164833715 M * Bertl you're welcome! tx to ensc and daniel_hozac 1164833774 M * jpachec bertl: this document was interesting. but im looking for something more practicle 1164833814 M * Bertl you know the flower page/config? 1164833841 M * Bertl depending on your tool version, the scheduler parameters can be directly used for your guests 1164833861 M * jpachec 0.30.211 1164833867 M * Bertl they either go to a single file (as described) or for very recent versions to single files 1164833878 M * Bertl s/single/separate/ 1164833899 M * Bertl you did read the scheduler parameters page, right? 1164833907 M * marcfiu Bertl: I thought the irq backport would fix the scheduler problem I was seeing. 1164833911 M * jpachec i read the page you sent me 1164833916 M * marcfiu however, it doesn't look like it. 1164833922 M * Bertl jpachec: both of them? 1164833953 M * Bertl marcfiu: then you are observing a different issue, as it is definitely fixed in 2.1.1.2.3 1164833955 M * marcfiu Bertl: if I run " while [ 1 ] ; do /bin/true ; done" from within a context I see the Token value slowly drop to the TokensMin value. 1164834006 M * marcfiu Bertl: if I run a hog process that simply runs "main(){while(1);}", then the Token value remains unchanged. 1164834015 J * Aiken ~james@tooax6-104.dialup.optusnet.com.au 1164834048 M * Bertl marcfiu: could you verify with 2.1.1.2.3 that you see the same there? 1164834053 M * Bertl morning Aiken! 1164834104 M * jpachec bertl: im reading scheduler+parameters now 1164834350 M * jpachec ok 1164834358 M * jpachec i kind of understand what's going on here 1164834374 M * jpachec where do i find the files to edit under my version of utils? 1164834393 M * daniel_hozac /etc/vservers//schedule 1164834420 M * jpachec i don't have that file in my vserver 1164834424 M * jpachec do i have to create it? 1164834433 M * Bertl yep 1164834437 M * jpachec k 1164834506 Q * bonbons Quit: Leaving 1164834528 Q * kugg Ping timeout: 480 seconds 1164834540 M * jpachec vsched: non-numeric value specified for '--priority_bias' 1164834544 M * jpachec this is what i put in the file 1164834546 M * marcfiu Bertl: will give that a shot 1164834556 M * Bertl marcfiu: TIA 1164834556 M * jpachec 7 1164834556 M * jpachec 32 1164834556 M * jpachec 500 1164834556 M * jpachec 200 1164834556 M * jpachec 1000 1164834558 M * marcfiu but I'd like to understand the change. 1164834558 M * jpachec dummy7 1164834558 M * jpachec 32 1164834560 M * jpachec 500 1164834560 M * jpachec 200 1164834562 M * jpachec 1000 1164834562 M * jpachec dummy 1164834573 M * Bertl jpachec: please avoid spamming the channel 1164834573 M * daniel_hozac jpachec: then you a) misrepresented your version, and b) dummy should be the priority bias. 1164834577 M * jpachec sorry 1164834593 M * Bertl longer pastes go to paste.linux-vserver.org, tx 1164834595 M * daniel_hozac but in that case, you're better off creating the sched directory and putting the values in the right file. 1164834604 M * daniel_hozac +s 1164834630 M * marcfiu that is, related to the scheduler what does adding the in_interrupt() check in vx_check do? 1164834676 M * jpachec my version of utils is 0.30.211 1164834705 M * jpachec daniel_hozac: i have to create a directory called "sched" in the guest config dir? 1164834706 M * daniel_hozac no, it is 0.30.211-4. 1164834710 M * Bertl marcfiu: the scheduler does the accounting based on the process context, but without the enter/leave removed, there will be no context to account for 1164834747 M * daniel_hozac jpachec: you can use the schedule file if you want. 1164834760 M * daniel_hozac but IMHO the directory layout is better. 1164834793 M * jpachec and how do i go about creating the proper directory layout? 1164834800 M * jpachec and b) dummy 1164834801 M * jpachec +should be the priority bias. 1164834807 M * jpachec could you explain this 1164834821 M * daniel_hozac mkdir /etc/vservers//sched, put the correct values into the correct files. 1164834842 M * jpachec what do i name the files? 1164834846 M * daniel_hozac see http://people.linux-vserver.org/~dhozac/p/uv/experimental/configuration.html 1164834854 M * jpachec im sorry. but is this documented somewhere? 1164834866 A * hardwire ventures to say.. maybe.. 1164834882 M * daniel_hozac given that there's no release of util-vserver with this configuration method yet, not really :) 1164835105 M * jpachec so i can't use this method yet then, correct? 1164835117 M * jpachec if im only using 0.30.211 1164835120 M * daniel_hozac you can. 1164835126 M * jpachec ok 1164835136 M * daniel_hozac you're using 0.30.211-4, which is basically 0.30.212-rc1. 1164835159 M * jpachec vserver --version 1164835166 M * jpachec gives me 0.30.211 1164835175 M * daniel_hozac and dpkg -l util-vserver says what? 1164835201 M * jpachec ah 1164835202 M * jpachec ic 1164835287 M * hardwire we don't 1164835339 M * Guy- is hardwire a bot? :) 1164835360 M * hardwire why do I always get that asked about me! 1164835372 M * Guy- OK, that answers it, thanks :) 1164835382 M * hardwire What is your conclusion? 1164835398 M * hardwire amibotornot.com? 1164835448 M * Guy- it's getting more complex. the first two lines I saw from you would have been easily scriptable and funny in the kind of way I tend to associate with bot writers 1164835456 M * Guy- the third line matched that 1164835469 M * hardwire so people actually target bots to act like me. 1164835472 M * Guy- now, however, you are either not a bot, or a bot that is being sockpuppeted by someone :) 1164835474 M * hardwire I must be somewhat famous then 1164835492 M * hardwire vserver hardwire enter 1164835496 M * hardwire heh 1164835566 M * hardwire i joined #apache on freenode the other day 1164835583 M * hardwire and said my usual "word" entrance phrase 1164835585 M * hardwire word.. 1164835597 M * hardwire a bot responded with a definition of word.. just to be a smarty pants. 1164835628 M * hardwire I wanted to test the logic so I tried "WORD" and it responded in all caps.. so to have fun I said "W3rd!" and it responded.. and somebody in the channel decided I was just there to abuse a bot and kicked me. 1164835631 J * DavidS ~david@chello062178045213.16.11.tuwien.teleweb.at 1164835632 M * hardwire :( 1164835737 M * jpachec k 1164835744 M * jpachec i setup the sched dir 1164835753 M * jpachec put the files in, and put in the values i wanted 1164835769 M * jpachec i restarted the vserver and checked sched in proc for that vserver 1164835773 M * jpachec the values are all there 1164835787 M * jpachec but the vserver is still taking up all of the cpu 1164835792 M * Bertl excellent, did you also enable sched_hard ? 1164835809 M * Bertl ah, and btw, what kernel version do you use? 1164835813 M * jpachec kernel compile? 1164835825 M * jpachec 2.6.17-2-vserver-686 1164835836 M * jpachec debian pkg kernel 1164835867 M * Bertl should be fine, although I have no idea to which vserver version that maps 1164835879 M * hardwire Bertl: is the scheduler WRR based? and if so is that functionality provided by the vserver kernel patch? 1164835883 M * jpachec mmm 1164835893 M * jpachec # CONFIG_VSERVER_HARDCPU is not set 1164835898 M * jpachec that's bad right? 1164835911 M * jpachec does this stop my settings from having any effect? 1164835926 J * kugg kugg@illvilja.org 1164835941 M * hardwire jpachec: thats the way the debian vserver kernels are distributed 1164835955 M * jpachec right 1164835963 M * jpachec but if its not set 1164835964 M * Bertl hardwire: WRR? 1164835972 M * hardwire Bertl: like a weighted round robin. 1164835977 M * jpachec then that means its not in the kernel, correct? 1164835983 M * Bertl hardwire: it's a token bucket 1164835987 M * hardwire ok 1164836016 M * daniel_hozac jpachec: right. 1164836030 M * jpachec bertl: do i need sched_hard enabled to make my changes to take effect? 1164836048 M * hardwire Bertl: interesting. 1164836052 M * Bertl yes, the token bucket itself is configured by the scheduling parameters 1164836075 M * Bertl the two scheduler flags (sched_prio and sched_hard) control how the token bucket affects scheduling 1164836107 M * jpachec daniel_hozac: do you know how i might be able to get the source for my current kernel out of apt-get/aptitude? 1164836110 M * Bertl sched_prio adjusts the priorities according to the bucket state, while sched_hard suspends the context when the bucket gets empty 1164836116 M * daniel_hozac jpachec: apt-get source? 1164836132 M * jpachec debian only gave me the bin and mods 1164836149 M * daniel_hozac as they should. 1164836210 M * jpachec so if i don't recompile, then i can't limit how much cpu my guests take up right? 1164836269 M * Bertl jpachec: the HARD_CPU feature should be compiled in, I guess 1164836277 M * jpachec ok 1164836286 M * Bertl the flag goes to the context flags 1164836304 M * Bertl http://linux-vserver.org/Capabilities_and_Flags 1164836489 M * DavidS jpachec: for debian, look at the kernel-package package and the {kernel,linux}-source-* stuff 1164836555 M * hardwire jpachec: you familiar with rebuilding debian kernels? 1164836559 M * hardwire I can run you through this if you want 1164836565 M * hardwire its like.. what I do man 1164836577 M * jpachec vs2.0.2.2-rc8 1164836581 M * jpachec is this ok to use? 1164836588 M * jpachec im going to build 2.6.18.3 1164836613 M * jpachec hardwire: im going to using the kernel config file in boot that was used for my current kernel 1164836617 M * daniel_hozac that's fine. 1164836620 M * Bertl ATM, I'd go for 2.1.1.2.3 (but that's just me :) 1164836628 M * daniel_hozac well, indeed. 1164836632 M * hardwire jpachec: ok.. if you are interested in the debian package method of handling this give me a bark 1164836634 M * daniel_hozac 2.0.2.2-rc8 has the broken scheduler, right? 1164836636 M * jpachec i need something stable 1164836647 M * daniel_hozac 2.1 is probably just as stable. 1164836648 M * hardwire jpachec: don't we all 1164836659 M * jpachec lol 1164836677 M * jpachec i only see 1164836678 M * hardwire more than stable.. i want a twinkie.. or a ding dong.. 1164836680 M * jpachec 2.1.1.2 1164836695 M * daniel_hozac http://vserver.13thfloor.at/Experimental/patch-2.6.18.3-vs2.1.1.2.3.diff 1164836742 M * jpachec hardwire: what is the benifit of using debian pkg mgr for my kernel build? 1164836771 M * daniel_hozac it's managed in the same way your usual kernels are? 1164836799 M * jpachec daniel: how come the patch isn't listed on the main site? 1164836842 M * DavidS .../Experimental/... ;) 1164836848 M * Guy- jpachec: you get a nice .deb that contains all the modules and the vmlinuz; you can copy it over to other machines, you can later upgrade to a newer version, it can add a string to the version number so you can have several different flavours of the same kernel, etc 1164836850 M * daniel_hozac because it's sort of an experimental release, and nobody has put it there yet. 1164836866 M * jpachec ic 1164836876 M * Bertl don't bother, 2.1.1.3 will be out tonight 1164836882 M * jpachec ok, so how to i build my kernel with the help of debian? 1164836889 M * Bertl (almost unmodified 2.1.1.2.3) 1164837007 M * jpachec hardwire? 1164837014 M * Guy- jpachec: apt-get install kernel-package 1164837048 M * jpachec guy: i would like to build the kernel i got from kernel.org 1164837057 M * Guy- jpachec: cd /where/your/kernel/tree/is; make menuconfig/oldconfig/whatever; make-kpkg --revision 20061129.1 --append-to-version -flavour kernel-image 1164837065 M * Guy- jpachec: no problem with that 1164837079 M * Guy- jpachec: kernel-package contains make-kpkg, not a kernel 1164837087 M * jpachec ahh, ok cool 1164837089 M * jpachec dling 1164837111 M * Guy- jpachec: it can also build your 3rd party modules, if any (and if packaged for Debian) 1164837131 M * jpachec mmmm 1164837137 M * jpachec don't have any 3rd party mods 1164837143 M * Guy- lucky you 1164837145 M * jpachec whatever is in the current kernel 1164837151 M * jpachec and vserver 1164837166 M * jpachec debian just uses the vanilla kernel right? 1164837166 M * Guy- oh, make-kpkg can do patching as well, but I never used that 1164837171 M * Guy- no 1164837178 M * Guy- they apply some patches, but not many 1164837190 M * jpachec ic 1164837190 M * Guy- it's not like redhat 1164837204 M * Guy- ubuntu adds a bit more, I think 1164837242 M * jpachec k, so i just unpack the kernel 1164837248 M * jpachec apply the vserver patch 1164837266 M * jpachec and compile? 1164837297 M * Guy- apply the vserver patch, make config, and then make-kpkg does the compilation for you 1164837307 M * jpachec sweet 1164837311 M * Guy- and builds a linux-image...deb in ../ 1164837313 M * jpachec k 1164837316 M * hardwire jpachec: ? 1164837322 M * jpachec i'll let u know when im at that point 1164837324 M * hardwire oh.. you asked 1164837329 M * hardwire :0 1164837331 M * hardwire you ready? 1164837349 M * jpachec guy is helping me out, but more help is always nice 1164837361 M * jpachec im just patching right now, nothing debian specific yet 1164837361 M * hardwire lets wait till Guy- the bot screws uo 1164837364 M * hardwire then I will help 1164837368 M * Guy- :D 1164837534 Q * cdrx Quit: Leaving 1164837626 M * jpachec any good options i should compile into the kernel while im here? 1164837634 M * jpachec i've got Enable Hard CPU limits 1164837679 M * Bertl well, please read the help for the options 1164837688 M * Bertl then decide if you want/need that feature 1164837720 M * jpachec i know that i need to limit the % of cpu that a guest is allowed to use 1164837785 M * Bertl good :) 1164838123 M * jpachec ok 1164838128 M * jpachec done setting my options 1164838155 M * jpachec ready for the compile stage 1164838170 M * Bertl SMP/SMT system? 1164838204 M * jpachec i have those options set 1164838236 M * Bertl yeah, just wanted to note that you can speed up the compile by adding a '-j ' option to the make 1164838242 M * jpachec do those options bare a lot of importance on what im trying to do? 1164838248 M * jpachec ah 1164838270 M * Bertl so for 4 virtual cpus, the best performance will be around -j5 or -j6 1164838295 M * jpachec right 1164838301 M * jpachec amount of cpu's + 1 1164838308 M * Bertl roughly 1164838567 M * marcfiu Bertl: I'm trying to bend my head around the IRQ problem. 1164838604 M * daniel_hozac marcfiu: are you sure you're running the patched kernel? did you get rid of all the __enter/leaves? 1164838604 M * marcfiu Bertl: daniel_hozac mentioned over the weekend that you diagnosed the scheduling related problem to be isolated to systems that use APIC. 1164838620 M * marcfiu daniel_hozac: yes 1164838630 M * marcfiu daniel_hozac: remember, I am debugging the back port. 1164838636 M * Bertl marcfiu: nope, that was a misunderstanding 1164838657 M * Bertl I asked daniel_hozac a few questions to identify his specific config 1164838665 M * marcfiu Bertl: the thing that I am observing also is that in /proc/virtual//sched the cpu: fields are not updated. 1164838670 M * Bertl to find the path in the kernel 1164838682 M * marcfiu the user/sys/hold tick values. 1164838689 M * marcfiu they are basically always 0. 1164838689 M * Bertl marcfiu: look, it's quite simple 1164838706 M * Bertl forget everything you observed or analyzed for a moment 1164838723 Q * DavidS Ping timeout: 480 seconds 1164838751 M * Bertl and try to follow me here: 1164838781 M * marcfiu the only code that appears to update those values is in account_user_time(), which appears to be called from apic.c. 1164838783 M * marcfiu Bertl: ok 1164838786 M * Bertl - every process has a context attached 1164838787 M * marcfiu following 1164838806 M * Bertl - host processes have xid=0 and no context struct assigned 1164838873 M * Bertl - (some) interrupts are supposed to happen on the host (hardware) 1164838882 M * Bertl everything clear so far? 1164838889 M * marcfiu yes 1164838914 M * Bertl okay, let's look at the scheduling stuff now 1164838935 M * Bertl - every timer tick is accounted for the context (if there is one assigned) 1164838954 M * Bertl - the token bucket is updated as well as the system tick count 1164838972 M * Bertl - once the TB is empty (and sched_hard) is set, the context is suspended 1164838972 M * marcfiu right.. but system tick count doesn't appear to be updated in my system. 1164838973 J * prae ~Benjamin@foxhound.sherpadown.net 1164838993 M * Bertl neither does the TB work in your setup, right? 1164839004 M * marcfiu that's what I am trying to test 1164839013 M * marcfiu before the token count wasn't updated at all. 1164839018 M * Bertl so, let's follow me a few more thoughts 1164839024 M * marcfiu Bertl: following. 1164839040 Q * lilalinux Remote host closed the connection 1164839054 M * Bertl - __enter/leave was introduced to handle the IRQs should happen within the host context 1164839081 M * Bertl - it works by replacing the xid/vxi info with 0/NULL 1164839118 M * Bertl - unfortunately the timer interrupt was affected too (in certain cases, i.e. apic/noapic/x86/x86_64 etc ...) 1164839177 M * Bertl - removing the enter/leave and switching to in_interrupt() handles that correctly, as the values are not touched 1164839222 M * Bertl that's it, further questions? 1164839240 M * marcfiu ok 1164839258 M * marcfiu I had that basic understanding before, but now its solid. 1164839269 M * Bertl ok, great! 1164839280 M * marcfiu So what I am trying to debug now is the fact that user_ticks and sys_ticks are not updated when I run a hog within a context. 1164839293 M * Bertl with 2.1.1.2.3? 1164839301 M * marcfiu no... my back ported version. 1164839306 M * marcfiu I have not tried yours yet 1164839332 M * Bertl well, there will be a 2.0.x version tonight I guess 1164839343 M * Bertl (still have some other work to do atm :) 1164839410 M * Wonka wtf? 5-part version numbers? 1164839473 M * Bertl don't worry, we'll get rid of that soon :) 1164839538 M * Wonka good... 1164839556 M * daniel_hozac yes, we're heading for at least 6 digits. 1164839557 M * daniel_hozac :) 1164839570 M * Wonka aaargh 1164839580 M * daniel_hozac (2.1.1.2.4-rc1 anyone? :)) 1164839609 M * derjohn 2.1.1.2.4-rc1-git7 1164839624 M * Wonka 3.1.4.1.5.9.2.6.5.3.5.8.9.7 anyone? 1164839679 M * Wonka 2.7.1.8.2.8.1.8.2.8.4.5.9.0.4.5.2.3.5.3.6 1164839763 M * doener .19 is out :) 1164839777 M * derjohn Wonka, well regard all version len($versionnumer) > 4 as experimental. my $.02. 1164839794 M * Wonka :) 1164839797 M * doener quoting Linus: It's one of those rare "perfect" kernels. 1164839798 M * derjohn .19 ? doener does 2.1.1.2 apply ? 1164839824 M * doener derjohn: I _really_ doubt that 1164839841 M * derjohn doener, on kernel org. 18.3 is last stable 1164839844 M * Bertl but there is a version which should apply 1164839858 M * Wonka The requested URL /pub/linux/kernel/v2.6/linux-2.6.19.tar.bz2 was not found on this server. 1164839885 M * Wonka but .18.4 is there 1164839888 M * Guy- Wonka: you got pi wrong :) 1164839917 M * Wonka Guy-: happens 1164839961 A * derjohn 's strategy is to wait until it's clear what works ;) 1164839983 M * doener Wonka: probably still uploading, the mail went out 20 minutes ago 1164839991 M * doener even less... 1164840050 M * Bertl daniel_hozac: are the tools ready? 1164840074 M * marcfiu Bertl: unfortunately, it seems I've mastered chasing phantoms... 1164840080 M * marcfiu Bertl: it just works! 1164840083 M * daniel_hozac in theory, vnamespace should clone with CLONE_NEWUTS and CLONE_NEWIPC at least. 1164840101 M * daniel_hozac unfortunately i haven't had a chance to test it yet. 1164840106 M * marcfiu Bertl: it helps if I actually booted into the new kernel rather than the old one. 1164840116 M * daniel_hozac marcfiu: told you :) 1164840119 M * Bertl daniel_hozac: okay, that should suffice, any 'release' version which does that yet? 1164840133 M * daniel_hozac not yet, but i intend to release 0.30.212 this week. 1164840156 M * Bertl what about a 'pre release' tonight? 1164840165 M * daniel_hozac well, -rc1 is already up. 1164840180 M * Bertl ah, good, so that should have/do it, yes? 1164840190 M * daniel_hozac yes. 1164840197 M * Bertl perfect, will test that 1164840198 M * daniel_hozac although i should probably upload a -rc2, sec.. 1164840208 M * Bertl even better 1164840302 M * hardwire did I ever tell you guys how much I love vserver 1164840314 M * hardwire and how much I want to beat whoever released edgy w/o vserver kernel packages 1164840329 M * jpachec lol 1164840332 M * Bertl hehe, tx! 1164840389 M * hardwire and I am a big fan of the debian vserver utilities.. newvserver.. 1164840402 M * hardwire that is a quite nice base for quick and dirty vserver love 1164840403 M * jpachec as am i 1164840423 M * hardwire its even de-lovelyer when using a caching apt proxy 1164840468 M * Guy- what are the advantages of vserver over openvz? 1164840493 M * hardwire I can never remember the name of the later 1164840510 M * hardwire so that in itself is a great advantage 1164840521 M * Bertl Guy-: mainly that it is very lightweight (Linux-VServer) 1164840532 M * Guy- the kernel patch seems to be less messy (I get lots of 'sleeping function called from invalid context' with openvz) 1164840533 M * hardwire and by very he means. super very lightweight 1164840546 M * Guy- and vserver supports newer kernels 1164840550 M * Bertl Guy-: and that it does work with all kernel options and architectures, not just with special configs 1164840550 M * hardwire because afaik there is still a lot of virtualizatino that needs to take place w/ openVZ 1164840554 M * hardwire like the network devices I think 1164840568 M * hardwire I love having a virtual server specifically as an X terminal server for my slow laptop 1164840579 M * hardwire running native 1164840582 M * daniel_hozac http://people.linux-vserver.org/~dhozac/p/uv/experimental/util-vserver-0.30.212-rc2.tar.bz2 1164840594 M * Bertl ah, great, tx! 1164840616 M * Guy- hardwire: well, openvz virtualizes the network, so a VE (a guest) can have its own routing and firewall rules 1164840651 M * Bertl yes, and packets have to travel two stacks (performance( 1164840654 M * hardwire which I like Guy- 1164840660 M * hardwire I had to adapt to vserver 1164840697 M * Guy- Bertl: sure, it's a trade-off 1164840718 M * Bertl yep, an unnecessary one actually 1164840720 M * hardwire travelling through a raw device emulation layer sucks 1164840737 M * hardwire which is why I am not a fan of vmware for linux based virtual systems. 1164840749 M * Guy- Bertl: unnecessary? how? 1164840752 M * Bertl Guy-: some folks here already provided mechanisms to have iptables with network isolation too (so no overhead) 1164840759 M * Guy- ah 1164840761 M * hardwire done via the host 1164840784 M * Bertl yep, a policy daemon on the host verifies and applies the rules if found ok 1164840805 M * hardwire Guy-: yeh geez.. what planet are you from. 1164840807 M * Guy- sounds a bit kludgy... but I haven't seen it 1164840827 M * Guy- hardwire: from a small one neer Betelgeuse 1164840830 M * Guy- near 1164840833 M * hardwire Botguise? 1164840841 M * hardwire I have heard it rotates near that planet. 1164840842 M * Guy- quite. 1164840856 M * Bertl Guy-: well, it's quite simple, if you need 'full' virtualization (for whatever reason) and do not care about the overhead, then Xen is the best choice 1164840888 M * Bertl if you care about overhead and want to get the best out of your resources, isolation is the way to go 1164840903 M * Guy- Bertl: I'm not sure - for Xen, you need a sh*tload of memory; openvz seems to be a nice compromise between full virtualization and isolation 1164840903 M * Bertl if you have mixed demands, you can combine both easily 1164840914 M * Guy- yes 1164840923 M * Guy- OK, you basically reinforced what I thought 1164840960 M * Guy- vserver has the added benefit of actually working, of course :) 1164840990 M * Bertl hehe, well, yes 1164840994 M * hardwire Guy-: Xen does eat ram.. but it can balloon 1164841006 M * Bertl for me personally, the code quality would be a criterion too 1164841024 M * Guy- Bertl: alas, I can't judge that very well 1164841029 Q * marcfiu Quit: Download Gaim: http://gaim.sourceforge.net/ 1164841031 M * Bertl quality and readability, but that might not be an issue for a pure user 1164841041 M * hardwire quality is an issue :) 1164841044 M * Guy- hardwire: the problem is, you need to have as much physical RAM as you want to give your guests 1164841048 M * hardwire quality of code readability. not so much 1164841060 M * hardwire Guy-: you can start small and inflate 1164841065 M * Guy- hardwire: with UML, you can give away as much memory as you want, it can use swap too 1164841075 M * hardwire xen can use swap :) 1164841089 M * Guy- not for this 1164841091 M * hardwire Guy-: you don't have to start a xen kernel with dom0_mem=blahM 1164841098 M * Guy- I know 1164841115 M * Guy- the point is, if you have 1G of RAM, you can't have four domUs with 512M each 1164841122 M * Guy- with UML, you can 1164841137 M * Guy- in many cases you won't want to, of course 1164841140 M * hardwire Guy-: if they ever made a way to map all the ram its actually talking to.. at all times.. and follow deallocations.. that would be neat 1164841149 M * matti Bertl: Fine :) Thanks. 1164841157 M * hardwire but you would almost certainly require swap at that point :) 1164841431 M * hardwire I need to work 1164842117 Q * dna_ Quit: Verlassend 1164842247 M * jpachec hardwire: the compile is finished 1164842254 M * jpachec what now? 1164842294 M * hardwire you didn't do it my way 1164842297 M * hardwire I'm not going to talk to you 1164842360 M * jpachec mmm? 1164842379 M * jpachec i did the make-kpkg thingy 1164842385 M * hardwire really? 1164842395 M * Aiken doener * refs/tags/v2.6.19: storing tag 'v2.6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6 1164842397 M * hardwire did you install the package it made? 1164842406 M * hardwire otherwise you wouldn't be asking "now what" :) 1164842435 M * hardwire whats it going to take to get recycling bins in this place? 1164842457 M * hardwire I don't want to work somewhere that has the "recycling is too hard" attitude. 1164842496 M * jpachec yes 1164842501 M * jpachec i used make-kpkg 1164842513 M * hardwire did you install the package it made? 1164842521 M * jpachec im at that point now 1164842541 M * hardwire dpkg --install (the package) 1164842574 M * jpachec done 1164842577 M * hardwire there is an almost inevitable reason your kernel will not boot however 1164842607 M * hardwire no initrd 1164842611 M * jpachec right 1164842617 M * hardwire and you copied a tree form a running debian kernel 1164842638 M * hardwire ready to play footsies with the gods of standardization? 1164842645 M * jpachec wha? 1164842647 M * hardwire heheh 1164842652 M * hardwire get your toes out! 1164842677 M * hardwire actually Guy- told you basically everything 1164842696 M * hardwire but my guess is Guy configures kernels with the correct filesystems and ide/scsi/sata drivers compiled inline the kernel. 1164842726 M * jpachec i usually do that 1164842730 M * hardwire ok 1164842732 M * hardwire so it should boot then 1164842742 M * jpachec but i just wanted to use debians .config for this run 1164842750 M * hardwire I thought you copied debians kernel config.. then compiled after setting the CONFIG_VSERVER_... cruft 1164842759 M * jpachec that's correct 1164842761 M * hardwire give it a reboot already 1164842767 M * jpachec lol 1164842771 M * jpachec i know it won't work 1164842777 M * jpachec i need to create the initrd 1164842801 M * Guy- I keep losing track of how to do that, it seems to change every week 1164842819 M * Guy- but nowadays there is an update-initrd 1164842828 M * Guy- and the postinst from linux-image invokes it, no? 1164842848 M * hardwire Guy-: yeh.. that little flag --initrd tells the package to run update-initrd when it installs the kernel image 1164842865 M * hardwire its just kind of one of those things you don't leave out if you ever want to play sharesys the kernel package with your buddies down the street. 1164842889 M * kugg Hey about the vs grsec patch for 2.6.17.14 seems to be for 2.6.17.13 1164842937 M * Guy- hardwire: I distinctly remember being annoyed about it wanting to update the initrd even though one wasn't needed, and I'm sure I didn't pass any --initrd flag... 1164842946 M * Guy- hardwire: but that must have been last week then :) 1164843045 M * hardwire been years man 1164843056 M * hardwire years upon years upon years 1164843093 M * hardwire kugg: I am totally new when it comes to grsecurity 1164843094 M * micah Guy-: so I didn't completely follow the issue and the resolution to your problem, but it seems to be related to ubuntu's version of the package, as the debian one works without the segfault 1164843131 M * micah you said this was 'edgy'? 1164843184 M * hardwire meh 1164843186 M * Guy- micah: no 1164843206 M * Guy- micah: feisty, but I _think_ the one from Debian doesn't work either 1164843209 M * Guy- micah: let me try 1164843220 M * micah i mean, the debian one, on a debian system, works 1164843250 M * Guy- yes it does 1164843259 M * Guy- OK, that would have been the simplest fix then 1164843266 M * Bertl micah: but maybe it starts failing with gcc 4.1? 1164843282 M * Guy- micah: I assumed (with no reason) that it was the same as the one in Ubuntu 1164843294 M * micah Guy-: so the debian one works in ubuntu? 1164843297 M * Guy- micah: yes 1164843307 M * Guy- micah: do you compile with gcc-4.1 or 4.0? 1164843551 M * Guy- hardwire: can't have been years, I think it was this summer 1164843573 M * hardwire can't have been.. I have been compiling debian kernels the debian way for much longer than that 1164843582 M * hardwire but I have no memory 1164843584 M * hardwire so meh 1164843584 Q * dmax Read error: Connection reset by peer 1164843587 M * Guy- as have I 1164843605 M * Guy- but, as you correctly surmised, I don't usually use initrds 1164843606 M * hardwire heh 1164843614 M * hardwire I want to go home 1164843617 M * hardwire can i go home? 1164843618 J * dmax ~semaj@85.242.226.114 1164843618 M * hardwire please! 1164843627 M * Guy- hardwire: sure, feel free :) 1164843640 M * hardwire "some guy said I could.. hasta.." 1164843697 M * Guy- I am at home, if that's any consolation :) 1164843702 M * micah Guy-: I think I used 4.1 1164843707 M * Guy- micah: are you sure? 1164843716 M * micah i used "i think" because I wasn't sure 1164843717 M * Guy- micah: for me the fix was to compile with 4.0 instead of 4.1 1164843720 M * micah but I think I am sure :) 1164843744 M * Guy- micah: I asked if you were sure because this was a polite way of expressing doubt :) 1164843749 M * micah yes, I just re-ran the build and I'm using /usr/bin/gcc which is a symlink to gcc-4.1 1164843763 M * Guy- must be some ubuntu magic then 1164843776 M * micah yeah, I think so 1164843825 M * Bertl maybe compare the binaries? 1164843840 M * Bertl i.e. look at the disassembled code with objdump 1164844068 M * Guy- Bertl: you mean the ubuntu and debian binaries of util-vserver? 1164844070 M * Guy- or gcc? 1164844092 M * Guy- I for my part almost certainly don't want to be looking at the disassembled code of gcc :) 1164844148 M * Bertl the util vserver sections causing your issues :) 1164844218 M * Guy- OK 1164844336 M * Guy- I have the dumps 1164844360 M * Guy- unfortunately, I can't say I see what the key difference is 1164844365 M * Guy- some offsets are different 1164844405 M * Bertl okay, try to use sed/diff to compare without offsets ... anything obvious? 1164844509 M * Guy- yes 1164844518 M * Guy- the stack protector stuff ensc was going on about 1164844524 M * Guy- is it OK to post 7 lines of diff? 1164844537 M * Bertl better use the paste.linux-vserver.org for that 1164844540 M * Guy- OK 1164844550 M * Bertl (in this case, because it is easier to find) 1164844788 Q * klausk Quit: Leaving