1111709005 M * Doener hm, guess i'm off to bed, too tired to look at any code... good luck with the bug! 1111709011 M * Doener cya tomorrow 1111709013 M * Bertl thanks, cya! 1111709015 N * Doener Doener_zZz 1111709314 J * lilo ~lilo@lilo.usercloak.oftc.net 1111710074 M * alexx hi Bertl 1111710082 M * Bertl hey alexx! 1111710128 M * alexx i have see the bug : http://rs.rhapsodyk.net/vserver/oops-2.6.11.5-vs1.9.5.txt and your explain on it 1111710143 M * alexx disabled shed_hard can temporary solve the prob ? 1111710152 M * Bertl yes, it should avoid it 1111710163 A * Bertl is working on a fix right now 1111710190 M * Bertl well, some day folks will learn to test the release candidates ;) 1111710262 M * alexx i have verified ... in fact, i don't use shed_hard ... :) 1111710286 M * alexx Bertl, perhaps a miss comunication on release candidate ? :) 1111710333 M * Bertl any idea to avoid that in the future? 1111710380 M * alexx announce Release candidate on ml ? 1111710391 M * Bertl hmm, good point! 1111710474 M * alexx some time, i read the listing of /Experimentals/... but it's not as easy as to follow a ml or to feed an RSS 1111710519 M * Bertl you are absolutley right, I should announce the -rc patches on the ml ... didn't think about that before ... 1111710533 M * Bertl thanks for opening my eyes ;) 1111710680 Q * stupidawy oxygen.oftc.net uranium.oftc.net 1111710680 Q * DaPhreak|gone oxygen.oftc.net uranium.oftc.net 1111710680 Q * ensc|w oxygen.oftc.net uranium.oftc.net 1111710680 Q * Loki|muh oxygen.oftc.net uranium.oftc.net 1111710680 Q * nox oxygen.oftc.net uranium.oftc.net 1111710680 Q * rs_ oxygen.oftc.net uranium.oftc.net 1111710680 Q * SiD3WiNDR oxygen.oftc.net uranium.oftc.net 1111710680 Q * jason357 oxygen.oftc.net uranium.oftc.net 1111710680 Q * virtuoso oxygen.oftc.net uranium.oftc.net 1111710680 Q * maharaja oxygen.oftc.net uranium.oftc.net 1111710680 Q * Radiance oxygen.oftc.net uranium.oftc.net 1111710680 Q * ensc oxygen.oftc.net uranium.oftc.net 1111710680 Q * atsab oxygen.oftc.net uranium.oftc.net 1111710680 Q * jd86 oxygen.oftc.net uranium.oftc.net 1111710680 Q * micah oxygen.oftc.net uranium.oftc.net 1111710680 Q * mcp oxygen.oftc.net uranium.oftc.net 1111710680 Q * Snow-Man oxygen.oftc.net uranium.oftc.net 1111710680 Q * bro oxygen.oftc.net uranium.oftc.net 1111710680 Q * sith oxygen.oftc.net uranium.oftc.net 1111710680 Q * spocki oxygen.oftc.net uranium.oftc.net 1111710680 Q * berni oxygen.oftc.net uranium.oftc.net 1111710680 Q * aba oxygen.oftc.net uranium.oftc.net 1111710708 J * berni ~berni@svr01.mucip.net 1111710708 J * aba ~aba@sol.turmzimmer.net 1111710765 J * stupidawy foo@you.wish.you.were.pimp.olicio.us 1111710786 J * rs_ ~rs@imhotep.rhapsodyk.net 1111710786 J * SiD3WiNDR luser@bastard-operator.from-hell.be 1111710786 J * jason357 ~m00@wv-rndhll-cmts1a-a-105.shphwv.adelphia.net 1111710786 J * virtuoso ~s0t0na@tranq.dorms.spbu.ru 1111710786 J * maharaja maharaja@ipax.at 1111710786 J * Radiance kryptonite@wrath.shellfx.net 1111710786 J * ensc ~ircensc@ultra.csn.tu-chemnitz.de 1111710786 J * atsab ~as@lotes.vtu.lt 1111710786 J * jd86 ~jim@ip68-9-97-23.ri.ri.cox.net 1111710786 J * micah micah@micha.hampshire.edu 1111710786 J * mcp ~hightower@www.c-tera.de 1111710786 J * Snow-Man ~sfrost@snowman.net 1111710786 J * spocki ~mk@lex.knuettel.de 1111710786 J * sith sith@aaronp.com 1111710786 J * bro ~vanity@lanparty.lv 1111710797 T * services.oftc.net http://linux-vserver.org/ | latest stable 1.2.10, devel 1.9.5, ng9.4 -- He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the wiki, and we'll forget about the minute ;) 1111710800 J * nox ~nox@83.133.126.31 1111710800 T * xenon.oftc.net http://linux-vserver.org/ | latest stable 1.2.10, devel 1.9.5, ng9.4 -- He who asks a question is a fool for a minute; he who doesn't ask is a fool for a lifetime -- share the gained knowledge on the wiki, and we'll forget about the minute ;) 1111710808 J * ensc|w ~ensc@62.153.82.27 1111710808 J * DaPhreak|gone ~phreak@lms.rz.uni-greifswald.de 1111710808 J * Loki|muh loki@satanix.de 1111710863 M * Bertl not too shabby! 1111710867 Q * lilo Quit: bbbiab 1111710977 Q * ndim Ping timeout: 480 seconds 1111711167 Q * mcp Ping timeout: 480 seconds 1111711270 J * lilo ~lilo@lilo.usercloak.oftc.net 1111711278 J * ndim hun@helena.bawue.de 1111711528 M * Bertl rs_, alexx: http://vserver.13thfloor.at/Experimental/FOR-1.9.6/delta-unhold-fix01.diff 1111711564 M * Bertl it is compile and qemu tested, but not on a real smp system (going to do that in a few) 1111711572 M * alexx Bertl, you are so great ;) 1111711597 M * alexx Bertl, have you an smp near you ? 1111711605 M * alexx else, i have one for test here 1111711652 M * rs_ I will put it on the prod-test node with some vserver of know people envolv in new version testing 1111711681 M * Bertl alexx: well, testing can not hurt, I have a test machine to test it ... 1111712866 M * alexx Bertl, delta-blkio-feat01.diff is it a new feature, or a bug correction ? 1111712877 M * Bertl a new feature ... 1111712897 M * Bertl -fix?? is a bugfix --feat?? is a feature 1111712913 M * alexx okiiiiiiiii, it's more clear now ;) 1111712931 M * Bertl there is also -clean?? and -debug?? 1111712957 M * Bertl clean is code cleanup, no change in behaviour, -debug is debug code 1111713441 M * rs_ thought this naming was clean for anyone.. :) 1111713446 M * rs_ clear 1111713610 M * Bertl nothing is obvious untill you see that it's obvious ... 1111714163 M * alexx right :) 1111714260 M * jd86 is there some reason this chat is on OFTC and not freenode? lol every other channel i'm in is on freenode 1111714281 M * Bertl yes, there is ... 1111714290 M * jd86 what is it? 1111714308 M * Bertl this channel started on irc.linz.at ... 1111714325 M * jd86 hrm :) 1111714335 M * Bertl and then folks came and told me .. hey why not go to 1111714348 M * jd86 lol 1111714361 M * jd86 seems like freenode is the home of most oss projects 1111714364 M * Bertl and we had a lengthy discussion why is soo much better 1111714393 M * Bertl and after that we did a little voting ... and the result was irc.oftc.net ;) 1111714730 N * BobR_oO BobR 1111715003 N * BobR BobR_oO 1111715753 M * rs_ hmm it's worth, it even not ping at all 1111715766 M * rs_ oups wrong place :) 1111716287 M * Bertl np 1111716869 M * Beirdo as far as I'm concerned, oftc and freenode are both good networks 1111716880 M * Beirdo people should extract head from ass :) 1111717742 M * rs_ bed time 1111717745 M * rs_ cya 1111717747 Q * rs_ Quit: bed 1111718347 Q * yarihm Ping timeout: 480 seconds 1111720680 J * Beave ~beave@vistech.org 1111720799 M * Bertl welcome Beave! 1111720809 M * Beave I'm attempting to do a vserver setup on a gentoo box, and when i start (vserver --verbose gentoo-template start) i get no errors, but a "status" shows vserver as "stopped".. 1111720811 M * Beave hello bertl! 1111720828 M * Beave whats a good way for me to debug whats happening? 1111720830 M * Bertl probably your services are not starting as expected 1111720854 M * Bertl so the vserver tools do everything they should do, but the gentoo scripts do not start anything 1111720868 M * Bertl this is often caused by some files in /var/* 1111720879 M * Bertl (gentoo makes some notes about started services there) 1111720882 M * Beave hmm. I thought i cleaned things up pretty well. 1111720884 M * Beave yeah. 1111720911 M * Bertl well, it could also be the 'wrong' init style, which IIRC, is gentoo for gentoo ;) 1111720945 M * Beave yeah - style is set to "gentoo" 1111720979 M * Bertl okay, if you are sure everything is cleaned up fine, then do: 1111720992 M * Bertl vserver --debug gentoo-template start 1111721003 M * Beave ah. i'll try that. (was using --verbose 1111721004 M * Beave ) 1111721004 M * Bertl and upload the output somewhere (e.g. pastebin.com) 1111721093 M * Beave let me verify my /var before i waste anymore time. I've "restarted" this processes a few times. 1111721136 M * Bertl ensc: would it be an option to have some cleanup stuff running before a gentoo guest is started? 1111721171 M * Bertl something like a gentoo pre-startup script, or so? 1111721172 Q * monrad Read error: Connection reset by peer 1111721184 M * ensc sorry... I do not know how to start gentoo clients in a good way 1111721202 M * Bertl well, 90% of the errors reported here are caused by those /var/* files 1111721208 M * ensc the gentoo initmethod should call init which should do cleanup 1111721220 M * Bertl it should? 1111721239 M * ensc that's the usual linux startup routine 1111721260 M * ensc only difference is, that most hardware scripts are failing for vserver 1111721311 M * Bertl maybe gentoo folks can provide a 'proper' cleanup which can be executed on startup? 1111721947 M * Beave Okay - did a bit more twidling .. i put the debug dump at http://vistech.net/~champ/debug.txt .. will that work? 1111721955 M * Beave still no luck. 1111722034 J * monrad ~monrad@213083190130.sonofon.dk 1111722110 M * Bertl Beave: somewhere in the lower 20% you see ... 1111722121 M * Bertl .... --endsetup --chroot --silent -- /sbin/rc default 1111722142 M * Beave yes.. 1111722149 M * Bertl which means that it calls the /sbin/rc script _inside_ your guest, with the default argument 1111722152 Q * micah Ping timeout: 480 seconds 1111722169 M * Bertl this is supposed to get the services (or at least one persistent service) running 1111722174 M * Bertl evening monrad! 1111722212 M * monrad hi 1111722214 M * Bertl if this script does not start any daemon, your vserver guest will not keep running, instead it will drop dead right after the vserver script returns 1111722217 M * monrad beagle is quite cool 1111722240 M * Beave ah 1111722337 M * Beave so - basically, i need to have somethng running (cron, etc)? 1111722350 M * Beave in order for vserver not to drop? 1111722424 M * Bertl yep, usually that's syslogd 1111722432 M * Beave ah... well, live and learn! 1111722446 M * Bertl without processes, no process separation ;) 1111722458 M * Beave yeah.. right after you said that.. 1111722472 M * Beave i thought, "gee. he has a freaking point". 1111722481 M * Bertl ;) 1111722492 M * Beave ok.. thanks.. 1111722507 M * Bertl you're welcome! 1111722527 M * Beave I might idle here a bit to pick up some other *cough* useful tips. 1111722528 M * Beave heh. 1111722544 M * Beave let me switch clients 1111722553 Q * Beave Quit: BitchX: melts in your mouth, not in your hands 1111722600 J * Beave ~beave@vistech.org 1111723185 M * Beave ... and do you know.. its up.. suprise suprise. 1111723235 M * Bertl fascinating ... but the 'same' client, right? 1111723260 M * Beave hehe. 1111723270 M * Beave 'same' client, what do you mean? 1111723278 M * Bertl irc client ... 1111723308 M * Bertl < Beave> let me switch clients 1111723326 M * Beave ah. 1111723327 M * Beave i see. 1111723344 M * Beave well. i usually have BitchX running in screen.. 1111723369 M * Beave when i joined in, i was in via a non-screen session, so i dropped that and jump into screen.. 1111723378 M * Bertl i.c. good choice ;) 1111723381 M * Beave easier for me to idle that way.. and switch betweens servers. 1111723393 M * Beave and not drop, etc..etc.. 1111724101 M * Bertl erwan_taf: hey found some mandrake rpms for util-vserver 0.30.204?! 1111724518 M * Beave wow. that /var/lib/init.d needs to be cleaned quite a bit. 1111725350 M * Beave okay.. here's another one.. IP doesnt seem to be binding to my vserver correct.. for example.. within my guest os, if i start sshd i'll get... 1111725356 M * Beave Mar 25 04:32:48 gentoo-template sshd[16313]: fatal: Cannot bind any address. 1111725374 M * Beave the ip is actually up. (pingable) 1111725378 M * Bertl probably your sshd on the 'host' is already bound there 1111725387 M * Beave just not tied to my vserver. 1111725397 M * Beave ah. 1111725404 M * Bertl best is to restrict it to one ip per sshd config 1111725466 M * Beave So, on the host, set the ListenAddress in sshd_conf (and the same for the guests i assume?) 1111725483 M * Bertl no, for the guests 0.0.0.0 is fine 1111725499 M * Bertl they are restricted by the vserver kernel (to the configured ips) 1111725510 M * Beave ok. 1111725511 M * Beave i see. 1111725631 M * Beave that did it. So, pretty much any service (apache, etc) i'll have to do that .. okay. thanks again. 1111725653 M * Bertl you can use the v_* wrappers for most services ... 1111725658 M * Bertl (on the host) 1111725660 A * Beave 's taking notes so he doesnt forget all this. 1111725705 M * Bertl (channel is logged, http://irc.13thfloor.at/LOG/) 1111725740 M * Beave i should know that (i've been reading though some logs i ran into on google.) 1111725741 M * Bertl but sshd is a little special here, because you might want to administrate the vservers via ssh logon 1111725790 M * Bertl and if you use the v_sshd warpper there, you will not be able to start a vserver successfully (because of the existing network restrictions ;) 1111727117 M * Bertl okay, enough for today ... I'm off to bed now ... have a nice whatever everyone! 1111727147 M * Bertl cya tomorrow folks! 1111727153 N * Bertl Bertl_zZ 1111727365 M * douglas hey 1111727366 M * douglas bertl 1111727368 M * douglas still there? 1111727538 M * douglas I'm running 1.9.5-rc3 and I can ping, but traceroute still is not permitted. 1111732190 J * erwan_ho ~erwan@lns-vlq-39f-81-56-133-136.adsl.proxad.net 1111732264 Q * erwan_ho Quit: 1111732267 J * erwan_ho ~erwan@lns-vlq-39f-81-56-133-136.adsl.proxad.net 1111733619 Q * erwan_ho Remote host closed the connection 1111734065 Q * maharaja Ping timeout: 480 seconds 1111738396 J * ydupont ~dupont-y@tomintoul.cri.univ-nantes.fr 1111738611 Q * ydupont Quit: 1111739745 Q * virtuoso Read error: Connection reset by peer 1111740372 J * kalou ~kalou@ALamentin-101-1-5-105.w81-48.abo.wanadoo.fr 1111740383 M * kalou Hi all ! 1111740413 M * jason357 hi 1111741239 Q * grecea Remote host closed the connection 1111742337 Q * kalou Ping timeout: 480 seconds 1111744102 J * ydupont ~dupont-y@tomintoul.cri.univ-nantes.fr 1111744723 J * maharaja maharaja@ipax.at 1111746832 J * virtuoso ~s0t0na@80.253.205.251 1111747212 M * ydupont hello all 1111747255 M * ydupont something elese seeing this in 2.6 ? 1111747263 M * ydupont someone, sorry: 1111747312 M * ydupont inside a vserver: 1111747314 M * ydupont eth0:Dist Link encap:Ethernet HWaddr 00:30:48:28:AC:F8 1111747314 M * ydupont inet addr:172.20.12.105 Bcast:172.20.12.255 Mask:255.255.255.0 1111747314 M * ydupont UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 1111747314 M * ydupont Base address:0x3000 Memory:f8200000-f8220000 1111747314 M * ydupont eth0:EdCh Link encap:Ethernet HWaddr 00:30:48:28:AC:F8 1111747316 M * ydupont inet addr:172.20.12.104 Bcast:172.20.12.255 Mask:255.255.255.0 1111747317 M * ydupont UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 1111747319 M * ydupont Base address:0x3000 Memory:f8200000-f8220000 1111747321 M * ydupont eth0:Igar Link encap:Ethernet HWaddr 00:30:48:28:AC:F8 1111747323 M * ydupont inet addr:172.20.12.103 Bcast:172.20.12.255 Mask:255.255.255.0 1111747325 M * ydupont UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 1111747327 M * ydupont Base address:0x3000 Memory:f8200000-f8220000 1111747329 M * ydupont eth0:Metr Link encap:Ethernet HWaddr 00:30:48:28:AC:F8 1111747331 M * ydupont inet addr:172.20.12.94 Bcast:172.20.12.255 Mask:255.255.255.0 1111747333 M * ydupont UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 1111747335 M * ydupont Base address:0x3000 Memory:f8200000-f8220000 1111747339 M * ydupont eth0:Nagi Link encap:Ethernet HWaddr 00:30:48:28:AC:F8 1111747343 M * ydupont inet addr:172.20.12.107 Bcast:172.20.12.255 Mask:255.255.255.0 1111747345 M * ydupont UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 1111747347 M * ydupont Base address:0x3000 Memory:f8200000-f8220000 1111747349 M * ydupont eth0:Netv Link encap:Ethernet HWaddr 00:30:48:28:AC:F8 1111747351 M * ydupont inet addr:172.20.12.35 Bcast:172.20.12.255 Mask:255.255.255.0 1111747353 M * ydupont UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 1111747355 M * ydupont Base address:0x3000 Memory:f8200000-f8220000 1111747357 M * ydupont eth0:Perd Link encap:Ethernet HWaddr 00:30:48:28:AC:F8 1111747359 M * ydupont inet addr:172.20.12.135 Bcast:172.20.12.255 Mask:255.255.255.0 1111747361 M * ydupont UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 1111747363 M * ydupont Base address:0x3000 Memory:f8200000-f8220000 1111747365 M * ydupont lo Link encap:Local Loopback 1111747367 M * ydupont inet addr:127.0.0.1 Mask:255.0.0.0 1111747369 M * ydupont UP LOOPBACK RUNNING MTU:16436 Metric:1 1111747373 M * ydupont RX packets:8468135 errors:0 dropped:0 overruns:0 frame:0 1111747375 M * ydupont TX packets:8468135 errors:0 dropped:0 overruns:0 carrier:0 1111747377 M * ydupont collisions:0 txqueuelen:0 1111747379 M * ydupont 1111747381 M * ydupont taht is, ALL the interfaces ? 1111747383 M * ydupont with the IP @ 1111747385 M * ydupont this is not a behaviour I Had with 2.4 and the even the olders 2.6 patches 1111747580 M * alexx ydupont, i've no pb with 2.6.11.5-vs1.9.5 1111747750 M * ydupont that's what I have too 1111747762 M * ydupont Linux HighlandPark 2.6.11.5-vs1.9.5-rc4TTEC-SA 1111747771 M * ydupont alexx: well not totaly the same 1111747813 M * alexx have you "hide_netif" flags set ? 1111747818 M * ydupont alexx: I assume there is not much differences beetween rc4 1111747834 M * ydupont seems to be the default with latest utils ? 1111747849 M * alexx ha ? i don't know :) 1111747859 M * ydupont I use the latest utils, but in legacy mode 1111747875 M * ydupont so maybe the problems is here 1111748136 M * alexx i use the alpha utils too, with new configuration system 1111748151 M * alexx i don't know default flags 1111748336 M * ydupont probably the problem lies in the legacy mode... 1111749103 M * SiD3WiNDR eww, caps in hostnames :p 1111749938 J * DuckMaster ~duckx@195.75.27.158 1111749947 Q * DuckMaster Quit: 1111749965 J * DuckMaster ~duckx@195.75.27.158 1111750439 J * yarihm ~yarihm@80.218.3.115 1111752082 Q * douglas Quit: 1111752626 J * j357 ~m00@wv-rndhll-cmts1a-a-105.shphwv.adelphia.net 1111752996 Q * jason357 Ping timeout: 480 seconds 1111754207 M * ydupont Sid3WiNDR: yes caps... doesn't matter ;) 1111754225 M * SiD3WiNDR it's just ugly :p 1111754236 M * ydupont Sexy, you just wan to say ? 1111755308 N * Bertl_zZ Bertl 1111755386 M * Bertl morning folks! 1111755465 N * Doener_zZz Doener 1111755475 M * Doener morning! 1111755491 M * Bertl morning Doener! 1111755551 M * Bertl ydupont: didn´t manage to grasp the issue, please explain! 1111755580 M * ydupont bertl: hello 1111755601 M * Doener AFAICT he just doesn't want all interface(-aliase)s to show up in the vserver 1111755602 M * ydupont Bertl: inside a vserver in 2.6, i see all the interface WITH the IP number 1111755630 M * ydupont this wasn't a behaviuor I had with previous 2.6 versions (old ones, yes...) 1111755675 M * ydupont I think the proble is because I use legacy mode (still my old vserves.cfg) 1111755697 M * ydupont (I use the latest vserver-utils) 1111755712 M * Bertl well, set the hide_netif flag then? 1111755942 Q * yarihm Quit: Leaving 1111756084 J * yarihm ~yarihm@80-218-3-115.dclient.hispeed.ch 1111756302 M * ydupont isn't hide_netif a defult, now ?? 1111756434 M * Bertl it's a feature flag, and flags are default off in 1.9.x 1111756479 M * Bertl that didn't really change but IIRC we fixed an issue where older releases did the hiding accidentially 1111756564 M * Bertl Doener: ad interfaces, we should check two things there ... 1111756595 M * Bertl first it seems that the ip check doesn't handle 0.0.0.0 correctly 1111756626 M * Bertl then I'm not sure that the netmask is handled properly 1111757473 M * ydupont humm i'm quite lost in the doc really... 1111757519 M * Bertl hmm, in what way? 1111757543 M * ydupont how can I apply the hide_netif 1111757559 M * ydupont I'm on the floware page of enrico right now 1111757562 M * ydupont flashy ! 1111757567 M * ydupont flower, sorry 1111757582 M * Bertl k, you found the different stylesheets? 1111757628 M * Doener Bertl: hm, two OT questions regarding screen... do you know how to have screen adapt to a resized xterm without reattaching? and do you know a way to use the mouse with screen, for example in vim? 1111757654 M * Bertl ad adapt, happens here automatically ... 1111757666 M * Bertl ad mouse, never tried ... 1111757685 M * Doener hm, xterm or some other terminal? 1111757691 M * Bertl mgt 1111757704 M * Doener k 1111757749 Q * Vudumen Read error: Connection reset by peer 1111757755 M * Bertl XT (bool) Terminal understands special xterm sequences (OSC, mouse tracking). 1111757780 M * Bertl so maybe just your terminal config is wrong? 1111757811 M * Bertl ydupont: okay, look for context flags ... 1111757828 M * Bertl Contains per line a flag. See lib/cflags-v13.c for possible values. 1111757875 M * Bertl # /etc/vservers//flags 1111757903 Q * ydupont Read error: Connection reset by peer 1111757981 A * Bertl .oO( hmm, is it that bad? ) 1111757994 J * ydupont ~dupont-y@tomintoul.cri.univ-nantes.fr 1111758001 M * Bertl wb ydupont! 1111758018 M * ydupont Bertl: I shoot the power cord of my station :-( 1111758025 M * ydupont arf' 1111758029 M * Bertl excellent idea ;) 1111758034 M * ydupont very good indeed 1111758094 J * mcp ~hightower@www.c-tera.de 1111758112 M * Bertl welcome mcp! 1111758133 M * albeiro hey mcp, hey all others 1111758149 M * Bertl ydupont: I heard that this sophisticated technique even protects M$ based machines from remote attacks ... 1111758153 M * albeiro mcp: when wolk for 2.6 is starting ? ;p 1111758444 J * grecea ~grecea@h-195-22-237-74.mdl.net 1111758456 M * Bertl welcome grecea! 1111758789 M * ydupont Bertl: Ok I'm currently reading the messages in the archive so what i'm seeing is OK. 1111758815 M * ydupont Bertl: Other thing : maybe you remember I was aving pb with mem allocation in 2.6 ? 1111758826 M * ydupont Bertl: I still have ... 1111758900 M * ydupont swapper: page allocation failure. order:1, mode:0x20 1111758901 M * ydupont [<8013d9ec>] __alloc_pages+0x2e8/0x387 1111758901 M * ydupont [<801401b2>] kmem_getpages+0x2a/0x84 1111758901 M * ydupont [<80140d89>] cache_grow+0xaf/0x160 1111758901 M * ydupont [<8014100c>] cache_alloc_refill+0x1d2/0x20f 1111758902 M * ydupont [<801412d0>] __kmalloc+0x64/0x66 1111758903 M * ydupont [<80312163>] alloc_skb+0x41/0xe5 1111758905 M * ydupont [<8033f0ee>] tcp_collapse+0x142/0x34c 1111758907 M * ydupont [<8033f3fe>] tcp_prune_queue+0x71/0x1e3 1111758909 M * ydupont [<8033eac8>] tcp_data_queue+0x658/0xb3c 1111758911 M * ydupont [<80311b39>] sk_reset_timer+0xc/0x16 1111758913 M * ydupont [<8033d4aa>] tcp_ack+0x22c/0x612 1111758917 M * ydupont [<8033feaf>] tcp_rcv_established+0x3ec/0x7e3 1111758919 M * ydupont [<80348877>] tcp_v4_do_rcv+0xf2/0x104 1111758921 M * ydupont [<80349067>] tcp_v4_rcv+0x7de/0x90c 1111758923 M * ydupont [<8036688f>] ip_vs_in+0x2e0/0x303 1111758925 M * ydupont [<8036154c>] ip_ct_refresh_acct+0x10a/0x10c 1111758927 M * ydupont [<8032dece>] ip_local_deliver_finish+0x0/0x1e0 1111758929 M * ydupont [<8032df3f>] ip_local_deliver_finish+0x71/0x1e0 1111758931 M * ydupont [<80321313>] nf_hook_slow+0xdd/0xfd 1111758933 M * ydupont [<8032dece>] ip_local_deliver_finish+0x0/0x1e0 1111758935 M * ydupont [<8032dde6>] ip_local_deliver+0x178/0x260 1111758937 M * ydupont [<8032dece>] ip_local_deliver_finish+0x0/0x1e0 1111758939 M * ydupont [<8032e747>] ip_rcv_finish+0x191/0x2c2 1111758941 M * ydupont [<80320f02>] nf_iterate+0x52/0x9b 1111758943 M * ydupont [<8032e5b6>] ip_rcv_finish+0x0/0x2c2 1111758949 M * ydupont [<8032e5b6>] ip_rcv_finish+0x0/0x2c2 1111758951 M * ydupont [<80321313>] nf_hook_slow+0xdd/0xfd 1111758953 M * ydupont [<8032e5b6>] ip_rcv_finish+0x0/0x2c2 1111758955 M * ydupont [<8032e41c>] ip_rcv+0x36e/0x508 1111758957 M * ydupont [<8032e5b6>] ip_rcv_finish+0x0/0x2c2 1111758959 M * ydupont [<80279eae>] blk_run_queue+0x25/0x3c 1111758961 M * ydupont [<80318162>] netif_receive_skb+0x24d/0x29e 1111758963 M * ydupont [<802b0008>] scsi_host_cancel+0x52/0xb5 1111758965 M * ydupont [<8028800f>] e1000_clean_rx_irq+0xb6/0x474 1111758967 M * ydupont [<80344860>] tcp_delack_timer+0x0/0x1e9 1111758969 M * ydupont [<80287edb>] e1000_clean_tx_irq+0x190/0x20e 1111758971 M * ydupont [<80287c9c>] e1000_clean+0x4d/0xfc 1111758973 M * ydupont [<80318333>] net_rx_action+0x70/0xf2 1111758977 M * ydupont [<8011c783>] __do_softirq+0x5f/0xcd 1111758979 M * ydupont [<8011c81e>] do_softirq+0x2d/0x2f 1111758981 M * ydupont [<8010452e>] do_IRQ+0x1e/0x24 1111758983 M * ydupont [<80102e12>] common_interrupt+0x1a/0x20 1111758985 M * ydupont [<8010060d>] default_idle+0x23/0x29 1111758987 M * ydupont [<80100694>] cpu_idle+0x4e/0x5c 1111758989 M * ydupont [<80472875>] start_kernel+0x158/0x194 1111758991 M * ydupont [<804722fe>] unknown_bootoption+0x0/0x1d4 1111758993 M * ydupont Is there some vserver-specific function in this path ?? 1111758995 M * ydupont this line, maybe ? 1111758997 M * ydupont [<8036688f>] ip_vs_in+0x2e0/0x303 1111759013 M * Bertl no, that is the 'other' linux virtual server ;) 1111759035 M * Bertl btw, could you upload it somewhere ;) 1111759060 M * ydupont no probs. 1111759066 M * ydupont by mail ? 1111759088 M * ydupont BTW i'm not sure VS is the problem. I suspect e1000 more 1111759120 M * Bertl well, basically I would not suspect anybody ... it's an allocation failure ... 1111759124 M * alexx i work with e1000 without problem on 2.6.11.5 1111759135 M * Bertl so just no more oder 1 page blocks are there ... 1111759153 M * ydupont after just some minutes of load ? 1111759156 M * Bertl you don't get a panic or so, right? 1111759160 M * ydupont yes 1111759189 M * ydupont I upped a bit /proc/sys/vm/min_free_kbytes 1111759194 M * Bertl so this is the memory allocation system which can not handle 'whatever' load/issues your system has ... 1111759196 M * ydupont and now i don't get those 1111759215 M * ydupont yes, I understand thgat, but for me it's a regression agaiunst 2.4 1111759229 M * ydupont and I understand it's probably not vserver fault 1111759233 M * ydupont just wanted ti be sure 1111759250 M * Bertl the chances for linux-vserver being involved there are neglectible ... 1111759251 M * ydupont I'm using the new memory model intrduced by vserver 1111759257 M * ydupont I have 2G of Ram 1111759276 M * Bertl that should ease the issues, hope you disabled highmem ... 1111759279 M * ydupont I'm not using HighMem anymore 1111759293 M * ydupont last time I tried this, I had a crash in some hours 1111759298 M * ydupont now it seems to be ok 1111759324 M * ydupont But I still don't understanf whuy 2.6 doesn't cope too well with that 1111759351 M * ydupont BTW, where does the New 3/1G cames from ? 1111759354 M * Bertl did you use e1000 with 2.4? 1111759372 M * ydupont yes 1111759375 M * ydupont the very same hardware 1111759383 M * Bertl similar throughput? 1111759385 M * ydupont yes 1111759394 M * ydupont same vservers 1111759407 M * ydupont this is the same macheni with the same vservers 1111759413 M * Bertl well, guess it's really a regression ... is it still there with 2.6.11.5? 1111759418 M * ydupont yes 1111759439 M * ydupont HighlandPark:~# uname -a 1111759439 M * ydupont Linux HighlandPark 2.6.11.5-vs1.9.5-rc4TTEC-SAN- #2 SMP Tue Mar 22 12:16:27 CET 2005 i686 unknown 1111759471 M * Bertl google for 'page allocation failure' 1111759489 M * Bertl IIRC there was a thread suggesting some vm/kmem tunings 1111759539 M * ydupont You should upgrade to the newest kernel if possible. If that's not possible, 1111759539 M * ydupont increase /proc/sys/vm/min_free_kbytes 1111759539 M * ydupont This allocation failure really should not cause your system to crash, but 1111759539 M * ydupont increasing min_free_kbytes will make it less likely that you will see an 1111759539 M * ydupont allocation failure. 1111759546 M * ydupont this is what i've done... 1111759556 M * ydupont and OK, it seems to bypass the problem. 1111759570 M * ydupont But I Still thinks there is a problem somewhare 1111759615 M * Bertl well, I think (but that is not verified) that 2.4 simply did hide those issues 1111759682 M * ydupont ah maybe 1111759823 J * Vudumen vudumen@perverz.hu 1111759824 Q * Vudumen Quit: 1111759857 J * Vudumen vudumen@perverz.hu 1111760085 M * Bertl the thing is, if you have GB ethernet and some workload 1111760107 M * ydupont Lot of workload 1111760111 M * ydupont (8 or more) 1111760122 M * Bertl then it can easily happen that packets arrive at a higher rate the kernel can handle (from the memory allocation point of view) 1111760143 M * ydupont yes I understand that 1111760175 M * ydupont It's juste that 2.4 seemed to handle that better 1111760177 M * Bertl now for 2.4 I guess, it was just not reported, a packet dropped now and then should not cause too much trouble 1111760188 M * ydupont but, once again, maybe 2.4 hide these 1111760194 M * ydupont in 2.6 i also have this 1111760207 M * ydupont TCP: Treason uncloaked! Peer 172.20.12.14:42820/873 shrinks window 9761660:9762612. Repaired. 1111760207 M * ydupont TCP: Treason uncloaked! Peer 172.20.12.14:42820/873 shrinks window 9761660:9762612. Repaired. 1111760207 M * ydupont TCP: Treason uncloaked! Peer 172.20.12.66:39997/873 shrinks window 3287782147:3287783595. Repaired. 1111760207 M * ydupont TCP: Treason uncloaked! Peer 172.20.12.66:39997/873 shrinks window 3287782147:3287783595. Repaired. 1111760207 M * ydupont TCP: Treason uncloaked! Peer 172.20.12.66:39997/873 shrinks window 3287886301:3287887749. Repaired. 1111760208 M * ydupont TCP: Treason uncloaked! Peer 172.20.12.66:39997/873 shrinks window 3287899333:3287902229. Repaired. 1111760210 M * ydupont TCP: Treason uncloaked! Peer 172.20.12.66:39997/873 shrinks window 3287939601:3287941049. Repaired 1111760220 M * ydupont wich seems to indiquate that some packets are lost anyway 1111760291 M * Bertl well, it indicates that some machines use broken tcp ;) 1111760306 M * ydupont those machine are linux 2.4 vservers ;-) 1111760345 M * Bertl So it appears that someone is running some sort of "tar-pit" system that is designed to keep sockets in a bad state and run you out of kernel memory. 1111760348 M * Bertl Maybe you should tell your ISP that they are to blame for such actions being done to you and that they should give you face(I think that was the term you used) by closing their open relays. 1111760356 M * ydupont semmes more related to the memory allocation failure, I think 1111760356 M * Bertl (from a web forum) 1111760366 M * ydupont nop, this is a private network 1111760385 M * ydupont and i OWN the machines involved 1111760397 M * ydupont and it doesn't apper with 2.4 1111760401 M * Bertl #ifdef TCP_DEBUG 1111760401 M * Bertl if (net_ratelimit()) 1111760401 M * Bertl printk(KERN_DEBUG "TCP: Treason uncloaked! Peer 1111760401 M * Bertl %u.%u.%u.%u:%u/%u shrinks window %u:%u. Repaired.\n", 1111760401 M * Bertl NIPQUAD(sk->daddr), htons(sk->dport), sk->num, tp->snd_una, tp->snd_nxt); 1111760403 M * Bertl #endif 1111760414 M * ydupont yes I think, th pb is here 1111760423 M * ydupont maybe 2.6 is quick enough to saturate ? 1111760449 M * Bertl so a) this is not there in 2.4 and b) probably your limits are too low ;) 1111760475 M * ydupont ok, I can try to tune them 1111760496 M * rs re 1111760511 M * Bertl welcome rs! 1111760514 M * rs thx 1111760529 M * Bertl so (how) is the fix working? 1111760559 M * rs no yet test actually :/ 1111760568 M * rs I going to put it on a node 1111760586 M * Bertl ah, thought you want to wait for the next release ;) 1111760603 M * rs hehe :) 1111760726 M * ydupont ratelimit is just not for killing syslog 1111760742 M * Bertl yep 1111760747 M * ydupont so the problem lies in tcp_timer 1111760778 M * Bertl precisely at: if (tp->snd_wnd == 0 && !sk->dead && 1111760778 M * Bertl !((1<state)& TCPF_SYN_SENT|TCPF_SYN_RECV))) { 1111760785 M * ydupont /* Receiver dastardly shrinks window. Our retransmits 1111760785 M * ydupont * become zero probes, but we should not timeout this 1111760785 M * ydupont * connection. If the socket is an orphan, time it out, 1111760785 M * ydupont * we cannot allow such beasts to hang infinitely. 1111760785 M * ydupont */ 1111760791 M * ydupont ok ok 1111760854 M * ydupont maybe this in a rsync temptative from another host on a not yet up rsyncd 1111760867 M * ydupont or... whatever... 1111760883 M * ydupont I think i'll try a post on netdev 1111760898 M * Bertl Doener: how much paschal motivation do you feel? 1111760975 M * Bertl ydupont: btw, can't hurt to disable 'linux virtual server' (not linux-vserver) if you do not use it ... 1111760992 M * ydupont and now... trying to convert those old configs to use new tools dans hide_netif 1111760995 M * ydupont well I use 1111761011 M * ydupont i'm currently building clusters of vservers 1111761025 M * ydupont well, anyway IpvS is not for the nodes, I could disable them 1111761047 M * Bertl sounds good, any 'documentation' on that, or maybe some posting on the ml (in the future?) 1111761047 M * ydupont I just have to use it on the directors (which are nor vservers) 1111761053 M * ydupont point taken 1111761057 M * ydupont well ... 1111761070 M * ydupont In fact I use a setup that won't plese you i'm afraid 1111761083 M * Bertl how do you know? ;) 1111761086 M * ydupont The directors are based on Xen virtual machines 1111761097 M * ydupont BUT the nodes are vservers 1111761145 M * Bertl well, contrry to common believe, I'm absolutely not against Xen ;) 1111761150 M * Doener paschal motivation: about none... motivation in general: medium+ ;) screen is still bugging me though... got xterm to do scrolling by mouse wheel, but no mouse in vim yet... 1111761181 M * ydupont In fact I think xen is a totally good complement to vservers 1111761187 M * ydupont vservers delivers the services 1111761202 M * ydupont xen provide the infrastructure for multiples directors 1111761233 M * ydupont I can give you a pictures if you want to know what we're implementing 1111761277 M * Bertl Doener: http://lists.gnu.org/archive/html/screen-users/2004-12/msg00029.html 1111761379 M * Bertl ydupont: I would appreciate some posting about such activities on the ml (just to give folks an idea what can be done ...) 1111761417 M * Bertl and maybe it helps you too, by providing new ideas or stating obvious flaws/issues 1111761442 M * Bertl but of course that's totally up to you ... 1111761508 M * Doener thanks, that already does 50% of what i need ;) 1111761801 M * ydupont Bertl: yes I'd like to do too 1111761836 M * ydupont Bertl: but you know, i'm currently doinf what was planned for 4 months... And I even don't talk about IPv6 ;-) 1111761892 M * ydupont Bertl: but, on the good side i'm proposing a paper about virtualization on a conf... If it's accepted you'll have a decent paper 1111761954 M * Bertl excellent! 1111761986 M * ydupont in french :( 1111761994 M * ydupont (Ok, i accpet to translate ;) 1111762005 M * Bertl :) 1111762285 M * ydupont Bertl: probably a FAQ... is there a script to handle the config format change ? 1111762285 Q * Vudumen Read error: Connection reset by peer 1111762351 M * Bertl ydupont: not that I know of, because it's obviously trivial, nobody bothered to write _and_ publish something like that (unfortunately) 1111762553 M * ydupont ;-) 1111762567 M * ydupont I'm quite lazy and as I have more than 100 to convert ;-) 1111762598 M * Bertl looks like a good chance to see a script soon ;) 1111762607 M * ydupont don't think so 1111762623 M * ydupont baecause my configs are old, anyway 1111762635 M * ydupont and I won't migrate 100 vservers in 1 day 1111762644 M * Bertl well, then either you have somebody to cahnge it for you, or you aren't lazy ;) 1111762654 M * ydupont I'm not SO lazy ;à 1111762660 M * ydupont ;-) 1111762666 M * ydupont dman fingers! 1111762674 M * ydupont damn!!!! grr 1111762953 M * Bertl well, what would you do without them ;) 1111765824 J * Vudumen vudumen@perverz.hu 1111766251 M * Bertl welcome Vudumen! 1111766926 M * ydupont Bertl: ok, the new config works fine with 2.6 1111766931 M * ydupont so it was a non issue : 1111766935 M * ydupont bye & thanks 1111767040 Q * ydupont Quit: Leaving 1111767188 J * micah micah@micha.hampshire.edu 1111767390 M * Bertl welcome micah! 1111767645 M * micah thanks! 1111768417 M * Bertl Doener: still working on vim mouse support? 1111768427 M * Doener nah, gave up 1111768448 M * Bertl do you have qemu/latest kernel available? 1111768469 M * Doener qemu yes, latest kernel no... but that's fixable 1111768589 M * erwan_taf qemu rox 1111768595 M * erwan_taf kqemu even more 1111768672 M * Doener Bertl: including for-1.9.6 stuff i guess? 1111768758 M * Bertl well, yeah, guess not necessary .. but wont hurt 1111768858 M * Bertl http://vserver.13thfloor.at/Experimental/OOPS/OOPS-05.txt 1111768982 M * Doener hmm... interesting... 1111769009 M * Bertl yeah, indeed ;) 1111769106 M * erwan_taf Bertl: you are running a 2.6.11 on a Mandrakelinux 8.2 ? 1111769126 M * Bertl more or less, yes ;) 1111769145 M * erwan_taf waaaaaaaa 1111769149 M * Bertl btw, discovered 'your' packages yesterday 1111769174 M * Bertl (pbone has indexed them) 1111769269 M * erwan_taf :b 1111769322 M * Bertl don't you like mandrake? 1111769332 M * erwan_taf I was working a Mandrakesoft :) 1111769340 M * Bertl yeah, I know, so? 1111769349 M * erwan_taf of course I like it 1111769364 M * Bertl just because of the 'waaaaaaaa' 1111769374 M * erwan_taf waaaaaaaaaa = impressed 1111769388 M * erwan_taf running a 2.6 on a 8.2 is not very common 1111769396 N * DaPhreak|gone DaPhreak 1111769424 M * DaPhreak lo erwan_taf, Bertl 1111769425 M * erwan_taf and may cause some troubles 1111769429 M * erwan_taf lo DaPhreak 1111769464 M * Bertl erwan_taf: well, I can assure you, no troubles ;) 1111769484 M * Bertl (but it's not really 8.2 anymore, it has evolved) 1111769528 M * erwan_taf yes, you must have upgrade many things 1111769536 M * erwan_taf fs utils etc.. 1111769607 M * Bertl I recently 'adapted' a 10.1/2 version but it's not deployed everywhere yet 1111769689 M * erwan_taf :b 1111770061 M * DaPhreak yay, no prae if you need one :) 1111770099 M * Doener Bertl: can't reproduce that bug... 1111770152 M * Bertl k, testing a few things here ... but good to hear ;) 1111770309 N * j357 jason357 1111770321 M * Bertl welcome? jason357! 1111770330 M * jason357 hi 1111771709 M * Bertl Doener: hehe, it's x25 again ... 1111771717 M * Bertl EIP is at x25_ioctl+0x21/0x400 1111771755 M * Doener hm, may become a running bug/gag 1111771768 M * Bertl yeah, looks like x25 is severely broken ... 1111773204 M * rs ensc: around ? 1111773217 M * ensc rs: yep 1111773229 M * rs I'm trying 205 (with the stop fix) 1111773235 M * rs and having a strange error 1111773246 M * rs I tried a restart and got this message: 1111773247 M * rs vc_xidopt2xid(""): No such file or directory 1111773250 Q * DuckMaster Quit: Leaving 1111773255 M * rs seems not to be an error while the restart worked 1111773286 M * rs seems to happen on stop 1111773314 M * ensc argl... please do s!C_CONTEXT!S_CONTEXT! in the fix 1111773612 Q * erwan_taf Quit: Leaving 1111773716 M * rs ok 1111777350 Q * yarihm Quit: Leaving 1111778238 M * Bertl okay, folks! we are currently investigating a somewhat strange behaviour of namespaces, which make life for some tools like 'yum' hard ... (enrico mentioned that on the ml) 1111778275 M * Bertl here is a short example of what happens and why it causes some trouble ... 1111778299 M * Bertl let us consider a running (namespace based) virtual server called ZZZZ 1111778320 M * Bertl further let us assume that we are logged on to the host 1111778384 M * ensc Bertl: it's probably not vserver related. Can be written shorter as vnamespace --new bash -c "mount --bind /bin / && ls -dli / /.." 1111778417 M * Bertl yeah, I know that it is not vserver related, give me a moment ;) 1111778427 M * ensc and you can remove the 'vnamespace' also 1111778440 M * Bertl now if you do: 1111778444 M * Bertl # vnamespace --enter ZZZZ bash 1111778444 M * Bertl # ls -d /vservers 1111778444 M * Bertl /vservers/ 1111778444 M * Bertl # ls -d /../vservers 1111778444 M * Bertl ls: /../vservers: No such file or directory 1111778462 M * Bertl (which is what causes trouble for yum) 1111778492 M * Bertl looking at the actual inodes now reveals: 1111778531 M * Bertl # ls -id /. /.. 1111778531 M * Bertl 2 /./ 835585 /../ 1111778531 M * Bertl # exit 1111778531 M * Bertl # ls -id /. /.. 1111778531 M * Bertl 2 /./ 2 /../ 1111778544 M * Bertl (note, the ls after the exit is on the host) 1111778595 M * Bertl looking at the code I see that this is caused by the follow_dotdot()/follow_mount() procedures checking for certain things like the current root mount/dentry 1111778626 M * Bertl if you reach the 'final' root mount, then the inodes of '..' and '.' will mtach 1111778713 M * Bertl now as I think this is an issue (even for mainline) we'll try to investigate it further and fix it ... you are welcome to join the fun ;) 1111778868 J * Hollow ~Hollow@home.xnull.de 1111778875 M * Bertl welcome Hollow! 1111778883 M * Hollow hey Bertl, how's it going? 1111778884 M * matti Bertl: ;] 1111778901 M * Bertl hey matti! `:] 1111779102 M * Bertl here is a patch to show some details about the internal stuff ... 1111779103 M * Bertl http://vserver.13thfloor.at/Experimental/delta-namei-debug2.diff 1111779159 M * Bertl (and a slighly less verbose version at: http://vserver.13thfloor.at/Experimental/delta-namei-debug.diff) 1111779773 J * IceTi ~IceTi@dsl-082-083-060-184.arcor-ip.net 1111779778 M * IceTi hi 1111779821 M * IceTi Is there a german site about vserver ?? 1111780084 J * yarihm ~yarihm@80-218-3-115.dclient.hispeed.ch 1111780098 J * DuckMaster ~Duck@dyn-83-157-182-47.ppp.tiscali.fr 1111780202 M * Bertl IceTi: probably ... 1111780222 M * Bertl look at the documentation on linux-vserver.org 1111780350 M * IceTi i don´t find something 1111780432 M * Bertl man, and you are doing that as a class project? 1111780484 M * IceTi oh yes 1111780502 M * Bertl and you expect to get good marks? 1111780507 Q * duckx Ping timeout: 480 seconds 1111780520 M * IceTi i think the page is very unclearly 1111780538 M * IceTi oh yes i will become a good mark, do u don´t think that? 1111780546 M * IceTi we will see ;-) 1111780593 M * IceTi it´s a documentation and a presentation and i think the "jury" don´t know very much about this topic 1111780596 M * IceTi i hope 1111780635 M * Bertl well, if your teachers know about the stuff you don't know, and you do not bother to find out yourself, they will not give you good marks ... 1111780683 M * IceTi hmm 1111780686 M * Bertl such projects are usually about 'discovering stuff, and working on your own' not getting everyone to do the job for you, or is that marketing class? 1111780708 M * Bertl or maybe even management ;) 1111780717 M * IceTi sorry i think i don´t really understand that in english 1111780728 M * IceTi :-( 1111780789 M * Bertl "solche projekte sind überlicherweise dazu da dass man lernt dinge zu entdecken/erforschen und selbstständig tätig zu werden, nicht einfach jeden so lange zu nerven bis er den job für dich tut" 1111780807 M * Bertl (translation) 1111780816 M * IceTi oh ok 1111780822 M * Bertl for example: 1111780824 M * Bertl who exactly has started the vserver Project and when? 1111780839 M * Bertl don't you think you can find that out easily? 1111780869 M * IceTi i swear i´ve searched but i don´t find it out 1111780889 M * IceTi the time when this started ... 1111780961 M * Bertl http://linux-vserver.org/ProjectOverview 1111780974 M * Bertl One Kernel Patch, 2 Different Tools 1111780980 M * Bertl Jacques Gélinas created the VServer project a number of years back (see [Jack's Site]). He still does vserver development and the community can be glad to have him. He's a genius, without him, vserver would not exist. Three cheers for Jack. 1111781024 M * Bertl 4th entry on the main page/Documentation 1111781025 M * IceTi a numbe rof years ago? ;-) 1111781046 M * Bertl "Jack's Site" maybe? 1111781066 M * Bertl that's how the internet works, everything is _linked_ 1111781069 M * IceTi mom 1111781079 M * IceTi but its not so clearly 1111781090 M * IceTi the site need an update ;-) 1111781095 M * Bertl nothing is plain and simple ... you have to use your brains! 1111781096 M * IceTi a disign update 1111781103 M * IceTi hmmm 1111781111 M * Bertl and please go ahead, update the page ;) 1111781119 M * Bertl (that's why it is a Wiki ;) 1111781131 M * IceTi hmm ok 1111781174 M * Bertl nobody is expecting you to _know_ everything out of the blue, and I guess everyone here already did help you somehow ... 1111781212 M * IceTi yes 1111781236 M * Bertl but to be honest, if you were my disciple, you would do that project again next year ... 1111781241 M * IceTi and i am very gratefully for that 1111781322 M * Bertl Doener: that's interesting ... 1111781336 M * Bertl [root@(none) ZZZZ]$ ls -id /. /.. 1111781340 M * Bertl ··· current root 1111781340 M * Bertl ··· follow_mount() 1111781340 M * Bertl follow_mount()[810a8e60,8117704c] »/« 1111781340 M * Bertl ··· lookup[810a8b60,83ca05ec] »/« 1111781340 M * Bertl 2 /. 14377 /.. 1111781342 M * IceTi Jacques Gélinas is a guy right 1111781347 M * IceTi ;-) 1111781372 M * Bertl well, what do you expect? 1111781383 M * IceTi :-) 1111781402 M * IceTi And U herbert, work together with jacques on that projekt? 1111781432 M * Bertl well, I have taken over project maintainership about one and a half year ago ... 1111781448 M * Bertl (jack had some private issues) 1111781463 M * Bertl all this and much more can be gathered from the mailing list archives 1111781486 M * IceTi u are his /aushilfe"? 1111781514 M * Bertl yeah, I'm jacks cleaning woman ;) 1111781528 M * IceTi :-) 1111781534 M * IceTi u are from germany? 1111781545 M * IceTi and do u live in germany? 1111781547 M * Bertl how old are you? 1111781548 M * Doener it's even on the page you mentioned above, Bertl... *sigh* 1111781560 M * IceTi me? 19 ! 1111781562 M * IceTi and U ;-) ? 1111781571 M * Bertl 35 1111781587 M * Bertl 19 years and you do not know how to read country codes? 1111781597 A * Doener .oO( must resist... must resist to... must... ) 1111781616 M * IceTi country codes ?? öhm 1111781627 M * Bertl what's your email? 1111781633 M * IceTi why? 1111781648 M * Bertl just so that you get some spam from the internet ;) 1111781659 M * IceTi :-) 1111781666 M * IceTi no 1111781674 M * Bertl well, it's @Ruhr-Uni-Bochum.de, right? 1111781679 M * IceTi yes 1111781683 M * Doener ever wondered what that .de at the end means? 1111781702 M * IceTi de = deutschland (germany) 1111781710 M * Bertl congratulations! 1111781715 M * IceTi :-) 1111781716 M * Bertl now what's my email? 1111781726 M * IceTi why? 1111781733 M * IceTi i think it´s in the mailing list 1111781741 M * IceTi take that: mlrtimbf@rub.de 1111781757 M * Bertl nope that's not my email ;) 1111781762 M * IceTi but my? 1111781764 M * IceTi ! 1111781789 M * Doener ok, i'll be gone for a few minutes... guess i can't resist much longer... 1111781794 M * Bertl cya! 1111781800 M * IceTi cu 1111781803 N * Doener Doener|gone 1111781816 M * IceTi can speak german now? ;-) 1111781828 M * Bertl nope, channel language is english 1111781830 M * IceTi ok 1111781840 M * Bertl something you should know well at the age of 19 1111781860 M * Bertl (and if not, it's a good chance to learn it) 1111781883 M * IceTi a very nice guy answered my email ;-) 1111781919 M * Bertl yeah, and you did bother some folks about something you could have found out yourself in a few seconds, right? 1111781958 M * IceTi yes yes yes i see! 1111781969 M * IceTi öhm (ich sehe es ja ein) 1111781979 M * IceTi daddy ;-) 1111781982 M * Bertl and now consider, the ten minutes it took me to make you see that ... 1111782002 M * Bertl are 10 minutes lost for linux-vserver project development 1111782013 M * IceTi soory 1111782019 M * Bertl how many folks are in this channel right now? 1111782032 M * IceTi i am such an idiot, do u wanne hear that? 1111782041 M * IceTi i don´t know 1111782049 M * IceTi many 1111782052 M * Bertl no, you are not an idiot! you are just too lazy to do something on your own ... 1111782058 M * IceTi yes 1111782066 M * IceTi i think u are right 1111782083 M * Bertl so get your ass moving and do something productive, either for this project or something else ... 1111782100 M * IceTi ok ok 1111782101 M * IceTi SIR 1111782127 M * Bertl excellent! 1111782133 M * IceTi .-) 1111782290 M * Hollow bertl the booster.. *g* you should this to me too sometimes.. :P 1111782297 M * Hollow *should do 1111782313 M * Bertl well, we can set up a bot to do that ;) 1111782321 M * IceTi why ? 1111782338 M * Hollow heh, unfortunately athene (my rbot) is only on freenode 1111782342 A * Bertl .o( maybe slapper would be a good name too) 1111782345 M * Hollow heh 1111782368 A * Hollow is too lazy 1111782393 M * Hollow but i'll to commit the 1.9.5 ebuilds to the tree today 1111782398 M * Hollow try 1111782404 M * Hollow damn, i even lose my words 1111782412 M * Bertl hmm, add at least one fix please 1111782432 M * Hollow which one? 1111782446 M * Bertl http://vserver.13thfloor.at/Experimental/FOR-1.9.6/delta-unhold-fix01.diff 1111782454 M * Hollow okidoki 1111782608 Q * IceTi Quit: get satisfied! • :: ««« (Gamers.IRC) »»» www.gamersirc.net :: 1111782778 N * Doener|gone Doener 1111782785 M * Doener re 1111782878 M * Bertl wb Doener! 1111783096 J * slapper ~slapper@styx.xnull.de 1111783101 M * Hollow uhu 1111783102 M * Hollow :P 1111783130 M * Bertl welcome slapper! ;) 1111783139 M * Hollow :help 1111783139 M * slapper help topics: core, auth, keywords [13 plugins: autorejoin, eix, host, karma, math, metadata, nickserv, nslookup|dns, quotes, remind|remind+, search, seen, wserver] (help for more info) 1111783167 M * Hollow if you want to have any functionality let me know, i'll add it 1111783227 M * Doener hm, most important (imho) can it answer in private? *g* 1111783233 M * Hollow yup 1111783273 M * Bertl Hollow: yeah, you know the lxr feature from #kernelnewbies? 1111783283 M * Hollow nope 1111783310 M * Bertl well, it looks up stuff in the kernel source ... 1111783312 M * Hollow what does it do? 1111783314 M * Hollow mhm 1111783343 M * Hollow i'll take a look 1111783376 M * Hollow Bertl++ 1111783378 M * Hollow :karma Bertl 1111783378 M * slapper karma for Bertl: 1 1111783380 M * Hollow ;) 1111783706 M * Bertl yeah, that's an absolutely essential feature (at least it seems so, every bot has it ;) 1111783869 J * kalou ~kalou@80.13.75.104 1111783877 M * Bertl welcome kalou! 1111783887 M * kalou :) Bertl is the best ! 1111783887 M * slapper lemme take care of that for you 1111783910 M * nox : *g* 1111783972 M * kalou little question tonight ... I found that calls to getmntinfo() gives "private" information about other vservers running on the same host. (vs 1.2.10, k 2.4.29) 1111783995 M * Bertl hmm, interesting ... 1111784014 M * kalou :) Let me show you how lsof behaves here: 1111784015 M * Bertl got a simple test tool/script? 1111784029 M * kalou azoe:/usr/src/lsof_4.74_src# ./lsof 2> /tmp/e > /dev/null 1111784029 M * kalou zoe:/usr/src/lsof_4.74_src# 1111784041 M * kalou zoe:/usr/src/lsof_4.74_src# head -1 /tmp/e 1111784041 M * kalou lsof: WARNING: can't stat() ext3 file system /media/sound/iTunes 1111784047 M * kalou as simple as that. 1111784064 M * kalou (zoe is the name of one of my vservers) 1111784136 M * kalou the relevant code in lsof relies upon an lstat() call, which uses informations provided by getmntinfo() 1111784171 M * Bertl could you do a quick strace -fF on that lsof? 1111784187 M * Bertl (and upload the output somewhere, e.g. pastebin.com) 1111784195 Q * yarihm Quit: Leaving 1111784357 M * Bertl because I would say that getmntinfo() uses the /proc/mounts entry to gather that information ... 1111784377 M * kalou so I could hide /proc/mounts using vproc, right ? 1111784393 M * Bertl no, unfortunately vproc doesn't help there ... 1111784404 M * kalou lstat64("/proc/28604/fd/3", {st_mode=S_IFLNK|0500, st_size=64, ...}) = 0 1111784404 M * kalou open("/proc/mounts", O_RDONLY|O_LARGEFILE) = 3 1111784404 M * Bertl it's an entry generated by every process 1111784413 M * kalou yep it's using /proc/mounts ... 1111784419 M * Bertl but there is a patch to hide that information 1111784422 M * kalou do you need the full lsof ? 1111784442 M * kalou hmmm. interresting .. just applied the standard patch 1111784469 M * Bertl no, thanks, not required 1111784571 M * kalou hmm ok this patch is related to "namespaces" I guess 1111784596 M * Bertl no it's pretty simple and disables /proc//mounts inside a vserver completely 1111784642 M * kalou hey ... I'm gonna do my first hand made patch ? 1111784662 M * Bertl well, I know it must be somewhere, but I don't find it atm ... 1111784675 M * kalou oki. don't worry.. I'll be patient :) 1111784699 M * nox mount -o ro,bind is not working 4 me on 2.6.11.3-vs1.9.5-rc3 ... the vserver still get rw access (not only root) 1111784726 M * Bertl which is expected, no? 1111784751 M * nox well i expected ro 1111784772 M * Bertl well, then you think different than the folks on lkml ... 1111784782 M * Bertl ;) 1111784811 M * Bertl sidenote: I'm trying for almost a year now to get a patch into mainline which 'fixes' this ;) 1111784818 A * nox is well known 4 strange way of thinking *g* 1111784841 M * Bertl kalou: ah, found it: http://vserver.13thfloor.at/Experimental/VARIOUS/no-proc-mounts-vs1.24.diff 1111784855 M * nox Bertl: is there any way to get an real ro bind mount ? 1111784868 M * Bertl yeah, sure, you just have to use my patches ;) 1111784899 M * nox (: 1111784982 M * kalou oh thank you Bertl.. I'll try this asap. 1111784997 M * Bertl you're welcome! 1111785025 M * Bertl nox: http://vserver.13thfloor.at/Experimental/BME/ 1111785040 M * nox thx ! 1111785057 M * Bertl didn't check if they apply to 2.6.11.5, if you get any rejects or fuzz > 1 please let me know 1111785076 M * nox yes 1111785378 J * prae ~prae@sherpadown.net 1111785396 M * Bertl welcome prae! 1111785430 M * prae Hi Bertl :) 1111785509 M * nox bertl: http://linuxkun.de/vserver/patch-2.6.11-rc5-bme0.06.1.diff-2.6.11.3-vs1.9.5-rc3.log 1111785527 M * kalou Bertl, I have 3 hunks and one reject, while applying no-proc-mounts-vs1.24.diff to 2.4.29-vs1.2.10 . 1111785536 M * kalou 1 out of 3 hunks FAILED -- saving rejects to file fs/namespace.c.rej 1111785577 M * kalou ok. That's a simple includ 1111785580 M * Bertl well, congrats kalout! that is the most you can get of this simple patch ;) 1111785585 M * kalou I'll cope with this :) 1111785602 M * Bertl excellent! ;) 1111785625 M * kalou I'll do a little reboot and let you know the results 1111785638 M * Bertl nox: ah, forgot, you are applying to linux-vserver! *G* 1111785726 M * nox well maybe should apply all updates if i have to reboot anyway 1111785767 M * nox Bertl: ok do it on vanilla 1111785774 M * Bertl give me an hour or so, I'll update the bme to linux-vserver 1111785810 M * Bertl I wanted to include it in linux-vserver anyway ... as mainline seems not to like it ... 1111785812 M * Hollow what is BME? 1111785834 M * nox Bertl: they have any issues with that ? 1111785841 M * Bertl it's short for Bind Mount Extensions ... 1111785845 M * nox or just ignoring ? 1111785869 M * Bertl and it makes --bind mounts behave like they are supposed to behave ... 1111785896 M * Bertl nox: al viro vetoed it almost a year ago, and since then it's basically ignored ... 1111785896 M * Hollow sounds interesseting.. though i don't know internals i always felt bind mounts are misbehaving in some way *g* 1111785905 M * Hollow any doc about the issues? 1111785937 M * Bertl well, options like noatime, ro, and such are silently ignored on --bind mounts 1111785963 M * Hollow and these are working with these pathches? great :) 1111785980 M * Bertl yep, they ae 1111785990 M * SiD3WiNDR quick q, I updated to 2.6 with vs1.9.5, now my vserver doesn't have /proc/uptime anymore, how do I put it back? :) 1111785990 M * Bertl *are even ;) 1111785994 M * Hollow do the vserver patches include bme? 1111786014 M * Bertl SiD3WiNDR: start vprocunhide 1111786021 M * SiD3WiNDR on the host? 1111786037 A * SiD3WiNDR googles 1111786037 M * Bertl yep 1111786058 M * SiD3WiNDR then I need new util-vserver it seems ;) 1111786063 M * Bertl Hollow: not yet, but I really plan to add it ... 1111786088 M * Bertl SiD3WiNDR: if you want to stick with the legacy tools, look at the vproc page 1111786090 M * Hollow great 1111786098 M * nox oh Bertl i try to hurry with the faq 1111786099 M * Hollow i.e. i can finally get rid of mounting the portage tree with nfs inside my vservers yay! 1111786120 M * SiD3WiNDR Bertl: thanks, you rock at helping people, even if I actually just need to read the docs then I understand :) 1111786151 M * SiD3WiNDR it seems util-vserver 0.30 is in debian unstable, so yay :) 1111786154 M * Bertl thanks for the flowers! I appreciate it! 1111786154 M * Hollow btw: i really like to fool statement in the topic... ++! 1111786188 M * nox SiD3WiNDR: no debian tools dont work 1111786192 M * SiD3WiNDR hum :) 1111786193 M * Hollow wh00t, 0.30 in unstable... increadible 1111786201 M * SiD3WiNDR they're in there but don't work? that sucks 1111786203 M * Hollow 1111786204 M * Bertl http://linux-vserver.org/Proc-Security 1111786211 M * SiD3WiNDR Hollow: :) 1111786232 M * Hollow 0.30.204 is in gentoo testing ;) 1111786237 M * Hollow (and works ahem) 1111786238 M * Hollow *g* 1111786252 M * Bertl debian folks are working to get alpha tools and 2.6 patches into their distros ... 1111786264 M * SiD3WiNDR seems to work fine. 1111786272 M * SiD3WiNDR started vprocunhide with initscript, now I have everything :D 1111786284 J * erwan_ho ~erwan@lns-vlq-39f-81-56-133-136.adsl.proxad.net 1111786285 M * erwan_ho re 1111786287 M * Hollow SiD3WiNDR: distro? 1111786296 M * SiD3WiNDR debian ofcourse 1111786297 M * Bertl welcome home erwan! 1111786301 M * Hollow heh 1111786302 M * SiD3WiNDR (no, no distro wars;) 1111786308 M * erwan_ho thx Bertl 1111786326 A * Hollow doesn't start wars 1111786342 M * nox Version: 0.30.204-1 1111786351 M * nox wow didn´t realize 1111786358 M * Hollow not bad ;) 1111786395 M * SiD3WiNDR nox: indeed 1111786399 M * SiD3WiNDR nox: that's what I said :) 1111786415 J * ataraxis ~mail@p54948D61.dip0.t-ipconnect.de 1111786419 M * SiD3WiNDR my klogd is taking 50% inside the vserver... somehow I think it shouldn't be there? (following mailinglists with one eye) 1111786423 M * nox SiD3WiNDR: im so sorry *g* 1111786432 M * Hollow someone at our look held a presentation about vserver in late 04 1111786442 M * Hollow he's using debian as well 1111786447 M * Hollow so, seems to work :P 1111786628 M * ataraxis is there a way to find out how many vserver are running on a machine? (if you are inside one vserver) 1111786884 J * yarihm ~yarihm@80-218-3-115.dclient.hispeed.ch 1111786885 Q * yarihm Quit: 1111786916 M * kalou I know an unofficial way .. using 2.4.29 and vs1.2.10 (without no-proc-mounts patch) ... but it's a hack :) 1111786921 M * Bertl ataraxis: inside is not easy, if the setup is fine ... 1111786959 M * Bertl kalou: well, that'sa known way, so not really 'unofficial' ;) 1111786990 M * ataraxis i see :) on a different server i stumpled upon some stuff in /tmp 1111786992 A * kalou is a really young hacker 1111787008 M * ataraxis so, is there a vserver user faq somewhere which has that information? 1111787026 M * ataraxis i could only find a vserver admin faq, but I'm "on the other side" *G* 1111787049 M * Bertl what does uname -a show you? 1111787077 M * ataraxis Linux m29s02 2.4.28-vs1.29 #1 Tue Nov 30 21:21:03 CET 2004 i686 GNU/Linux 1111787131 M * Bertl try 'grep proc /proc/mounts|wc' 1111787190 M * ataraxis ah, okay. i see two other vservers there so far. that's nice 1111787214 M * ataraxis my load average shows only the vserver one and not the "real one", right? 1111787247 M * Bertl on 2.4 I really doubt that ... 1111787321 M * ataraxis great :) at least I know what's happening on the server then 1111787533 M * Hollow m29s02 sounds kinda familar to me... 1111787542 M * Hollow at least the naming sheme 1111787564 M * SiD3WiNDR Bertl: on 2.6 it does? 1111787574 M * SiD3WiNDR or it can 1111787576 M * SiD3WiNDR or something 1111787581 M * Bertl yep 1111787723 M * Hollow Bertl: what information does the bot about lxr show? or how does it work? 1111787729 M * Hollow the commands i mean 1111787745 M * Bertl http://lxr.linux.no/ 1111787786 M * Hollow yeah... i mean what commands does the bot take and what shall it show? 1111787799 M * Bertl http://ds9a.nl/klogbot/?year=2003&month=10&day=27&hour=23 1111787867 M * Hollow k, thx 1111787951 M * Bertl thank you! 1111788090 M * Hollow now i just need to find out how ti query lxr.linux.no 1111788092 M * Hollow ;) 1111788134 M * Bertl don't spend too much time on it ... 1111788160 M * Bertl it would be nice to have, but we can live without it ... 1111788181 M * Hollow nvm.. ;) 1111788188 Q * erwan_ho Quit: Leaving 1111788719 Q * kalou Quit: "reboot" 1111788754 M * SiD3WiNDR Bertl: that's very nice with the loadaverage, can it do per-vserver uptime too? 1111789096 J * kalou ~kalou@193.253.182.38 1111789133 M * kalou just tested the no-proc-mounts patch on 2.4.29 vs 1.2.10. Works great. +1 for inclusion in the next stable release :) 1111789363 Q * kalou Quit: 1111789424 M * Bertl SiD3WiNDR: of course .. see http://linux-vserver.org/Release+FAQ for details ... 1111789483 M * SiD3WiNDR neat 1111790309 M * Bertl nox: ah, needed to 'hack' a little, eh? 1111790377 Q * ciphernaut Ping timeout: 480 seconds 1111790569 M * Bertl Doener: still around? 1111790573 M * Doener yep 1111790588 M * Bertl the solution to the namespace issues is surprisingly simple ... 1111790605 M * Bertl in follow_dotdot() 1111790615 M * Bertl change the first break to return 1111790710 M * Bertl (that's it ;) 1111790720 M * Doener hum... no side-effects? 1111790740 M * Bertl haven't seen any yet, maybe there are ... but it makes sense 1111790757 M * Bertl (to make that change) 1111790837 M * Bertl ensc: can you test the yum stuff somehow? 1111790865 M * ensc Bertl: not now 1111790882 M * Bertl np, I'll upload a patch ... 1111791293 M * nox sorry Bertl ... where is 1.9.5 couln´t find the patch 1111791316 M * Bertl http://linux-vserver.org/ 1111791335 M * nox patch-2.6.11.5-vs1.9.5-rc4.diff is latest i find no incr either 1111791385 M * Bertl where does the first link in the news section, and the 4th of the Download section point to? 1111791444 M * Doener hm, 4th in download section points to stable releases ;) 1111791452 M * nox omg so sorry i am to fixed to known paths 1111791477 M * Bertl Doener: k, you win, it's the 4th 'point' 1111791629 M * Doener anyway, i've seen someone (matt IIRC) talking about some web-interface to manage xen instances (or whatever they call their stuff)... is that planned to be adapted for linux-vserver? 1111791637 M * Bertl nox: if you use sched_hard, this one is of interest to you too ... http://vserver.13thfloor.at/Experimental/FOR-1.9.6/delta-unhold-fix01.diff 1111791654 M * Bertl ensc: http://vserver.13thfloor.at/Experimental/FOR-1.9.6/delta-namei-fix01.diff 1111791697 M * ensc Bertl: ok, thx. Will test it next week 1111791703 M * Bertl Doener: as far as I got matt, in some way yes ... 1111791749 M * ensc Bertl: will you announce it on lkml? 1111791798 M * nox Bertl: i just tried bme on vanilla wannt rej od should i wait for your patch ? 1111791840 M * Bertl if you have it at hand, I would appreciate an url ... 1111791871 M * Bertl ensc: probably ... as soon as I know that it has no unwanted side-effects 1111792056 M * nox http://linuxkun.de/vserver/2.6.11.5+patch-2.6.11-rc5-bme0.06.1.diff+patch-2.6.11.5-vs1.9.5.diff 1111792064 M * nox bme worked well 1111792167 M * Beirdo OK, patch attempt 1 against the ubuntu-patched kernel failed miserably :) 1111792168 M * Beirdo heh 1111792181 M * Beirdo as expected 1111792187 M * Bertl :) 1111792206 M * Beirdo so I guess I'll patch a 2.6.10 kernel with the patch, then regenerate it 1111792216 M * Beirdo as your patch is for a newer kernel :) 1111792222 M * Beirdo hmm 1111792231 M * Beirdo or I can see if ubuntu has a 2.6.11 1111792239 M * Beirdo that's a smarter move, I think 1111792270 M * Bertl if it has, it would definitely be 1111792299 M * Beirdo looks like 1111792385 M * nox FOR-1.9.6 means to get included or doesn´t work with 1.9.5 ? 1111792414 M * Bertl means will probably be in 1.9.6 1111792425 M * Bertl (was originally waiting for ...) 1111792673 M * nox hmm sched.c fails Hunk #3 FAILED at 2827. Hunk #4 FAILED at 2895. (2.6.11.5+patch-2.6.11-rc5-bme0.06.1.diff+delta-unhold-fix01.diff= 1111792960 M * Beirdo OK, now THAT worked better 1111792998 M * Beirdo one hunk failed in fs/super.c 1111793021 M * Beirdo and one in fs/file_table.c 1111793021 M * Bertl should be easy to resolve, right? 1111793039 M * Beirdo I'd think so 1111793054 M * Beirdo and fs/attr.c 1111793070 M * Beirdo heh 1111793073 M * Beirdo and Makefile 1111793075 M * Beirdo not bad 1111793084 M * Beirdo 4 failed hunks outta the whole patch 1111793132 M * Bertl nox: you have a test machine? 1111793165 M * nox yes just set one up 1111793194 M * Bertl okay, bme patch is almost done, just have to run a compile test and basic start 1111793327 A * nox waits patient 1111793336 M * nox ly 1111793357 M * Bertl well, you can prepare some tests, because you will have to test both stuff, the vserver _and_ the bme one ... 1111793381 M * nox ok 1111793383 M * Beirdo hmm 1111793394 M * Beirdo I can't find the section this patch hunk is for 1111793406 M * Beirdo + if (ia_valid & ATTR_XID) 1111793407 M * Beirdo + dn_mask |= DN_ATTRIB; 1111793415 M * Beirdo in fs/attr.c 1111793425 M * Beirdo and I don't see any other dn_mask stuff 1111793462 M * Bertl maybe ubuntu has removed that, or moved it to a different file (debian did such fun) 1111793485 M * Bertl just grep for something in the vicinity 1111793576 M * Beirdo K :) 1111793756 M * Beirdo a grep for DN_ATTRIB in fs/ only shows up in the .rej file. Hmm 1111793799 M * Bertl ahem, I meant to grep for stuff in the context (of that hunk) 1111793856 M * Beirdo I did 1111793861 M * Beirdo none of it's there 1111793874 M * Beirdo getting vanilla 2.6.11 to compare 1111793881 M * Bertl all gone, well, maybe it's not required ... 1111793924 M * Beirdo OK, it's in setattr_mask in vanilla 1111793973 M * Beirdo grepping for the func in the ubuntu source 1111793990 M * Bertl cscope is a nice tool too ;) 1111794005 M * Beirdo and it's not in the code at all in the ubuntu code 1111794016 M * Beirdo OK, I'm gonna assume I can live without it 1111794072 M * Beirdo the Makefile one was the EXTRAVERSION, and the other two were includes 1111794079 M * Beirdo easily fixed by hand 1111794089 M * Beirdo well here goes nothing. Time to configure 1111794204 M * Bertl nox: http://vserver.13thfloor.at/Experimental/BME/delta-2.6.11.5-vs1.9.5.3-bme0.06.1.diff 1111794225 M * nox thx 1111794245 M * Bertl should apply to 2.6.11.5/vs1.9.5 1111794286 M * Bertl compiles and boots, no further testing done ... have fun! 1111794299 M * Bertl I'm off for now ... back later ... 1111794303 N * Bertl Bertl_oO 1111794310 M * nox cu Bertl_oO so much thx# 1111794422 M * Beirdo OK, compiling 1111794447 M * SiD3WiNDR is that the next radiohead album or something ;) 1111794866 Q * prae Quit: Pwet