1138233748 J * ntrs__ ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com 1138233748 Q * ntrs_ Read error: Connection reset by peer 1138233956 J * ntrs_ ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com 1138233956 Q * ntrs__ Read error: Connection reset by peer 1138233958 P * stefani I'm Parting (the water) 1138235250 N * Bertl_oO Bertl 1138235255 M * Bertl back now ... 1138235268 M * Cru re bertl 1138235365 M * Bertl tx 1138235394 M * Bertl ebiederm: so how is it going? 1138236933 J * ntrs__ ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com 1138236942 Q * ntrs_ Read error: Connection reset by peer 1138237559 Q * zobel arion.oftc.net venus.oftc.net 1138237559 Q * aba arion.oftc.net venus.oftc.net 1138237630 J * zobel zobel@zobel.irc.ftbfs.de 1138237630 J * aba ~aba@eos.turmzimmer.net 1138237862 Q * gerrit Ping timeout: 480 seconds 1138238870 Q * mkhl Quit: 1138240557 J * samv_south ~samv@watts.utsl.gen.nz 1138240560 Q * samv_south Quit: 1138240873 M * ebiederm Bertl: slowly. 1138241066 M * Bertl better slowly than not at all ... 1138241226 M * ebiederm Building consensus is a lot harder work than writing code :) 1138241243 M * ebiederm The bane of control freaks everywhere! 1138241289 M * ebiederm I think I at least have my bug fixes pushed upstream. 1138241710 M * ebiederm Do you do much kernel cross compiling? 1138241928 Q * azazel Quit: Client exiting 1138241935 M * Bertl ebiederm: enough, why? 1138241963 M * ebiederm I haven't done much in a long time and to test that my code at least compiles I'm going to need to. 1138241975 M * ebiederm I was wondering if you had any tips. 1138241983 M * Bertl sure, what distro do you use? 1138242001 M * ebiederm Debian mostly. 1138242062 M * Bertl toolchains are there? 1138242078 M * Bertl I usually build them myself, because it's much easier 1138242096 M * Bertl (and I have a known/identical state for all archs) 1138242105 M * ebiederm right. Actually that is one of the nice things about debain. It has an easy sytem for building the cross compiler toos. 1138242134 M * Bertl well, I do that on mandrake ... but if the toolchains are there, it's quite easy ... 1138242186 M * Bertl my toolchains currently support: alpha, arm, cris, hppa, hppa64, i386, ia64, m68k, mips, mips64, ppc, ppc64, s390, sh, sh4, sparc, sparc64, v850, x86_64 1138242186 M * ebiederm Mostly I was wondering if there were any gotchas on building any of the architectures etc. 1138242195 M * ebiederm Cool. 1138242204 M * ebiederm I'm not quite that diverse! 1138242210 M * Bertl plus a view variations like shbe and k6 1138242228 M * Bertl ah, forgot s390x and mipsel too :) 1138242231 M * ebiederm To veryify my could I should probably aim at that though. 1138242259 M * ebiederm How long does it take to build everything? 1138242273 M * ebiederm i.e. all of toolchains? 1138242284 M * Bertl well, if you want a common (same version) toolchain, it takes about 6 hours on a moderate machine 1138242307 M * Bertl I'm not using crosstools because I do not need the libc part 1138242313 M * Bertl http://vserver.13thfloor.at/Stuff/Cross/howto.info 1138242319 M * ebiederm Thanks. 1138242347 M * Bertl let me upload the latest gcc/binutil sets, I guess you can convert and reuse rpms, yes? 1138242359 M * Bertl (i.e. source rpms) 1138242360 M * ebiederm Sure not a problem. 1138242796 M * ebiederm I'm currently finding it funny that there is more similarity accross architectures for the same error message (on how to identify a task) then there is within the same file! 1138242816 M * Bertl heh, copy & paste 1138242845 M * Bertl btw, the #1 source for bugs too 1138242994 M * Bertl okay, upload will take a few minutes, binutils and 4.0.2 gcc are already there 1138242995 M * Bertl http://vserver.13thfloor.at/Stuff/Cross/SRPMS/ 1138243008 M * Bertl 3.4.5 and 3.3.6 gcc incoming ... 1138243037 M * ebiederm Thanks. 1138243086 M * Bertl np, I will also give you a short script fragment to build them (i.e. getting the archs right) 1138243100 M * Bertl okay, all are uploaded now 1138243180 M * ebiederm I will grab them in a bit. I will see how many builds I can run while I am sleeping. 1138243346 M * Bertl http://vserver.13thfloor.at/Stuff/Cross/SRPMS/build.info 1138243374 M * Bertl the karch is not required here, but you will need that to map toolchain arch to kernel arch 1138243394 M * Bertl (of course, you have to adapt it for debian) 1138243397 M * ebiederm Ok that makes sense. 1138243430 M * Bertl for recent kernels we probably need ppc* -> powerpc too 1138243594 M * Bertl ah, on gcc 4.0.2 some sh* variants do not build 1138243617 M * Bertl (according to the gcc folks it will be fixed sometimes in head) 1138243655 M * Bertl I have the best results with the 3.3.6 gcc (that's why it is still there) but the 4.0.2 lists more warnings 1138243718 M * ebiederm Which is faster 3.3.6 or 4.0.2? 1138243736 M * Bertl when compiling the kernel? definitely 3.3.6 1138243741 M * ebiederm At the moment I'm after the quick does it compile test to catch typos. 1138243749 M * ebiederm Ok. What I suspected thanks. 1138243764 M * Bertl there is a feature to 'optimize' 4.0.2 but that is broken for cross compiles :) 1138243771 M * ebiederm There are days I'm almost ready to switch to gcc 2.95. 1138243783 A * ebiederm laughs 1138243794 M * Bertl I'm very satisfied with the 3.3.6, I can recommend it 1138243851 M * ebiederm The last time I updated my tools 3.2.3 was the latest and greatest! 1138243891 M * Bertl had a few troubles with 3.1 and 3.2 ... 1138244156 M * ebiederm It takes a while to stabalize a compiler. 1138244278 M * ebiederm I've debugged a few compilers problems and it can get nasty. 1138244354 M * ebiederm A bug in one pass can sometimes go through several passes before it gets caught. Or two passes can work together to generate code you never would have thought would have worked. 1138245517 A * ebiederm must remember to add an is_init_task function..... 1138246409 J * gerrit ~gerrit@c-24-22-19-162.hsd1.or.comcast.net 1138246687 M * Bertl wb gerrit! 1138247267 J * Smutje_ ~Smutje@xdsl-87-78-18-223.netcologne.de 1138247424 Q * Smutje Ping timeout: 480 seconds 1138249913 M * ebiederm Silly question, does any one ever run vservers from a user mode linux kernel? 1138249925 M * Bertl yes 1138249935 M * Bertl it works quite fine there ... 1138249996 M * ebiederm Is that mostly a development platform? Or is there a practical use I haven't thought of? 1138249997 M * Bertl (well, at least it did last time I checked :) 1138250013 M * Bertl no, for development I use QEMU 1138250034 M * Bertl practical use is similar to Xen + vserver, i.e. have different kernels 1138250135 M * ebiederm So much of the recent development I have done is low-level code that requires the real hardware I haven't paid much attention to these other platforms. 1138250161 J * marl_ ~matt@albacom.plus.com 1138250260 M * Bertl ebiederm: well, linux-vserver is maybe 2-5% platform/arch dependant code 1138250316 M * ebiederm I had that feeling. And where most of my development has been about 90% chipset dependent code.... You develop a different set of tricks :) 1138250372 M * Bertl well, I did some hardware related development too .. 1138250389 M * ebiederm Hopefully we can start getting the arch dependent code merged. 1138250404 M * Bertl that would be pretty cool 1138250421 J * marl__ ~matt@84.92.193.226 1138250424 M * Bertl (not that I have seen it yet, but arch dependent stuff is always ugly 1138250471 M * ebiederm Well I got a patch to fix the alpha getxpid so it is at least correct now. 1138250492 M * Bertl great! you saw my 'solution' for the getxpid? 1138250505 M * ebiederm Yes. I liked it but fixing the assembly was easy enough. 1138250535 M * Bertl well, okay, just might give issues (i.e. arch dependant code) again if you change something 1138250552 M * ebiederm Bertl: I know. 1138250562 Q * marl Ping timeout: 480 seconds 1138250598 M * Bertl if possible, I'd prefer alpha to move to C code there 1138250635 M * ebiederm I think I can get away with like 2 additional instructions, or possibly I will just break alpha altogether. 1138250679 Q * marl_ Ping timeout: 480 seconds 1138250690 M * ebiederm Basically at some point there needs to come a kpid (kernel pid) and upid (user pid) separation and the patch for that is going to deliberately break the compile for just about everything. 1138250716 M * Bertl where kpid is the task struct, no? 1138250761 M * ebiederm kpid can't be the task struct. Logically kpid is (process id space, pid). 1138250784 M * Bertl hmm ... what do we need that for? 1138250839 M * ebiederm There are a small but signficant number of places in the kernel that send signals to processes without necessarily being in the same context. 1138250851 M * ebiederm fown_struct from fcntl.c is one example. 1138250860 M * Bertl so? there the task would be sufficient, no? 1138250882 M * ebiederm spawnpid from drivers/char/keyboard.c and drivers/char/vt_ioctl.c 1138250902 M * Bertl no need for kernel space indirection, or am I missing soemthing? 1138250908 M * ebiederm Besides having the wrong lifetime rules, there are not task_structs for process groups. 1138250940 M * Bertl hmm, okay, the process groups are a good argument 1138250985 M * ebiederm The other is that if you look at spawnpid you will notice it may never be cleared once set until the kernel reboots. 1138251005 M * ebiederm That tends to be a problem if we hold onto the task_struct. 1138251063 M * ebiederm At least I think holding onto the task_struct of a process indefinitely is a bad thing. 1138251089 M * Bertl well, keeping a pid which 'might' not be there is better? 1138251109 M * Bertl (or even worse, which has been replaced :) 1138251169 M * ebiederm It is only better in the sense that it is a well understood problem. 1138251210 M * ebiederm I have done the proof of concept for implementing weak pid references. Which will actually solve the problem. 1138251233 M * ebiederm Basically the idea is that you have a list of pid references and when the pid goes away you clear the pid. 1138251313 M * ebiederm Although I probably want to look at just how bad holding a reference to a task_struct really is. 1138251398 M * ebiederm Any technique we pick will require breaking all of the pid interfaces so we are certain everything was properly converted. 1138251415 M * ebiederm Every patch I know of has rare cases where something is silently missed. 1138251464 M * Bertl well, once we decided for a good solution, we can test the hell out of it 1138251484 M * ebiederm Bertl: That should help too. 1138251508 M * ebiederm But it is only likely to catch the common things. 1138251547 M * ebiederm I don't want something like current->pid that years later people still don't know how to use correctly. 1138251603 M * ebiederm *yeah* I have completed my first pass through the archtectures cleaning up task name printing. 1138251617 M * Bertl congrats! 1138251629 M * ebiederm That was the easy grep looking for ->comm. 1138251646 M * ebiederm The next one looks for ->pid and will catch a few more cases. 1138251691 M * ebiederm Currently my global patch stands at: 84 files changed, 413 insertions(+), 413 deletions(-) 1138251740 M * ebiederm Wow someone moved ll_rw_block.c from drivers/block to just block. 1138252042 M * jkl hey bertl! 1138252056 M * Bertl hey jkl! 1138252062 M * jkl whats up? 1138252097 M * Bertl well, not much, basically cleanups and preparations 1138252114 M * jkl ah ha 1138252139 M * jkl i have a little problem 1138252170 M * jkl somehow i have broken emerge on all my vservers :( 1138252170 M * Bertl let's hear .. 1138252173 M * jkl very saddening 1138252176 M * jkl hehe 1138252194 M * Bertl hmm .. how did dad happen? 1138252228 M * jkl not sure! it's been awhile since ive done emerge -p world on any of thelm 1138252233 M * jkl *them 1138252251 M * jkl now they all say 'All ebuilds that could satisfy ">=sys-apps/baselayout-1.11.14" have been masked." 1138252270 M * Bertl probably best is to wait for hollow, who will get up in a few hours 1138252284 M * jkl yes you are probably right 1138252301 M * jkl would you think that a vserver would need sys-fs/udev though? 1138252311 M * jkl that's what's depending on it 1138252314 M * Bertl no, definitely not 1138252320 M * jkl hmm 1138252338 M * jkl probably the profile update screwed things then 1138252406 M * Bertl there is a special guest profile, so much do I know 1138252558 M * ebiederm I just ran into the strangest driver. drivers/macintosh/apm_emu.c 1138252599 M * ebiederm It amazes me that anyone would emulate APM on a machine that didn't have it. 1138252704 M * Aiken jkl could it be baselayout-vserver you are looking for? 1138252744 M * jkl I have vserver in my use flags 1138252768 M * jkl udev depends on baselayout, not vserver-baselayout 1138252779 M * jkl i shouldnt be needing udev in a vserver 1138252797 M * jkl i dunno why emerge -p world selects udev 1138252835 M * jkl do you know where the profile is kept 1138252854 M * Bertl no idea, sorry, didn't make it to gentoo yet 1138252861 M * jkl yeah, its okay 1138252870 M * Aiken mayeb a dep problem? baselayout and baselayout-vserver both provide virtual/baselayout 1138252891 M * jkl yeah it's def a conflict 1138252915 M * Aiken I am just looking at a gentoo image I sometimes chroot into. I don't run gentoo on any machine 1138252926 M * jkl i really just want to update this guy and then clone it 1138253893 Q * vrwttnmtu Quit: Leaving 1138254199 Q * marl__ Ping timeout: 480 seconds 1138255350 Q * zobel arion.oftc.net venus.oftc.net 1138255350 Q * aba arion.oftc.net venus.oftc.net 1138255419 J * zobel zobel@zobel.irc.ftbfs.de 1138255419 J * aba ~aba@eos.turmzimmer.net 1138255707 M * ebiederm *yeah* first pass cleanup up task name printing is now complete all of the way through the kernel. 1138255872 M * Bertl congrats again! 1138256003 M * Hollow jkl: do you suffer from http://bugs.gentoo.org/show_bug.cgi?id=105616 ? 1138256046 M * Bertl morning Hollow! 1138256052 M * Hollow morning Bertl :) 1138256878 M * Hollow ok, off to school now, cu later 1138258349 M * FaUl morning all 1138258381 M * jkl Hollow: yes 1138258451 M * jkl i guess i missed him 1138258452 M * jkl shucks 1138258464 M * Bertl guess so ... 1138258485 M * jkl that post hasnt helped me at all 1138258494 M * jkl but they have my problem 1138258507 M * Bertl probably he would have had an answer ... 1138258547 M * jkl i think i am going to take this box down in the meantime 1138258565 M * jkl its is behaving strangely i will run memtest86 on it for awhile 1138258580 M * Bertl can't hurt to verify the hardware 1138258590 M * Bertl (but looks for rootkits or similar too) 1138258631 M * jkl i have tons of these: 1138258631 M * jkl Jan 25 21:29:49 [smartd] Device: /dev/hdb, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 248 to 249_ 1138258631 M * jkl Jan 25 21:29:49 [smartd] Device: /dev/hdb, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 248 to 249_ 1138258634 M * jkl oops 1138259326 M * Bertl seems your disk is dying ... 1138259620 N * ebiederm ebiedermZz 1138259644 M * Bertl night ebiedermZz! 1138259660 M * ebiedermZz night. 1138259719 Q * _are_ Ping timeout: 480 seconds 1138260832 Q * jkl Ping timeout: 480 seconds 1138262589 Q * mikmak Quit: [BX] You can breathe without BitchX, but I wouldn't recommend it 1138263799 J * cohan ~martin@p54AD1150.dip0.t-ipconnect.de 1138263849 M * Bertl morning cohan! 1138263884 M * cohan ;) you are never asleep? 1138264092 M * Bertl well, I'm almost off to bed, just waiting for a few test results 1138264124 M * daniel_hozac Bertl: sorry, i didn't get around to testing that patch last night (fell asleep). 1138264131 M * daniel_hozac i'll test it today. 1138264142 M * Bertl daniel_hozac: which one? 1138264148 M * daniel_hozac tagid 1138264152 M * cohan some at least little funny comment from diff: 1138264158 M * cohan File .../dev/zero is a character special file while file /dev/zero is a character special file 1138264169 M * Bertl daniel_hozac: well, you should read it, it's already tested :) 1138264191 M * Bertl daniel_hozac: i.e. check for possible issues and/or typos ... 1138264207 M * daniel_hozac Bertl: heh, ok. i did read through it, and all the changes look fine to me... 1138264226 M * Bertl btw, I get a feeling that time is very relative in 2.6.15 .. 1138264234 M * Bertl real 7m32.416s 1138264234 M * Bertl user 1m49.307s 1138264234 M * Bertl sys 11m1.124s 1138264242 M * daniel_hozac hahaha 1138264245 M * daniel_hozac that's great. 1138264260 M * Bertl and even better, it's reproduceable ... 1138264282 M * Bertl maybe some SMP effect, not sure yet ... 1138264285 M * cohan hyperthreading SMP? 1138264299 M * daniel_hozac http://cvs.fedora.redhat.com/viewcvs.cgi/rpms/kernel/FC-4/linux-2.6-posix-timers-sched_time-accumulation.patch?rev=1.1&sortby=date&view=auto ? 1138264340 M * cohan at least if real time is what i _think_ it should be this kind of measurements are very common in SMP or distributed environments 1138264443 M * Bertl interesting .... 1138264449 M * daniel_hozac it would seem odd to have one process use both processors though. 1138264468 M * Bertl it's a script which does heavy forking and such ... 1138264495 M * cohan and even threads could be shared thru cpus, depending on the used thread model 1138264539 M * Bertl okay, granted so we should assume the following equation holds: 1138264556 M * Bertl real*CPU >= sys + user 1138264607 M * Bertl and probably real*cpu ~ sys+user+idle 1138264641 M * cohan if all aspects of speedstep, snooze et al are considered correctly by the counting/measuring algos, i'd agree 1138264681 M * cohan face it, time IS relative in recent information processing systems ;) 1138264721 M * cohan sometimes i even doubt causality 1138264811 M * Bertl are you moving at the speed of light? 1138264823 M * SiD3WiNDR who isn't 1138264835 M * cohan used to cross light speed barrier... since then, my life's a mess ;) 1138264882 M * Bertl well, that explains ... ahem, will have had explained ... 1138264913 M * daniel_hozac haha. 1138264913 M * SiD3WiNDR :) 1138264951 M * cohan ;) do you remember that nice passage in the hitchhiker, where the grammar for time travellers is explained? 1138265015 Q * shedi Quit: Leaving 1138265194 M * Bertl okay, enough work for me for today ... off to bed ... back later 1138265202 M * Bertl have fun everyone! 1138265211 N * Bertl Bertl_zZ 1138266469 Q * Aiken Ping timeout: 480 seconds 1138266826 Q * click Ping timeout: 480 seconds 1138267464 J * prae ~prae@ezoffice.mandriva.com 1138267485 Q * mnemoc Ping timeout: 480 seconds 1138267549 J * jkl eric@c-67-173-248-142.hsd1.co.comcast.net 1138267844 J * marl ~matt@84.92.193.226 1138268513 M * cohan any experiences with accessfs and vservers? 1138268883 A * SiD3WiNDR still wondering in what timezone Bertl_zZ really is 1138269325 M * cohan vampire masquerade? ;) 1138269458 M * Hollow jkl: still around? 1138269669 J * shedi ~siggi@tolvudeild-205.lhi.is 1138269705 M * Hollow hm, accessfs sounds interesting 1138270323 M * cohan yes, and it is "requested" by a special type of "customer" 1138270348 M * cohan did not look into it too deep yet, but i can imagine its not that easy to combine it with vserver 1138270448 M * yang I am getting this error on vserver (I cannot set clock) - hwclock is unable to get I/O port access: the iopl(3) call failed. 1138270579 M * cohan inside the vserver? i believe you cannot set the time within 1138270628 M * cohan time should be kept accurate by the host - but you can easily adjust the timezone of each individual guest 1138270652 M * yang ah yes, maybe the timezone is wrong 1138270661 M * yang becouse it delays for 1h from my host 1138270689 M * cohan sounds like timezone, yes ;) 1138271983 J * pusling pusling@195.215.29.124 1138272108 J * bool ~weechat@eos.rbi.informatik.uni-frankfurt.de 1138272256 J * YBN ~lenhart@eos.rbi.informatik.uni-frankfurt.de 1138272287 Q * YBN Remote host closed the connection 1138272296 P * bool 1138272457 J * bool ~weechat@eos.rbi.informatik.uni-frankfurt.de 1138272478 P * bool WeeChat 0.1.8-cvs 1138272946 M * cohan beecrypt for vhashify... hm, in beecrypt part of some larger software package? 1138272971 M * cohan is beecrypt part of, thats what i wanted to ask 1138273300 M * cohan the first example for creation at: http://linux-vserver.org/alpha+util-vserver 1138273311 M * cohan says: Its hostname will be vs.foo.org and the name shown by tools like vps or vserver-stat be bar 1138273319 M * cohan where does the *bar* come from? 1138273419 M * schellh i guess some error normally its foo.bar 1138273444 M * schellh comes from fubar 1138273451 M * schellh do you know this term ? 1138273455 M * cohan but the name shown by the tools is foo, not bar, right? 1138273470 M * cohan yes, i know about all the foobar/fubar examples ;) 1138273495 M * schellh well i believe the vservers name is the hostname normally ? 1138273509 M * schellh so i guess it should gome out to cs 1138273512 M * schellh vs 1138273528 M * cohan internally yes, but on the host its just an arbitrary name you gave your vserver, i thought 1138273558 M * schellh sorry i am not that much into it. we should wait for someone who knoes this *g 1138273831 M * SiD3WiNDR the name on the host is what /etc/vservers/thenamehere is called 1138273835 M * SiD3WiNDR which you chose on "vserver build blah" 1138273843 M * SiD3WiNDR vserver blah build, even 1138273875 M * cohan i know, i just wondered about that "bar" reference in the example 1138274375 Q * marl arion.oftc.net kinetic.oftc.net 1138274375 Q * kilian arion.oftc.net kinetic.oftc.net 1138274375 Q * matti arion.oftc.net kinetic.oftc.net 1138274375 Q * Psy0rz_ arion.oftc.net kinetic.oftc.net 1138274470 J * marl ~matt@84.92.193.226 1138274470 J * kilian kk@projects.verfaction.de 1138274470 J * matti matti@linux.gentoo.pl 1138274470 J * Psy0rz_ ~psy0rz@lounge.datux.nl 1138274701 M * cohan is there an example vserver-build.copy anywhere? 1138275175 Q * harry Ping timeout: 480 seconds 1138276590 J * harry ~harry@d515321D1.access.telenet.be 1138276998 J * jayeola ~jayeola@host-87-74-46-211.bulldogdsl.com 1138277888 M * cohan thats odd - when i say use: vserver vserv2 start 1138277912 M * cohan it immediatly chickens out with: 1138277943 M * cohan No command given; use '--help' for more information\nAn error occured while executing the vserver startup sequence; when there are no other messages, it is very likely that the init-script() failed 1138277958 M * cohan but if i use: 1138277959 M * cohan strace -f vserver vserv2 start 1138277998 M * cohan it does not finish execution, and does not show the above message at all 1138278502 J * mnemoc ~amery@200.75.27.75 1138279487 M * romke matti: I've got Ubuntu CDs delivered today, wanna some? 1138280100 M * cohan what do i miss to start a vserver via the vserver command? it seems that chcontext or another sub-program gets no parameters 1138280136 M * cohan i made a skeleton, filled its vdir/ with my favourite guest image, then i use 1138280146 M * cohan vserver vserv2 start 1138280176 M * cohan and it does not work - is there a magic file, a place i tell it to launch guests init, whatever, i miss? 1138280656 M * blizz hi ho 1138281125 M * blizz Hollow, you alive? what's the vhelper script in vserver-utils? i guess i need it in order to make the guest not reboot the host.. :P 1138281224 M * Hollow a guest should never reboot the host... there is no helper app currently 1138281229 M * blizz mh 1138281230 M * blizz thats trange 1138281232 M * Hollow i.e. reboot does not work 1138281233 M * blizz i do vserver start foo 1138281236 M * blizz then i do vserver enter foo 1138281250 M * blizz when i enter reboot now, the ssh connection to the host stalls 1138281256 M * blizz same happens after entering vserver stop foo 1138281316 M * Hollow strange, never had such an error.. 1138281324 M * Hollow maybe a configuration error? 1138281332 M * Hollow of ips, or sshd or whatever 1138281422 M * blizz Failed to open lockfile: No such file or directory 1138281439 M * blizz that happens when i try to start it again after having had to reboot the machine manually ;) 1138281451 M * blizz i guess i did something wrong, but i dont know what.. 1138281600 M * blizz capabilities are installed 1138281686 M * Hollow blizz: hm, which version of vserver-utils? 1138281695 M * blizz everything bloody edge 1138281695 M * blizz ;) 1138281729 A * Hollow shrugs 1138281735 M * Hollow never saw sshd dissapear on the host 1138281749 M * blizz i dont know if it is only ssh or the whole box 1138281753 M * blizz maybe i can check logs, wait a sec 1138281790 M * blizz Jan 26 00:09:30 anarchy agetty[2211]: vc/1: read: Success 1138281791 M * blizz Jan 26 00:12:32 anarchy dhcpd: receive_packet failed on eth0: Network is down 1138281796 M * blizz 3 times 1138281806 M * blizz thats the amount of host failures i had.. ;) 1138281810 M * Hollow seems like something takes down your network 1138281815 M * blizz mhh 1138281838 M * blizz default caps should beo k too, right? 1138281852 M * blizz AND after loki told me yesterday, i included linux capability system into the kernel *cough* 1138281864 M * Hollow yep.. and i doubt vserver-utils removes the network link, because we do not handle this at all 1138281887 M * cohan blizz: this is only necessary when you compile with some exotic "enable-security" 1138281903 M * cohan in default kernel config, linux caps are included 1138282061 Q * Hollow Remote host closed the connection 1138282178 M * blizz i have a theory.. 1138282189 M * blizz well, the guest system doesnt get a particular ip adress 1138282200 M * cohan hollow just quit, wait till he's back 1138282208 M * blizz yes sir :) 1138282214 M * cohan just your interface is brought down? 1138282221 M * blizz seems like 1138282232 M * blizz i had to walk over and reboot the router itself manually by invoking acpid by pressin the big red button.. 1138282309 J * Hollow ~hollow@home.xnull.de 1138282347 M * blizz "Failed to open lockfile: No such file or directory" thats strange.. lockfile exists 1138282365 M * blizz what is it good for anyway? 1138282469 M * Hollow to prevent two starts of the same vserver 1138282514 M * cohan btw, ignore my complains from about an hour ago about not starting vservers - something went wrong with "initstyle" 1138282861 M * blizz well okaay.. 1138282872 M * Hollow sorry, was on the phone 1138282885 M * blizz entering ifconfig eth0 inet apparently changed the host's ip address 1138282886 M * Hollow blizz: check if /var/lock/vservers exists 1138282898 M * Hollow in the guest? 1138282899 M * cohan is minit a special, vserver-guest-specific init-replacement? 1138282915 M * blizz Hollow, yep 1138282918 M * Hollow no, iirc it's an init replcement by the author of dietlibc 1138282924 M * cohan ah, okay, thx 1138282940 M * blizz it doenst 1138282949 M * cohan dönst? 1138282957 M * Hollow end dönst 1138282957 M * blizz doesnt :) 1138282959 M * SNy Dönertier 1138282962 M * Hollow gg 1138282964 M * cohan lol 1138282966 M * blizz ;) 1138282972 M * blizz im a poor utf8 bastard.. 1138282982 M * blizz and i even misconfigured it 1138282993 M * blizz but ssh + screen + irssi is evil anyway :) 1138282998 M * SNy no way 1138283005 M * SNy it's awesome 1138283008 M * cohan well, after i now managed to launch a vserver with default-util-vserver, i'll have something dönerlike to eat now ;) 1138283008 M * SNy ;p 1138283011 M * blizz sure, but in terms of utf8 :) 1138283021 M * blizz guten appetit ;) 1138283034 M * SNy "something dönerlike" 1138283039 M * SNy that actually sounds pretty awful 1138283094 M * cohan perhaps i find some "other green meet"? ;) 1138283098 M * SNy hrhr 1138283131 M * blizz Hollow, i dont even know if i did everything right to get a vserver running.. but generally i copied the config to my "foo" folder, modified initstyle and id, extracted everything required to /vservers/foo, replaced mtab and fstab and ran it.. 1138283165 M * SNy see, there's your mistake, it should be named "phoo" 1138283168 M * Hollow which init style do you use? 1138283171 M * blizz sysvinit 1138283175 M * SNy j/k 1138283175 M * blizz crux' default 1138283180 M * Hollow hm, ok 1138283188 M * Hollow just trying to reproduce it 1138283205 M * blizz thanks id advance 1138283206 M * blizz in 1138283224 M * Hollow do you use vserver-utils with diet? 1138283476 M * blizz jup 1138283482 M * blizz well i think so 1138283486 M * blizz dont know if it found dietlibc *checking* 1138283620 M * Hollow zeus ~ # vserver enter test 1138283620 M * Hollow localhost / # ifconfig 1138283621 M * Hollow Warning: cannot open /proc/net/dev (No such file or directory). Limited output. 1138283621 M * Hollow localhost / # ifconfig eth0 inet 1.2.3.4 1138283621 M * Hollow SIOCSIFADDR: Cannot assign requested address 1138283622 M * Hollow SIOCSIFFLAGS: Cannot assign requested address 1138284570 J * mkhl ~mkhl@200-148-40-151.dsl.telesp.net.br 1138284588 M * blizz hmm 1138284852 M * blizz maybe i got the wrong proc mounted? 1138284899 M * Hollow there is only one procfs 1138284960 M * blizz hum 1138285046 M * blizz so what did i do wrong? :/ 1138285598 M * yang I got problem with Memory 1138285603 M * yang there are 2x512mb inside but free shows only 960MB 1138285609 M * yang had the same problem before with 2x 256, showed 380MB 1138285619 M * yang the BIOS shows 1024 MB ... 1138285857 M * cohan onboard vga with shared ram? 1138285874 Q * gerrit Ping timeout: 480 seconds 1138286061 M * yang its a server 1138286073 M * yang with an integrated vga card 1138286094 M * yang must be bugged memory slot 1138286123 M * cohan no, its shared ram for the integrated vga card, it "grabs" 64 MB 1138286141 M * cohan perhaps you can reduce that memory in the bios as well 1138286159 M * cohan at least it would be very unusual reports for a "bugged memory slot", 1138286182 M * cohan furthermore, if the bios reports the GB, and the post succeeded, you can almost outrule "physical" problems 1138286254 M * yang but 1024 - 906 = 118Mb 1138286286 M * schellh maybe its hotplug pci ? this eats alot ram 1138286297 M * yang hotplug? 1138286310 M * yang i think there are no pci cards being used there 1138286314 Q * shedi Ping timeout: 480 seconds 1138286315 M * yang no there arent 1138286317 M * schellh ok 1138286389 M * yang maybe i should check with some memory program checker 1138286408 M * yang did any of you ever used that? 1138286497 M * cohan yang: you said 960 MB in the post before... and 960+64=1024 1138286567 M * cohan and i suspect when you had 2x256, it was 480+32=512 (instead of your posted 380) 1138286777 M * yang cohan: I have 2x512MB inside ... and its Mem: 906268 = 885MB 1138286811 M * yang when i had 2x 256, it showed me different amount of ram on every boot 1138286860 M * cohan okay, sorry for misinterpreeting, it just summed up so nicely ;) 1138286913 M * yang yeah... 1138287226 M * cohan hm, any reasons why the pushd in util-vserver/vserver.functions works different then when invoked directly from the shell? (it cannot push a directory which is a dual symlink, but it works when doing so on the bash prompt) 1138287515 M * daniel_hozac does it say "pushd: cannot push a directory which is a dual symlink" or is that your interpretation? 1138287648 Q * prae Quit: Execute Order 69 ! 1138287802 J * Guest1786 ~michal@www.rsbac.org 1138287802 M * cohan it says: ...line 647: push: /etc/vservers/phoenix/vdir: No such file or directory, 1138287812 N * Guest1786 michal_ 1138287815 M * cohan whereas popd /etc/vservers/phoenix/vdir; works 1138287867 M * daniel_hozac popd doesn't accept path arguments, AFAIK. 1138287908 M * cohan sorry, pushd 1138287919 M * cohan second line was no cut'n'paste, but typed manually 1138288089 Q * jayeola Quit: brb 1138288141 M * cohan (its line 646 in the virgin version, i just added an echo for debugging, thats why its line 647 in my paste) 1138288204 J * Viper0482 ~Viper0482@p5497503B.dip.t-dialin.net 1138288264 M * cohan okay, got the error 1138288274 M * yang Is there a log file, of how many times the vserver has been restarted and when? 1138288349 M * Hollow yang: last reboot 1138288352 J * gerrit ~gerrit@bi01p1.co.us.ibm.com 1138288386 M * Hollow but dunni if it's accurate all the time 1138288412 M * Hollow hm.. 1138288419 M * yang Hollow: that is just valid for host 1138288424 M * yang i was wondering for guest 1138288424 M * Hollow tbh i don't have an entry in my guests, so probably forget it ;) 1138288448 M * cohan with our old (legacy-based) scripts we have an extra log/ dir per vserver, where all host-induced vserver activity is logged 1138288497 J * shedi ~siggi@tolvudeild-205.lhi.is 1138288498 M * cohan "our old" refers to personal ones we use over here for our "hosting", not publicly accessable and horribly outdated 1138288713 M * cohan daniel_hozac: just if you are curious: i used relative symlink from /vservers ' point of view, 1138288736 M * cohan so in /vservers there was a link phoenix->../opt/cell01/phoenix 1138288776 M * cohan which for whatever reason works even when walking the .defaults-path as long as not within the vserver-scripts 1138289195 M * daniel_hozac and an absolute link solved the problem? 1138289331 M * cohan yes - seems that .. is interpreted differntly not only depending on your working dir (and whether its equal to it's pwd -P version), but sth else 1138289367 J * liquid3649_ ~Viper0482@p54977A08.dip.t-dialin.net 1138289809 Q * Viper0482 Ping timeout: 480 seconds 1138290025 J * ComplexMind ~ComplexHo@cpc1-brig3-6-0-cust194.brig.cable.ntl.com 1138290081 M * daniel_hozac cohan: that sounds really odd, should work fine IMHO. 1138290193 M * cohan it's in the deepths of bash, i believe - should be easy to reproduce this effect, though 1138290377 M * daniel_hozac i can't see it being bash's problem really, unless it does some weird symlink handling on its own. 1138290720 J * vrwttnmtu ~eryktyktu@82-69-161-137.dsl.in-addr.zen.co.uk 1138290733 M * Falle Good morning folks 1138290755 M * Falle Can someone tell me if kernel patch 1.2.10 supports vshelper? 1138290799 M * Falle im following some howto on getting it to work and it says that its not supported in sysctl? 1138290893 M * Falle The vshelper script is used to correctly stop and restart virtual servers. You have to tell the kernel where the vshelper script is located. 1138290896 M * Falle # echo 'kernel.vshelper = /usr/lib/util-vserver/vshelper' >> /etc/sysctl.conf ; sysctl -p 1138291030 M * jkl Hollow: you around? 1138291083 M * Falle hmm, my bad. I'm too morningdizy.. entered it in the wrong server :/ 1138291480 J * Smutje ~Smutje@xdsl-87-78-62-181.netcologne.de 1138291589 Q * Smutje_ Ping timeout: 480 seconds 1138291641 J * Johnnie ~jdlewis@dynamic-acs-24-154-53-16.zoominternet.net 1138292084 J * _are_ ~are@62.112.159.81 1138292308 M * cohan Step-by-Step+Guide+2.6 says in Section: Chaning the vserver base path: 1138292374 M * cohan The first part is easy. /etc/vservers/.defaults/vdirbase is a symlink to the desired vserver base directory, we just need to change it. (It works this way if you have not enabled CONFIG_VSERVER_LEGACY in the kernel config. Otherwise you have to change the location in /etc/vservers/util-vserver-vars) 1138292399 M * daniel_hozac the kernel config has nothing to do with it. 1138292406 M * cohan thats what i thought 1138292407 M * daniel_hozac and that path is wrong. 1138292420 M * daniel_hozac (util-vserver-vars is in $(pkglibdir) 1138292437 Q * baggins Read error: Connection reset by peer 1138292449 A * daniel_hozac wishes the wiki had an annotate feature. 1138292467 M * cohan well, Bertl adds a note suggesting rebuilding the utils anyway (with ./configure --with-vrootdir) 1138292558 M * cohan better said, he already added the note - but anyway, is it save (when using utils 0.30.210) to disable CONFIG_VSERVER_LEGACY already? 1138292588 M * daniel_hozac yes. the utils won't support any of the legacy stuff anyway without special options. 1138292621 M * cohan the api thingy. okay 1138292652 M * daniel_hozac and even if you enable it in both the kernel and the utils, it won't be used. 1138292705 M * cohan so what about that barrier - if using no legacy and namespaces, barrier for /vservers is still suggested? 1138292757 M * daniel_hozac i think the concensus was that it shouldn't be needed, but no one has verified. 1138292769 M * cohan ic 1138292809 M * cohan hm, perhaps the help in the kernel patch regarding CONFIG_VSERVER_LEGACY could also be changed with the next patch release? still speaking of migration perhaps, but not of reduced functionality? 1138292827 M * daniel_hozac yes, i imagine it will. 1138293579 M * cohan hm, the Step-By-Step guide also referst to a vserver-build manpage which does not exist anymore, man vserver does not show much about build, is "vserver - build --help" the current equivalent to the manpage? 1138293635 M * cohan (which is better than nothing, but i think not what the writer of the Step-By-Step Guide meant when writing "The vserver-build manpage is really well written,"... 1138293794 M * cohan another thing i am curious about: is it necessary to rebuild modules after i patched the kernel? 1138293826 M * cohan sorry, not building, but doing a make modules_install after the make 1138293950 Q * shedi Ping timeout: 480 seconds 1138294944 Q * _are_ Ping timeout: 480 seconds 1138295241 J * bonbons ~bonbons@83.222.38.150 1138295441 J * KArDelen turksehri@85.108.244.59 1138295462 P * KArDelen 1138295686 P * AllenJB Parted 1138296083 J * _are_ ~are@62.112.159.81 1138296542 J * KArDelen turksehri@85.108.244.59 1138296562 P * KArDelen 1138296573 M * daniel_hozac cohan: well, it does change EXTRAVERSION by default. 1138296609 M * cohan yes, that requires a make modules_install, of course - or another symlink 1138296656 M * daniel_hozac i think there may be other problems as well, as certain core macros/functions/etc. are changed. 1138296667 M * cohan but i guess one should re-install the modules, for internals changed 1138296687 M * cohan aright, as you just said 1138296905 M * TheSeer gna.. is there a way to prohibit those spambots to flood people? 1138296911 M * cohan where is the CTX id stored btw? even after reboot, the servers keep the same when assigned dynamically - in the filesystem, is it the xid? 1138296965 M * daniel_hozac don't use dynamic contexts. 1138297006 M * daniel_hozac and yes, context id == xid. 1138297032 M * cohan hm - okay, i read sth. that _suggested_ to use dynamic contexts when not using legacy, perhaps i mixed sth up 1138297063 M * daniel_hozac well, in the devel branch, not using legacy == dynamic contexts won't be supported. 1138297116 M * cohan ah... that explains ;) the whole thing i do today is about migrating to "newest" tools with no legacy at all 1138297249 M * cohan so this is another tiny thing which could be changed on the Step-By-Step-Page? (i am just collecting little oddities i stepped over on the documentation) 1138297249 M * daniel_hozac dynamic contexts is probably as legacy as you get. 1138297266 M * daniel_hozac feel free to fix everything that's incorrect. 1138297279 M * daniel_hozac (or could be rephrased, or whatever) 1138297348 M * cohan i'll do so - still, i am new to the new tools so i'd like someone to review those changes, i'll tell you when i applied them 1138297358 N * Bertl_zZ Bertl 1138297364 M * Bertl morning folks! 1138297370 M * daniel_hozac morning! 1138297442 M * cohan perhaps one of you also knows what to suggest instead of man vserver-build in the step-by-step-page? 1138297505 M * daniel_hozac vserver - build --help is probably as close as you get. 1138297552 M * cohan *noted* (was the old manpage really more verbose?) 1138297638 M * daniel_hozac i can't even find it. 1138297692 M * cohan referenced by a built made on 2005-06-19 1138297749 J * stefani ~stefani@superquan.apl.washington.edu 1138297759 M * daniel_hozac it has never been in CVS, AFAICS. 1138297771 M * Bertl welcome stefani! 1138297937 M * stefani hello 1138298518 M * cohan interesting - also considered deleted sources? perhaps someone around with a util-vserver source packet from around mid 2005? 1138298599 M * Bertl http://www.13thfloor.at/~ensc/util-vserver/files/ 1138298684 J * brc_ bruce@20151222045.user.veloxzone.com.br 1138299086 Q * marl Ping timeout: 480 seconds 1138299222 J * AllenJB ~Allen@stuEAED.kent.ac.uk 1138299314 M * Bertl welcome brc_! AllenJB! 1138299390 J * marl ~matt@84.92.193.226 1138299457 M * Hollow jkl: yes 1138299468 M * Hollow hey Bertl 1138299520 M * Hollow i got a strange exception today, while doing vc_namespace_clenaup: http://home.xnull.de/misc/page-exception.txt 1138299839 M * jkl hey! 1138299853 M * jkl Hollow: i've got that problem described in the bug report 1138299855 M * jkl with udev 1138299865 M * jkl on ALL my vservers! it's hectic 1138299936 M * Hollow well, you can either workaround it by adding udev to package.provided, or find the ebuild depending on udev 1138300054 M * daniel_hozac vmware? heh. 1138300111 M * daniel_hozac addr2line? 1138300283 M * Hollow well, i need an internet explorer to check if pages look like they should, and to do taxes.. 1138300390 M * Bertl hmm, taxes require an IE? 1138300393 M * Hollow hm, how do i get the linux binary from bzImage? 1138300424 M * daniel_hozac /vmlinux would be the binary. 1138300424 M * Bertl strip the bootload and unzip it 1138300425 M * Hollow Bertl: no, since 1.1.06 you can do it via browser and java applets, but before there was just a software for windows and you have to do it electronically 1138300450 M * Hollow at least for VAT 1138300452 M * Bertl Hollow: yeah, we have a browser solution too 1138300468 M * Bertl (we being Austria) 1138300501 M * Hollow yeah, but niether konqueror nor firefox passed the validation, so i did it on the mac.. sigh 1138300517 M * Bertl interesting ... had no problems with galeon yet 1138300531 M * Hollow well, i guess you have a different system, no? 1138300538 M * Bertl I hope so :) 1138300542 M * Hollow ;) 1138300678 M * Hollow ok, so how do i get the binary? i don't have the tree anymore 1138300694 M * Hollow well, i have it, but it's not compiled.. 1138300832 M * Bertl see arch/i386/boot/Makefile 1138300841 M * Bertl and 'try' to reverse the process 1138301187 M * Bertl dd if=arch/i386/boot/bzImage bs=512 skip=34 | dd bs=20 skip=1 | zcat 1138301199 M * Bertl seems to give the uncompressed image without some sections 1138301353 M * Bertl well, it gives the arch/i386/boot/compressed/vmlinux.bin to be precise 1138301480 N * ebiedermZz ebiederm 1138301486 M * Bertl Hollow: but you wont get any debug info from there, as it is usually stripped 1138301491 M * Bertl morning ebiederm! 1138301506 M * ebiederm Morning. 1138301530 M * ebiederm You actually can't get vmlinux from a bzImage. 1138301542 M * ebiederm The ELF headers have been lost. 1138301564 M * ebiederm There is an objcopy -O binary vmlinux ... vmlinux.bin in the process before the compression step. 1138301602 M * ebiederm What do you need the vmlinux for? 1138301657 Q * bonbons Quit: Leaving 1138301882 J * undefined ~undefined@adsl-68-93-109-94.dsl.rcsntx.swbell.net 1138302018 M * Bertl welcome undefined! 1138302027 M * undefined howdy Bertl 1138302102 M * Bertl ebiederm: would it be a big problem to CC me or the ML in the future? 1138302149 M * Bertl (on patches and/or discussions regarding virtualization) 1138302150 M * ebiederm Bertl: No. It just a pain connecting all of the threads. 1138302187 M * ebiederm My last patch I CC'd the ML but it was a little too big..... 1138302190 M * cohan what can be the reason for: # vserver phoenix stop 1138302190 M * cohan vshelper.init: can not determine xid of vserver 'phoenix'; returned value was '' 1138302213 M * cohan when starting, a similar message is displayed, but it is started correctly, 1138302245 M * cohan # cat /proc/sys/kernel/vshelper 1138302258 M * ebiederm Bertl: you must have found the thread on kernel.org 1138302267 M * cohan shows /sbin/vshelper, which exists 1138302290 M * cohan i no longer use dynamic contexts as well, i switched to static ones and rebootet the whole system 1138302301 M * Bertl ebiederm: yep, no problem, but I'm not reading lkml every day 1138302303 J * Splinter ~dd@adsl-178-250-192-81.adsl.iam.net.ma 1138302309 M * Bertl welcome Splinter! 1138302321 P * Splinter 1138302355 M * ebiederm Bertl: Grumble a little at the IBM guys as well because they didn't CC the interested parties when they restarted their thread. 1138302434 M * cohan with the old tools, i was able to do a vps xafuw | grep , get the pid of the leftover init-process, and do a chcontext --ctx kill -9 1138302505 M * cohan this also does not work, but i see that the fakeinit pid1 thingy became better, on my old environment, i saw two inits (one fake with pid1, one with real pid) when doing a ps xafu within the context 1138302507 M * Bertl with the new tools you can do vkill --xid 0 1138302513 M * Bertl oops 1138302523 M * Bertl vkill --xid -- 0 1138302543 M * Bertl (or 1 or -1) 1138302570 M * Bertl cohan: and why should it not work btw? (except of init protection :) 1138302586 M * cohan my "oldstyle" says: 1138302610 M * cohan chcontext --ctx 235 kill -9 833 1138302610 M * cohan kill 833: No such process 1138302625 M * cohan i think thats good fakeinit, right? 1138302628 M * Bertl well, it's the init process, no? 1138302637 M * Bertl so inside it will have pid=1 1138302651 M * cohan which returns true, but init is still there 1138302661 M * Bertl which is the normal init behaviour 1138302671 M * cohan which can be overridden by -9 1138302679 M * cohan or do i mix sth up? 1138302688 M * Bertl try it on your host's init :) 1138302710 M * cohan hm, why can i kill the leftover inits on the 2.4er kernel that way... *wondering* 1138302723 M * Bertl was a kind of bug ... 1138302738 M * Bertl well, not bug, but it got improved ... 1138302772 M * Bertl anyway, the vkill will be able to send signals to the entire context, or just init 1138302809 M * cohan yes, vkill works, thx 1138302873 M * cohan okay, so the issue left _why_ i have to do it manually, "vserver phoenix start" works expect: 1138302879 M * cohan # vserver phoenix start 1138302879 M * cohan vshelper.init: can not determine xid of vserver 'phoenix'; returned value was '' 1138302891 M * cohan s/expect/except/ 1138302947 M * cohan any idea why vshelper.init is fooled like this? 1138302987 M * Bertl how was the guest created? 1138303001 M * Bertl looks like the reverse mapping is missing 1138303019 M * cohan vserver phoenix build -m skeleton --hostname phoenix.local --interface a235=eth0:192.168.1.235/24 --initstyle plain 1138303039 M * Bertl please use static context ids!!! 1138303045 M * cohan and the actual content of the rest of the fs is my own vserver master extracted, everything inside works fine 1138303051 M * Bertl i.e. add --context 1138303055 M * cohan ah, yes, i added static context id later 1138303082 M * cohan with echo "235" > /etc/vservers/phoenix/context 1138303087 M * Bertl okay 1138303099 M * cohan then rebooting host - any other place where this should be mentioned? 1138303118 M * Bertl could you upload the output of ls -lR /etc/vservers/phoenix somewhere (e.g. pastebin)? 1138303122 M * cohan also vserver-stat shows 235 as context, just no "name" 1138303199 M * cohan http://pastebin.com/524396 1138303261 M * cohan is the symlink: ls -la /vservers/phoenix 1138303261 M * cohan lrwxrwxrwx 1 root root 25 Jan 26 16:20 /vservers/phoenix -> /opt/cell01/phoenix/vroot 1138303298 M * cohan perhaps again a problem? (used to be a relative symlink before which fooled some pushd in vserver start) 1138303666 M * Bertl why do you make symlinks there? 1138303729 M * Bertl I mean, why not simply change the vdir entry in the config? 1138303751 M * cohan thats a new option with the new tools - i am migrating our old custom tools 1138303809 M * cohan i'll try it with a direct link if this has no other side-effects.. i also just realized no network device was set up, odd 1138303982 M * cohan direct link, same effect, i update the pastebin... 1138304010 M * Bertl ah, didn't see the url :) 1138304055 M * Bertl what is in your /var/run/vservers.rev ? 1138304082 M * cohan http://pastebin.com/524421 1138304124 M * cohan many, many symlinks - looks as if for all dynamic runs before, 1138304134 M * cohan and the most current 235 one 1138304147 M * cohan lrwxrwxrwx 1 root root 21 Jan 26 20:29 235 -> /etc/vservers/phoenix 1138304165 M * cohan (should that dir be cleaned on bootup?) 1138304180 M * Bertl so the tools should be able to figure the name fron the xid 1138304195 M * Bertl (unless they look somewhere different) 1138304211 M * cohan standard tools, freshly build 1138304215 M * Bertl cohan: might it be that you have two versions of tools installed and they somehow mix? 1138304228 M * Bertl cohan: with what configure options, btw? 1138304296 M * cohan http://pastebin.com/524428 1138304301 M * cohan paste is growing ;) 1138304334 M * cohan i had only one other build earlier today, but with the same directory layout, 1138304376 M * cohan and i verified that "pkgrm" removed the whole package completely (just rebuild for trying --without-dietlibc and with installed beecrypt) 1138304417 M * Bertl ahem, no dietlibc? 1138304419 M * cohan so it is unlike sth is mixed, as long as not some temporary files like this /var/run - stuff was left over 1138304452 M * cohan did not change a thing, i thought that would suppress the warning that no dietlibc is found and that glibc is used instead 1138304481 M * cohan but the waring was still there and the binaries seem not to dither as well 1138304552 M * Bertl well, you should install dietlibc instead of supressing a reasonable warning :) 1138304662 M * cohan but i doubt my errors come from dietlibc? ;) well, i'll give it a try... just thought i could omit that on this porting stage 1138304759 M * cohan what's /var/run/vservers-default for? 1138305110 J * Blissex ~Blissex@82-69-39-138.dsl.in-addr.zen.co.uk 1138305678 M * ebiederm Bertl: You set the weirdest followup-to header in your email. 1138305757 M * Bertl ebiederm: really? well it's the one mutt chooses ... 1138305767 M * ebiederm It doesn't include you. 1138305809 M * Bertl well, that's correct, as it is the lkml thread 1138305827 M * ebiederm Ok. I thought you wanted to be CC'd on the lkml threads. 1138305855 M * Bertl if possible yes, so I will answer sooner ... 1138305886 M * Bertl doesn't matter once I watch/read a thread ... 1138305914 M * ebiederm Ok. I see. 1138305918 M * ebiederm Gmail? 1138305945 M * Bertl not yet, saw no reason for it ... 1138305960 M * ebiederm How does it work that you see updates once you watch/read a thread. 1138305970 M * ebiederm Is that a mutt feature I am unaware of. 1138305985 M * Bertl you can mark mails easily 1138305999 M * Bertl with the threaded view, you see any additions 1138306038 M * ebiederm And then you just check into your lkml inbox when you know there is an interesting thread? 1138306083 P * undefined 1138306097 M * Bertl if you CC/BCC it to me, then I will have it in my inbox, otherwise I check interesting threads on lkml from time to time 1138306141 M * ebiederm So let me put this clearly. I'm trying to see if you want me to CC you my reply to your lkml thread. 1138306155 M * cohan Bertl: i'll soon have it rebuilt with dietlibc - do you really think my troubles come from that? 1138306234 M * Bertl cohan: it could be, we had the funniest issues with glibc 1138306258 M * Bertl cohan: the problem is the dynamic loading, which once the process has entered the guest, will happen from the guest fs 1138306282 M * Bertl cohan: as you can imagine, all kind of strange effects can arise from that 1138306337 M * Bertl ebiederm: simple rule, if you want a 'fast' reply from me, please CC me, if you are replying to one of my posts, and just want me to read it sometimes, no need to CC me 1138306348 M * ebiederm Bertl: Ok. 1138306380 M * Bertl usually the no-CC emails will take 2-4 days, where the CC emails should be answered within the hour 1138306437 Q * liquid3649_ Remote host closed the connection 1138306555 J * undefined ~undefined@adsl-68-93-109-94.dsl.rcsntx.swbell.net 1138307508 M * cohan can vserver-build be forced to procude link to a custom vdir? 1138307654 M * cohan okay, linked vs. dietlibc, still same results, even phoenix built from scratch 1138307667 M * Bertl --rootdir 1138307698 M * Bertl how large is that guest? 1138307746 M * cohan but --rootdir is a dir it creates, not one it should simlink to - hm 1138307764 M * cohan # du -hs /opt/cell01/phoenix/vroot/ 1138307764 M * cohan 392M /opt/cell01/phoenix/vroot/ 1138307808 M * cohan the guest runs, just this odd message on start and the incomplete shutdown 1138307818 M * Bertl could you do a dump 0zf /tmp/phoenix.dump /opt/cell01/phoenix/vroot/ and upload that somewhere? 1138307834 M * Bertl (I mean so that I can download it) 1138307863 M * cohan i'll try - do you really suspect the guest itself? 1138307877 M * Bertl no, I more suspect the setup/config/tools 1138307914 M * Bertl but we can do some more tests first if you like ... 1138307931 M * Bertl a very interesting output would be 1138307943 M * Bertl vserver-info - SYSINFO 1138307956 M * Bertl and the lines from testme.sh 1138307963 M * Bertl (again pastebin or so) 1138308025 M * cohan done: http://pastebin.com/524552 1138308072 M * cohan note that the pkgfile beyond is outdated now 1138308156 M * Bertl hmm, well, the testme.sh says it 1138308196 M * cohan ah, interesting, did not say it the run before... with the tools vs. glibc 1138308222 M * Bertl try to compile your tools with --enable-apis=NOLEGACY 1138308235 M * Bertl and keep the dietlibc for now 1138308235 M * cohan okay, just a minute... 1138308290 M * daniel_hozac well, that looks more like no legacy support in the kernel. 1138308297 M * daniel_hozac (i.e. no dynamic IDs) 1138308366 M * Bertl could be, yes ... 1138308392 N * ebiederm ebiedermOo 1138308459 M * cohan i asked before, someone said its safe to disable legacy support in the kernel when using 0.30.210 with default build? 1138308466 M * daniel_hozac it is. 1138308471 M * daniel_hozac the test script just won't work with it. 1138308480 M * cohan and NOLEGACY produces what kind of tools? 1138308503 M * daniel_hozac tools with support for all but the überancient API. 1138308549 M * Bertl yeah, it's one of Enricos new confusing macros :) 1138308552 M * cohan hm, so its worth giving it a try? (my kernel has no legacy support, but i can recompile that in) 1138308574 M * Bertl cohan: okay, in this case you just have to enable dynamic contexts 1138308594 M * Bertl daniel_hozac: so you are right again :) 1138308618 M * cohan grmpf, i wonder why i just kicked them out... 1138308674 M * cohan so i shall really try it with parial legacy stuff enabled again, and not try to figure out what blows the "no legacy at all"-case? 1138308680 M * cohan s/parial/partial/ 1138308775 M * daniel_hozac the only thing that should blow up is the test script. 1138308818 M * cohan okay, so my tools without --enalbe-apis at all and a no-legacy-kernel is perfectly okay? 1138308830 M * daniel_hozac it should be. 1138308837 M * daniel_hozac if you find any other problems, they ought to be fixed. 1138308856 M * Bertl cohan: actually only the dynamic context ids are required for the network contexts 1138308876 M * Bertl will make that independant from the legacy on the next release 1138308878 M * Bertl (for now) 1138308880 M * daniel_hozac (for the test script) 1138308899 M * cohan ah... hmpf, totally confused - only for the test script? 1138308909 M * daniel_hozac the utils themselves should work fine without any legacy features. 1138308918 M * Bertl well, I guess it will fix the guest startup too 1138308936 M * Bertl daniel_hozac: or where would the network context get the static id? 1138308952 M * Bertl daniel_hozac: is that already in 0.30.210? 1138308957 M * daniel_hozac my patched altered the scripts as well. 1138308957 M * cohan okay, i prepare a second kernel and both packages are standing by 1138308972 M * daniel_hozac so static network contexts are also default. 1138308983 M * daniel_hozac (assuming a static context is specified) 1138309001 M * Bertl daniel_hozac: ah, excellent! so no need to allow for dynamic ID then ... just have to update the test script :) 1138309020 M * daniel_hozac exactly. 1138309045 M * Bertl you could have told me *G* :) 1138309070 M * cohan okay, i'll try on to figure out what fails in my setup then 1138309087 M * Bertl could you do athe following startup: 1138309097 M * Bertl vserver --debug phoenix start 1138309105 M * Bertl and upload the output ... 1138309137 M * cohan btw, i did NOT yet disable CONFIG_VSERVER_NGNET: 1138309152 M * cohan that means it is the default =N 1138309169 M * cohan # CONFIG_VSERVER_NGNET is not set 1138309190 M * cohan or should that be set as well for a "no-legacy-at-all-kernel"? 1138309226 M * cohan heh... lots of output with the --debug, did not redirect it 1138309283 M * Bertl well, kill/stop/whatever it 1138309293 M * Bertl (i.e. make sure that the remains get removed) 1138309306 M * Bertl then, redo with a redirect :) 1138309331 M * cohan just what i did now ;) 1138309360 M * cohan whatever remains is /var/run/vservers/* and /var/run/vserver.revs/*, anything else? 1138309439 Q * ag- Ping timeout: 480 seconds 1138309677 M * cohan https://servy.dynip.yawsp.de/~install/ 1138309773 M * cohan that debug is nice 1138309819 M * daniel_hozac cohan: what do you have in /etc/vservers/phoenix/name? 1138309836 M * cohan # cat /etc/vservers/phoenix/name 1138309836 M * cohan phoenix 1138309845 M * cohan and do you know whats odd? : 1138309870 M * cohan # /usr/sbin/vserver-info /etc/vservers/phoenix CONTEXT 1138309870 M * cohan 235 1138309870 M * cohan # /usr/sbin/vserver-info /etc/vservers/phoenix CONTEXT false 1138309870 M * cohan # 1138309890 M * daniel_hozac hmm. 1138309897 M * cohan but the _latter_ one is what vserver phoenix start tries to do according to debug.start 1138309905 M * daniel_hozac yep. 1138309934 M * cohan does that make sense? 1138309961 M * daniel_hozac the false returns the xid here. 1138309989 M * cohan hm? but if i use the first line, the correct xid is returned, 1138310004 M * cohan if i use the second line (like vserver start does), i get an empty output 1138310091 M * daniel_hozac false means that dynamic contexts are allowed, i think. 1138310121 M * daniel_hozac (so it shouldn't matter as you have a static context) 1138310147 M * cohan yes, okay, so we have now tracked the problem down to vserver-info 1138310157 M * cohan its --help is not very verbose ;) 1138310203 M * daniel_hozac hmm. 1138310209 M * cohan but at your system, with no dynamic ids enabled, vserver-info WITH the false returns a value? 1138310213 M * daniel_hozac false seems to fail when the vserver is not running. 1138310220 M * cohan it is running right now 1138310248 M * daniel_hozac i still have legacy features enabled, but that shouldn't matter. this is util-vserver only. 1138310500 M * Bertl hey, I have a funny mainline/iproute/kernel issue ... 1138310535 M * Bertl ip addr add 192.168.1.1 label eth0foo dev eth0 1138310547 M * Bertl (will work, but screw up ifconfig :) 1138310641 M * cohan too long alias names screw up ifconfig, don't they? 1138310657 M * Bertl well, no, they just do not show the whole truth :) 1138310682 M * Bertl anyway, I will now compile a kernel with legacy disabled and test with 0.30.210 .... 1138310702 M * cohan sounds good... i'll strace vserver-stat 1138310712 M * Bertl make that 1138310755 M * daniel_hozac hmm. 1138310805 M * daniel_hozac it seems false means "don't read .../context if it's not running". 1138310840 M * daniel_hozac while initially (in vserver-info) it seemed to mean "_only_ read .../context". 1138310882 M * daniel_hozac so, what i said holds true. it should return the xid, as long as the vserver is running (with false). 1138310925 M * Bertl it does here 1138310971 M * cohan and how is "running" determined? 1138310982 M * daniel_hozac /etc/vservers/.../run 1138310982 M * Bertl visible in vserver-stat 1138311011 Q * Blissex Read error: Connection reset by peer 1138311068 M * cohan well, this is where strace vserver-info ... false differs at my machine (running/not running) 1138311082 M * cohan read(3, "235\n", 5) = 4 1138311083 M * cohan close(3) = 0 1138311083 M * cohan vserver(0x2e050000, 0xeb, 0xbfe4bdb4, 0xbfe4d979, 0xeb) = -1 ESRCH (No such process) 1138311083 M * cohan _exit(1) = ? 1138311095 M * cohan this was the "not running" case, 1138311098 M * cohan and if running: 1138311139 M * cohan http://pastebin.com/524639 1138311174 M * daniel_hozac so you get the xid with false, but only when it's not running? 1138311193 M * cohan no, with false i never get the gid, but it is read in either case 1138311206 M * cohan just whats odd: see the strace, the final: 1138311215 M * cohan phoenix became a phoeni ?? 1138311236 M * cohan s/gid/xid/ 1138311241 M * daniel_hozac hmm, /etc/vservers/.../run isn't removed after stop? 1138311269 M * daniel_hozac or was the pastebin when it's running? 1138311289 M * Hollow oh yay 1138311303 M * cohan pastebin was when running 1138311305 M * Hollow paper is finished 1138311312 M * cohan where it _should_ return the xid 1138311334 M * cohan and i think the /run is not removed (i do it manually) on stop because the stop fails, 1138311340 M * cohan saying it cannot get the xid 1138311345 M * daniel_hozac oh. 1138311384 M * cohan its kind of vicious circle 1138311409 M * cohan but still, now its running (the phoenix), and vserver-info ... false produced the pastebin-strace, which at least looks odd 1138311473 Q * Johnnie Quit: G'bye! 1138311512 M * daniel_hozac Bertl: is the uts context anywhere in proc? 1138311534 M * cohan btw, # vserver-stat 1138311534 M * cohan CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 1138311534 M * cohan 0 37 44M 19.7M 4m42s00 2m41s72 4h00m10 root server 1138311534 M * cohan 235 9 13.8M 3.1M 0m00s51 0m00s80 8m31s27 1138311543 M * cohan looks good, but also lacks name resolution 1138311553 M * cohan same issue? 1138311588 M * cohan Hollow: grats for you finished "facharbeit", right? 1138311609 M * daniel_hozac cohan: when it's running, what does vserver-info /etc/vservers/phoenix UTS show? 1138311629 M * derjohn strange Q: would vserver run on unionfs? It dont mean tagxid, just want to know if anyone tried out or is there anything I should look at? (I didnd even try to patch yet ...) 1138311652 M * cohan /etc/vservers/phoeni Linux host 2.6.15-vs2.1.0.5 #4 SMP Thu Jan 26 17:56:44 CET 2006 i686 (none) 1138311659 M * daniel_hozac cohan: probably related... 1138311660 M * cohan interesting.. the missing "x" again 1138311666 M * daniel_hozac indeed. 1138311669 M * cohan a config file without a \n? 1138311670 J * Johnnie ~jdlewis@dynamic-acs-24-154-53-16.zoominternet.net 1138311697 M * cohan no, cat /etc/vservers/phoenix/name shows the last \n 1138311764 M * Bertl derjohn: some folks use unionfs with vserver, but I've heard it is not very stable 1138311774 M * mnemoc i 1138311789 M * mnemoc it's mostly unusable :) 1138311846 M * derjohn Bertl, just thinking about a creating a "livecd" based on grml with a vserver patched kernel and some guests for playing around ... or does such already exist? 1138311943 M * Hollow cohan: right ;) 1138312034 M * Hollow off to bed then.. cu tomorrow 1138312069 M * Bertl night Hollow! 1138312099 M * cohan gn8 Hollow 1138312101 J * Aiken ~james@tooax6-123.dialup.optusnet.com.au 1138312116 M * daniel_hozac anyone happen to know where util-vserver sets the uts context? 1138312116 M * Bertl derjohn: well, why not fit the entire host stuff into a ramdisk, should not be really much ... 1138312133 M * Bertl uts context` 1138312135 M * Bertl ? 1138312169 M * daniel_hozac ah, there it is. 1138312191 M * derjohn Bertl, a whole guest? r.g. 515M /var/lib/vservers/ns2/ ... and then I'd like to offer fcX, debian sarge, sid, maybe suse .... 1138312227 M * Bertl derjohn: no, Iw as talking about the host system ... 1138312256 M * Bertl welcome Johnnie! Aiken! 1138312259 M * cohan i could donate a crux-based guest 1138312262 M * Aiken hi 1138312266 M * cohan very simple and slim, <100 MB 1138312275 M * Bertl derjohn: but maybe you are right and folks want huge test guests ... 1138312276 M * daniel_hozac Bertl: VHIN_CONTEXT. 1138312289 M * derjohn Bertl, ah, yes, that would fit. But people couldn't change what's inside the guests without .... 1138312299 M * Bertl derjohn: neverthess, my test guests use less than 30MB 1138312309 M * daniel_hozac Bertl: (sorry, it's exposed as part of the uts structure in util-vserver) 1138312329 M * derjohn Bertl, well, at least there should me apache mysql and other "standard" (whatever that is ;)) stuff be inside .. just as proof 1138312357 M * Aiken Hollow ping 1138312388 M * derjohn cohan, the 2nd time I get in contact with crux ... you crux folks seem to have to growing communiy :) 1138312403 M * daniel_hozac Aiken: he went to bed one minute before you joined ;) 1138312409 M * Bertl Aiken: he went to bed ... 1138312410 M * Aiken :( 1138312425 M * derjohn cohan, is you guest image d'loadable? where? is it in the wiki ? 1138312435 M * Aiken trying vserver-utils 1138312440 M * Aiken having problems 1138312459 M * cohan yes, slowly it is growing (crux)... it's about the right size of community right now, and i love the simple, easy ports system 1138312491 M * cohan makes maintaining very easy, and crux's maxime is KIS(S) 1138312548 M * cohan derjohn: not yet, at least its a bit of a mess right now (old glibc for 2.4 kernel tree), i am just updating the guest 1138312576 M * derjohn cohan, ok .. I dont want provide a mess on such a test cd ;) 1138312594 M * cohan when do you plan "release"= 1138312594 M * cohan ? 1138312597 M * Aiken a big surpise when vserver stop slate shutdown the host 1138312598 M * derjohn cohan, oh, from .de? will you join linuxtag 06? 1138312621 M * cohan if time permits... not sure yet, will be in the middle of my diploma thesis 1138312646 M * derjohn cohan, well .. all unsure. I'd like to get a community area for linux-vserver there ... is i find people who join me there 1138312657 M * derjohn that why I am asking .de and .at first 1138312673 M * Bertl Aiken: hmm, that sounds like too many capabilities ... 1138312690 M * daniel_hozac cohan: i can't see anything that would strip the last character, and it should've bitten everyone. 1138312725 M * cohan daniel_hozac: odd - okay, it's dietlibc now... so sth. else seems to be specific on my system... 1138312737 M * cohan ...or perhaps only with trailing x ? ;) 1138312822 M * cohan derjohn: yes, i am interested.. drop a note on the mailinglist, i just joined 1138312840 M * cohan and if "linuxtag" is in the subject, i'll not miss it 1138312842 M * Aiken Bertl no caps are set in context.conf and the other problem is the guest has the host's hostname not it's own 1138312876 M * Bertl Aiken: well, that sounds like missing cflags then 1138312877 M * Aiken I'll go back to util-vserver for the moment, I want 2 guest running 1138312895 M * Bertl Aiken: yeah, I guess he will have more time on the weekend 1138312904 M * Bertl Aiken: IIRC, some test tomorrow ... 1138312910 M * Aiken the guest I tried had not network 1138312934 M * cohan daniel_hozac: do you agree that, according to my strace output, it cannot be a misconfig? 1138312961 M * Aiken still trying to find out exactly what is wrong but it is starting to look like that alpha kernel I was trying has a problem with ne2k driver that was surposed to be fixed 10 - 12 years ago 1138312963 M * cohan http://pastebin.com/524685 1138312966 M * daniel_hozac cohan: the kernel has the wrong context name set for it. 1138313008 M * daniel_hozac cohan: so the contexts aren't believed to be the same. 1138313016 M * daniel_hozac cohan: and false disables the static context parsing. 1138313024 M * daniel_hozac so i guess the results you see are expected, given the values available. 1138313075 M * daniel_hozac as to why the kernel has the wrong name... i have absolutely no idea. 1138313078 M * cohan okay, so i have to find out where the wrong name comes into the kernel? 1138313109 M * Bertl daniel_hozac: a kernel bug? 1138313128 M * Bertl quick let's get that kernel guy here ... :) 1138313167 M * daniel_hozac Bertl: i don't think so, i'd expect that to be visible elsewhere. 1138313189 M * daniel_hozac vserver-info /etc/vservers/ UTS reports correct paths here. 1138313239 M * daniel_hozac (although, i am still on 2.0.1, so i guess it's not ruled out) 1138313356 M * cohan i use 2.1.0.5 1138313386 J * CaMbA_BoRRaChO ~sadfds@pool-71-126-139-95.washdc.fios.verizon.net 1138313388 P * CaMbA_BoRRaChO 1138313405 M * daniel_hozac well, the kernel doesn't do anything at all with the passed values. 1138313463 M * Bertl okay, off for a little, back later ... will report findings with the new kernel 1138313471 N * Bertl Bertl_oO 1138313505 M * cohan but i also believe its sth. specific with my setup, other would have seen this oddities 1138313518 M * daniel_hozac yes, i agree. 1138313548 M * daniel_hozac your startup trace shows the right argument being passed to vuname as well. 1138313564 M * cohan can i read that value directly from /proc ? 1138313580 M * daniel_hozac no, vuname -g --xid context 1138313622 M * cohan i also enabled CONFIG_VSERVER_DEBUG=y, if that is of any interest 1138313697 M * daniel_hozac there is no debugging in vc_set_vhi_name, and as i said earlier, it doesn't do anything with the value. it just copies it to the correct place. 1138313762 M * cohan who is supposed to write the value to the kernel during startup? 1138313769 M * cohan e.g. vserver phoenix start 1138313773 M * daniel_hozac vuname 1138313775 M * daniel_hozac you see it in the trace. 1138313806 M * daniel_hozac ...vuname --xid self --set -t context=/etc/vservers/phoenix... 1138313858 M * cohan ah, you mean in the --debug version 1138313869 M * daniel_hozac right. 1138314121 M * daniel_hozac could you add some debugging to util-vserver-0.30.210/lib/syscall_setvhiname-v13.hc? 1138314177 M * cohan i'll try (if that was for me) 1138314181 M * daniel_hozac just some simple printf("val=%s,name=%s\n",val,cmd.name); after name has been set would do. 1138315049 J * shedi ~siggi@inferno.lhi.is 1138315308 M * cohan # vserver phoenix start 1138315308 M * cohan val=phoenix.local,name=phoenix.local 1138315308 M * cohan val=/etc/vservers/phoenix,name=/etc/vservers/phoenix 1138315308 M * cohan vshelper.init: can not determine xid of vserver 'phoenix'; returned value was '' 1138315384 M * daniel_hozac which line did you add it after? after the cmd.name[len] = '\0';? 1138315409 M * cohan no, rc = vserver(VCMD_set_vhi_name, CTX_USER2KERNEL(xid), &cmd); 1138315412 M * cohan after that 1138315416 M * daniel_hozac ah, that late even. 1138315426 M * cohan but can be changed 1138315445 M * daniel_hozac it doesn't matter, as long as it's after the = '\0';. 1138315485 M * daniel_hozac so the kernel should be getting the right argument. 1138315504 M * cohan looks like :/ 1138315654 Q * _are_ Ping timeout: 480 seconds 1138316241 M * cohan and vserver(VCMD_set_vhi_name, CTX_USER2KERNEL(xid), &cmd) is sure do it correct? 1138316268 M * cohan but if vuname -g --xid 235 1138316283 M * cohan does only read that - the x has to get lost somewhere 1138316345 M * cohan wow, what's that? 1138316350 M * cohan # strace vuname -g --xid 235 1138316352 M * cohan ... 1138316359 M * cohan vserver(0x2020000, 0xeb, 0xbfe11df4, 0, 0x804c325) = 0 1138316359 M * cohan write(1, "/etc/vservers/phoeni\257\7", 22/etc/vservers/phoeni¯) = 22 1138316411 M * cohan look closely at this special char in the end... phoeni¯ (i don't even know how this "top-score"-character is called) 1138316453 M * daniel_hozac how bizarre. 1138316469 M * cohan i'll look into vuname.c now 1138316494 M * daniel_hozac it's too bad strace can't decode the vserver arguments... 1138316543 M * daniel_hozac could you possibly be bothered to add some debugging to the kernel too? 1138316655 M * cohan its a devel system... so just tell me what to do 1138316760 M * daniel_hozac kernel/vserver/cvirt.c, vc_set_vhi_name, add a printk("name = %s\n", name); after the memcpy. 1138316792 M * cohan if (vc_get_vhi_name(xid, val, buf, sizeof(buf)-1)==-1) 1138316829 M * cohan is that sizeof(buf)-1 correct? (util-vserver-0.30.210/src/vuname.c:209) 1138316861 M * daniel_hozac yeah, especially as that buffer is twice as big as any of the entries. 1138316867 M * daniel_hozac well, nearly. 1138316872 M * cohan ah, okay 1138316929 M * cohan like this? 1138316929 M * cohan if (name) 1138316929 M * cohan memcpy(name, vc_data.name, 65); 1138316929 M * cohan printk("name = %s\n", name); 1138316939 M * daniel_hozac yeah. 1138316951 M * cohan the 65 is a magic number? 1138317047 M * cohan kernel built in progress, i hope a clean etc. is not required before 1138317061 M * daniel_hozac well, 65 is the length of all the fields. 1138317068 M * daniel_hozac no, that shouldn't be necessary. 1138317087 M * cohan ah, compiled quite fast, just a couple of .o's touched 1138317095 M * daniel_hozac yep. 1138317125 P * stefani I'm Parting (the water) 1138317165 M * cohan okay, rebooting (and cleaning the /var/run/vservers...) 1138317403 M * cohan Jan 27 00:12:13 servytest kernel: name = phoenix.local 1138317403 M * cohan Jan 27 00:12:13 servytest kernel: name = /etc/vservers/phoenix 1138317441 M * cohan why phoenix.local? thats the hostname, not the context name 1138317454 M * daniel_hozac yeah, it logs all the names. 1138317469 M * daniel_hozac if you would have set the system name, architecture, etc. that would also show. 1138317489 M * cohan # cat /etc/vservers/phoenix/uts/nodename 1138317490 M * cohan phoenix.local 1138317490 M * cohan # cat /etc/vservers/phoenix/name 1138317490 M * cohan phoenix 1138317499 M * cohan is that correct or the wrong name round? 1138317500 M * cohan ah, okay 1138317547 M * cohan each time another random character: 1138317547 M * daniel_hozac so the kernel sees the correct name initially too. i have to admit i'm at a loss. 1138317548 M * cohan # vuname -g --xid 235 1138317548 M * cohan /etc/vservers/phoeni¥ Linux host 2.6.15-vs2.1.0.5 #5 SMP Fri Jan 27 00:06:23 CET 2006 i686 (none) 1138317565 M * daniel_hozac for each start? 1138317567 M * daniel_hozac or for each run? 1138317581 M * cohan for each start, at least, host reboot 1138317586 M * cohan *rebooting guest* 1138317685 M * cohan each vserver boot, after vkill --xid 235 -s 9 and rebooting with vstart phoenix start it shows another char (this time, not a printable) 1138317722 M * cohan write(1, "/etc/vservers/phoeni\245\7", 22/etc/vservers/phoeni¥) = 22 1138317751 M * Bertl_oO hmm hmm .. looks like the CoW link breaks we do?! 1138317795 M * cohan ? but why noone else has this effects? i mean... that would have thrown up others, wouldn't it? 1138317817 M * Bertl_oO well, the CoW braking should a) not happen on the rootfs 1138317828 M * Bertl_oO (because of missing tagxid and friends) 1138317851 M * Bertl_oO and it should not hit for files which are not marked as immutable and unlink 1138317861 M * Bertl_oO (i.e. which are unified) 1138317886 M * Bertl_oO but after all, it might not even be related here 1138317919 M * Bertl_oO looks more like an off by one strncpy or so 1138317953 M * cohan so, what exactly is stored in kernel space? the xid (235 in my case), the thingies i added debug for: 1138317953 M * cohan Jan 27 00:15:57 servytest kernel: name = phoenix.local 1138317953 M * cohan Jan 27 00:15:57 servytest kernel: name = /etc/vservers/phoenix 1138317972 M * cohan but not a phoenix alone? or shall i just add more debug code to the kernel? 1138317989 M * Bertl_oO the kernel stores whatever userspace puts there 1138318000 M * Bertl_oO it does not use the 'context' uts entry at all 1138318022 M * Bertl_oO i.e. it is supposed to return the entry _as_is_ 1138318043 M * Bertl_oO the maximum length is 65 chars, no trailing zero 1138318079 M * cohan i'll add kmesg to vc_get_vhi_name as well 1138318273 M * daniel_hozac userspace doesn't touch it either though, it too just copies it to the final destination before printing it. 1138318564 M * cohan well, somewhere it has to be modified... perhaps some other kernel code which messes with that field 1138318694 M * cohan Jan 27 00:33:44 servytest kernel: set name = phoenix.local 1138318694 M * cohan Jan 27 00:33:44 servytest kernel: set name = /etc/vservers/phoenix 1138318694 M * cohan Jan 27 00:33:44 servytest kernel: get name kern = /etc/vservers/phoeni} 1138318694 M * cohan Jan 27 00:33:44 servytest kernel: get name user = 1138318704 M * cohan okay, so what happened in between? 1138318733 M * cohan get name kern: shows that broken character already 1138318841 M * Bertl_oO where are your printk()s? 1138318862 M * Bertl_oO could you do a diff -NurpP of your changes? 1138318898 M * cohan just a second 1138318993 M * cohan easy way to exclude diffing of .o etc. ? 1138319024 M * daniel_hozac well, you just changed kernel/vserver/cvirt.c, no? 1138319032 M * Bertl_oO -x or -i 1138319051 M * cohan yes, right, but i made the cp -al error 1138319062 M * Bertl_oO error? 1138319063 M * cohan so the diff showed nothing, stupid me 1138319076 M * Bertl_oO you mean, your editor does not break links properly? 1138319079 M * cohan i think vi changed the "backup" made by cp -al as well 1138319090 M * cohan never checked that, not in kernel hacking recently 1138319111 M * Bertl_oO well, vim does that when configured to do backups 1138319132 M * cohan its just three lines, i upload the cvirt.c 1138319153 M * cohan it made the ~ file, still, the main files are identical now 1138319173 M * daniel_hozac yeah, my vim does that too. freakishly annoying. 1138319256 M * cohan https://servy.dynip.yawsp.de/~install/ 1138319278 M * Bertl_oO set patchmode=.orig 1138319284 M * Bertl_oO (.vimrc) 1138319291 M * daniel_hozac that's what i have. 1138319309 M * cohan ah, okay - have to recall that every time i setup a new devel sys then 1138319309 M * Bertl_oO I also have 1138319312 M * Bertl_oO set nobackup 1138319312 M * Bertl_oO set writebackup 1138319325 M * daniel_hozac ah. 1138319351 M * cohan well, i know that printk("get name user = %s\n", data); is wrong, 1138319368 M * cohan but the funny output is produced even with the printk before that 1138319376 M * daniel_hozac hmm, that still doesn't work for me. 1138319379 M * Aiken is there an accepted way for a guest to tell if it is running as a guest instead of a normal machine? 1138319414 M * Bertl_oO on typical systems /proc/self/vinfo will tell 1138319440 M * cohan ah, perhaps goto out_put; fires? hm, unlikely 1138319442 M * Bertl_oO cohan: %65.65s 1138319465 M * Aiken thanks 1138319465 M * daniel_hozac my vim is still copying the original to .orig, and writing the new file to all hardlinks. 1138319520 M * Bertl_oO I have another one left ... 1138319522 M * Bertl_oO set backupcopy=no 1138319570 M * cohan Bertl_oO: I am changing that msg... 1138319591 M * daniel_hozac ah, that did it, thanks a lot! 1138319652 M * daniel_hozac is the 65 really needed? all you care about is what's before the first \0. 1138319655 Q * gerrit Ping timeout: 480 seconds 1138319789 M * cohan what does that do? name = vx_vhi_name(vxi, vc_data.field) 1138319795 M * cohan (name is later recycled?) 1138319806 M * daniel_hozac gets a pointer to the correct variable. 1138319854 M * daniel_hozac well, i'm going to get some sleep, good luck and have fun! 1138319858 M * cohan but the memcpy later... 1138319876 M * daniel_hozac will write to the correct memory, thanks to that assignment. 1138319876 M * cohan ah, is dest, src 1138319877 M * Bertl_oO daniel_hozac: good night and tx! 1138319984 M * cohan well, another kernel build in progress