1120521602 M * Bertl which one? 1120521630 M * Greek0 the devpts_readdir function 1120521648 M * Bertl did you look at the simple_readdir()? 1120521648 M * Greek0 would it help to compare it to the generic readdir function? 1120521673 M * Greek0 not yet. just scratched my head and skipped over it after some time ;) 1120521700 M * Bertl but no problem,we can also discuss the implementation independantly of that 1120521722 M * Bertl it basically has to build the directory inode 1120521740 M * Bertl the contents of the /dev/pts dir (or wherever it is mounted on) 1120521874 M * Bertl dcache_readdir() is the original 1120521905 M * Bertl fs/libfs.c 1120521936 M * Bertl + if (!vx_check(next->d_inode->i_xid, VX_IDENT)) 1120521936 M * Bertl + continue; 1120521943 M * Bertl that's all we add to that ... 1120521970 M * Greek0 ic 1120522009 M * Bertl but it might be a good idea to not duplicate the code there . 1120522035 M * Greek0 ok, now I can see my problem. 1120522046 M * Greek0 it's not the vserver specific part that I don't understand ;) 1120522053 M * Greek0 it's the whole function surrounding it :) 1120522061 M * Bertl hehe, yeah :) 1120522225 M * Greek0 what is the filp actually? 1120522238 M * Bertl a file inside the kernel 1120522250 M * Greek0 err, yes. _what_ file 1120522272 M * Bertl the one which is read ... 1120522308 M * Greek0 does it represent the directory in the kernel? or is that done by it's f_dentry? 1120522325 M * Bertl it is the directory contents 1120522334 M * Greek0 the file or the its f_dentry? 1120522352 M * Bertl the file is what you read when you do ls 1120522425 M * Greek0 so that struct file* there is actually representing the directory contents? 1120522431 M * Bertl yep 1120522666 J * rs ~rs@imhotep.rhapsodyk.net 1120522678 M * Bertl wb rs! 1120522688 M * rs re 1120522850 M * Bertl Greek0, Doener: what about this one (yet untested) http://vserver.13thfloor.at/Experimental/delta-devpts-clean01.diff 1120522878 M * Bertl it probably adds insignificant overhead to the generic case 1120522927 M * Bertl (which could be avoided by another indirection) 1120522988 M * Doener looks good 1120523003 Q * SiD3WiNDR Ping timeout: 480 seconds 1120523010 M * Greek0 I understood the other function now. At least I see what you are doing.. 1120523188 M * Aiken even with the pid errors I pasted above the vserver still seemed to start 1120523203 M * Bertl yeah, we made a small mistake ... 1120523234 M * Bertl it's probably the better choice to take the getpid() instead of the getppid() 1120523280 M * Bertl but it's still not correct, will need further investigations 1120523555 J * SiD3WiNDR luser@bastard-operator.from-hell.be 1120523593 M * Aiken top/ps/pstree/vps/vtop seem to be activing as expected 1120523750 M * Greek0 fs/namei.c, is the change in follow_dotdot just a bugfix? 1120523795 M * Bertl http://vserver.13thfloor.at/Experimental/delta-devpts-clean02.diff (here a version with no overhead) 1120523826 M * Bertl Greek0: it would be easier for us if you named the function :) 1120523845 M * Doener hm, he did ;) 1120523865 M * Bertl ah, okay, missed that (because of the missing ()) 1120523869 M * Greek0 sorry 1120523968 M * Doener ok, enough commits to libvserver for today ;) I'm off to bed now 1120523978 M * Greek0 xid_permission(), can't the (inode->i_xid == 0) check be included in vx_check using VX_HOST? 1120523985 M * Bertl Greek0: yep, that's a bugfix vs. mainline 1120524010 M * Bertl well, it was some time ago, it seems to be fixed differently now 1120524034 M * Bertl so I guess we can drop that change ... 1120524063 M * Doener good night folks! 1120524070 M * Greek0 good night 1120524074 M * Bertl night Doener! 1120524158 M * Bertl hmm, no, it does behave differently 1120524166 M * Bertl and I now remember why ... 1120524180 M * Bertl (maybe we should add a comment there) 1120524233 M * Bertl we actually want the deepest inode information available (on a mountpoint) where mainline doesn't care and gives us the highest 1120524238 M * Greek0 hu? maybe it's the daytime, or the sad feeling about getting up at 6:30 today, but I don't see the difference just now 1120524249 M * Bertl follow_mount(&nd->mnt, &nd->dentry); 1120524255 M * Bertl that's the difference 1120524269 M * Greek0 ah 1120524279 M * Bertl in the vserver case, it is not called when the first condition holds 1120524290 M * Greek0 ok 1120524302 M * Greek0 I thought you talked about xid_permission already. 1120524309 M * Bertl this gives us 'sane' root fs inodes inside a chroot :) 1120524347 M * Bertl no, you are too fast, some things need to be considered :) 1120524396 A * Greek0 considers going to bed now ;) 1120524450 M * Greek0 I don't really get what you mean with deepest inode info there.. 1120524479 M * Bertl do you have a running vserver kernel at hand? and an upatched kernel? 1120524550 M * Greek0 yep, both 1120524573 M * Bertl chroot /some/place/ ls -laid /. /.. 1120524588 M * Bertl execute that with an arbitrary (ls able) chroot on both systems 1120524651 M * Bertl (check it with place being a mount point and without) 1120524677 M * Bertl (with --rbind the dir is always a mountpoint) 1120524764 M * Greek0 I got no chroot where I have a working ls atm 1120524802 M * Bertl okay, check it out when you find some time ... 1120524815 M * Bertl one will show you the same inode, the other different inodes 1120524854 M * Bertl (because the linux-vserver will not 'climb' up the mount tree for /.. 1120524995 M * Bertl and regarding your xid question, I guess it can be reduced to a 1120525021 M * Bertl vx_check(inode->i_xid, VX_ADMIN|VX_WATCH|VX_IDENT|VX_HOSTID) 1120525071 M * Greek0 yep 1120525073 M * Bertl but it would be less efficient 1120525102 M * Bertl (which is actually the fault of the __vx_check inline 1120525140 M * Greek0 because id==0 is the most common case here? 1120525165 M * Bertl well, because it doesn't evaluate the vx_current_xid() which is expensive in this case 1120525189 M * Greek0 hmm ok 1120525239 M * Bertl but it might make sense to move that check (in __vx_check) upfront 1120525252 M * Bertl but only extensive profiling could reveal that 1120525272 M * Bertl (which we will do after 2.0) 1120525287 M * Greek0 with what tools do you plan to ship 2.0? 1120525299 M * Bertl broken ones :) 1120525313 M * Greek0 util-vserver? 1120525316 M * Bertl yep 1120525398 M * Bertl well, maybe enrico releases 0.30.208 just in time ... 1120525456 M * Greek0 back to follow_dotdot(). break; here will cause the dentry from the 1120525478 M * Greek0 'lowest' mountpoint to be returned, whereas return gives the one of the highest mount? 1120525490 M * Bertl the other way round, but yes 1120525514 M * Greek0 ok 1120525605 M * Greek0 btw, you have quite a lot includes of your headers in files you don't touch otherwise. 1120525615 M * Greek0 vs_memory.h mostly 1120525673 M * Bertl hah! could be left overs from the original modifications 1120525696 M * Greek0 in fs/binfmt_* for example 1120525699 M * Bertl good point, Doener did probably remove some, but might have missed a few ... 1120525711 M * Bertl did you try to remove them? 1120525729 M * Bertl (maybe they are still required by some macro?) 1120525795 M * Greek0 no, not yet. just saw it in the diff that the #include is the only modification in that file. 1120525802 M * Bertl CC fs/binfmt_elf.o 1120525802 M * Bertl fs/binfmt_elf.c: In function `load_elf_binary': 1120525802 M * Bertl fs/binfmt_elf.c:777: warning: implicit declaration of function `vx_rsspages_sub' 1120525832 M * Greek0 oh 1120525845 M * Bertl so I guess most of them _are_ required :) 1120525870 M * Greek0 that vx_ function is in the patch I have on my server, but not in the one I downloaded on my notebook today 1120525886 M * Greek0 patch-2.6.12.2-vs2.0-rc5.diff 1120525932 M * Bertl but if you really want to reduce such stuff, you might want to look into a little project I started some time ago (probably needs some polishing and of course the final 10% are missing) 1120525960 M * Bertl which tries to identify unused headers inside the kernel source 1120525976 M * Bertl unused meaning the following: 1120525997 M * Bertl - the header is included in a c file 1120526015 M * Bertl - the c file does not use anything the header defined 1120526030 M * Bertl - the c file does not use anything defined in other headers the header included 1120526077 M * Bertl basically did this as a modification of the sparse tool, which is able to do 95% of what we need for that 1120526187 M * Greek0 patch-2.6.11.11-vs2.0-rc4.diff / fs/binfmt_aout.c included some vx_ stuff 1120526205 M * Greek0 in patch-2.6.12.2-vs2.0-rc5.diff that's gone, only the #include is left 1120526228 M * Bertl yep, because the accounting was moved to a macro 1120526238 M * Bertl (which now has the vx_* stuff) 1120526283 M * Bertl but it might make sense to move the includes there too 1120526297 M * Greek0 ok 1120526341 M * Greek0 personally I don't care too much about too much includes, I mean, they aren't such a huge problem after all, just increasing compile time a little bit 1120526357 M * Bertl if you feel like doing a patch for that (compile tested) I'd be inclined to add it to 2.0 1120526367 M * Greek0 it's just that I noticed it in the patch, since it was quite obvious that the #includes were the only changes to that files 1120526383 M * Greek0 k, will look into it tomorrow 1120526387 M * Greek0 I'm really off to bed now 1120526429 M * Bertl okay, thanks a lot, and have a good night then! 1120526465 M * Greek0 .. I knew I would end up spending houres talking about linux-vserver when I should actually be asleep, since I got to get up at 6:30 ;) 1120526487 M * Greek0 good night then, cu 1120526646 M * Aiken only just realized there is 2.6.12 vserver patch, I'll move the alpha to that 1120526723 M * Bertl well, won't change the issue, but good idea ... 1120526742 M * Bertl how much time do you intend to spend tonight for the alpha issue? 1120526754 M * Bertl (tonight being right now :) 1120526770 M * Aiken it is not quite midday here, I have a few hours 1120526785 M * Bertl okay, because I have some ideas how to really fix it ... 1120526826 M * Aiken do you want to wait for a new kernel to be build from scratch or continue with the 2.6.11.11 kernel? 1120526836 M * Bertl let's move to 2.6.12.2-vs2.0-rc5 then, I'll prepare a few changes in the meantime ... 1120526869 M * Bertl let me know if your compile 'fails' at some point, because it did in my cross compile tests 1120526894 M * Aiken hopefully I am back, just got disconnected 1120526895 M * Bertl (but I have a fix for that too) 1120526911 M * Aiken I have had a lot more success in cross compiling for sparc than I have alpha 1120526937 M * Aiken the entire image for my IPX is cross compiled 1120526945 M * Bertl well, I have built _working_ cross compilers (for the kernel) for almost all kernel archs 1120527013 M * Aiken I think the kernel booted but userspace was rubbish when I was cross compiling for my alpha 1120527050 M * Bertl alpha arm cris frv h8300 hppa hppa64 i386 i586 k6 ia64 m32r m68k mips mipsel mips64 ppc ppc64 s390 s390x sh sh3 sh4 shbe sh64 sh64be sparc sparc64 v850 x86_64 1120527061 M * Bertl (currently working cross compilers :) 1120527155 M * Aiken I have done alpha, sparc, sparc64, mips, ppc, ppc64, s390, arm (for netwinder), various x86 1120527202 M * Aiken the fun one was cross compiling a toll chain on the athlon to run on sparc32 that targeted arm 1120527217 M * Bertl canadian cross 1120527225 M * Aiken that is the word 1120527394 M * Aiken turned out to be easier than I expected at the time 1120527397 M * Bertl okay, I'm digging into alpha assembler right now, let me know when you have some issues 1120527428 M * Aiken do you want me to make any changes before I start compiling 1120527454 M * Bertl not, just compile the 2.6.12.2-vs2.0-rc5 and let me know when it complains 1120527544 M * Bertl s/not/no/ 1120527662 M * Aiken there is one line in the config that always has me wondering EV56 CPU (speed >= 366MHz)? 1120527672 M * Aiken mine is a ev5 @ 433MHz 1120527699 M * Bertl so I'd answer with yes there, no? 1120527728 M * Bertl btw, you are using the old .config, no? 1120527732 M * Aiken I leave it at now, I have tried a test program compiled for ev56 and it fails to run 1120527763 M * Aiken I am using the .config from 2.6.11.11 which a quick check with menuconfig to make sure it is ok 1120527772 M * Aiken s/now/no/ 1120527786 M * Bertl okay, best way to see 'new' options is to do 'make oldconfig' 1120527909 M * Aiken drivers for hardware I don't have and 1 option for kernel debugging 1120528476 M * micah Bertl: http://vserver.13thfloor.at/Experimental/FOR-2.0 right? 1120528553 M * Bertl yep, that's it ... 1120528700 M * micah cool 1120529145 Q * AprilDL Read error: Connection reset by peer 1120529365 M * micah Bertl: it looks like you guys update these patches in place, so i should keep an eye for any changes 1120529394 M * Bertl the patches are never replaced, but older ones might be obsoleted 1120529420 M * Bertl so 'sometimes' *01 is obsoleted by *02 1120529462 M * micah ah ok 1120529488 M * Bertl for example the comp32-feat* 1120529505 M * Bertl usually this happens for features only 1120529511 Q * monrad Remote host closed the connection 1120529524 M * Bertl fixes and/or cleanups are usually cummulative 1120529546 Q * rs Quit: rs 1120529581 M * Bertl micah: but it's a good idea to check them in chronological order ... 1120529636 M * micah Bertl: so for example: delta-comp32-feat03.diff should be used over ...-feat02, ...-feat01? 1120529658 M * Bertl int this case, the 03 replaces both predecessors 1120529675 M * micah yes, so I should only use 03, and not the 02 or 01 1120529680 M * Bertl yep 1120529745 J * anonymousc ~anonymous@staff.internode.com.au 1120529754 M * Bertl welcome anonymousc! 1120529777 M * micah but if I were to use the highest ## for each patch, its hard to follow chronological order 1120529816 M * anonymousc greets bertl - I'm going through the fun of merging the latest nfs patchset with 2.6.12.2 + vs 2.0rc5 1120529834 M * Bertl anonymousc: sounds intetesting :) 1120529844 M * anonymousc care to recommend a good tool for resolving the conflicts? 1120529855 M * Bertl vi? 1120529859 M * anonymousc :) 1120529866 M * micah so maybe I will work with the April patches and then move on to the May.. etc. 1120529880 M * Bertl anonymousc: and a good brain, of course ... 1120529989 M * Bertl micah: the comp32 seems to be the only exception, just ignore 01 and 02 1120530024 M * anonymousc its not too hard - just tedious 1120530040 M * Bertl yeah, I guess there should be no 'critical' issues 1120530150 M * micah Bertl: yeah, all the others are 01 1120531612 M * Aiken the kernel compiled but it is too big 1120531632 M * micah Bertl: I'm going through comp32..03 and have come upon this part: 1120531635 M * micah diff -NurpP --minimal linux-2.6.11.7-vs2.0-pre2/include/linux/vserver/dlimit_cmd.h linux-2.6.11.7-vs2.0-pre2-comp32/include/linux/vserver/dlimit_cmd.h 1120531651 M * micah my kernel source does not have a .../include/linux/vserver directory :p 1120531726 M * micah err 1120531736 M * micah my fault, I needed to apply the vserver 1.9.5 patch first 1120531782 M * Bertl Aiken: is it too big, or is it just telling that it is too big? 1120531815 M * micah what is the difference between "fuzz" and "offset"s in patches? 1120531832 M * Bertl fuzz means that some context lines did not match 1120531832 M * Aiken it is > 4meg 1120531836 M * micah offsets seem like they are more acceptable 1120531841 M * Bertl Aiken: strip? 1120531849 M * Aiken that is after strip 1120531859 M * Bertl cool! 1120531883 M * Bertl micah: yes, offset means it applied at a different line as expected 1120531890 M * Bertl micah: small offsets can be ignored 1120531905 M * micah so I should probably examine fuzz from patches though? 1120531910 M * Bertl small offsets with fuzz 1 might be fine 1120531945 M * Bertl if you have larger offset (>10 or so) or fuzz>1 then you should examine it 1120531952 M * micah I've got an offset 5 and a fuzz 2 as my worst ones 1120531962 M * micah ok, I'll look at the fuzz 2 1120531964 M * Bertl you should definitely look into thise 1120531967 M * Bertl *those 1120531987 M * micah the offset 5 as well? 1120531995 M * Bertl that might be okay 1120532005 M * micah I'll look at it anyways 1120532049 M * micah is the best way to look at these to open the .diff in vi, and open the unpatched file in another vi and compare? 1120532060 M * micah thats what I would do, but maybe there is a better way 1120532078 M * Bertl I'm using a modified patch (which generates unified diffs on rejects) 1120532089 M * Bertl as you probably have no rejects 1120532095 M * micah no rejects 1120532119 M * Bertl the best way is to open the patch/hunk, look at the changes and open the changed code side on side 1120532129 M * Bertl you can also use a 3way diff for that 1120532147 M * Bertl (but it's usually easier just with the editor) 1120532152 M * micah ok 1120532217 M * micah the worst part is the repeated untar'ing of the source ;) 1120532236 M * Bertl not required 1120532244 M * Bertl you can use hard links for that 1120532263 A * micah raises eyebrows 1120532280 M * Aiken Linux pebbles.bedrock 2.6.12.2-vs2.0-rc5 #3 Tue Jul 5 12:54:34 EST 2005 alpha Unknown Alcor GNU/Linux 1120532290 M * Bertl micah: tar xjf linux-2.6.12 1120532291 M * micah ooh alpha :) 1120532303 M * Bertl micah: cp -la linux-2.6.12 linux-2.6.12-test01 1120532320 M * Bertl micah: cd linux-2.6.12-test01; patch <../whatever 1120532332 M * Bertl then if you need a new clean source ... 1120532338 M * Bertl cp -la linux-2.6.12 linux-2.6.12-test02 1120532469 M * micah great, this is a good tip 1120532519 M * Bertl just make sure that your editor (vi) does make backups (i.e. move the original away) if you edit in such hardlinked trees 1120532607 M * micah hmm I dont think my vim is setup to do that 1120532639 M * Bertl set patchmode=.orig 1120532663 M * micah um 1120532674 M * micah should I be shot because I am using emacs to add that to my .vimrc? ;) 1120532686 M * Bertl hanged! 1120532689 M * micah haha 1120532696 M * micah burnt at the stake 1120532808 M * Bertl Aiken: excellent! I already figured the asm stuff ... I guess ... 1120532808 M * Aiken soemthing is wrong 1120532820 M * Bertl hmm? 1120532832 J * eXplasm explasm@p549F7EE5.dip.t-dialin.net 1120532836 M * Aiken a vserver that was starting under 2.6.11.11 is not under 2.6.12.2 :( 1120532852 M * Bertl with or without the hack modifications? 1120532873 M * Aiken no hacks just std kernel + vs2.0-rc5 patch 1120532882 M * Bertl 2.6.11.11 I meant 1120532920 M * Aiken except for the fakeinit problem the vserver fan fine under 2.6.11.11 1120532934 M * Aiken s/fan/ran/ 1120532940 M * Bertl give the testme.sh a sping 1120532942 M * Bertl *spin 1120532978 M * Aiken 201 and 202 fail 1120532986 M * Bertl gentoo guest? 1120533000 M * Aiken no 1120533013 M * Bertl okay, how does it fail? 1120533014 M * Aiken rh style init system 1120533051 M * Aiken looks like syslog fails 1120533138 M * Aiken should syslog be stopped from starting or not? 1120533196 M * Bertl no, basically we have syslog and klogd 1120533207 M * Bertl the klogd should be handled in 2.0* 1120533229 M * Bertl (but depends on the context flags) 1120533312 M * Aiken my shiny brand new alpha cross compiler successfully compiled a hello world program 1120533371 M * Bertl congrats! 1120533418 M * Aiken if I remove the rc3.d entry for sysklogd the vserver now starts cleanly 1120533501 M * micah Bertl: I determined that this fuzz 2 was because the following unrelated code is different in the original source than what is represented in the patch 1120533532 M * micah I'll modify the patch so it is more in alignment for future patchers 1120533544 M * Bertl okay 1120533563 M * Bertl Aiken: okay, maybe an unexpected /proc issue? 1120533568 M * micah just being verbose to make sure I am doing things right :) 1120533653 M * Bertl Aiken: you're good with alpha assembler? 1120533691 M * Aiken no 1120533698 M * Bertl np :) 1120533781 M * Aiken my last real assembly was writing an 8080 assembler for a z80 based machine and wrting a 8080/cpm emulator so I could test the assembler while sitting in front of a pc for uni project 1120533813 M * Bertl okay, test patch will be ready soon ... 1120533950 M * micah Bertl: can you help me understand something about patches: 1120533955 M * micah I can understand: @@ -19,6 +19,7 @@ 1120533978 M * micah but what does this mean: 1120533978 M * micah @@ -467,8 +468,10 @@ void ext3_free_blocks(handle_t *handle, 1120534023 M * Bertl - means before 1120534027 M * Bertl + means after 1120534034 M * Bertl 467 is the original line 1120534052 M * Bertl 468 the line where the hunk applies 1120534061 M * Bertl the original context/lines are 8 1120534069 M * micah 8 what? 1120534070 M * Bertl the result will be a block of 10 1120534072 M * Bertl lines 1120534104 M * micah ah, ok, right 1120534108 M * micah but the part I dont get 1120534114 M * Bertl for example 6 context line plus 2 lines removed 1120534129 M * micah is the @@ vs. the @@ void ext3_free_blocks(handle_t *handle, 1120534138 M * Bertl that's a patch option 1120534155 M * Bertl or to be precise diff option 1120534159 M * Aiken should the host be able to use kill to kill of processes in the guest? 1120534175 M * micah Aiken: vkill 1120534179 M * Bertl micah: you can list arbitrary stuff after the @@ so this option mentions the previous label 1120534191 M * Aiken I am not talking about vkill 1120534202 M * Aiken I am talking about kill 1120534217 M * Bertl Aiken: IIRC, last time we checked it was able 1120534224 M * Bertl (if you knew the proper pid) 1120534250 M * Aiken which can be given by vps 1120534260 M * micah Bertl: so what follows after the @@ is just a note? 1120534265 M * Bertl yep 1120534389 M * Bertl Aiken: okay, time to test something :) 1120534399 M * Bertl http://vserver.13thfloor.at/Experimental/delta-getxpid-fix01.diff 1120534404 M * Bertl http://vserver.13thfloor.at/Experimental/delta-getxpid-fix02.diff 1120534415 M * Bertl apply both to a _copy_ of your current tree 1120534425 M * Bertl (make it with cp -la tree tree.copy) 1120534460 M * Bertl then compile, install and boot ... 1120534479 M * Bertl (be prepared that the kernel might crash) 1120534527 M * Aiken that will be fun, the machine is currently headless 1120534593 M * Bertl well, add a panic=60 or so ... and have a default known good kernel 1120534619 M * Bertl but actually I'm optimistic, as I tested the code in question in userspace ... 1120534687 M * Aiken this is promising, the cross compiler produced the same size kernel from the same configuration as the native tool chain 1120534743 M * Bertl ah, now I understand your previous comment about hello world :) 1120534774 M * Aiken still waiting for the src tree to copy 1120534788 M * Bertl did you use cp -la ? 1120534796 M * Aiken I always use av 1120534813 M * Bertl don't do that 1120534822 M * Aiken why? 1120534844 M * Bertl because it makes a deep copy 1120534853 M * Bertl and the the cp -la makes just a shallow one 1120534873 M * Bertl (which is more than sufficient for our purpose and a lot faster 1120534927 M * Aiken in a vserver under 2.6.11.11 and 2.6.12.2 doing a strace -f syslogd produces different results 1120535003 M * Bertl please upload the traces ... 1120535237 M * Aiken not good for the alhpa, it has not reappeared on the network :( 1120535252 M * Aiken the good one http://pastebin.com/307613 1120535295 M * Aiken syslogd not working http://pastebin.com/307614 1120535338 M * Aiken I don't think much of kill(-2147155960, SIG_0) = -1 ESRCH (No such process) 1120535365 M * Bertl does /var/run exist in both guests? 1120535380 M * Bertl do you use xid tagging? 1120535416 M * micah I have cleared out all the offsets and fuzzes from the original patch-2.6.11.6-vs1.9.5.12.diff, now I have a good baseline to begin with 1120535434 M * Bertl 1.9.5.12? 1120535448 M * Bertl didn't we have a 1.9.5.x-5? 1120535461 M * micah yes, thats for 2.6.8 1120535476 M * micah this is a patch that someone made and posted to the list for debian 2.6.11 1120535480 M * Bertl aha .. *confused* 1120535483 M * micah :) 1120535521 M * micah I'm going to work with the 2.6.11 source and move towards FOR-2.0 1120535555 M * micah because now that sarge has frozen, I am guessing that 2.6.8 will be phased out and 2.6.11 (with many patches) will become more standard 1120535561 M * Bertl hmm, and the 2.6.11 source is what? 1120535583 M * micah if I get good at this I will do it for the 2.6.8 one as well 1120535593 M * micah the 2.6.11 source is the debian 2.6.11 kernel source 1120535595 M * Bertl because we have a 2.6.11.x version of 2.0-rc4 1120535609 M * Bertl (i.e. you should try to apply that first) 1120535619 M * micah ok, that might make my life easier 1120535623 M * Bertl http://vserver.13thfloor.at/Experimental/patch-2.6.11.11-vs2.0-rc4.diff 1120535640 M * micah is it broken down into individual patches? 1120535655 M * Bertl not publically ... 1120535663 M * Aiken same guest different kernel 1120535673 M * micah is that patch against 2.6.11 vanilla, or is it against 2.6.11+vs1.9.5? 1120535687 M * Bertl 2.6.11.11 vanilla 1120535691 M * micah hmm ok 1120535699 M * micah I will look into this then 1120535732 M * Aiken Bertl the trace that worked was with 2.6.11.11 2.0-rc5 1120535732 M * Bertl Aiken: does the failing kernel use xid tagging? 1120535749 M * Aiken and the trace that failed was 2.6.12.2 2.0-rc5 1120535764 M * Bertl there is no 2.0-rc5 for 2.6.11.11 1120535781 M * Aiken typo rc4 for the 2.6.11.11 1120535786 M * Bertl but I'd suggest comparing the .config files 1120535800 M * Aiken I'll just get the machine running properly again 1120535805 M * Aiken it did not even boot 1120535818 M * Bertl that's bad ... with the new modifications, right? 1120535821 M * Aiken 1st thing I saw when i connected a monitor was a stack trace 1120535825 M * Aiken yes 1120535841 M * Bertl well, stack trace might be very helpful 1120535843 M * Aiken it all finished with -> die_if_kernel recursion detected 1120535850 M * Bertl any chance to capture/photograph it? 1120535870 M * Aiken could try a picture 1120535895 M * Aiken do_softirq was the last line in the trace with losts of scsi references 1120536107 M * micah Bertl: wow, that patch works quite well, a couple big offsets to fix, but not much! 1120536206 M * Bertl yeah, funny, isn't it? 1120536236 M * Bertl that's because the debian kernel folks decided to use 2.6.11 instead of patching up 2.6.8 ... 1120536298 M * micah yeah 1120536304 M * micah I can fix these easy I think 1120536688 M * Aiken I have pictures of another 2 crashes, 1 clear, the other looks like I moved the camera 1120536765 M * Bertl http://vserver.13thfloor.at/Experimental/delta-getxpid-fix03.diff 1120536778 M * Bertl let's try this ontop of the existing tree 1120536796 M * Bertl and let me have a look at those pictures 1120536830 M * Aiken uploading them at the moment, will take abit, 56k modem 1120537171 M * Aiken http://members.optusnet.com.au/~boddingt/crash1.jpg 1120537179 M * Aiken and the other is called crash2.jpg 1120537185 M * Bertl k 1120537347 M * micah Bertl: I got patch-2.6.11.11-vs2.0-rc4.diff to successfully patch with no offsets/fuzz to debian kernel-2.6.11-7 1120537352 M * micah yay 1120537414 M * Aiken that was even worse, the machine started booting that time then died wityh sys_getxpid 1120537438 M * Bertl that's better, can you capture the trace there? 1120537489 M * Bertl btw, you can reduce the imagesi quality (i.e make it 16 or 8 grays) 1120537592 M * micah now I need to think about the advantages/disadvantages of providing vs2.0-rc4 over vs1.9.5 1120537650 M * Bertl well, I assumed you wanted to keep/maintain the 2.6.8 kernel 1120537678 M * Bertl IMHO the best option is to use vanilla 2.6.12.2 + vs2.0-rc5 :) 1120537950 M * micah of course :) 1120538020 M * micah well, now that sarge has frozen, 2.6.8 debian revision -16 is the kernel-source in sarge. It will only be updated with security fixes, and the vserver patch that exists in sarge will not be updated either/ 1120538053 M * Bertl well, then sarge is broken by default ... 1120538058 M * micah so before I do a lot of work on 2.6.8 I will find out what its lifespan is for the newer releases 1120538063 M * micah broken, porque? 1120538075 M * Bertl well, the vserver stuff in sarge is just broken 1120538101 M * micah it works well for me 1120538113 M * micah except for the chattr +t stuff that ola threw in to the tools 1120538121 M * Bertl because you probably do not use any arch != x86 1120538122 M * micah but that is a minor error 1120538134 M * micah ah, outside of x86 it is broken 1120538153 M * Bertl well, it's broken for x86 too, because we fixed some issues since then 1120538185 M * micah yes, but Bertl vservers will always be broken... there is always something to fix :) 1120538219 M * micah but somewhere you draw a line saying this is as stable as it can be, and for us to make the changes we want we have to break a lot (hence the 1.9.5 to 2.0 stuff) 1120538243 M * Bertl yeah, but for me there is a difference between 'we know it is broken' and 'we think we might find some issues' 1120538269 M * Bertl remember, 1.9.x is not considered 'stable' 1120538281 M * Bertl but 2.0 for example will be considered 'stable' 1120538299 M * micah hehe, yes, but you tell people all the time it is stable enough :) 1120538310 M * micah and I agree, it works really well on the machines I've used it on 1120538312 M * Aiken some really shocking photography http://members.optusnet.com.au/~boddingt/crash3.jpg 1120538332 M * micah ah I love the Aieee 1120538404 M * Aiken I have not seen a killing interrupt handler message for a long time 1120538406 M * micah Bertl: the good thing is we will soon have a 2.0 stable version and there will be a debian version available so when people come in and have a problem with something you know is fixed you can tell them to use the newer one 1120539065 M * Bertl yes, but there is no point in doing so, I can perfectly fine suggest to use vanilla 1120539082 M * Bertl (which isn't only much easier, but better for maintainence) 1120539095 M * Bertl Aiken: okay, please revert the 03 patch, and apply the 03b 1120539110 M * Bertl http://vserver.13thfloor.at/Experimental/delta-getxpid-fix03b.diff 1120539119 M * Bertl (reverting is done with -R) 1120539193 Q * BWare Ping timeout: 480 seconds 1120539215 M * Bertl micah: I would understand the debian philosophy if it was: just make changes we verified and considered good, ultimately leading to a perfectly stable product 1120539260 M * Bertl but the debian philosophy seems to be: "this broken wossname we define as 'stable' and because it is 'stable' it will not be changed ..." 1120539350 M * micah Bertl: yes, but in an entire distro it is difficult to get every piece to that stable state. 1120539357 M * Bertl for example, the 2.6.11.1* (sucker tree) kernel reached a point where it really became stable 1120539367 M * micah Also, if we were to use a stable vserver kenel patch we wouldhave to use the 1.2 one, which ola was really pushing for 1120539394 M * micah but everyone wanted the newer version, so you are stuck between people wanting 1.9.4 and 1.2 being out of date, but stable 1120539405 M * Bertl well, in a month or so, the v2.0 is the stable tree for 2.6 kernels, no? 1120539441 M * Bertl and after all the testing/fixing we put into it, it's for sure more stable than some arbitrary 1.9.x version, don't you agree? 1120539453 M * micah once it has settled down, yes 1120539475 M * Bertl do you follow the release/fix/test cycle? 1120539482 M * Bertl do you know what -rc means? 1120539489 M * micah yes of course 1120539524 M * Bertl and still you consider the debian 1.9.x version more stable than rc5 for example? 1120539525 M * micah I do not defend the debian model, in fact I am pushing to have it changed, but it is what we have now so we have to work with it 1120539543 M * micah well, that one would be up to you I think 1120539552 M * micah but rc5 was not available when debian froze 1120539559 M * Bertl so? 1120539562 M * micah so we had to make a choice 1120539571 M * micah and everyone did not want 1.2 version 1120539592 M * Bertl good, but that doesn't mean that it should not be fixed 1120539609 M * micah and it will be fixed, that is what I have been working on tonight 1120539628 M * micah when these are available, they will go into debian unstable, then move to the testing branch 1120539631 M * Bertl hmm, no, you did work on patching a 2.6.11 kernel, no? 1120539641 M * micah people will be able to get these from there if they like 1120539658 M * Bertl well, they are able to compile their own too ... 1120539673 M * micah well yes, I worked on 2.6.11 because I am awaiting information from the kenrel team about 2.6.8 1120539678 M * Bertl the question is, when I install the 'stable' debian release, will it work or not? 1120539695 M * Bertl and 'stable' release also means that it will work ... 1120539704 M * micah but the idea is to fix the 1.9.x version in debian moving it to 2.0 (when it is stable) using the proper kernels that are available 1120539717 M * micah I use the stable version all the time 1120539724 M * Aiken http://pastebin.com/307630 1120539754 M * Bertl hey great! it booted? 1120539758 M * Aiken yes 1120539762 M * micah yes, things that have been fixed from 1.9.5 will not be fixed in the stable version, but when I make the 2.0 versions available people who run stable can install those 1120539769 M * Bertl Aiken: and it seems to work too?! 1120539828 M * Aiken the guest starts up 1120539884 M * micah if debian waited a couple more months for vserver to go to a stable 2.0, then it would have to wait for almost 10,000 other packages to also reach a stable state, and as we know that would mean it would never happen 1120539897 M * micah so really, this means the debian release model is flawed, and that is why I am interested in changing it 1120539923 M * Bertl micah: yeah, I agree that it is flawed ... 1120539946 M * Bertl and don't get me wrong, this is absolutely no personal attack on debian folks ... 1120539959 M * micah there is a debian developer meeting next week in finland that I will go to, and the release discussion is a hot topic now 1120539991 M * Bertl feel free to use linux-vserver as example :) 1120540014 M * micah :) 1120540020 M * Bertl Aiken: I ahve another patch, slight modification, wanna test that too? 1120540039 M * Aiken yes 1120540052 J * BWare ~bware@office.intouch.net 1120540077 M * Bertl Aiken: okay, rever the 03b, and apply the 03c 1120540094 M * Bertl http://vserver.13thfloor.at/Experimental/delta-getxpid-fix03c.diff 1120540113 M * Bertl morning BWare! 1120540127 M * Aiken on top of the others or -R 03b first? 1120540169 M * Bertl -R 03b 1120540172 M * Bertl then 03c 1120540352 Q * mountie Ping timeout: 480 seconds 1120540377 M * Bertl I will have to clean that up, so that it doesn't duplicate code, but it seems that we have a solution for the unfortunate alpha getxpid() :) 1120540460 M * Aiken everything with testme.sh passed 1120540474 M * Bertl excellent, so 3c it is ... 1120540480 M * Aiken vserver hoppy start works 1120540493 M * Bertl the syslog issues remain? 1120540507 M * Aiken yes 1120540542 M * Bertl try to capture them with strace -fF -o syslog.trace syslogd -m 0 1120540579 M * Bertl for both cases, and make sure that the /var/run/syslogd.pid does not exist before you trace it 1120540672 M * micah Bertl: until debian releases are fixed, i can provide a backport so stable users can have an updated "stable" version of the patch 1120540832 Q * BWare Ping timeout: 480 seconds 1120540902 M * Bertl well, if that can be used without jumping through hoops, then that is probably fine ... 1120540921 M * Bertl micah: needless to say that I'm more worried about the tools than the kernel patch 1120540957 M * Bertl s/fine/useful/ 1120541090 M * Aiken http://members.optusnet.com.au/~boddingt/syslog.trace-2.6.11.11 1120541097 M * Aiken http://members.optusnet.com.au/~boddingt/syslog.trace-2.6.12.2 1120541131 M * micah Bertl: yes it would be quite easy to make available... and anyone who has bugs with the debian version should be instructed to file them in the debian BTS 1120541182 M * Aiken the working example gets a SIGTERM and exits cleanly the other gets a SIGCHILD 1120541239 M * Bertl I see, strange ... 1120541319 M * Bertl but I guess this is a change in the vanilla kernel, nevertheless I'll look into it (but not now :) 1120541343 Q * SNy uranium.oftc.net keid.oftc.net 1120541343 Q * maharaja uranium.oftc.net keid.oftc.net 1120541343 Q * sladen uranium.oftc.net keid.oftc.net 1120541343 Q * albeiro uranium.oftc.net keid.oftc.net 1120541343 Q * neofutur uranium.oftc.net keid.oftc.net 1120541348 J * neofutur ~neofutur@neofutur.net 1120541351 J * sladen paul@starsky.19inch.net 1120541353 M * Bertl Aiken: thanks a lot for your time, I guess we solved a major alpha issue tonight ... 1120541365 J * SNy ~mfr@bmx-chemnitz.de 1120541371 J * albeiro ~albeiro@graffias.estrefa.pl 1120541374 J * maharaja maharaja@ipax.at 1120541402 M * Bertl I will see that we get a cleaned up version into vs2.0, so that alpha should work as expected ... 1120541419 M * Aiken that will be good 1120541445 M * Aiken anyway Bertl I was thinking thanks for your time 1120541481 M * Bertl I'm off to bed now ... have a nice whatever everyone! 1120541502 M * Bertl micah: keep me up-to-date ... 1120541520 M * Bertl (so that I know what to tell debian folks) 1120541540 M * Bertl Aiken: yw, and thanks again for testing ... 1120541546 N * Bertl Bertl_zZ 1120541556 M * Aiken good night 1120541565 M * Aiken or morning 1120541639 J * BWare ~bware@office.intouch.net 1120542645 Q * BWare Ping timeout: 480 seconds 1120543239 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com 1120543613 J * Aiken_ ~james@tooax8-042.dialup.optusnet.com.au 1120543618 N * are|lunch _are_ 1120543623 Q * _are_ Quit: bbl 1120543918 Q * Aiken Ping timeout: 480 seconds 1120544202 J * BWare ~bware@office.intouch.net 1120545012 Q * BWare Ping timeout: 480 seconds 1120545380 J * _are_ ~are@gateway-dsl.lihas.de 1120546447 Q * Aiken_ Read error: Connection reset by peer 1120547253 J * sukria ~sukria@sargon.lncsa.com 1120547853 J * Doener` ~doener@p54876E3A.dip.t-dialin.net 1120548055 J * erwan_ho ~erwan@konilope.dyndns.org 1120548285 Q * Doener Ping timeout: 480 seconds 1120548954 T * * http://linux-vserver.org/ | latest stable 1.2.10, devel 1.9.5, 2.0-rc5, ng9.5 -- 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 ;) 1120548954 T * Hollow|mobile - 1120548955 Q * Pazzo Ping timeout: 480 seconds 1120548955 Q * BobR_afk Ping timeout: 480 seconds 1120548960 Q * neofutur Ping timeout: 480 seconds 1120548960 Q * eXplasm Ping timeout: 480 seconds 1120548965 Q * kevinp Ping timeout: 480 seconds 1120548965 Q * Bertl_zZ Read error: Connection reset by peer 1120548975 Q * Doener` Ping timeout: 480 seconds 1120548980 Q * _are_ Ping timeout: 480 seconds 1120548999 J * Doener` ~doener@p54876E3A.dip.t-dialin.net 1120549022 J * _ag_ ag@caladan.roxor.cx 1120549063 J * eXplasm explasm@p549F7EE5.dip.t-dialin.net 1120549063 J * kevinp ~kevinp@ny.webpipe.net 1120549063 J * _are_ ~are@gateway-dsl.lihas.de 1120549063 J * Pazzo ~Pazzo@host130-250.pool8172.interbusiness.it 1120549063 J * Bertl_zZ ~herbert@212.16.62.52 1120549063 J * xbing ~nb@dsl081-044-121.lax1.dsl.speakeasy.net 1120549063 J * pusling ~pusling@195.215.29.124 1120549063 J * DaPhreak ~phreak@styx.xnull.de 1120549063 J * neofutur ~neofutur@neofutur.net 1120549063 J * SiD3WiNDR luser@bastard-operator.from-hell.be 1120549063 J * SNy ~mfr@bmx-chemnitz.de 1120549063 J * skceb skceb@bang-bang.feuer-frei.com 1120549063 J * cereal ~cereal@217.20.124.153 1120549063 J * sladen paul@starsky.19inch.net 1120549063 J * Medivh ck@paradise.by.the.dashboardlight.de 1120549063 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com 1120549063 J * maharaja maharaja@ipax.at 1120549063 J * albeiro ~albeiro@albeiro.usercloak.oftc.net 1120549063 J * Zoiah Zoiah@matryoshka.zoiah.net 1120549063 J * [maple] ~maple@strace-nat0.ua-online.net 1120549063 J * Vudumen vudumen@perverz.hu 1120549063 J * baggins baggins@kenny.mimuw.edu.pl 1120549063 J * gregster ~gregor@greart.de 1120549063 J * cryo ~say@212.86.243.154 1120549063 J * Greek0 ~greek0@81.189.246.175 1120549063 J * matti matti@linux.gentoo.pl 1120549063 J * nox ~nox@noxlux.de 1120549063 J * aba ~aba@eos.turmzimmer.net 1120549063 J * Loki|muh_ loki@satanix.de 1120549063 J * meebey meebey@booster.qnetp.net 1120549063 J * tchan ~tchan@c-24-13-81-164.hsd1.il.comcast.net 1120549063 J * jkl ~eric@ool-182cef46.dyn.optonline.net 1120549063 J * janra janra@paradox.homeip.net 1120549063 J * FaUl ~immo@ip88.164.1211G-CUD12K-01.ish.de 1120549063 J * virtuoso ~s0t0na@80.253.205.251 1120549063 J * id ~id@relax-media.softwarezentrum.de 1120549063 J * zimbo ~zimbo@callisto.dom.bonis.de 1120549063 J * mcp ~hightower@wolk-project.de 1120549063 J * dsoul darksoul@pingu.ii.uj.edu.pl 1120549064 J * kestrel ~athomas@vsrouter.swapoff.org 1120549064 J * brc bruce@200141220059.user.veloxzone.com.br 1120549064 J * DaCa-fi ~danny@mail.limehouse.org 1120549064 J * alexx ~alexx@82.225.136.176 1120549064 J * pattieja ~pattieja@adsl-69-153-174-41.dsl.stlsmo.swbell.net 1120549064 J * eyck eyck@81.219.64.71 1120549064 J * case ~case@donpanic.faveve.uni-stuttgart.de 1120549064 J * locksy ~locksy@mrtg.sisgroup.com.au 1120549064 J * flock ~restless@l192-117-111-12.broadband.actcom.net.il 1120549064 J * lilo ~lilo@lilo.usercloak.oftc.net 1120549064 J * micah micah@micha.hampshire.edu 1120549064 J * mugwump ~samv@210-54-92-184.ipnets.xtra.co.nz 1120549064 J * stupidawy foo@you.wish.you.were.pimp.olicio.us 1120549064 J * Hunger Hunger.hu@levnor.hu 1120549328 J * BobR_afk ~georg@212.16.62.52 1120549496 J * prae ~prae@ezoffice.mandriva.com 1120549858 Q * mountie Ping timeout: 480 seconds 1120551069 J * BWare ~bware@office.intouch.net 1120552594 J * erwan_taf ~erwan@81.80.43.67 1120552870 J * Hollow ~Hollow@home.xnull.de 1120555170 M * Doener` morning! 1120555396 M * _are_ Hi Doener` 1120558484 Q * sukria Quit: see you 1120560835 Q * erwan_taf Ping timeout: 480 seconds 1120561312 J * erwan_taf ~erwan@81.80.43.67 1120562479 J * sukria ~sukria@213.223.184.202 1120563454 J * monrad ~monrad@213083190130.sonofon.dk 1120564162 Q * dsoul Ping timeout: 480 seconds 1120565477 Q * Vudumen Read error: Network is unreachable 1120565708 J * Vudumen vudumen@perverz.hu 1120566172 J * dsoul darksoul@pingu.ii.uj.edu.pl 1120566452 Q * _are_ Ping timeout: 480 seconds 1120567072 Q * eXplasm Ping timeout: 480 seconds 1120567110 Q * erwan_taf Ping timeout: 480 seconds 1120567775 J * erwan_taf ~erwan@81.80.43.77 1120568085 Q * dsoul Ping timeout: 480 seconds 1120568107 P * erwan_taf Leaving 1120568541 M * FaUl hmm, 1120568545 M * FaUl re 1120569519 M * id morning 1120569791 M * Hollow morning 1120569966 J * eXplasm ~explasm@p549F6EAC.dip.t-dialin.net 1120570491 M * meebey I need a MTA which runs on port 25 and does mail relay only for a specific ip rang e(my vservers) 1120570494 M * meebey any suggestions? 1120570518 M * meebey esmtp and nullmailer are local only means sendmail command emulation and that's it 1120570524 M * meebey no daemon onport 25 1120570655 M * aba meebey: I use exim4 for that. 1120570725 M * meebey :) 1120570761 M * meebey I will use exim for that too 1120570770 M * meebey or postfix if I can't get exim running 1120571016 M * meebey ah smtpd is maybe an option 1120571180 J * dsoul darksoul@pingu.ii.uj.edu.pl 1120571209 M * meebey so what I wanted is probably called a mail proxy with ACLs 1120571256 Q * eXplasm jupiter.oftc.net kinetic.oftc.net 1120571256 Q * zimbo jupiter.oftc.net kinetic.oftc.net 1120571256 Q * id jupiter.oftc.net kinetic.oftc.net 1120571256 Q * virtuoso jupiter.oftc.net kinetic.oftc.net 1120571256 Q * FaUl jupiter.oftc.net kinetic.oftc.net 1120571256 Q * mcp jupiter.oftc.net kinetic.oftc.net 1120571256 Q * alexx jupiter.oftc.net quasar.oftc.net 1120571256 Q * brc jupiter.oftc.net quasar.oftc.net 1120571256 Q * kestrel jupiter.oftc.net quasar.oftc.net 1120571256 Q * tchan jupiter.oftc.net quasar.oftc.net 1120571256 Q * meebey jupiter.oftc.net quasar.oftc.net 1120571256 Q * Loki|muh_ jupiter.oftc.net quasar.oftc.net 1120571256 Q * gregster jupiter.oftc.net quasar.oftc.net 1120571256 Q * baggins jupiter.oftc.net quasar.oftc.net 1120571256 Q * [maple] jupiter.oftc.net quasar.oftc.net 1120571256 Q * Medivh jupiter.oftc.net quasar.oftc.net 1120571256 Q * sladen jupiter.oftc.net quasar.oftc.net 1120571256 Q * SiD3WiNDR jupiter.oftc.net quasar.oftc.net 1120571256 Q * DaPhreak jupiter.oftc.net quasar.oftc.net 1120571256 Q * xbing jupiter.oftc.net quasar.oftc.net 1120571256 Q * DaCa-fi jupiter.oftc.net quasar.oftc.net 1120571256 Q * albeiro jupiter.oftc.net quasar.oftc.net 1120571256 Q * Greek0 jupiter.oftc.net quasar.oftc.net 1120571256 Q * matti jupiter.oftc.net quasar.oftc.net 1120571257 J * eXplasm ~explasm@p549F6EAC.dip.t-dialin.net 1120571257 J * mcp ~hightower@wolk-project.de 1120571257 J * zimbo ~zimbo@callisto.dom.bonis.de 1120571257 J * id ~id@relax-media.softwarezentrum.de 1120571257 J * virtuoso ~s0t0na@80.253.205.251 1120571257 J * FaUl ~immo@ip88.164.1211G-CUD12K-01.ish.de 1120571273 J * xbing ~nb@dsl081-044-121.lax1.dsl.speakeasy.net 1120571273 J * DaPhreak ~phreak@styx.xnull.de 1120571273 J * SiD3WiNDR luser@bastard-operator.from-hell.be 1120571273 J * sladen paul@starsky.19inch.net 1120571273 J * Medivh ck@paradise.by.the.dashboardlight.de 1120571273 J * albeiro ~albeiro@albeiro.usercloak.oftc.net 1120571273 J * [maple] ~maple@strace-nat0.ua-online.net 1120571273 J * baggins baggins@kenny.mimuw.edu.pl 1120571273 J * gregster ~gregor@greart.de 1120571273 J * Greek0 ~greek0@81.189.246.175 1120571273 J * matti matti@linux.gentoo.pl 1120571273 J * Loki|muh_ loki@satanix.de 1120571273 J * meebey meebey@booster.qnetp.net 1120571273 J * tchan ~tchan@c-24-13-81-164.hsd1.il.comcast.net 1120571273 J * kestrel ~athomas@vsrouter.swapoff.org 1120571273 J * brc bruce@200141220059.user.veloxzone.com.br 1120571273 J * alexx ~alexx@82.225.136.176 1120571273 J * DaCa-fi ~danny@mail.limehouse.org 1120572647 M * meebey smtpd is ugly to configure but looks like I should work 1120572812 N * Bertl_zZ Bertl 1120572824 M * Bertl morning folks! 1120572924 M * meebey hm smtpd is a half-MTA ... 1120572944 M * meebey it uses /usr/bin/sendmail to send the queued mails 1120573295 M * id hi Bertl ! 1120573624 M * baggins hi Bertl 1120573779 M * Bertl hey id, baggins! 1120573784 M * Bertl welcome dsoul! 1120573860 M * baggins Bertl: I tested vanilla kernel + vs2.0rc5, results at http://pastebin.com/307810 1120573877 M * baggins Bertl: looks like 64bit problem to me 1120574027 M * Bertl okay, you did test with the same guest? or did you create a new one? 1120574084 M * baggins Bertl: every time created new one, but I checked old guests and it was the same 1120574105 M * Bertl could you upload your kernel .config please? 1120574161 M * baggins all of it, or just VSERVER part? 1120574197 M * Bertl I'd prefer all of it (best as real file, not via pastebin.com) 1120574207 M * Bertl but you can dcc it to me, if you like 1120574386 M * baggins Bertl: dcc get or wget http://kenny.mimuw.edu.pl/~baggins/.config 1120574453 M * Hollow Bertl: why are there structs for {ctx,net}_create in rc5? 1120574488 M * Bertl baggins: tx, I got it ... 1120574582 M * Bertl Hollow: to specify an initial flagword? 1120574597 M * Hollow so this has the same effect as set_cflags? 1120574628 M * Bertl not exactly, because it might circumvent the triggers (for one shot flags) 1120574663 M * Bertl if you pass NULL as argument for the struct, you have backwards compatibility 1120574683 M * Hollow ah 1120574688 M * Hollow which triggers? 1120574725 M * Bertl #define VXF_ONE_TIME (0x0003ULL<<32) 1120574759 M * Hollow and what does this flag do? 1120574769 M * Bertl flag_s_ 1120574781 M * Bertl #define VXF_STATE_SETUP (1ULL<<32) 1120574781 M * Bertl #define VXF_STATE_INIT (1ULL<<33) 1120574788 M * Doener` evening folks! 1120574793 M * Hollow evening Doener` 1120574795 M * Bertl hey Doener`! 1120574812 M * Bertl Hollow: one does end the setup, the other set the init process 1120574833 M * Hollow yeah... but what does ONE_TIME do? 1120574851 M * Bertl it's a mask of both flags, to declare them as one-time flags 1120574902 M * Bertl baggins: what gcc do you use for the kernel? 1120574933 M * baggins Bertl: gcc version 3.3.6 1120574949 M * Bertl k 1120575057 M * Hollow Bertl: then what is INIT_SET? 1120575135 M * Bertl INIT_SET is the initial value for the flagword for compatibility calls 1120575150 M * Bertl (i.e. if the flagword struct is NULL) 1120575180 M * Hollow aah 1120575181 M * Hollow ok 1120575209 M * Hollow i'm still not used to reading these defines ;) 1120575227 M * Doener` Hollow: if we want the lib to be useful we have to support the legacynet stuff... (Bertl: This is still true, right?) 1120575246 M * Bertl hmm, only for the networking 1120575261 M * Hollow what is network_cmd.h supposed to be/do? 1120575272 M * Doener` does legacynet contain anything non-networking? 1120575272 M * Bertl if the tools/lib do the 'right' things you can live without all other legacy support 1120575294 M * Bertl (just enricos tools still need the legacy API for some things) 1120575311 M * Bertl Doener`: I don't hope so ... 1120575340 M * Bertl Doener`: but I read legacy isntead of legacynet :) 1120575365 M * Doener` :) 1120575377 M * Bertl so the correct answer is: yes it needs legacy_net_ support for now 1120575442 M * Hollow hm 1120575465 M * Hollow Bertl: do the commands in network_cmd.h anything useful yet? 1120575473 M * Hollow or can we skip them completely 1120575481 J * _are_ ~are@gateway-dsl.lihas.de 1120575694 M * Bertl Hollow: well, they don't do much useful right now ... 1120575722 M * Bertl but to be honest, I'd prefer to complete them and use them for non-ngnet networking 1120575770 M * Bertl so basically we could clean them up, and use them instead of legacy net ... 1120575812 M * Hollow I'd welcome that.. 1120575813 M * Hollow until 2.0? 1120575848 M * Bertl why not, should be straight forward but requires a little testing of course 1120575864 M * Hollow we'll do ;) 1120576024 M * Bertl basically that might also allow ipv6 (at least in a limited fashion :) 1120576423 M * Loki|muh_ w00t! 1120576430 M * Loki|muh_ i hear ipv6 :) 1120577237 N * BobR_afk BobR 1120577268 M * Doener` Hollow: how about a 0.2 release after adding the flags to {vx,nx}_create and converting the dlimit stuff, which should be the last .c file in the lib that is not converted yet 1120577776 M * Doener` userspace vserver programming can't be good for conversations... ;) 1120578132 M * eyck why not? 1120578159 M * Doener` because conversation simply fades out... Jack, Enrico and now Hollow ;) 1120578807 M * daniel_hozac haha. 1120578836 M * Bertl conv what? 1120578854 Q * Greek0 Read error: Connection reset by peer 1120578887 J * Greek0 ~greek0@81.189.246.175 1120578919 M * Doener` Bertl: hm? 1120578944 M * Bertl Doener`: exactly! 1120578975 M * Doener` phew... glad that i knew it ;) 1120579952 Q * eXplasm Ping timeout: 480 seconds 1120579956 M * Bertl Hollow, Doener`: http://vserver.13thfloor.at/Experimental/delta-netnew-feat01.diff 1120579969 M * Bertl (it's just compile tested) 1120580479 M * DaPhreak i'll try it ;) i still need to to the 2.6.12.2 jump from 2.6.11 ;) so i'll put this also in 1120580508 J * eXplasm explasm@p549F3401.dip.t-dialin.net 1120580526 M * Greek0 Bertl: I think I won't have time to move the #includes around as we talked about yesterday. after 2 hours of sleep last night and 10 hours of work, I don't feel like coding any more. 1120580553 M * Greek0 I'll probably look into it tomorrow 1120580556 M * Bertl np 1120580694 M * DaPhreak Bertl: am I right that http://vserver.13thfloor.at/Experimental/BME/delta-2.6.11.5-vs1.9.5.3-bme0.06.1.diff is the latest BME ? 1120580713 M * Bertl the latest vserver BME, I guess 1120580726 J * jonsmel|out_partying ~jscottorn@209.33.206.3 1120580743 M * Bertl wb jonsmel|out_partying! still partying? 1120580782 N * jonsmel|out_partying jonsmel 1120580785 M * jonsmel thanks 1120580793 M * jonsmel well, just winding down 1120580795 M * jonsmel :) 1120580858 J * Val ~val@v41.ath.cx 1120580868 M * Val hi 1120580928 Q * eXplasm Remote host closed the connection 1120580975 Q * prae Quit: Execute Order 69 ! 1120580979 M * Bertl welcome Val! LTNS! 1120581054 M * Val Hi Bertl :) LTNS ? 1120581097 M * Bertl yeah, well at least for me ... 1120581108 M * Val oh, yeah :) 1120581165 M * Val does rc5 correct anything, or else is it just the rc4 version against 2.5.12.2 ? 1120581206 M * Bertl a change in the release number _always_ means a change in the patch 1120581214 M * Val ok :) 1120581217 M * Bertl (rediffs just get the same version) 1120581234 M * Val il will know it now 1120581317 M * DaPhreak anyone in here, who knows how quilt recognizes, which patch i've created a snapshot of ? 1120581415 M * Bertl hmm, you make the snapshot of a stack, IIRC 1120581445 M * Doener` Bertl: you can add addresses on the fly, but you can only remove all at once, right? 1120581457 M * Bertl Doener`: for now, yes 1120581466 M * DaPhreak yeah .. and he recognizes it by a special directory which contains all changes on the current stack 1120581484 M * Bertl Doener`: once that is working, we can add various ways to remove an existing ip 1120581501 M * Bertl (by index, by reference ...) 1120581532 M * Doener` not that much of a limitation... what about extending the vc_nx_info to get the number of existing addresses and a second call to get the actual addresses? 1120581540 M * Doener` s/call/command/ 1120581553 M * Bertl hmm, good point 1120581644 M * Bertl that brings up the question if a 'set/get' might be preferable over add/remove? 1120581666 N * sukria sukria|away 1120581764 M * Doener` hm, the code relies on the fact that the addresses are from index 0->n, a index based get/set might introduce problems if userspace isn't careful... while a good add/remove would prevent such problems... 1120581792 M * Bertl indeed ... 1120581794 M * Doener` what we could do is having additional get/set calls, that take care that addresses are stored consecutive in the array 1120581819 M * Doener` i.e. you can only _change_ the address via set, you cannot add/remove it 1120581859 M * Doener` dunno how useful such a set command woulb be though 1120581867 M * Doener` s/woulb/would/ 1120581908 M * Bertl well, the current add/remove will not allow to change the first (main) ip easily, for example 1120581926 M * Doener` true 1120582060 M * Doener` but removing an address that is not at the end would require some work anyways, so the set would basically also be doable via remove/add, if we support removal of addresses at arbitrary positions in the array 1120582414 J * sukria ~sukria@www.sukria.net 1120582569 Q * sukria Quit: 1120582635 M * Bertl yeah, I guess we stay with the add/remove for now ... and I'll add a get later (maybe even a change, if that makes sense) 1120582765 M * Bertl okay, off now ... will be back later ... 1120582768 M * Doener` ok, i'll get libvserver to support the add/remove stuff and write some test tool 1120582787 M * Bertl excellent! 1120582802 N * Bertl Bertl_oO 1120583868 M * Doener` brb 1120583871 Q * Doener` Quit: Leaving 1120584108 N * BobR BobR_oO 1120584294 J * Doener ~doener@p54876E3A.dip.t-dialin.net 1120584307 M * daniel_hozac wb 1120584323 M * Doener thx :) 1120585870 Q * sukria|away Quit: see you 1120585887 M * kevinp quick question for you smart guys out there 1120585904 M * kevinp I want to change the root password inside the vserver from the outside in one line 1120585950 M * kevinp so "vserver vname exec echo testpass | passwd root --stdin" doesn't work because of the pipe 1120585965 M * kevinp it changes the root password of the host instead of the guest 1120585996 M * Doener kevinp: try chpasswd 1120586048 M * Doener or do bash -c "echo testpass | passwd root --stdin" 1120586057 M * Doener off for dinner now... 1120586063 M * kevinp thanks! 1120586076 M * Doener you're welcome 1120587245 J * prae ~prae@sherpadown.net 1120587313 Q * cryo Remote host closed the connection 1120587572 M * prae yapalala ~people :) 1120587621 J * cryo ~say@212.86.243.154 1120588702 Q * _are_ Quit: bbl 1120592827 J * _are_ ~are@dsl-084-056-129-055.arcor-ip.net 1120593061 J * sannes ~ace@cm-84.118.217.070.chello.no 1120593254 M * sannes so, what changed between rc4 and rc5 ? 1120593738 Q * sannes Ping timeout: 480 seconds 1120593975 M * kevinp Is it possible to change the fstab to make / a certain size, like say 2 GB? 1120593990 M * daniel_hozac that's what disk limits are for. 1120594125 M * kevinp back to the flower page I guess 1120594160 M * daniel_hozac no, it's not integrated that well into util-vserver yet. 1120594352 M * daniel_hozac vdlimit --xid --set space_used=`du -sc /vservers/ | awk '{ print $1 }'` --set space_total=$(( 2048 * 1024 )) --set inodes_used=`ls -1aRi | awk '/^[0-9]+ / { print $1 }' | sort -u | wc -l` --set inodes_total= /vservers/ 1120594358 M * daniel_hozac or something similar. 1120594388 M * kevinp wow! 1120594547 M * kevinp just run this once from the command line or every time the box is rebooted? 1120594547 J * erwan_ho ~erwan@konilope.dyndns.org 1120594556 M * daniel_hozac every time it's rebooted. 1120594563 M * daniel_hozac unfortunately. 1120594913 M * daniel_hozac oh, and the -c in the du command needs to die. 1120595121 M * Doener daniel_hozac: hm, saving the values prior to reboot and restoring right after boot should also work. Doesn't it? 1120595160 M * daniel_hozac Doener: yeah, but AFAIK no one has created scripts for that yet ;) 1120595178 A * Doener doesn't use disklimits, so he won't step forward ;) 1120595924 M * kevinp daniel_hozac, does this change the output of df? 1120596001 M * Hollow evening folks 1120596008 M * Doener hey Hollow 1120596072 M * Doener Hollow: could you take a look at the newnet patch Bertl made? 1120596081 M * daniel_hozac kevinp: yes. 1120596091 M * Hollow Doener: that i get where from? 1120596095 M * Doener i don't get the ip[4] and mask[4] in the vcmd_net_addr_v0 struct... 1120596134 M * Doener backlog ;) or the usual http://vserver.13thfloor.at/Experimental/FOR-2.0/ (IIRC there it is) 1120596193 M * Doener http://vserver.13thfloor.at/Experimental/delta-netnew-feat01.diff 1120596198 M * Doener ok, wrong dir ;) 1120596257 M * Hollow Doener: yep.. saw it... and haha about fading away.. you know.. babes are evil, i told you.. they really are. 1120596280 M * Doener heh 1120596429 M * Hollow patch looks good 1120596496 M * Hollow Doener: btw: should we add debug functions as well? 1120596514 M * Doener Hollow: count > 4 will make it run over the array boundaries, won't it? 1120596566 M * Hollow which count for which array in which file? ;) 1120596601 M * Doener linux-2.6.12.2-vs2.0-rc5.3/kernel/vserver/network.c -- first hunk, vc_net_add() 1120596612 M * Doener the while-loop 1120596700 M * kevinp daniel_hozac, do I have to put in inodes too or can it just be space driven? 1120596744 M * daniel_hozac kevinp: i think space should do it, but it didn't work for me... i haven't looked into it though. 1120596811 M * kevinp I get weird results: /dev/hdv1 2.0G 832M 0 100% / 1120596825 M * daniel_hozac kevinp: oh, yeah, you have to set reserved=5 as well. 1120596834 M * daniel_hozac for some reason it defaults to 100. 1120596886 J * AprilDL ~chatzilla@ip68-9-200-247.ri.ri.cox.net 1120596890 M * kevinp perfect, thanks a bunch! 1120596935 M * AprilDL i am building my 2.6.11 kernel again - shall i say yes to all the new vserver options like Virtual Root device support (BLK_DEV_VROOT) [N/m/y/?] (NEW) 1120596952 M * Hollow Doener: svn up 1120596956 M * Hollow öh 1120596960 M * Hollow conflict.. 1120596976 M * AprilDL the application is for hosting, to isolate users from each other and measure their resource usage - mainly apache-mysql-php 1120596982 M * daniel_hozac Doener: doesn't the other check catch that? 1120596996 M * Doener which one? 1120597004 M * Doener NB_IPV4ROOT is 16 1120597024 M * Hollow Doener: ok, now svn up 1120597036 M * daniel_hozac ah. 1120597054 M * daniel_hozac yeah, i guess that would run over the array. 1120597086 M * daniel_hozac AprilDL: VROOT is for quotas within vservers. 1120597313 M * Doener Hollow: why did you drop ip and mask from struct nx_net when you changed vserver.h introducing the new api? 1120597339 M * Hollow in changeset 46? 1120597385 M * Doener nvm, the changeset browser just seems to have a bug... 1120597391 M * Hollow *g* 1120597413 M * Hollow it just skips some lines.. 1120597415 M * Doener 154 154 uint16_t count; 1120597415 M * Doener 158 158 }; 1120597427 M * Doener there should be a "..." line in between... 1120597435 M * Doener 39 39 uint16_t count; 1120597435 M * Doener … … 1120597435 M * Doener 49 49 extern int vc_net_migrate(uint32_t, void __user *); 1120597439 M * Doener this one's fine... 1120597442 M * Hollow heh .. yep 1120597462 M * Doener ok, who's gonna file a bug? 1120597508 M * Hollow :) 1120597584 M * Hollow i'd write but not today anymore.. i'm not at good shape to write good bug reports.. 1120597896 M * AprilDL ther seems to be some conflicting advice as to whether to Enable Legacy Kernel API (VSERVER_LEGACY) ... with kernel 2.6.11 and vserver patch 1.95 on debian 1120597904 M * AprilDL what's the current advice 1120597919 M * Doener Hollow: it's already filed at trac 1120597950 A * Doener would love to have said "already fixed..." ;) those guys are usually quite fast 1120597989 M * daniel_hozac AprilDL: why aren't you using 2.0-rc5? 1120598021 M * AprilDL don't know 1120598050 M * AprilDL but lets say i'll move up to that after i even get the 2.6.11 kernel to boot with the 1.95 patch i guess since i'm in the middle of it 1120598069 M * AprilDL 1.95 is in use by some hosting companies like Open HOsting 1120598075 M * AprilDL i don't need to go to the bleeding edge 1120598096 M * Doener 2.0-rc5 is more like the stable edge compared to 1.9.5... 1120598100 M * AprilDL :) 1120598101 M * AprilDL thanks 1120598118 M * AprilDL how about the legacy api question - do i need that 1120598130 M * Doener 2.0 will be the first stable release for the 2.6 kernel ;) 1120598148 M * AprilDL ok i'll go to that after i get this to boot 1120598160 M * Doener hm, don't remember how it was with 1.9.5... with 2.0-rc5 you don't absolutely need it for most stuff 1120598176 M * Doener IIRC vserver-stat and vps/vtop still need it, but that's it 1120598198 M * Doener legacy networking is another story... but that may get solved today/tomorrow 1120598213 M * Doener not yet ngnet, but at least some new api ;) 1120598630 Q * prae Quit: Pwet 1120598675 J * are|lunch ~are@dsl-084-056-129-203.arcor-ip.net 1120598686 Q * _are_ Read error: Connection reset by peer 1120598737 N * are|lunch _are_ 1120599490 Q * erwan_ho Remote host closed the connection 1120600513 J * Aiken ~james@tooax8-075.dialup.optusnet.com.au 1120600790 M * Doener welcome Aiken 1120600868 M * Hollow n8 folks 1120600873 M * Doener night Hollow 1120600907 M * Aiken good morning 1120600933 A * Doener loves timezone magic ;) 1120600952 M * Hollow :P 1120600957 M * Aiken here or amateur radio it gets annoying 1120600982 M * Aiken sometimes it is handy to have a clock set to someone elses timezone 1120601057 M * Hollow my preffered timezone is UPT (universal personal time) ;) 1120601360 M * Aiken my UPT says it is breakfast time 1120602786 M * Doener daniel_hozac: http://www.13thfloor.at/~doener/vserver/patches/delta-netnew-feat02.diff 1120602792 M * Doener that should be better, right? 1120602845 M * Doener oops... typo... sec... 1120602915 M * daniel_hozac well, except for the vc typos, it looks good. ;) 1120602935 M * Doener updated... 1120603005 M * Doener ok, test booting... 1120603007 Q * Doener Quit: Leaving 1120603068 M * kevinp daniel_hozac, when using the vdlimit does the space_used update automatically or do I need to update it every once in awhile through a cronjob? 1120603088 M * daniel_hozac kevinp: the kernel will handle space_used and inodes_used automatically. 1120603103 M * kevinp okay, great, thanks again 1120603135 M * kevinp I just don't see it change 1120603168 M * kevinp I copied a 200 MB file in and am copying it do fill up the space and df stays the same 1120603177 M * kevinp s/do/to 1120603208 M * daniel_hozac you have xid tagging enabled, right? 1120603223 M * kevinp hmm, good question 1120603232 M * daniel_hozac and you're copying the file in a way that it'll get tagged appropriately? 1120603238 M * daniel_hozac as in, over SSH or similar. 1120603248 M * kevinp would that have been when I compiled the kernel? 1120603260 M * kevinp I'm in a vserver test enter 1120603346 M * kevinp just copied it in ssh and same df 1120603454 M * daniel_hozac hmm, that seems to happen on non-tagxid filesystems. 1120603469 M * daniel_hozac (mounted with the tagxid option) 1120603561 J * Doener ~doener@p54876E3A.dip.t-dialin.net 1120603627 M * daniel_hozac wb 1120603676 Q * Val Quit: My damn controlling terminal disappeared! 1120603711 M * Doener thx, 1120603723 M * Doener now let's see if that new net stuff actually works :) 1120603796 M * kevinp ok, so I can just add tagxid to /vservers and remount? 1120603820 M * daniel_hozac you need to umount, and the mount again. 1120603835 M * daniel_hozac -o remount,tagxid didn't work last time i checked. 1120603843 M * kevinp and stop all the vservers on that mount I assume? 1120603870 M * daniel_hozac yeah, i don't think you'll be able to umount it otherwise. 1120604978 M * kevinp ok, so now I have xid tagging and the test vserver has supposedly 697M left, but when I try to copy the 215M file, I get no space left on device 1120604998 M * Doener what does df say? 1120605014 M * Doener (df and df -i) 1120605022 M * daniel_hozac that was my problem as well. 1120605026 M * daniel_hozac you need to set the inodes. 1120605033 M * kevinp ahh, that's where the inodes come in 1120605047 M * Doener one file, one inode 1120605061 M * daniel_hozac can a dlimit not have non-set fields? 1120605065 M * kevinp so what if I don't want to limit inodes, just space? 1120605078 M * Doener if you don't want to limit them, set them to the same value as the partition itself has 1120605133 M * kevinp or a number they should never hit? 1120605259 M * kevinp everything is working now wonderfully 1120605382 M * Doener i don't know how the kernel behaves if the dlimit is above the actual capacity... but i assume that Bertl has taken care of that 1120605423 M * daniel_hozac but vdlimit defaults to setting them to unlimited. should inodes really be limited in that case? 1120605974 M * daniel_hozac hmm, no, it defaults to keeping previous values. 1120606222 M * kevinp this is really strange, I just noticed that there is no /etc/shadow in my vserver 1120606282 M * kevinp with a yum rpm install does it default to some other authentication? 1120606366 M * daniel_hozac did you install the setup package? 1120606417 M * daniel_hozac i have noticed that as well though. 1120606450 M * kevinp hmm, which setup package? 1120606452 M * daniel_hozac i'm guessing it's falling back on /etc/passwd. 1120606501 M * daniel_hozac well, the setup package is the one owning /etc/shadow here. 1120606525 M * daniel_hozac (but i have that package installed. still no /etc/shadow) 1120606552 M * kevinp yeah, shadow-utils is installed on both 1120606614 M * Doener probably needs reconfiguration of pam(?) 1120606681 M * daniel_hozac hmm, i guess. 1120606716 M * Doener pwconv should create /etc/shadow 1120606734 M * kevinp that worked 1120606751 M * Doener and /etc/pam.d/system-auth (or wherever that is on fc) should contain the shadow keyword 1120606756 M * Doener system-auth:password sufficient /lib/security/pam_unix.so nullok md5 shadow use_authtok 1120606763 M * Doener that's what i have... 1120606783 M * Doener same for system-auth-winbind (whatever that is...) 1120606887 M * kevinp hmm, I don't see that 1120607018 M * Doener "locate system-auth" may help... or "grep -R pam_unix.so /etc/* | grep password" 1120607089 M * kevinp sorry, I meant the file is there, but I didn't see and shadow entries in it 1120607136 M * Doener well, that was expected ;) 1120607159 M * Doener shadow passwords were disabled, so you should add that keyword now that you have a shadow file 1120607181 M * kevinp oh, I see, so what was it using before? 1120607189 M * Doener /etc/passwd 1120607222 M * Doener if you look at /etc/passwd now, the second field contains just an x for all users 1120607242 M * Doener previously this field contained the users' passwords 1120607267 M * kevinp yeah, I just assumed that it looked like that before too, I just checked a different vserver and passwd looked like the shadow file 1120607277 M * kevinp makes sense now 1120607769 N * jonsmel jonsmel_zZ 1120607961 J * jkl_ eric@c-67-165-222-86.hsd1.co.comcast.net