1122078297 M * Zoiah Bertl: about my problem, I'm quite sure it's problem in my vserver. 1122078309 M * Zoiah Bertl: if I leave the hardwaretouching initscripts in the vserver, it does shut down. 1122078319 M * Zoiah Bertl: only if I remove them, it hangs, I just wonder why. 1122078801 M * Bertl hmm, is it gentoo? 1122078887 M * Bertl Zoiah: the guest I mean ... 1122079992 M * Zoiah Bertl: CentOS 4 1122080046 M * Bertl hmm .. okay, if you do the stop, and it times out ... could you check what is still left inside the context? 1122080137 M * Zoiah Bertl: 'minilogd' 1122080158 M * Bertl interesting ... 1122080162 M * Zoiah It doesn't time out btw. 1122080163 M * Zoiah It just hangs. 1122080173 M * Bertl ah, even better ... 1122080186 M * Zoiah Until I ctrl-c the stop (but then it's not really stopped) or I kill the PID manually (then it is nicely stopped). 1122080187 M * Bertl you do a vserver stop and it hangs? 1122080241 M * Zoiah http://pastebin.com/318915 1122080251 M * Zoiah After the 'killall', it hangs. 1122080269 M * Zoiah Also, if I ctrl-c the stop a 'vwait' process remains. 1122080279 M * Bertl yes, that is okay ... 1122080295 M * Bertl please do me a favor and get a guest into that state (including the hanging stop) 1122080310 M * Zoiah It is, now. 1122080312 M * Bertl (do not interrupt it though) 1122080320 M * Zoiah Ok. 1122080327 M * Bertl now get the xid of that context, and send a vkill 1122080340 M * Zoiah vkill to what? 1122080342 M * Zoiah XID is 244 1122080377 M * Bertl vkill --xid 224 -s TERM -- 0 1122080397 M * Zoiah armatron:~# vkill --xid 244 -s TERM -- 0 1122080397 M * Zoiah armatron:~# 1122080401 M * Bertl oops 244 :) 1122080408 M * Zoiah And the stop is finished properly. 1122080412 M * Zoiah Now. 1122080423 M * Bertl okay, that is supposed to be send by the stop ... 1122080496 M * Bertl what kind of init style do you use? 1122080513 M * Bertl (looks like sysv to me, no? 1122080537 M * Zoiah Yes. 1122080604 M * Bertl hmm ... basically the sysv methods are designed to get rid of all running processes ... but it might happen that your final 'kill' script doesn't run 1122080617 M * Bertl (maybe that's why it works with the hardware errors/stuff)? 1122080642 M * Bertl it seems to me that the minilogd is started, but cannot be stopped by your guest scripts 1122080662 M * Bertl of course, this should have a timeout, after which the guest is force killed as you did now 1122081580 Q * richardw Quit: Leaving 1122081615 M * Zoiah Sorry for my late answer, I had a fight with my laptop keyboard. (Stupid Numlock changes keys for numbers). 1122081634 M * Zoiah Yes, this was also my idea, I just don't know why the vwait doesn't timeout. 1122081717 M * Zoiah If I look in the process list I see this when it hangs: 1122081717 M * Zoiah root 3614 2306 2 03:21 pts/3 00:00:00 /bin/bash /sbin/vserver vrs stop 1122081717 M * Zoiah root 3622 3614 0 03:21 pts/3 00:00:00 /lib/util-vserver/lockfile /var/lock/vserver.etcvserversvrs.startup /tmp/vser 1122081717 M * Zoiah root 3636 3614 0 03:21 pts/3 00:00:00 /sbin/vwait --timeout 30 --terminate --status-fd 3 244 1122081726 M * Zoiah But even if I ctrl-c the stop, the vwait process remains. 1122081855 M * Zoiah armatron:~# strace -p3636 1122081855 M * Zoiah Process 3636 attached - interrupt to quit 1122081855 M * Zoiah vserver(0x30630000, 0xf4, 0x7ffffcb0, 0x7, 0x77ff5cd0) = ? ERESTARTSYS (To be restarted) 1122081855 M * Zoiah --- SIGALRM (Alarm clock) @ 0 (0) --- 1122081855 M * Zoiah sigreturn() = ? (mask now []) 1122081855 M * Zoiah vserver(0x30630000, 0xf4, 0x7ffffcb0, 0x7, 0x77ff5cd0 1122082034 M * Zoiah I That SIGALRM seems to be the timeout. 1122082038 M * Zoiah -I 1122082063 M * Zoiah But it doesn't actually out the time. ;) 1122082283 M * Bertl the vwait is supposed to 'wait' 1122082319 M * Bertl it waits until the last process inside the guest died, and the very last reference held by the context is released 1122082342 M * Zoiah Then who is supposed to do the killing after the guestscripts failed to do so properly? 1122082356 M * Bertl basically the shutdown of a guest (or reboot) works like this: 1122082361 M * Bertl (in theory :) 1122082378 M * Bertl a) something decides the context should go down ... 1122082399 M * Bertl b) that something starts a 'waiter' to wait for the context disposal 1122082430 M * Bertl c) then whatever is appropriate to tear down the context from inside is done (stop/shutdown/whatever scripts) 1122082456 M * Bertl d) after some timeout (30 secs default IIRC) the processes inside the guest are forced to die 1122082485 M * Bertl e) the context is dissolved, the waiter awakens 1122082509 M * Bertl if the shutdown/reboot comes from inside, then the timeout is not required 1122082533 M * Bertl i.e. d) can happen immediately after the vshelper did get the reboot 1122082708 M * Zoiah /sbin/vwait --timeout 30 --terminate --status-fd 3 244 1122082713 M * Zoiah Looks like your 30 secs. ;) 1122082802 M * Zoiah if (!args->do_terminate) 1122082802 M * Zoiah res.status = stTIMEOUT; 1122082802 M * Zoiah else { 1122082802 M * Zoiah vc_ctx_kill(args->xid, 1, 9); 1122082802 M * Zoiah vc_ctx_kill(args->xid, 0, 9); 1122082803 M * Zoiah res.status = stKILLED; 1122082803 M * Zoiah } 1122082823 M * Zoiah Seems like vwait.c is supposed to kill it after 30 secs. 1122083074 M * Bertl hmm, so why is it not killing it? 1122083113 M * Bertl does the alarm arrive at all? 1122083137 M * Zoiah Yes. 1122083140 M * Zoiah Look at my srace. 1122083141 M * Zoiah strace* 1122083146 M * Zoiah I'll printf something. 1122083236 M * Bertl okay, so let me get this straight ... the vwait is activating an alarm timer (30secs) after which the alarm is delivered (successfully) and the vwait sends two kills, one to userspace processes and one for init ... and all this doesn't impress the minilogd? 1122083250 M * Bertl do you have vserver debugging enabled on that kernel? 1122083261 M * Zoiah No. 1122083268 M * Zoiah I wonder if it even tries. :) 1122083293 J * Aiken_ ~james@tooax6-125.dialup.optusnet.com.au 1122083296 M * Zoiah Lets see what ltrace does. 1122083302 M * Zoiah When it timeouts. 1122083309 M * Bertl wb Aiken_? 1122083327 M * Zoiah armatron:/usr/src/util-vserver-0.30.208# ltrace -p4930 1122083327 M * Zoiah --- SIGALRM (Alarm clock) --- 1122083331 M * Zoiah Not much action... 1122083336 M * Aiken_ just hit the 5 hour session limit :( 1122083339 M * Aiken_ hello 1122083423 M * Bertl well, see how beneficial that is for social intercourse ... 1122083618 Q * Aiken Ping timeout: 480 seconds 1122083705 M * Zoiah Bertl: should I install a vserver kernel with debug on? 1122083913 M * Bertl well, it could help, as we can see what syscalls are made (and when) 1122083931 M * Bertl vserver syscall commands I mean 1122083953 M * Zoiah Yes. 1122083957 M * Zoiah Sure, should be doable. :) 1122084149 M * Zoiah It's building. 1122084567 Q * tchan Remote host closed the connection 1122085251 J * tchan ~tchan@c-24-13-81-164.hsd1.il.comcast.net 1122085665 Q * yarihm Quit: Leaving 1122086450 J * Doener` ~doener@p548740B3.dip.t-dialin.net 1122086460 M * Bertl evening Doener`? 1122086888 Q * Doener_ Ping timeout: 480 seconds 1122086894 Q * Aiken_ Quit: Leaving 1122087053 J * Aiken ~james@tooax6-125.dialup.optusnet.com.au 1122091247 Q * Aiken Ping timeout: 480 seconds 1122092788 N * pg|cereal cereal 1122094093 M * Hollow morning 1122094126 M * Hollow Bertl: i'm around ;) 1122094306 M * Bertl hey Hollow! 1122094362 M * Bertl well, regarding your patch ... 1122094437 M * Bertl why would we want to move the CMD stuff into context.h? 1122094492 M * Bertl I mean, the *_cmd files were created to separate the command interface from kernel internals (some time ago) 1122094535 M * Hollow hm, i think it's a matter of taste.. 1122094564 M * Bertl hmm, no, it's a matter of not including userspace stuff in every kernel file :) 1122094575 M * Bertl it's quite simple actually ... 1122094587 M * Hollow you can surround it by some #ifndefs 1122094607 M * Bertl we (I?) try to have the minimum amount of include dependancies possible 1122094627 M * Bertl why? simple ... consider I decide to add a new command or change a struct for a test 1122094639 M * Bertl now what happens right now? 1122094656 M * Bertl at most 3 kernel files are rebuilt ... 1122094667 M * Bertl after your change, even with #ifdefs ... 1122094679 M * Bertl 213 kernel files have to be rebuilt :) 1122094724 M * Hollow i'm used to compiling, i don't care about 1 or 300 files to compile :P 1122094757 M * Hollow i just did it the way i like it best ;) 1122094783 M * Hollow seems like i just like it the other way round: few files as possible ;) 1122094786 M * Bertl okay, but you see that this has a big disadvantage at least for me? 1122094792 M * Hollow yep 1122094855 M * Hollow so at least you have to include context.h and context_cmd.h in userspace to get the flag and cap defines 1122094876 M * Bertl well, we could easily move the flag/cap stuff into the _cmd 1122094893 M * Bertl because the relevant files using them are not many ... 1122094893 M * Hollow but then the kernel has to include _cmd.h 1122094974 M * Bertl it does so already ... for the switch 1122095028 M * Bertl but yes, it might be better to not do that .. because you (the userspace guy) don't care about depending on many includes *g* while I do :) 1122095053 M * Hollow heh 1122095838 M * Hollow Bertl: what about moving the internal stuff somewhere else? 1122095864 M * Bertl which, and where? 1122095922 M * Hollow maybe into kernel/vserver? 1122095930 M * Hollow and what about the vs_* headers 1122095931 M * Hollow ? 1122096132 M * Bertl kernel/vserver is not good, because other sections _might_ include it 1122096157 M * Hollow well... other drivers and kernel things do this as well 1122096161 M * Bertl (i.e. gives very nasty pathes, all shared includes should go into 'include/linux/bla' 1122096193 M * Bertl well, things _only_ included by the kernel/vserver/* files can go there of course ... (and some already do) 1122096220 M * Hollow hm 1122096412 M * Hollow maybe we'd just elave them as-is ;) 1122096415 M * Hollow *leave 1122097112 M * Hollow Bertl: we could also move all commands into one file.. 1122097140 M * Bertl well, basically yes, but that makes it somewhat unreadable ... no? 1122097159 M * Bertl but you can do a command.h :) 1122097175 M * Hollow hm, i don't think that some VCMD_* defines woud make it unreadable 1122097213 M * Hollow ok, i'll do a little patch.. 1122097349 M * Bertl hmm, the idea was that command.h simply includes all _cmd.h files ... 1122097524 M * Hollow ei.. 1122097530 M * Hollow then we don't need a command.h 1122097583 M * Hollow i try to reduce the fies and you want even more ;) 1122097587 M * Hollow *files 1122097660 M * Bertl okay, let me put it this way ... if you can prove that such a rearrangement doesn't cause additional dependancies, it's fine with me ... 1122097714 M * Hollow how can i get the dependencies? 1122097799 M * Bertl well, make can tell you them, but that's hard to check 1122097817 M * Bertl best way is probably to touch each file and see what recompiles 1122097833 M * Bertl of course grep and cscope are an option too 1122098155 J * Aiken ~james@tooax6-053.dialup.optusnet.com.au 1122098183 M * Hollow Bertl: is it correct that the *_x32 structs are only defined with __KERNEL__ defined? 1122098422 M * Bertl yep, should be so ... 1122101423 M * Hollow Bertl: ok, i'll give up ;) 1122101464 M * Bertl well, it's not easy to find a good balance with includes 1122101494 M * Bertl the methodical approach would be: include every file exactly there where you need it 1122101529 M * Bertl as we know that leaves us with a ball of string, where each and every file includes the kitchen sink 1122101589 M * Hollow who cares anyway about kernel headers but the util devs 1122101629 M * Bertl the kernel devs!!! :) 1122101646 M * Hollow kernel devs only want less deps ;) 1122102070 M * Hollow Bertl: the second approach, but probably still to many deps http://home.xnull.de/misc/vs2.0-rc8.1-cleanup_headers2.patch 1122102286 M * Bertl comments: 1122102308 M * Bertl - does it buy you anything to include commands.h instead of *_cmd.h ? 1122102329 M * Bertl - you have to include context.h too, because of the flags, no? 1122102335 M * Bertl - dont do this: 1122102335 M * Bertl -VSC_NETDOWN, 1122102336 M * Bertl +VSC_NETDOWN 1122102347 M * Hollow unfortunately code never buyed me sth 1122102352 M * Bertl because it doesn't help, but it might hurt easily 1122102352 Q * Aiken Ping timeout: 480 seconds 1122102379 M * Hollow tbh, i don't like this approach too ;) 1122102396 M * Bertl -struct _vx_usage_stat cpustat[NR_CPUS]; 1122102396 M * Bertl +struct __vx_usage_stat cpustat[NR_CPUS]; 1122102402 M * Bertl hmm, that's interesting ... 1122102416 M * Hollow heh 1122102480 M * Bertl -/* pass vxi only */ 1122102481 M * Bertl +/* pass vxi only */ 1122102489 M * Bertl comments in the first column? 1122102518 M * Hollow ? 1122102570 M * Bertl well, I avoid comments in the first column ... 1122102584 M * Bertl because they are easily confused with code (IMHO) 1122102612 M * Hollow ever heard about syntax highlighting? ;) 1122102634 M * Bertl yeah, and I use it whenever possible :) 1122102672 M * Bertl ever heard of indent? why not produce packed version :) 1122102688 M * matti ;p 1122102693 M * Hollow i use indent 1122102697 M * Bertl btw, did you actually compile the kernel with those headers? 1122102701 M * Hollow yup 1122102737 M * Bertl ah, you removed all the duplicate inclusion stuff, right? 1122102745 M * Hollow righty 1122102753 M * Bertl well, that explains it ... 1122102770 M * Hollow it's included only once anyway 1122102797 M * Bertl sure after your changes? 1122102801 M * Hollow yep 1122102809 M * Bertl how do you know? 1122102815 M * Hollow #ifndef _VX_COMMAND_H 1122102815 M * Hollow #define _VX_COMMAND_H 1122102833 M * Hollow so after you've included it once, it will never get there 1122102843 M * Bertl ah, no, that only ensures that the code is only parsed once ... not that it's only included once :) 1122102850 M * Hollow who cares 1122102854 M * Bertl me 1122102857 M * Hollow :P 1122102859 M * matti Nice conversation ;p 1122102860 M * matti ;p 1122102986 M * Hollow well.. doesn't really matter anyway, leave them as-is 1122103020 M * Hollow as long as i can produce a working libvserver with it i don't care 1122103025 M * Bertl well, we can rearrange a little stuff ... 1122103048 M * Bertl but I'm sure that I won't take most changes of this patch ... 1122103075 M * Bertl because a) they do clash with my coding style (and I have to read them probably more often than you) 1122103101 M * Hollow yeah, that's probably why i don't care that much ;) 1122103105 M * Bertl b) they do not add any benefit I would see ... 1122103127 M * Bertl now, what I can understand is further user/kernel space separation 1122103140 M * Bertl but that probably goes in a direction you will not appreciate either 1122103236 M * Bertl the _* -> __* change still puzzles me, what is the idea behind that? 1122103263 M * Hollow these are sub structs of the substruct 1122103268 M * Hollow aren't they? 1122103353 M * Bertl ah, that's the idea behind it ... an _ for each sublevel? 1122103367 M * Hollow yup 1122103397 M * Hollow i'd have skipped the _ prefix anyway, but so it's at least more consistent 1122103447 M * Bertl well, my idea for the underscore was to 'mark' private structs/types/whatever 1122103477 M * Hollow ah 1122103483 M * Bertl so you'll always find the underscore in fron of them 1122103506 M * Bertl and to distinquish structures from functions, I used two of them for the functions 1122103569 M * Bertl but yeah, this is probably a matter of taste ... 1122103580 M * Hollow ;) 1122103587 M * Hollow i hate underscores ;) 1122103598 M * Hollow (as prefix) 1122103616 M * Bertl well, how'd you handle something like the lookup stuff then? 1122103619 M * Hollow it just look ugly to me 1122103647 M * Hollow which lookup stuff? 1122103689 M * Hollow maybe just without the prefix.. 1122103690 M * Hollow ;) 1122103729 M * Bertl unhash_vx_info 1122103732 M * Bertl kernel/vserver/context.c 1122103759 M * Bertl with an additional postfix? 1122103786 M * Hollow well, here i'd probably just gave it another name 1122103796 M * Bertl like? 1122103850 M * Bertl just curious, not really important ... 1122103920 M * Hollow hm, i don't know what it's doing *shrug* 1122103986 M * Bertl okay, nevermind ... 1122103988 M * Hollow but doesn't matter 1122103991 M * Hollow heh 1122104006 M * Bertl don't let me stop you from working on the library/tools :) 1122104013 M * Hollow let's stop talking about irrelevant stuff 1122104014 M * Hollow ;) 1122104025 M * Hollow Bertl: you won't ;) 1122104071 M * Hollow well... you have to scope with my coding style wrt the library ;) 1122104097 M * Bertl btw, was nice talking about that stuff ... it's always interesting to hear other POVs 1122104114 J * cilkay ~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com 1122104122 M * Bertl welcome cilkay! 1122104132 M * cilkay hello Bertl 1122104147 M * Hollow POV? 1122104171 M * Bertl Point of View 1122104174 M * Hollow ah ;) 1122104342 M * Bertl or Philosophical Opinions of Value :) 1122104381 M * Bertl acronyms are so flexible ... 1122104412 M * Hollow hehe 1122104866 J * yarihm ~yarihm@80-218-5-17.dclient.hispeed.ch 1122105017 M * Bertl morning yarihm! 1122105302 M * Bertl Hollow: the syscall_shiny(2) works for your library, right? 1122105308 M * Hollow yay! 1122105397 M * Hollow Bertl: i'm just preparing release-0.2.1 1122105457 M * Bertl good, some 'make tests' would be great, is that possible? 1122105478 M * Bertl something which (for now) simply calls for the version or so 1122105493 M * Bertl and later executes a full spectrum of syscall command tests 1122105494 M * Hollow i'll take a look 1122105646 M * Bertl Hollow: something else, I'd like to change the __syscall_error to something different .. because it seems to clash with certail libcs ... 1122105657 M * Bertl *certain 1122105686 M * Bertl maybe __syscall_seterr ? 1122105710 M * Bertl or just __syscall_errval ? 1122105770 M * Hollow well, what does it do? return the error code? 1122105966 M * Bertl depends on the user actually ... 1122105988 M * Bertl when an error happens, it is called with the error value 1122106013 M * Bertl the 'procedure' has to store it ... 1122106028 M * Bertl (if the caller is interested in the error code) 1122106072 M * Bertl I tend to __syscall_errval() as this is equiv to __syscall_retval() 1122106080 M * Bertl s/tend/lean towards/ 1122106204 M * Hollow ok ;) 1122106230 M * Bertl okay, btw, do you define __syscall_error() atm? 1122106239 M * Bertl or do you rely on the internal defines? 1122106262 M * Hollow the latter one 1122106276 M * Bertl okay, that should be fine then ... 1122106552 M * Hollow http://dev.gentoo.org/~hollow/vserver/libvserver/libvserver-0.2.1.tar.bz2 1122106782 A * sladen looks around from Helsinki 1122107064 M * maharaja Bertl: i tried to reproduce that crash i encountered but nothing until now 1122107267 M * Bertl hey sladen! 1122107282 M * Bertl maharaja: well, okay, so we _assume_ that it is gone now? 1122107438 M * maharaja i'm talking about the second crash where you told me to addr2line some addresses 1122107450 M * maharaja don't think that something like this can simply go away ;) 1122107462 M * Bertl hmm, url? 1122107470 M * sladen so, what'st this libvserver stuff? 1122107573 M * Bertl basically a simple but complete userspace library, Hollow is the man to tell you the details ... 1122107593 M * Hollow well, you described it quite good ;) 1122107623 M * maharaja bertl: mhm, ok - might be my fault 1122107635 M * maharaja if theres any error, ill let you know 1122107679 M * maharaja brb (reboot) 1122107811 M * Hollow Bertl, sladen: well, it's planned to do new tools with this lib as well 1122107844 M * sladen Hollow: ooh, new tools would be good, I'm not a fan of the current ones 1122107849 M * sladen (not sure why) 1122107860 M * Hollow heh, yeah, that's why i started libvserver ;) 1122107901 M * Hollow libvserver already contains some preliminary tools, but basically for testing the lib stuff 1122107914 M * bipsen Bertl: regarding the kernel issue I had - compiling the kernel with buil-in DAC960 driver and Ext3 filesystem solved the problem 1122108033 M * Bertl bipsen: yep, read that ... 1122108046 M * Bertl bipsen: any other issues remaining? 1122108087 M * bipsen Bertl: Only the one on the mailing-list .... when stopping a vserver, something seems to hang, even though no daemons or similar have been started.. 1122108115 M * Bertl you might check _what_ hangs while it is hanging ... 1122108123 M * Bertl also make sure that you have the latest tools 1122108127 M * bipsen Oh yeah - and the one when trying to vserver-build on a mount-point for a partition from LVM (cannot rename - reported on savannah) 1122108152 M * Bertl regarding the CAP_SYS_RESOURCE for bind, you should be able to do without it 1122108170 M * Bertl might be that you need a special cflag/cap but not the actual bcap 1122108194 M * bipsen okay... tools have been upgraded to 0.30.208, seems like the most recent version 1122108203 M * Bertl yep, it is 1122108281 M * Bertl DECL("rlimit", VC_VXC_SET_RLIMIT) 1122108291 M * Bertl this should be sufficient for bind ... 1122108299 M * bipsen root 8357 500 dns-int1 0.0 0.0 1524 368 ? Ss 10:44 0:00 minilogd 1122108309 M * bipsen that the only thing in that context 1122108313 M * bipsen taht is 1122108330 M * bipsen (damn - can't spell properly this time of the day ;-)) 1122108331 M * Bertl well, that's fine then ... 1122108348 M * Bertl if the minilogd is not shut down properly by the guest scripts 1122108363 M * Bertl it has to wait for the timeout, and be killed from outside 1122108392 M * Hollow Bertl: btw: how can i kill a faked init process? 1122108407 M * bipsen I guess qmail/daemontools still needs fakeinit ?? 1122108419 M * Bertl Hollow: vkill -c xid -s 9 1 1122108431 M * Hollow if it'd work.. 1122108448 M * Hollow maybe it just hanged 1122108453 M * Hollow afk > breakfast 1122108482 M * Bertl bipsen: well, don't know, ... you tell me? 1122108627 M * bipsen Bertl: I remember it was required in "the old days", because daemontools was spawned from inittab (with respawn parameter) - don't know whether that has changed since kernel 2.4.20ctx-17smp 1122108669 M * bipsen a lot has happend since that time 1122108711 M * bipsen Of course - I can always give it a try, just to see what happens :-P 1122108825 M * Bertl well, do they still depend on the spawning from inittab? :) 1122108858 M * Bertl if yes, then you will also need to run an init inside ... 1122108939 M * bipsen Okay, I know there are other ways to get it running - only problem is then, that the daemontools monitoring process won't respawn, if it fails... minor issue.. 1122108957 M * bipsen Just tried to install bind in a "plain" vserver, without any flags: Starting named: named: capset failed: Operation not permitted 1122109024 M * bipsen I prefer to use "out of the box" rpm's, if possible... 1122109045 M * bipsen I'll try to set rlimit 1122109362 M * bipsen Bertl: it's just to place a file in /etc/vservers/dns-int1 named ccapabilities - containing a line with: rlimit ? 1122109719 M * Bertl yep 1122109753 M * Bertl you might also try the igneg_nice cflag 1122109769 M * Bertl don't remember what bind did wrong right now ... 1122109803 J * cryo ~say@212.86.243.154 1122109826 M * Bertl wb cryo! 1122110028 M * ddlp hi there 1122110055 M * ddlp how do i use the testfs.sh script? what is it for? 1122110117 J * sannes ~ace@cm-84.118.218.175.chello.no 1122110158 M * Bertl ddlp: ah, you use it for testing filesystem xid tagging and extended attributes 1122110186 M * Bertl it basically requires an empty partition/disk/loop (block device) 1122110196 M * ddlp hi Bertl ! 1122110208 M * Bertl and the corresponding filesystem tools ... then you can do 1122110242 M * Bertl testfs.sh -x -t -D /dev/some/device -M /some/mount/point 1122110265 M * Bertl and optionally (-F list,of,file,systems) 1122110301 M * Bertl be careful, it will overwrite the block device with the various filesystems 1122110325 M * ddlp hehe, ok 1122110329 M * Bertl (for example a loop device with roughly 100MB is fine for most filesystems) 1122110405 M * bipsen Bertl: igneg_nice ? 1122110428 M * ddlp Bertl: ok, cool. thanks! 1122110456 M * Bertl you're welcome! 1122110486 M * Bertl bipsen: it allows a process to renice itself with a smaller value 1122110508 M * Bertl well, actually it tells the process that it worked, but doesn't do it 1122110616 M * bipsen Okay... figured it out, and created the flags file... but I still get: Starting named: named: capset failed: Operation not permitted 1122110729 M * sannes trying to make quota work on a non-shared partition from a vserver .. I was sure this worked before, but I must be doing something wrong: vrsetup /dev/vroot/0 /dev/evms/home, put QUOTACTL in bcapabilities, make sure fstab mounts it with usrquota and grpquota, cp device into vserver (/dev/vroot/0) try to activate it from vserver: quotaon -vaug 1122110754 M * Bertl yep, the syntax changed slightly 1122110771 M * Bertl vrsetup /dev/vroot/0 /path/to/the/guest/filesystem 1122110796 M * Bertl and the QUOTA_CTL is now in ccaps ... 1122110913 M * sannes etc/vserver/vs/ccaps? so I mount it in the root server aswell then? or could the path be /vservers/vs/something? 1122111178 M * Bertl mount what? 1122111220 M * sannes maybe I have an old version of vrsetup .. 1122111390 M * sannes vrsetup /dev/vroot/6 /vservers/vs/home/ gives me: ioctl(): Invalid argument 1122111492 M * Bertl sorry, I'm talking nonsense ... 1122111505 M * Bertl I confused it with the vdlimit ... 1122111523 M * Bertl vrsetup 1122111527 M * Bertl is perfect ... 1122111618 M * sannes then (melodramatic) why oh why do I get Operation not permitted .. 1122111678 M * sannes :P 1122111682 M * Bertl probably because of the missing quota_ctl? did you add that one? 1122111692 M * sannes yip 1122111699 M * Bertl restarted the guest? 1122111742 M * Bertl filesystem type of the guest mtab is ufs? 1122111773 M * sannes quota_ctl ? or OUOTACTL or CAP_QUOTACTL? 1122111821 M * Bertl flower page says: ccapabilities and quota_ctl 1122111842 M * Bertl I assume you are using tools 0.30.208 1122111877 M * Bertl (if not, you can probably help yourself by specifying the bit value ...) 1122111931 M * Bertl #define VXC_QUOTA_CTL 0x00100000 1122111952 M * Bertl (so it would be ^20) 1122111997 M * Bertl Hollow: http://vserver.13thfloor.at/Experimental/SYSCALL/syscall_shiny3.h 1122112018 M * Bertl (the mentioned changes, plus a little more protection and clobbering :) 1122112051 M * sannes worked like a charm, thanks! :) i think i'll update the wiki a bit 1122112103 M * Bertl please do so! 1122112218 M * Bertl okay, I'm off to bed now ... have a nice whatever everyone! 1122112275 N * Bertl Bertl_zZ 1122112569 Q * cryo Remote host closed the connection 1122112813 J * cryo ~say@212.86.243.154 1122112864 M * bipsen regarding the problems with Bind9 and capset - should CONFIG_SECURITY be set or not in the kernel config ? 1122112963 Q * yarihm Quit: Leaving 1122118956 M * daniel_hozac bipsen: that will need to be set as linux-vserver depends on capabilities. 1122119103 M * bipsen okay, it has been set on my current kernel... But i'm not able to start bind inside a vserver 1122119126 M * daniel_hozac bipsen: i guess you'll need to give it CAP_SYS_RESOURCE after all. 1122119327 M * bipsen yeah, but CAP_SYS_RESOURCE is the "old style" stuff, right ?? How do I set this parameter with the new-style config ? 1122119487 M * daniel_hozac echo "CAP_SYS_RESOURCE" >> /etc/vservers//bcapabilites 1122119497 M * daniel_hozac as per the flower page. 1122119662 Q * Doener` Remote host closed the connection 1122119683 M * daniel_hozac of course, with correct spelling of bcapabilities. 1122119694 M * daniel_hozac it's too early in the morning :) 1122119717 M * bipsen ;-) 1122119726 M * bipsen just started the vserver - got a funny error: 1122119726 M * bipsen # vserver dns-int1 start 1122119727 M * bipsen Starting system logger: [ OK ] 1122119727 M * bipsen Starting console mouse services: O0o.oops(): [console.c(253)]: Can't determine console device 1122119727 M * bipsen [FAILED] 1122119741 M * daniel_hozac you probably don't want gpm running in the vservers ;) 1122119780 M * bipsen gpm probably got there because I threw in midnight commander 1122119796 M * daniel_hozac just chkconfig gpm off it. 1122119870 M * bipsen got it running... thanks... 1122119893 M * bipsen thought that Herbert & co found a way to fix this problem with Bind9 1122119898 M * daniel_hozac me too 1122119912 M * bipsen taht is - without re-compiling the bind binary 1122120077 J * Doener ~doener@p548740B3.dip.t-dialin.net 1122121480 Q * Doener Read error: Connection reset by peer 1122121811 J * Doener ~doener@p548740B3.dip.t-dialin.net 1122130933 J * bob8282 ~war@lucidpixels.com 1122132691 Q * bob8282 Ping timeout: 480 seconds 1122134775 Q * Zoiah Quit: leaving 1122135593 J * prae ~benjamin@sherpadown.net 1122135968 J * yarihm ~yarihm@217-162-114-40.dclient.hispeed.ch 1122137582 Q * prae Quit: Pwet 1122138758 J * MiXaTa ~LebSoul@82.198.5.150 1122138882 Q * MiXaTa Remote host closed the connection 1122141646 Q * cryo Quit: Покидаю 1122141659 J * cryo ~say@212.86.243.154 1122150504 N * Bertl_zZ Bertl 1122150514 M * Bertl morning folks! 1122150636 J * Jani ~mail@G9a6f.g.pppool.de 1122150638 A * Jani waves 1122150650 M * Bertl hey Jani! 1122150655 M * Jani Heya Bertl. 1122150713 M * Bertl bipsen, daniel_hozac: we did solve/test it some time ago, doesn't mean that a) bind didn't find a new obsession, b) it's still working as expected or even c) it got included in vs2.0-rc* ... 1122150787 M * Bertl FaUl: please elt me know when you're around ... 1122150911 M * Doener evening Bertl! 1122150926 M * matti Bertl: Morning? 1122150927 M * Bertl hey Doener! nice to meet you ... 1122150936 M * Bertl matti: yes morning! :) 1122150937 M * matti Bertl: At 10 PM? 1122150965 M * Bertl well, I got up about 30 minutes ago ... that counts as morning, right? 1122150969 M * Doener yeah, i've been/am pretty busy lately :( ... university, searching for a flat and so on... 1122150973 M * matti Bertl: It's BUT - Bertl Universal Time again? 1122150984 M * matti Bertl: Depends on point of view ;] 1122150995 M * matti Bertl: So, you want some tea, I guess? ;] 1122150996 M * Bertl matti: sorry for answering your questions before you ask ... 1122151024 M * matti Bertl: Not a problem - I assume you'll do that ;p 1122151028 M * matti Bertl: As usual ;p 1122151028 M * matti :) 1122151029 M * Bertl matti: reg. tee, yes please :) 1122151035 M * Bertl *tea 1122151054 M * matti Let's see. 1122151061 M * matti Tetley or Lipton/ 1122151066 M * matti Hm/ 1122151069 M * matti ?// 1122151071 M * matti Ups. 1122151077 M * Bertl hmm, maybe Lipton today? 1122151096 M * matti OK. 1122151098 M * matti Sugar? 1122151109 M * Bertl no, thanks ... 1122151124 M * matti :) 1122151125 M * Bertl Doener: so Flat search :) 1122151133 M * bipsen Bertl: okay, just noticed you wre back from ZzZzZ ... ;-) 1122151148 A * Doener throws dice to see how well matti's tea will be ;) 1122151178 A * matti gives Bertl a cup of hot Lipton tea :) 1122151183 M * Bertl bipsen: can you upload the bind binary somewhere ... 1122151189 M * Bertl matti: thanks :] 1122151192 M * matti Bertl: Maybe some lemons? 1122151201 M * Bertl not in the morning :) 1122151210 M * matti :) 1122151216 M * bipsen Bertl: Regarding Bind .... The one I'm testing with is bind-9.2.4-2 1122151219 M * daniel_hozac Bertl: the problem is that capset() with CAP_SYS_RESOURCE gives EPERM. 1122151263 M * bipsen let me know if I shoukd try different stuff.... (even though compiling a new kernel on that old PC takes some time) 1122151290 A * matti gives Doener a cup of hot Lipton tea too :] 1122151323 M * Bertl bipsen: binary please .. I dont want to search/convert packages 1122151368 M * bipsen Bertl: You need the bind binary ?? 1122151464 M * bipsen Bertl: named reports 9.2.4 (when checking version) 1122151484 M * Bertl url? 1122151493 M * bipsen hang on 1122151520 M * Bertl btw, a static binary would be excellent ... 1122151765 M * bipsen Bertl: http://62.242.9.138/vsrv/named.gz 1122151785 M * bipsen it's an "off the shelf" binary, don't know if it's staticly linked 1122152288 M * Bertl hmm, no .. doesn't work for me ... 1122152324 M * bipsen probably needs some libs and so on, then... 1122152347 M * Bertl liblwres.so.1 => not found 1122152347 M * Bertl libdns.so.16 => not found 1122152347 M * Bertl libisccfg.so.0 => not found 1122152347 M * Bertl libcrypto.so.4 => not found 1122152347 M * Bertl libisccc.so.0 => not found 1122152350 M * Bertl libisc.so.7 => not found 1122152406 M * bipsen okay, that was a bit.... any other way, I can help ? Maybe running commands pr. your instructions on the system ? 1122152408 M * daniel_hozac i have a test case. 1122152489 M * daniel_hozac http://daniel.hozac.com/tmp/test-CAP_SYS_RESOURCE.c 1122152517 M * daniel_hozac (linux_setcaps copied verbatim from bind) 1122152531 M * Bertl okay, so that's equiv to the bind thing, right? 1122152549 M * daniel_hozac bind sets a few more caps, but CAP_SYS_RESOURCE is the problematic one. 1122152572 M * daniel_hozac the test case shows the same behaviour as bind. 1122152581 M * Bertl current: fffffeff 1122152581 M * Bertl new: 01000000 1122152585 M * Bertl and this is good? 1122152618 M * daniel_hozac right, that means it worked. 1122152666 M * Bertl okay, thanks a lot, will look into it after dinner ... 1122152809 M * Bertl SO is hungry .. so I have to fix that first ... 1122152846 M * bipsen Hmm... Think I need to do a minimum install of WBEL4, grab the RPM list, and use that one as a base-install.... right now I'm trying to restart named inside a vserver, and killing the running process doesn't seem to work... 1122152898 N * Bertl Bertl_oO 1122156112 Q * sannes Quit: agh 1122156407 Q * Snow-Man Remote host closed the connection 1122156421 J * Snow-Man ~sfrost@snowman.net 1122157651 N * Bertl_oO Bertl 1122157666 M * Bertl okay, back now ... 1122157803 M * Bertl hey Snow-Man! LTNS! 1122158073 J * matta ~matta@69.93.28.254 1122158102 M * matta greetings 1122158565 M * Bertl hey matta! LTNS! 1122158613 M * matta same! 1122158632 M * matta just a heads up might get some of my users on here... seems to be demand for at least experimenting 1122158636 M * matta I sent them here in a post 1122158646 M * matta http://www.unixshell.com/forum/showthread.php?p=1808 1122158658 M * matta just did a quick check... like 20 are using the old vserver kernel, so not bad 1122158788 M * Bertl i.c. well, you know we are working on vs2.0 :) 1122158822 M * matta yeah, but it's better than 1.9.4 isn't it? :) 1122158823 M * Bertl so did you test it yet? 1122158833 M * matta it boots, that's all I can say so far 1122158850 M * Bertl hehe with Xen? 1122158853 M * matta yep 1122158867 M * matta besides Makefile no rejects 1122158870 M * Bertl could you give the latest testme.sh a try? 1122158874 M * matta xen only does 2.6.11 for now 1122158883 M * matta so i could only do rc4 1122158885 M * matta yeah, one sec 1122158902 M * matta where is testme again? 1122158918 M * Bertl http://vserver.13thfloor.at/Stuff/SCRIPT/ 1122158941 M * Bertl we have a filesystem test now too .. but it requires an empty/available partition (will be formatted) 1122159002 M * matta does that relate to CoW links at all? 1122159020 M * matta i think that ngn were the 2 that were busters for me 1122159053 M * Bertl ngn is currently broken ... 1122159067 M * Bertl the cow patch is available but untested 1122159074 M * matta ok, where are the tools... I need chcontext 1122159096 M * Bertl http://www.13thfloor.at/~ensc/util-vserver/files/alpha/ 1122159123 M * matta ok 1122159127 M * matta http://www.13thfloor.at/~ensc/util-vserver/files/stable/util-vserver-0.30.tar.bz2 is no good? 1122159139 M * Bertl more than a year old (outdated) 1122159156 M * Bertl especially you need the copat version feature enabled for that to work 1122159163 M * Bertl *compat that is 1122159389 M * matta root@server [~]# sh testme.sh 1122159389 M * matta Linux-VServer Test [V0.13] Copyright (C) 2003-2005 H.Poetzl 1122159389 M * matta chcontext: vc_new_s_context(): Function not implemented 1122159389 M * matta chcontext failed! 1122159389 M * matta chbind: vc_set_ipv4root(): Function not implemented 1122159391 M * matta chbind failed! 1122159391 M * matta Linux 2.6.11.10-xenU-vs2.0-rc4 i686/0.30.208/0.30.208 [Ea] (0) 1122159393 M * matta VCI: 0002:0001 273 03000076 1122159393 M * matta ? 1122159401 M * matta is there something else that needs to be enabled? 1122159414 M * matta I had to add the vserver Kconfig to arch/xen/Kconfig 1122159417 M * matta but it seemed fine 1122159418 M * Bertl I expected something like that ... 1122159442 M * Bertl very likely the syscall is missing in your xen kernel 1122159459 M * Bertl do you have the xen patch at hand? 1122159567 M * matta ahhhh... ok 1122159582 M * matta in arch/xen/i386/kernel/entry.S 1122159585 M * matta I need to add 1122159591 M * matta - .long sys_ni_syscall /* sys_vserver */ 1122159591 M * matta + .long sys_vserver 1122159619 M * Bertl yep, that's it ... 1122159647 M * Bertl how is xen on x86_64 atm? 1122159702 M * matta works fine AFAIK 1122159707 M * matta intel has 3 people working on it 1122159760 M * matta i'm not sure if a 64-bit xen / host kernel can boot 32-bit guests... i think so though 1122159805 M * Bertl well, 64bit linux-vserver is no problem 1122159813 M * Bertl and it supports 32bit guests quite fine 1122159839 M * matta yeah, i know :) 1122159850 M * matta it's for different markets the two... 1122159872 M * Bertl yup 1122159884 M * matta my unixshell people wouldn't be happy in vserver 1122159893 M * matta they want to compile modules, do VPN, etc 1122159901 M * matta I know vserver can do a lot (like in the post, I love it!) 1122159910 M * matta it's more comparable to virtuozzo 1122159918 M * matta xen is more going against mainframe/vmware 1122159968 M * matta ie. you can run vserver under a xen vm 1122159997 M * Bertl btw, would be great if you could post a mail to the linux-vserver ML when you successfully tested a Xen kernel (as arch report) 1122160011 M * matta x86_64 Xen port. A port to Opteron/EM64T is already in progress and will support xen-x86_64 guest OSes with both 32 and 64 bit applications. 1122160027 M * matta ok, so looks like 32-bit guest won't be in 3.0 prolly 1122160045 M * matta but I guess a 64-bit kernel w/ a 100% 32-bit userland runs fine I heard 1122160131 M * matta the big thing is VT support in new Xeon/Opteron procs 1122160138 M * matta hardware virtualization 1122160142 M * matta no need for a software port.... 1122160146 M * matta will run windows, solaris, etc 1122160149 M * meebey good evening 1122160156 M * Bertl matta: in theory, yes :) 1122160158 M * meebey is vserver able to handle vlans? 1122160167 M * meebey or multiple gateways 1122160172 M * Bertl meebey: yes to both 1122160174 M * meebey virtual routing tables? 1122160185 M * matta Bertl: well, xen is backed by some big guys..... intel/amd included 1122160191 M * Bertl meebey: nope, networking is on the host 1122160207 M * matta they have it working using a Intel VT emulator 1122160211 M * Bertl matta: yeah, they have great marketing ... 1122160217 M * meebey Bertl: but could I use different default gateways with multiple nics? 1122160224 M * meebey Bertl: for vservers 1122160227 M * Bertl meebey: yes 1122160260 M * Bertl meebey: http://linux-vserver.org/Documentation 1122160271 M * Bertl http://archives.linux-vserver.org/200311/0470.html 1122160315 M * meebey thy 1122160354 M * matta root@server [~]# sh testme.sh 1122160354 M * matta Linux-VServer Test [V0.13] Copyright (C) 2003-2005 H.Poetzl 1122160354 M * matta chcontext is working. 1122160354 M * matta chbind is working. 1122160354 M * matta Linux 2.6.11.10-xenU-vs2.0-rc4 i686/0.30.208/0.30.208 [Ea] (0) 1122160355 M * matta VCI: 0002:0001 273 03000076 1122160355 M * matta --- 1122160357 M * matta [000]# succeeded. 1122160357 M * matta [001]# succeeded. 1122160359 M * matta [011]# succeeded. 1122160359 M * matta [031]# succeeded. 1122160361 M * matta [101]# succeeded. 1122160361 M * matta [102]# succeeded. 1122160361 M * meebey Bertl: what about one nic and multiple vlans on one wite? 1122160363 M * matta [201]# succeeded. 1122160363 M * matta [202]# succeeded. 1122160366 M * meebey Bertl: wire 1122160382 M * Bertl meebey: same as two nics .. vlans are separate interfaces 1122160404 M * Bertl matta: looks good := 1122160532 M * matta yep 1122160535 M * matta i should post? 1122160595 M * matta what is this fstest? 1122160604 M * matta the server runs lvm so I can create a test partition 1122160606 M * meebey Bertl: thanks for the info 1122160631 M * Bertl okay, then get the fs tools for reiser, xfs, ext2/3 and jfs installed (usertools) 1122160638 M * Bertl meebey: you're welcome 1122160670 M * Bertl and do something like: testfs.sh -t -x -D /dev/vgx/y -M /test 1122160671 M * matta installed already 1122160681 M * Bertl make sure that /test is an unused mountpoint 1122160696 M * matta does /test need to be just a directory or should it be mounted already? 1122160719 M * Bertl just a directory 1122160728 M * Bertl fielsystem format and mount will be done by the tool 1122160746 M * Bertl i.e. it will format the block device with all filesystems 1122160893 M * matta hrm.... shit 1122160907 M * matta normally my test vm's are fc3 so it has the rpm's for all that shit 1122160910 M * matta this is centos 3.5 1122160920 M * matta which doesn't have xfs/jfs I don't think 1122160927 M * matta can I edit the script to skip those 2? 1122160942 M * Bertl just specify -F some,file,systems 1122160973 M * matta -F is skip? 1122160993 M * Bertl no, the list of filesystems you want to test 1122161066 M * matta Linux-VServer FS Test [V0.06] Copyright (C) 2005 H.Poetzl 1122161066 M * matta Linux 2.6.11.10-xenU-vs2.0-rc4 i686/0.30.208 1122161066 M * matta VCI: 0002:0001 273 03000076 (ugid24) 1122161066 M * matta --- 1122161066 M * matta testing ext2 filesystem ... 1122161067 M * matta [000]. (ext2 format) 1122161067 M * matta xid related tests ... 1122161069 M * matta [001]. [002]* [011]. [012]. [014]. [015]. [019]. 1122161069 M * matta [020]. [021]. [022]. [023]. [024]. [025]. [026]. [027]* [028]. 1122161071 M * matta [033]. [034]. [035]. [037]* 1122161071 M * matta xattr related tests ... 1122161073 M * matta [101]. [102]. [103]. [104]. [106]. [108]. [109]. 1122161073 M * matta [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119]. 1122161075 M * matta [121]. [122]. [123]. [124]. [199]. 1122161075 M * matta --- 1122161077 M * matta testing ext3 filesystem ... 1122161077 M * matta [000]. (ext3 format) 1122161079 M * matta xid related tests ... 1122161079 M * matta [001]. EXT3-fs: cannot specify tagxid on remount 1122161081 M * matta [002]. [011]. [012]. [014]. [015]. [019]. 1122161081 M * matta [020]. EXT3-fs: cannot specify tagxid on remount 1122161083 M * matta [021]* [022]. EXT3-fs: cannot specify tagxid on remount 1122161083 M * matta [023]* [024]. [025]. [026]. [027]* [028]. 1122161085 M * matta [033]. [034]. [035]. [037]* 1122161085 M * matta xattr related tests ... 1122161087 M * matta [101]. [102]. [103]. [104]. [106]. [108]. [109]. 1122161087 M * matta [112]. [113]. [114]. [115]. [116]. [117]. [118]. [119]. 1122161089 M * matta [121]. [122]. [123]. [124]. [199]. 1122161109 M * matta what needs to be enabled for tagxid? in the config the UID24/GID24 is set 1122161138 M * Bertl well, you are on pre vs2.0-rc8.1 so it's kind of expected that a lot of tests fail 1122161144 M * matta oh 1122161146 M * matta damn 1122161148 M * Bertl we had a bunch of fixes there ... 1122161159 M * matta yeah, apparently 2.6.12 has a lot of changes for xen people 1122161171 M * matta so the stable brand (what I run) is only up to 2.6.11.10 1122161179 M * matta the * are failed tests? 1122161184 M * matta so it "sort of works" ? 1122161217 M * Bertl yeah, if you avoid the -t (terse) 1122161232 M * Bertl then it will use the expanded (well known) format 1122161243 M * Bertl (please don't flood it here :) 1122161279 M * matta ok 1122161283 M * matta I removed -t 1122161288 M * matta just want the failures? 1122161299 M * Bertl no, I see them in the terse format too :) 1122161306 M * matta or is it known that anything below rc8 is expected to fail 1122161319 M * matta EXT3-fs: cannot specify tagxid on remount 1122161319 M * matta [021]# failed. 1122161319 M * matta [022]# succeeded. 1122161319 M * matta EXT3-fs: cannot specify tagxid on remount 1122161319 M * matta [023]# failed. 1122161321 M * matta [024]# succeeded. 1122161321 M * matta [025]# succeeded. 1122161323 M * matta [026]# succeeded. 1122161323 M * matta write /vservers/file_1: [^^^^:....] 0 1122161325 M * matta write /vservers/file_2: [^^^^:..^.] 1 1122161325 M * matta write /vservers/file_3: [^^^^:..^.] 255 1122161327 M * matta [027]# failed. 1122161327 M * matta that doesn't look good 1122161336 M * matta so what this is saying is that 1122161342 M * matta if tagxid is enabled on boot it should work 1122161342 M * Bertl http://linux-vserver.org/ChangeLog26 1122161346 M * matta but not on remount 1122161367 M * matta # general xid tagging cleanup 1122161368 M * Bertl it says, that a) remount doesn't work, and b) xid protection is not active 1122161368 M * matta # check for tagxid (re)mount options 1122161370 M * matta ahhhh 1122161401 M * Bertl the xattr tests for ext2/3 were fine ... 1122161402 M * matta ok, so until xen updates to 2.6.12 this is about as good as it gets 1122161420 M * Bertl well, you could patch up to rc8.1 by hand I guess 1122161422 M * matta I expect trying to apply the 2.6.12-rc8 against 2.6.11 will have a lot of failures 1122161428 M * matta lots of changes in 2.6.12 1122161447 M * Bertl http://vserver.13thfloor.at/Experimental/FOR-2.0/ 1122161459 M * Bertl those are the changes since 1.9.5 1122161492 M * matta # VXC_SYSLOG virtual syslog support 1122161492 M * matta # VXC_QUOTA_CTL support added 1122161492 M * matta # VXF_INFO_HIDE support added 1122161493 M * matta # VXF_FAKE_INIT support added 1122161495 M * matta nice 1122161523 M * matta vroot device (initial support) 1122161525 M * matta that too 1122161574 M * Bertl yeah, except for shared quota (which isn't in the 2.4 stable releases either) we have everything 1.2.x had and a lot more ... 1122161631 M * matta i'll see how rc8 does against 2.6.11, but I bet it will be very messy 1122161640 M * matta no problem though.... 2.6.12 for xen will be avail soon 1122161640 M * Bertl no chance I'd say 1122161644 M * matta yeah, me too 1122161660 M * Bertl but as I said, you might be able to patch up with the FOR-2.0 patches 1122161662 M * matta lots of changes to kernel stuff, even if the code is the same... cleanups and such will break the patch 1122161826 M * matta [root@vm1 linux-2.6.11-xenU]# patch -p1 --dry-run