1127865650 M * Bertl it's not my fault! :) 1127865665 M * shep Did as it suggested and it appears (!) to be behaving now... 1127865680 M * shep YAY! 1127865683 M * Bertl k 1127865683 M * shep BUILD arch/i386/boot/bzImage 1127865683 M * shep Root device is (3, 3) 1127865683 M * shep Boot sector 512 bytes. 1127865683 M * shep Setup is 4618 bytes. 1127865683 M * shep System is 2262 kB 1127865684 M * shep Kernel: arch/i386/boot/bzImage is ready (#4) 1127865721 M * shep rebooting... 1127865830 M * shep OK - ready to go 1127865858 M * Bertl okay, let's try to start the guest again, and watch the syslog/klog 1127865901 M * shep You're not going to believe this... 1127865921 M * shep It's behaving itself now :-) 1127865932 M * Bertl hmm ..., including shutdown? 1127865948 M * shep OK - I'm lying - hold on... 1127865969 M * shep vs_reboot dd99c000[#3253],0 1127865969 M * shep vs_reboot ddb9c000[#3253],0 1127865975 M * shep That's all that's appearing in the logs 1127865998 M * Bertl okay, does it shut down properly? 1127866013 M * Bertl or didn't it start at all? 1127866018 M * shep First start didn't complain (but didn't start), second bimbed verbosely with similar message as before 1127866030 M * Bertl ah, great! :) 1127866032 M * shep bombed, even... 1127866080 M * Bertl ah, gentoo is fancy ... 1127866096 M * Bertl it is doing LINUX_REBOOT_CMD_CAD_OFF 1127866130 M * Bertl (probably a config option or so, but it's a minor bug in the kernel, that this isn't handled properly ... let me fix that up) 1127866130 A * shep nods as if he understands totally... 1127866327 M * Bertl shep: could you revert the change in the kernel source, and apply the following patch instead? 1127866349 J * mrec_ ~revenger@p54B02396.dip0.t-ipconnect.de 1127866374 M * shep Sure... 1127866438 M * Bertl http://vserver.13thfloor.at/Experimental/delta-rkill-fix01.diff 1127866451 M * Bertl wb mrec_/revenger :) 1127866466 Q * mrec Ping timeout: 480 seconds 1127866612 M * mnemoc Bertl: just that aditionaly to obvious related parts of 2.1.0-rc2 ? 1127866637 M * Bertl ah, you are working on it too? 1127866686 M * shep This might just be my ineptitude: 1127866687 M * mnemoc not yet :p 1127866689 M * shep mnemonic vserver # patch -p1 helper.c < ~/delta-rkill-fix01.diff 1127866690 M * shep patching file helper.c 1127866690 M * shep Hunk #1 FAILED at 103. 1127866690 M * shep 1 out of 1 hunk FAILED -- saving rejects to file helper.c.rej 1127866694 M * mnemoc i just arrive home 1127866731 M * Bertl shep: try with patch -p1 -l < ~/delta-rkill-fix01.diff 1127866738 M * shep 'K 1127866770 M * Bertl I diffed against 2.1.0-rc2 maybe gentoo is using older sources 1127866782 M * shep Same error... 1127866791 M * shep 2.6.13-vs2.1.0-pre5-gentoo 1127866796 M * mnemoc pre5! 1127866802 M * Bertl ah, pre5 :( 1127866820 M * Bertl shep: how do you feel about an upgrade? 1127866826 M * shep S'OK - will get later if required :-) Would like to see this working! 1127866843 M * Bertl okay, it's the kill line which is only there once 1127866850 M * shep Is there an official vserver kernel site? 1127866857 M * Bertl sec, I make a patch for that too ... 1127866869 M * Bertl well, yes 13thfloor.at :) 1127866893 M * shep Only on half meg here so it might take a while... 1127866908 M * Bertl np 1127866922 M * Bertl give me a second you get an intermediate patch 1127866932 M * shep Cool :-) 1127867051 M * Bertl http://vserver.13thfloor.at/Experimental/delta-rkill-fix01.diff 1127867053 M * Bertl http://vserver.13thfloor.at/Experimental/delta-rkill-fix02.diff 1127867061 M * Bertl reget the fix01, it changed 1127867067 M * Bertl (it's now called fix02 :) 1127867082 M * Bertl apply them in sequence with -l 1127867189 M * shep OK... 1127867230 M * Bertl mnemoc: http://vserver.13thfloor.at/Experimental/delta-rkill-feat01.diff 1127867243 M * shep First two done... 1127867250 M * Bertl mnemoc: (if you are still in need of it) 1127867298 M * Bertl mnemoc: and you want both fixes ontop of that ... 1127867328 M * mnemoc Bertl: ok 1127867372 J * Blissex pcg@82-69-39-138.dsl.in-addr.zen.co.uk 1127867386 M * Bertl welcome Blissex! 1127867395 A * Blissex waves hi! 1127867402 M * mnemoc me fears the remote-oops :p 1127867426 M * mnemoc i guess i'll prepare an small test build to qemu 1127867436 M * Bertl mnemoc: so better check the code thoroughly ... 1127867454 M * Bertl but yes, qemu is always a good idea for checking things out 1127867481 A * Bertl just verified the BME patches for 2.6.14-* 1127867514 M * shep Ugh: http://pastebin.com/376360 1127867561 M * Bertl hmm, is your kernel that old? .. 1127867567 A * Bertl is checking now ... 1127867605 M * shep I'll get the later one if you need me to... 1127867703 Q * jayeola Quit: night chaps 1127867845 M * Bertl shep: okay, remove the #include line, the int vx_info_kill() should be there 1127867858 M * Bertl shep: but this is a hack, you'll need to update later ... 1127867865 M * shep OK 1127867880 M * Bertl shep: you'll get a warning (like that one) but it should compile 1127868079 M * shep That worked. Rebooting... 1127868315 M * shep Still timed out on vserver stop 1127868440 J * gndmstr ~gndmstr@ip1.pathworx.sbbsnet.net 1127868496 M * Bertl shep: okay, let's use the debug feature now ... 1127868499 M * Bertl welcome gndmstr! 1127868505 M * gndmstr hi Bertl 1127868509 M * gndmstr hey shep 1127868515 M * shep Hey :-) 1127868649 M * Bertl hmm, nah, we do a simpler test first ... 1127868650 M * mnemoc Bertl: fix01 is newer than fix02? 1127868667 M * Bertl mnemoc: yes, but apply them in order 01, 02 ... 1127868676 M * mnemoc ok 1127868692 M * Bertl shep: start the guest again, then do 1127868730 M * shep (vserver running) 1127868774 M * Bertl vkill --xid -s INT -- 1 1127868790 M * Bertl vps auxww | grep gentoo 1127868812 M * shep mnemonic ~ # vps auxww | grep gentoo 1127868813 M * shep root 7296 3253 gentoo 0.0 0.0 1452 496 ? Ss 01:51 0:00 init [0] 1127868813 M * shep root 8488 0 MAIN 0.0 0.0 1504 464 pts/1 S+ 01:53 0:00 grep gentoo 1127868856 M * Bertl hmm ... 1127868900 M * Bertl looks like we need some more debug info ... I'll prepare another small patch 1127868906 M * mnemoc .oO( his machine is called mnemonic? )o 1127868913 M * shep Hehe yeah :-) 1127868938 M * mnemoc :) 1127868976 Q * brc Ping timeout: 480 seconds 1127869003 M * shep One before this was called MysteryMachine (vservers were scrappy, scooby, frddie, velma etc...) 1127869008 J * Greek0 ~greek0@81.189.246.175 1127869011 M * shep Novelty soon wore off.. :-P 1127869018 M * mnemoc :) 1127869042 M * Bertl Greek0: can't sleep? 1127869418 J * Johnsie ~john@acs-24-154-53-217.zoominternet.net 1127869425 M * Bertl welcome Johnsie! 1127869471 M * Johnsie Hi Bertl! Thank you. :) 1127869492 Q * yarihm Quit: Leaving 1127869552 M * shep Bertl: going to have to call it a night: back to back meetings tomorrow, all of which will be boring and pointless :-) Any chance we can pick this up tomorrow? 1127869612 M * Bertl sure ... btw, patch is ready ... 1127869625 M * shep OK - will apply that first :-) 1127869648 M * Bertl cd .. 1127869652 M * Bertl *arg* 1127869672 M * shep :-) 1127869872 M * Bertl hmm, how did I manage to make fix02 a -p2 patch 1127869896 M * shep :-) 1127869985 M * Bertl http://vserver.13thfloor.at/Experimental/delta-rkill_debug-feat01.diff 1127870008 M * Bertl make should be quick 1127870109 M * Bertl (after that + reboot do) 1127870152 M * Bertl echo 48 >/proc/sys/vserver/debug_misc 1127870180 M * shep is it just a patch -p1 < delta-rkill_debug-feat01.diff for this? 1127870196 M * shep Seems unhappy with files.... 1127870229 M * Bertl hmm, try with -l and in what way? 1127870255 M * shep mnemonic vserver # patch -p1 -l < ~/delta-rkill_debug-feat01.diff 1127870255 M * shep can't find file to patch at input line 6 1127870255 M * shep Perhaps you used the wrong -p or --strip option? 1127870293 M * Bertl we are talking about that one http://vserver.13thfloor.at/Experimental/delta-rkill_debug-feat01.diff 1127870311 M * shep Yep 1127870312 M * Bertl looks like a simple -p1 to me ... 1127870330 M * Bertl you sure you are inside the kernel tree? 1127870344 M * mnemoc pwd :) 1127870347 M * shep in the vserver subdir.... Oops - sorry... 1127870353 M * mnemoc *g* 1127870354 M * Bertl ah :) 1127870375 M * shep mnemonic linux # patch -p1 -l < ~/delta-rkill_debug-feat01.diff 1127870375 M * shep patching file kernel/vserver/helper.c 1127870375 M * shep Reversed (or previously applied) patch detected! Assume -R? [n] 1127870425 M * shep Should I assume -R? 1127870507 M * Bertl hmm, no ... 1127870516 M * Bertl maybe you managed to apply the first hunk? 1127870529 M * Bertl (by specifying the correct file) 1127870536 M * shep OK - will roll back and try again :-) 1127870590 M * shep mnemonic linux # patch -p1 -l < ~/delta-rkill_debug-feat01.diff 1127870590 M * shep patching file kernel/vserver/helper.c 1127870590 M * shep patching file kernel/vserver/signal.c 1127870590 M * shep Better :-) 1127870621 M * Bertl k, great! 1127870634 M * shep Gonna knock out the signal.h line again, though :-) 1127870653 M * Bertl yeah, right! 1127870706 M * shep Rebooting 1127870826 M * shep OK - back up. 1127870850 M * Bertl guest start, then the echo 1127870858 M * Bertl then guest stop 1127870887 J * Aiken_ ~james@tooax6-179.dialup.optusnet.com.au 1127870889 M * Bertl ah, and you did a testme.sh run, right? 1127870905 M * shep Yeah - all green 1127870919 M * Bertl do you have the first 4 lines at hand? 1127870922 M * shep Timeout again. Dmesg: 1127870925 M * shep vxD: vx_info_kill(dd92f000[#3253],1,2)* 1127870925 M * shep vxD: vx_info_kill(dd92f000[#3253],5894,2) = 0 1127870948 M * shep mnemonic ~ # ./testme.sh 1127870948 M * shep Linux-VServer Test [V0.13] Copyright (C) 2003-2005 H.Poetzl 1127870948 M * shep chcontext is working. 1127870948 M * shep chbind is working. 1127870948 M * shep Linux 2.6.13-vs2.1.0-pre5-gentoo i686/0.30.208/0.30.208 [Ea] (0) 1127870950 M * shep VCI: 0002:0001 273 03110116 1127870953 M * Bertl tx 1127871009 M * Bertl hmm, legacy support is still enabled ... 1127871035 M * shep Turn off and recompile? 1127871038 M * Bertl 5894 is the pid of the init, yes? 1127871082 M * shep Not sure as the server was forcably killed by vserver stop. Running again... 1127871129 M * shep Yes - PID corresponds with dmesg 1127871133 M * Bertl hmm, why are we sending SIGINT not SIGKILL ... 1127871160 M * Bertl hmm, we are not sending that at all 1127871170 M * shep OK - after that second start, dmesg reads: 1127871172 M * shep vxD: vs_reboot(dd587000[#3253],0) 1127871173 M * shep vxD: vx_info_kill(dd587000[#3253],1,2)* 1127871173 M * shep vxD: vx_info_kill(dd587000[#3253],7395,2) = 0 1127871173 M * shep vxD: vx_info_kill(dd587000[#3253],1,9)* 1127871173 M * shep vxD: vx_info_kill(dd587000[#3253],7395,9) = 0 1127871174 M * shep vxD: vx_info_kill(dd587000[#3253],0,9)* 1127871174 M * shep vxD: vx_info_kill(dd587000[#3253],0,9) = 0 1127871181 M * Bertl ah, much better 1127871198 M * shep Still getting timeout though 1127871209 Q * Aiken Ping timeout: 480 seconds 1127871211 M * Bertl yeah, do you have time stamps for the logging? 1127871230 M * shep Sep 28 02:31:28 mnemonic vxD: vs_reboot(dd587000[#3253],0) 1127871230 M * shep Sep 28 02:31:52 mnemonic vxD: vx_info_kill(dd587000[#3253],1,2)* 1127871230 M * shep Sep 28 02:31:52 mnemonic vxD: vx_info_kill(dd587000[#3253],7395,2) = 0 1127871230 M * shep Sep 28 02:32:22 mnemonic vxD: vx_info_kill(dd587000[#3253],1,9)* 1127871230 M * shep Sep 28 02:32:22 mnemonic vxD: vx_info_kill(dd587000[#3253],7395,9) = 0 1127871232 M * shep Sep 28 02:32:22 mnemonic vxD: vx_info_kill(dd587000[#3253],0,9)* 1127871232 M * shep Sep 28 02:32:22 mnemonic vxD: vx_info_kill(dd587000[#3253],0,9) = 0 1127871242 M * Bertl ah yes, right 1127871251 M * Bertl we are still missing the init action 1127871262 M * Bertl could you verify that the inittab line is correct? 1127871271 M * Bertl (regarding the ctrl-alt-del) 1127871298 M * shep # Trap CTRL-ALT-DELETE 1127871299 M * shep ca::ctrlaltdel:/sbin/shutdown -r now 1127871309 M * Bertl and I wonder, why init sent the disable ... ah, no runlevel 1127871351 M * Bertl ca:12345:ctrlaltdel:/sbin/shutdown -r now 1127871357 M * Bertl try that one instead :) 1127871400 M * Bertl (but actually that should not matter, IMHO) 1127871421 M * shep Timeout.... 1127871434 M * Bertl okay, let's start the guest, and then do 1127871450 M * Bertl vserver gentoo exec /sbin/shutdown -r now 1127871460 M * mnemoc on sysvinit, what the difference between shutdown -r now, reboot and init 6 ? 1127871480 M * Bertl the shutdown is the generic interface 1127871489 M * Bertl shutdown -r == reboot 1127871493 M * shep hehehe: 1127871494 M * Bertl shutdown -p == poweroff 1127871495 M * shep mnemonic ~ # vps auxww | grep gentoo 1127871495 M * shep root 11363 3253 gentoo 0.0 0.0 1452 496 ? Ss 02:37 0:00 init [6] 1127871495 M * shep root 12560 0 MAIN 0.0 0.0 1504 464 pts/1 S+ 02:37 0:00 grep gentoo 1127871510 M * mnemoc yes, but vs. init 6? 1127871510 M * Bertl shutdown -h == halt 1127871534 M * Bertl the telinit 6 will finally call 'halt' (part of the scripts) 1127871541 M * Bertl shep: okay, let's try: 1127871547 M * mnemoc as runit don't have those i did a few sh scripts to fake reboot, halt and shutdown 1127871556 M * Bertl vserver gentoo exec /sbin/reboot -f 1127871583 M * mnemoc telinit 6 = halt?? not 0? 1127871588 M * Bertl mnemoc: yeah, doesn't really matter, you just have to call the kernel/helper 1127871596 M * shep mnemonic ~ # vserver gentoo exec /sbin/reboot -f 1127871596 M * shep Killed 1127871604 M * Bertl mnemoc: guess that depends on the distro 1127871613 M * Bertl shep: so the context is gone now 1127871623 M * shep Yep - well and truely nobbled... 1127871635 M * shep Dunno if this helps (observation): 1127871657 M * Bertl so this leaves only one conclusion, your init does not send the reboot when signalled with INT 1127871664 M * shep Within the guest, if I issue halt, nothing happens. Issue it again, system comes down neat'n'quick. 1127871676 M * Bertl that's weird ... 1127871688 M * shep Hence issuing halt;halt makes it close down immediately. 1127871698 M * Bertl maybe your shutdown script really hangs? 1127871722 M * Bertl we are addressing this issue for such a long time, that I didn't consider that until now ... 1127871726 M * gndmstr shep what happens if you do vserver gentoo exec halt;halt 1127871734 M * shep Quite possibly.... 1127871747 M * Bertl gndmstr: his host shuts down :) 1127871753 M * gndmstr LOL 1127871754 M * gndmstr ok 1127871780 M * shep Would enclosing it with quites solve that? i.e. 1127871790 M * shep # vserver gentoo exec "halt;halt" 1127871799 M * gndmstr ill stay out of this one :) ... having enough troubles converting a radius 1127871800 M * Bertl shep: maybe you should raise the timeout and check what is running while the timeout is waiting 1127871817 M * shep Done that. Init just sits as init [6] 1127871837 M * Bertl nothing else there, just init? 1127871843 M * shep Yep. 1127871869 M * shep Tried manually killing off services first just to make sure there were no stragglers. Same behaviour. 1127871944 M * Bertl any log lines from init inside the guest? 1127871956 M * Bertl something like 'ignoring bla bla ...' 1127871992 M * Bertl shep: do you know how to enable CTRL-ALT-DEL on gentoo? 1127872004 M * shep Sep 28 02:37:32 gentoo syslog-ng[11750]: syslog-ng version 1.6.8 starting 1127872004 M * shep Sep 28 02:37:32 gentoo cron[11843]: (CRON) STARTUP (V5.0) 1127872004 M * shep Sep 28 02:37:32 gentoo init: no more processes left in this runlevel 1127872004 M * shep Sep 28 02:37:44 gentoo shutdown[11854]: shutting down for system reboot 1127872004 M * shep Sep 28 02:37:45 gentoo init: Switching to runlevel: 6 1127872006 M * shep Sep 28 02:37:46 gentoo syslog-ng[11750]: syslog-ng version 1.6.8 going down 1127872032 M * shep Err - just with inittab... 1127872032 M * shep ca:12345:ctrlaltdel:/sbin/shutdown -r now 1127872042 M * Bertl do the runlevel script for runlevel 6 have a reboot command at the end? 1127872050 M * Bertl *s 1127872068 M * Bertl reboot -f / halt -f actually 1127872078 M * shep l6:6:wait:/sbin/rc reboot 1127872080 M * Bertl mnemoc: yeah, 6 is reboot 0 is halt, no? 1127872099 M * mnemoc at least here :) 1127872112 M * Bertl I already said, I'm confused today :) 1127872137 M * Bertl shep: okay, and what does /sbin/rc reboot do? 1127872155 M * Bertl (maybe start the guest, then try:) 1127872162 M * shep LOL!:: 1127872162 M * shep mnemonic ~ # vserver gentoo exec /root/diediedie 1127872162 M * shep Killed 1127872171 M * shep Contents of diediedie: 1127872179 M * shep #!/bin/bash 1127872179 M * shep halt;halt 1127872212 M * shep rc is Gentoo's runlevel control... 1127872217 M * Bertl vserver gentoo exec bash -cx "/sbin/rc 6" 1127872226 M * mnemoc 292 INITCMD_START=( /sbin/rc default ) 1127872227 M * mnemoc 293 INITCMD_STOP=( /sbin/rc shutdown ) 1127872240 M * mnemoc ^---- util-vserver/vserver.functions 1127872257 M * shep mnemonic ~ # vserver gentoo exec bash -cx "/sbin/rc 6" 1127872257 M * shep + /sbin/rc 6 1127872257 M * shep * ERROR: runlevel 6 does not exist; exiting ... 1127872264 M * Bertl aha! 1127872276 M * shep rc halt would do it... 1127872288 M * Bertl okay, let's try that then ... 1127872296 M * Bertl (sounds like a gentoo bug to me :) 1127872308 M * shep mnemonic ~ # vserver gentoo exec bash -cx "/sbin/rc shutdown" 1127872308 M * shep + /sbin/rc shutdown 1127872308 M * shep * Stopping local ... [ ok ] 1127872308 M * shep * Stopping vixie-cron ... [ ok ] 1127872308 M * shep * Stopping syslog-ng ... 1127872318 M * shep That did it. 1127872321 A * mnemoc still download kernel source :( 1127872327 M * shep Marvelous :-D 1127872332 M * Bertl great! 1127872353 M * Bertl guess we'll talk this through tomorrow with Hollow ... 1127872374 M * Bertl (who is maintaining the gentoo guest layouts) 1127872404 M * Bertl I guess we also successfully tested the reboot_kill feature ... 1127872406 M * shep mnemoc: where's vserver.functions live? 1127872425 M * shep Bertl: Hollow, I think 1127872431 M * mnemoc Bertl: for 2.0.1, i would only need rkill feat,fix1 and fix2 right? 1127872441 M * Bertl shep: this can be configured via /etc/vservers ... 1127872452 M * mnemoc shep: /usr/lib/util-vserver 1127872456 M * Bertl mnemoc: yep, but I guess the debug won't hurt ... 1127872481 M * Bertl ah, no, misc is missing, right? 1127872504 M * Bertl (so skip the debug patch then) 1127872527 M * mnemoc ok 1127872544 M * mnemoc i'll try to give you feedback tomorrow..... my link stinks :( 1127872545 M * shep (xgentoo) 1127872545 M * shep INITCMD_START=( /sbin/rc default ) 1127872545 M * shep INITCMD_STOP=( /sbin/rc shutdown ) 1127872549 M * shep Already in there... 1127872556 M * shep Hmmmm.... 1127872562 M * Bertl mnemoc: why are you downloading the entire kernel? 1127872578 M * mnemoc i don't have it on the laptop 1127872584 M * mnemoc to play on qemu 1127872595 M * Bertl yeah, but I guess you have an older version there, no? 1127872605 M * mnemoc i could just try remotely if you promise the machine will came back :) 1127872618 M * Bertl I'm not promising anything today :) 1127872618 M * mnemoc 2.6.11.12 1127872623 M * mnemoc :) 1127872652 M * Bertl yes, so deltas would have been faster, I guess ... 1127872677 M * Bertl (worst case scenario: 2.6.11.12 -> 2.6.11 -> 2.6.12 -> 2.6.13 -> 2.6.14-rc2 :) 1127872702 M * mnemoc i can't.... devfs acts odd at 2.6.11.12... i fear to step forward 1127872715 M * mnemoc i prefer to backport :p 1127872751 M * mnemoc and svk is friendly 1127872793 M * Bertl shep: you want to change the runlevel 6 to call /sbin/rc shutdown or similar 1127872827 M * Bertl (or alternatively, change the ctrl-alt-del to /sbin/rc shutdown 1127872920 M * shep Still timing out.... 1127872974 M * shep Really _must_ go and pass out now :-) 1127872991 M * shep Will have anoher bash tomorrow. Thanks for your help, guys... 1127873054 M * mnemoc sleep well shep 1127873094 M * mnemoc i have to keep fighting gcc 3.4.4 to build against dietlibc :\ 1127873184 M * Bertl shep: okay, good night and thanks! 1127873399 M * shep No probs mate - thank YOU! 1127873417 M * shep Should be ready for round two tomorrow :-) See ya... 1127873421 Q * shep Quit: KVIrc 3.2.0 'Realia' 1127873755 M * gndmstr hehe poor guy.. he has an early day tomorrow too and its around 3am there 1127873815 M * Bertl well, 4am here, but hopefully no early day .. 1127873899 M * gndmstr i was up till 2 yesterday working on this stuff... 1127873931 M * gndmstr shep and i have the same problem.. but for me its only on this host (3rd including my test bed) 1127873938 M * gndmstr dont have it on the first production host 1127873999 M * gndmstr but mine extends some but im not gonna worry until the shutdown gets cleared... when i had a few crashes shutting down a guest im working on , somehow it killed another guest as well... left the pid but it no longer was running 1127874001 M * gndmstr weird 1127874029 M * gndmstr after i get this radius conversion sorted then ill worry about what shep is worrying about :) 1127874066 M * Bertl well, maybe you're lucky and it is sorted till then :) 1127874171 M * gndmstr since i dont intend to stop any of the guests on this machine it should be 1127874204 M * gndmstr wonder if the fact that a full qmail installation is running on the host at this moment coudl be causing problems too... after the radius, im gonna move the qmail into a guest to get it off the host 1127874246 M * gndmstr this is just a temporary host.. im juggling 'machines' to free rack space to make room for the monster the boss is gonna put in.. then i have to move all the guests over to it 1127874294 M * gndmstr im hoping by then all these seemingly gentoo-unique problems will be fixed :) 1127874302 M * gndmstr talking a week or 2 at least 1127874352 M * gndmstr wonder if it would fix things if i did a normal install and then changed the base layout myself to work as a guest rather than use hollow's stuff.. i suspect he has special setups which accidently get pushed into the ebuilds 1127874396 M * Bertl guess that would work too 1127874459 M * gndmstr what made me wonder is the default runlevel has a link for local to some non-existant tmp area when it should be pointing to the local exec script 1127874498 M * gndmstr and boot runlevel all point to that black hole instead of init.d names.. most of the critical init.d names like networking etc are all pointing to a dummy script anyway 1127874554 Q * dddd44 Ping timeout: 480 seconds 1127875759 M * gndmstr gonna quit so i can concentrate fully on this for another half hour then get some sleep. see you tomorrow 1127875795 M * Bertl cya! 1127875802 M * Bertl will go to bed now too ... 1127875860 M * Bertl night everyone, cya tomorrow ... 1127875866 N * Bertl Bertl_zZ 1127875893 M * gndmstr night 1127875899 Q * gndmstr Remote host closed the connection 1127879234 J * sebi ~sebi@C4800.c.strato-dslnet.de 1127879343 Q * sebi_ Ping timeout: 480 seconds 1127879598 Q * micah Ping timeout: 480 seconds 1127879663 Q * litage Ping timeout: 480 seconds 1127880547 J * maharaja maharaja@ip52.ipax.at 1127881121 J * litage ~nick@203.201.96.22 1127881743 Q * douglas Read error: Connection reset by peer 1127883295 J * dddd44 dhb55@218.111.178.26 1127885825 Q * dddd44 Read error: Connection reset by peer 1127885836 J * dddd44 dhb55@218.111.178.26 1127886853 Q * Johnsie Quit: G'bye! 1127887140 J * Mystine ~meerzill@fire.webotek.com 1127887407 J * Johnsie ~john@acs-24-154-53-217.zoominternet.net 1127889095 M * Mystine can someone tell me what im doing wrong? i download source code of util-vserver => ./configure => make => make install => make install-distribution 1127889128 M * Mystine vprocunhide does not install anywhere so i have to copy it manually to /usr/local/sbin => when i run it i get => Can not find util-vserver installation (the file '/usr/lib/util-vserver/util-vserver-vars' would be expected); aborting... 1127893511 Q * monrad Quit: Leaving 1127894087 J * prae ~prae@gut75-1-81-57-27-189.fbx.proxad.net 1127895637 J * mrec ~revenger@p54B02396.dip0.t-ipconnect.de 1127895757 Q * mrec_ Ping timeout: 480 seconds 1127895942 J * menomc ~amery@200.75.27.15 1127896052 Q * mnemoc Ping timeout: 480 seconds 1127896052 N * menomc mnemoc 1127896204 Q * Aiken_ Quit: Leaving 1127897531 J * yarihm ~yarihm@84-74-18-28.dclient.hispeed.ch 1127897647 Q * Johnsie Ping timeout: 480 seconds 1127897744 J * erwan_taf ~erwan@81.80.43.77 1127898353 P * erwan_taf Leaving 1127898800 J * Johnsie ~john@acs-24-154-53-217.zoominternet.net 1127898934 Q * yarihm Quit: Leaving 1127899487 J * yarihm ~yarihm@84-74-18-28.dclient.hispeed.ch 1127901197 J * shep ~kvirc@217.205.252.71 1127904222 Q * shep Quit: KVIrc 3.2.0 'Realia' 1127904297 Q * dddd44 Read error: Connection reset by peer 1127904425 J * Doener ~doener@i5387D0BB.versanet.de 1127904509 J * dddd44 ~dhb55@218.111.178.26 1127905505 Q * dddd44 Read error: Connection reset by peer 1127905673 Q * VooDooMaster Quit: Do fish get thirsty? 1127906926 N * Bertl_zZ Bertl 1127906931 M * Bertl good morning folks! 1127906964 M * Bertl Mystine: when you do the ./configure part, what is the last page (25-30 lines) you get? could you upload that to patebin.com? 1127907101 Q * maharaja Ping timeout: 480 seconds 1127907363 M * Doener morning Bertl! 1127907375 M * Doener finally got a connection again! (only 1.5 weeks late ;) 1127907376 M * Bertl good morning Doener! how are you? LTNS! 1127907403 M * Doener i'm fine, currently enjoying to read up on my mails and having an eye on my lunch 1127907475 M * Bertl ah, running sushi? 1127907508 M * Doener rice with "Hühnerfrikasse" (no idea what that is in english)... 1127907544 M * Bertl well, 'frikasse' means shredded stuff ... 1127907550 M * Doener but i manage to forget about my food all the time... four times something is "übergekocht" 1127907560 M * Bertl so let's go for rice and shredded chicken :) 1127907583 M * Doener yeah, sounds good :) 1127907601 M * Bertl no, fricasse = frikassee 1127907956 Q * Johnsie Ping timeout: 480 seconds 1127908459 J * Johnsie ~john@acs-24-154-53-217.zoominternet.net 1127908914 M * Bertl wb Johnsie! 1127908972 Q * Doener Quit: Leaving 1127911057 M * lonewolff afternoon all 1127911173 M * Bertl good afternoon! 1127911358 M * entroposcope Bertl, I caught on mailing list archives a discussion you had with someone regarding automount and vserver guests 1127911381 M * Bertl hmm, yes? 1127911404 M * entroposcope where you mentioned that vnamespace might be the right tool to start automounter ? 1127911434 M * entroposcope "did you try to mount the autofs 'just' inside the 1127911435 M * entroposcope vserver namespace (well, that's what I would do anyways) " 1127911458 M * entroposcope context of host, namespace of guest 1127911482 M * entroposcope is what it appears you were getting at. 1127911527 M * entroposcope is there a pre... script that runs at that phase of guest startup? 1127911547 M * Bertl yes, there are plenty of, and they have different states/environments ... sec 1127911562 A * entroposcope trying to get nfs client working completely inside the guest, and having trouble now getting sunrpc pseudo filesystem to mount inside the guest 1127911574 M * entroposcope appears that it's a fs for rpc pipes 1127911589 M * entroposcope and that loading the sunrpc kernel module mounts it 1127911598 M * entroposcope that's what the startup script says, at least. 1127911606 M * Bertl http://vserver.13thfloor.at/Experimental/UTIL-VSERVER/SCRIPTS/ 1127911631 M * Hollow heya! 1127911766 M * Bertl hey Hollow, we have some gentoo issues/ideas/stuff ... 1127911794 A * Bertl is currently talking with phreak, let me know when you got some time too ... 1127911801 M * Hollow yeah... i saw some lines today morning.. what's up? 1127911809 M * Hollow i've time now 1127911814 M * Bertl okay, great ... 1127911830 M * Bertl two issues, one I'm analyzing right now is the hardened dietlibc build 1127911844 M * Hollow yeah, just read the backlog in #gentoo-vserver 1127911848 M * Bertl it seems that the hardened version replaces the inline syscalls with out-of-line calls 1127911861 M * Hollow but that's phreaks territory.. i don't use hardened 1127911866 M * Bertl I guess that's a matter of some defines, I'll check that 1127911878 M * Bertl the other thing is, the reboot/stop/shutdown 1127911880 M * Hollow we'll probably take maintainership for dietlibc 1127911921 M * Bertl we had a bunch of 'different' gentoo guest systems ... and it seems that there are some differences ... 1127911935 M * Bertl first let me list the players ... 1127911939 M * Hollow yup 1127911957 M * Bertl - init and the ctrl-alt-del entry 1127911979 M * Bertl - /etc/rc /sbin/rc ... 1127911994 M * Bertl - some system startup disabling ctrl-alt-del 1127912017 M * Bertl now, we fixed the kernel reboot_kill flag yesterday 1127912030 M * Bertl so that it ignores everything but the REBOOT/HALT/POWEROFF 1127912046 M * Bertl (which was a reasonably thing to do) 1127912047 M * Hollow there is no /etc/rc in gentoo 1127912072 M * Bertl yes, that's why I listed both pathes ... 1127912094 M * Bertl the issue we encounter yesterday was the following: 1127912122 M * Bertl - after adding 'ca' to inittab, /sbin/reboot now is called 1127912136 M * Bertl or /sbin/shutdown -h now / -r now (whatever) 1127912140 M * Hollow yup 1127912174 M * Bertl - this finally did invoke /sbin/rc 6 1127912184 M * Bertl which bailed out with unknown runlevel 6 :/ 1127912209 M * Bertl - replacing the entry with a direct call to halt or so did work fine 1127912231 M * Hollow ehm.. who does call /sbin/rc 6? 1127912234 M * Bertl shep will show up today for further analysis 1127912307 M * Bertl probably the runlevel 6 was just some misunderstanding, I was confused yesterday ... 1127912329 M * Bertl I'm more worried about gentoo disabling 'ca' on startup 1127912338 M * Hollow we fixed it.. 1127912344 M * Bertl (that's what caused the guest to terminate on startup yesterday) 1127912356 M * Bertl yeah, it was fixed in the kernel too ... 1127912376 M * Hollow what was fixed in kernel? 1127912387 M * Bertl sec 1127912388 M * Hollow where does ca appear in the kernel? 1127912427 M * Bertl http://vserver.13thfloor.at/Experimental/delta-rkill-fix02.diff 1127912560 M * Hollow hm, kay.. 1127912591 M * Bertl makes sense, no? 1127912593 A * Hollow shrugs 1127912599 M * Hollow what does it fix? 1127912611 M * Bertl the gentoo guest we had yesterday did call 1127912643 M * Bertl *sec* 1127912662 M * Bertl * CAD_OFF Ctrl-Alt-Del sequence sends SIGINT to init task. 1127912672 M * Bertl * CAD_ON Ctrl-Alt-Del sequence causes RESTART command. 1127912700 M * Bertl which is not supposed to kill the guest :) 1127912723 M * Hollow ok, makes sense, but why did the guest call these? 1127912762 M * Bertl no idea, I assume some startup script (or maybe init?) does that on startup 1127912777 M * Bertl to make sure that init gets the signal 1127912797 M * Hollow hmm... afaik baselayout-vserver does not, so probably it's not a gentoo issue, but rather a sysvinit issue 1127912798 M * Bertl we might want to track that in the future ... 1127912832 M * Hollow but ok... it's fixed 1127912835 M * Bertl anyway this (or similar) code will get into 2.0.1 1127912870 M * Bertl so it should work for the known cases then ... given that the gentoo guests have ca enabled and shutdown properly on SIGINT to init 1127912913 M * Hollow afaik init does not kill itself on SIGINT, right? 1127912923 M * Bertl yes, correct 1127912930 M * Hollow ok, just wanted to verify 1127912943 M * Bertl this is done by halt/reboot/poweroff -f 1127912973 M * Hollow yeah, so in the shutdown process we should call halt -f (and we do so currently) 1127913040 M * entroposcope how do I tell what capability or flag is required for an operation inside a guest that gets denied because of wrong permissions? 1127913202 M * Bertl best way: read the kernel source ... 1127913218 M * Hollow Bertl: init does the CAD call 1127913219 M * Bertl easiest way: tell me about it and ask me ... 1127913240 M * Bertl Hollow: ah, good, thought so ... 1127913271 M * entroposcope heh. nothing inbetween, eh? no magic flags to strace, for example, that will give me output that will expose the needed capabilities? 1127913292 M * Hollow so, what's left then? we have the ca inittab entry, we call halt/rebot -f, rkill is fixed.. 1127913297 M * Bertl entroposcope: not that I know of ... it works like this: 1127913309 M * Bertl userspace calles kernel with sys_wossname() 1127913319 M * Bertl kernel checks and returns errorcode ... 1127914100 M * entroposcope ok 1127914108 M * entroposcope maze of twisty passages and all tat 1127914109 M * entroposcope that 1127914111 M * entroposcope so 1127914154 M * entroposcope for what I'm trying to do at the moment, it looks like I need both CAP_SYS_ADMIN and binary_mount 1127914187 M * entroposcope can anyone summarize what risks I'm going to take by setting SYS_ADMIN in a guest? 1127914209 M * entroposcope (or point me to someplace?) 1127914227 M * entroposcope if it's find and grep over kernel source, so be it. 1127914229 M * entroposcope ;-) 1127914773 J * micah micah@micha.hampshire.edu 1127914867 M * Bertl welcome micah! 1127914896 M * Bertl entroposcope: SYS_ADMIN basically allows the guest too root your host :) 1127914907 M * entroposcope bah 1127914910 M * micah hi Bertl! I've been gone, but I'm back now and catching up 1127914914 M * entroposcope I figured it was something like that 1127914918 M * Bertl entroposcope: where do you need that` 1127914924 M * Bertl s/`/? 1127914929 M * entroposcope but that's the flag that it looks like I need to get mount of rpc_pipefs working inside guet 1127914953 M * Bertl what is rpc_pipefs? 1127914974 M * entroposcope that's the psuedo fs used by nfs clients for setting up rpc pipes for NFS 1127914993 M * Bertl havent seen it in the kernel .. where is it? 1127915021 M * entroposcope tracking it back from kernel's net/sunrpc/rpc_pipe.c 1127915054 M * entroposcope ends rpc_get_mount uses simple_pin_fs 1127915083 M * entroposcope which in turn uses do_kern_mount 1127915121 M * entroposcope and do_kern_mount seems to require CAP_SYS_ADMIN and VXC_BINARY_MOUNT 1127915131 M * Bertl ah, no ... 1127915153 Q * Mystine Ping timeout: 480 seconds 1127915154 M * Bertl it requires either CAP_SYS_ADMIN, or (VXC_BINARY_MOUNT and FS_BINARY_MOUNTDATA) 1127915180 M * entroposcope hrm 1127915181 M * Bertl so I assume that the pipefs doesn't match the binary mount conditions 1127915207 M * Bertl could you elaborate on the use/function of this pipefs? 1127915213 M * entroposcope well 1127915219 A * Bertl still doesn't understand the purpose/usage 1127915231 M * entroposcope it appears to be "mounted" when the nfs kernel mod is loaded 1127915253 M * entroposcope and the kernel based nfs client appears to require it in order to mount nfs filesystems 1127915283 M * entroposcope it looks like it's used to do IPC between various nfs programs 1127915323 M * Bertl hmm, kernel mod loading happens on the host, no? 1127915328 M * entroposcope yes 1127915332 M * entroposcope and the kernel is loaded in the host 1127915336 M * Bertl so this should work fine then ... no? 1127915336 M * entroposcope er, the module 1127915344 M * entroposcope well, it -should-, but it doesn't 1127915356 M * Bertl modprobe 'nfs' fails? 1127915381 M * entroposcope inside host, works fine 1127915385 M * entroposcope inside guest, I haven't tried. 1127915390 M * entroposcope though lsmod shows it loaded 1127915402 M * Bertl well, the host should be sufficient no? 1127915414 M * entroposcope apparently not. 1127915416 M * Bertl once the module is loaded, it is available in all guests 1127915423 M * entroposcope yes, I'd think so, too 1127915424 M * entroposcope but 1127915428 M * entroposcope this what I can tell you 1127915434 M * Bertl tell me :) 1127915444 M * entroposcope w/o CAP_SYSADMIN, and with binary_mount and mount capabilities... 1127915466 M * entroposcope I can't mount the sunrpc, rpc_pipefs filesystem inside the guest 1127915474 M * entroposcope and w/o that, nfs mounts don't work 1127915474 M * Bertl why would you want to? 1127915488 M * entroposcope so that I can do automount, or any nfs client mounts fully inside the guest 1127915488 M * Bertl I never mounted anything for nfs ... 1127915521 M * Bertl you're sure about that? 1127915534 M * entroposcope well 1127915550 M * entroposcope I've spent the last day or so trying a bunch of different permutations 1127915555 M * entroposcope all without success 1127915573 M * Bertl so how do you conclude that this would help? 1127915573 M * entroposcope CAP_SYSADMIN, blunt tool that it is, made everything work 1127915583 M * Bertl not very unexpected ... 1127915587 M * entroposcope no, I suppose not 1127915596 M * entroposcope and in my environment, -perhaps- a worthwhile risk 1127915601 M * entroposcope but I'd rather not if I can help it. 1127915612 M * Bertl did you track down _what_ actually failed in your tests? 1127915623 M * entroposcope well 1127915636 M * entroposcope the mount of NFS stuff always got permission denied 1127915638 M * entroposcope ENOPERM 1127915671 M * entroposcope and the host system logged an error to the console: 1127915674 M * entroposcope :net/sunrpc/rpc_pipe.c: rpc_lookup_parent failed to mount pseudofilesystem 1127915674 M * entroposcope NFS: cannot create RPC client. 1127915748 M * entroposcope which is an error that gets logged when rpc_get_mount() fails 1127915800 M * Bertl okay, but why does your NFS try to do those things anyway? 1127915813 M * entroposcope er, that's what the linux NFS client implementation does 1127915819 M * entroposcope I don't know why it does these tihngs 1127915823 M * Bertl hmm ... sure? 1127915828 M * entroposcope I didn't know it did any of it until I tried to get it to work 1127915830 M * entroposcope hrm 1127915831 M * entroposcope well 1127915845 M * entroposcope it -could- be the Redhat nfs client implementation 1127915853 M * Bertl I'm just wondering, because I never heard or have seen of the rpcpipefs before ... 1127915858 A * entroposcope is not a fan of redhat, but that's what I'm working with 1127915874 M * Bertl I have to admit, the code is there in 2.6.13/14 :) 1127915878 M * entroposcope otoh, the kernel source that I'm reading is right there 1127915879 M * entroposcope heh 1127915903 M * Bertl I'm just wondering if this isn't some feature nobody actually needs ... 1127915933 M * Bertl OTOH, it might be something which is completely handled in kernel space ... 1127915935 M * entroposcope I'd expect (and this is just speculation) that it's an optimization to speed up communication between the various proceeses involved in NFS 1127915954 M * entroposcope and that a userspace NFS implementation doesn' 1127915961 M * Bertl might be, in this case, you definitely don't want it ... 1127915969 M * entroposcope t get to use them, but is more portable and/but slower 1127915973 M * Bertl because it would require proper virtualization first 1127915995 M * Bertl otherwise your guests would do crosstalk ... 1127916136 M * entroposcope just got email from the guy who was trying to get this work back in april 1127916157 M * entroposcope he gave up, citing problems in the kernel with automount and namespaces 1127916180 M * entroposcope although I think it's fair to say the same thing about nfs mounts and namespaces 1127916186 M * entroposcope and that's what you're talking about, right? 1127916210 M * entroposcope since NFS mount isn't namespace and/or context aware, it really won't work correctly inside vservers 1127916211 M * entroposcope ? 1127916661 M * Bertl well, the automount itself is a separate issue 1127916698 M * Bertl I'd suggest to isolate the various aspects and analyze the requirements separated 1127916735 M * Bertl entroposcope: if you are interested in improving those things, we can work on that ... but it probably requires a bunch of tests and kernel compiles ... 1127916771 M * entroposcope yes, indeed. 1127916788 M * entroposcope I'm not sure how interested I am. 1127916800 M * entroposcope extremely, in the sense that if it already worked, I'd be using it 1127916809 M * Bertl for example, we _know_ that nfs mounts work perfectly fine when done on the host (for the guests) 1127916833 M * Bertl (this is how lycos has set up their stuff) 1127916850 M * entroposcope right 1127916858 M * Bertl I'm also convinced that the auto mounter is namespace aware (intentionally or accidentially :) 1127916901 M * Bertl I'm pretty sure that the automount stuff isn't touched by linux-vserver yet, so it is for sure not virtualized 1127916919 M * entroposcope the lycos folks do a mount in host of filer:/some/path /vserver/foo/mountpoint ? 1127916949 M * Bertl yep 1127916969 M * Bertl and they use the NFS tagging we implemented for them to make this xid aware 1127916978 M * entroposcope right 1127917027 M * entroposcope nothign wrong with that, but it doesn't really fit into how we're doing our NFS mounts, so it's not terribly appealing or useful for me 1127917041 M * Bertl never said that :) 1127918242 M * entroposcope so, in general, what has to happen to properly virtualize something? 1127918257 M * entroposcope if this is an impossible question, just let me know. 1127918258 M * entroposcope ;-) 1127918346 J * fluor ~fluor@tanneries.squat.net 1127918361 M * fluor do you guys know of any issues with running scponly in vservers? 1127918904 M * Bertl welcome fluor! 1127918914 M * Bertl no, what issues do you encounter/expect? 1127920630 M * Bertl am I still here? 1127920682 M * Bertl entroposcope: depends, sometimes it's just adding the xid to some hash/struct ... in other cases, it can be quite tricky 1127920693 M * Bertl entroposcope: but that's where I can help ... 1127921051 M * entroposcope ack. 1127921336 J * liquid3649 ~inet@p54976F62.dip.t-dialin.net 1127921544 M * liquid3649 hi 1127921682 M * Bertl welcome liquid3649! 1127921769 J * stefani ~stefani@superquan.apl.washington.edu 1127921780 M * Bertl welcome stefani! 1127921780 J * monrad ~monrad@port487.ds1-by.adsl.cybercity.dk 1127921787 M * Bertl welcome monrad! :) 1127921792 M * stefani hola Bertl 1127921805 M * monrad hi 1127921876 M * liquid3649 i still got a small problem with connectin to my vserver via ssh 1127921878 M * liquid3649 http://pastebin.com/376910 1127921910 M * liquid3649 i already change the listening adress and the port 1127921940 M * Bertl looks like your 'shell' or whatever sshd starts fails ... 1127921952 M * Bertl any logs inside the guest? in /var/log/messages or so? 1127922003 M * liquid3649 http://pastebin.com/376912 1127922068 M * liquid3649 something about loginuid 1127922132 M * Bertl yep, that's pam magic for kernel tracing 1127922144 M * Bertl just remove the pam entry and it should be fine 1127922176 M * Bertl we will make a workaround pretty soon (kernel side) but it's just userspace doing unnecessary things ... 1127922216 M * liquid3649 thx that it 1127922228 M * Bertl you're welcome! 1127922389 M * liquid3649 another thing 1127922402 M * liquid3649 its about the *.confs 1127922445 M * liquid3649 do i really need them and where can i find man for them 1127922505 M * andrew_ Bertl: hi 1127922510 N * andrew_ AndrewLee 1127922573 M * AndrewLee Bertl: I have a question with util-vserver, does util-vserver compiles required a vserver patched kernel? 1127922782 M * AndrewLee Bertl: Remember I filed a bug to Debian for util-vserver doesn't work on powerpc, the way to fix the bug is apply the fix02? 1127922831 M * AndrewLee Bertl: Now the util-vserver package maintainer has applied the fix02 patch, but still doesn't work for powerpc, but after I rebuilt the package from source, it works. 1127922882 M * AndrewLee Bertl: So I want to ask if util-vserver required a vserver patched kernel for compiling? 1127923606 M * Bertl welcome AndrewLee! 1127923647 M * Bertl AndrewLee: no, just a proper cross build environment 1127923689 M * Bertl AndrewLee: I don't know how debian folks build the non x86 packages 1127923706 M * Bertl I heard that they build it on the real hardware, which would make sense 1127923733 M * AndrewLee Bertl: Build on a buildd on powerpc. 1127923751 M * AndrewLee Bertl: Yes, on real hardware. 1127923760 M * Bertl the kernel should not be looked at by the utils ... 1127923768 M * AndrewLee Bertl: And everyone can access to the build log. 1127923782 M * Bertl nevertheless, they tools require a proper environment ... 1127923795 M * Bertl AndrewLee: where can I look at the log? 1127923821 M * AndrewLee Bertl: here is: http://buildd.debian.org/fetch.php?&pkg=util-vserver&ver=0.30.208-2&arch=powerpc&stamp=1127682182&file=log&as=raw 1127923868 M * AndrewLee Bertl: I found the wrong syscall: vserver(2) syscall#: 273/default 1127923891 M * AndrewLee Bertl: This version is 0.30.208 with the fix02 patch already. 1127923935 M * Bertl yeah, saw it, is there access to the config.log too? 1127924008 M * AndrewLee Bertl: Seems no..:( 1127924029 M * AndrewLee Bertl: Let me ask this question on #debian-devel 1127924146 M * AndrewLee Bertl: I confirmed, nowhere..:( 1127924162 M * AndrewLee Bertl: Why config.log is important? 1127924281 M * Bertl because I _assume_ the tools get the __NR_vserver from asm/unistd.h 1127924305 M * AndrewLee Bertl: The suggest me to ask buildd admin to send me the file. 1127924333 M * Bertl good idea ... 1127924338 M * AndrewLee Bertl: What files will possible need? I can ask on the same time? 1127924381 M * Bertl hard to tell, config.log maybe /usr/include/{linux,asm} as tarball? 1127924459 Q * Blissex Remote host closed the connection 1127924475 M * AndrewLee Bertl: Alright, I am writting email to buildd admin for the requests. 1127924517 M * Bertl thanks! 1127924566 Q * monrad Quit: Leaving 1127925554 M * Bertl okay, off for a while ... back later ... 1127925567 N * Bertl Bertl_oO 1127925588 Q * prae Quit: Execute Order 69 ! 1127927321 M * AndrewLee Bertl_oO: I sent the email to buildd admin for request more files and also cc to bug tracking system, you can see this bug report on: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=328209 1127928682 J * prae ~benjamin@sherpadown.net 1127930463 J * monrad ~monrad@213083190134.sonofon.dk 1127930524 J * liquid__ ~liquid@p54977228.dip.t-dialin.net 1127930766 Q * liquid3649 Ping timeout: 480 seconds 1127930966 Q * liquid_ Ping timeout: 480 seconds 1127931873 J * oliwel ~mail-at-o@host-62-245-151-178.customer.m-online.net 1127931881 A * oliwel waves hello to the crowd 1127931971 M * oliwel Hmm, seems that nobody is here 1127932077 A * mnemoc looks at himself 1127932217 M * oliwel hi mnemoc 1127932258 M * mnemoc bye oliwel :\ 1127932263 M * mnemoc i have to go _now_ 1127932449 M * oliwel ok bye 1127932968 M * lonewolff is there a lit if the files which would be required in /dev on a gues vserver? 1127932992 M * lonewolff and am i right in saying no init scripts releating to hardware are required? 1127933063 M * lonewolff list of* 1127933145 J * liquid3649 ~inet@p54977228.dip.t-dialin.net 1127933965 Q * oliwel Quit: Chatzilla 0.9.68.5 [SUSE 1.0.6-4.1/20050715] 1127934233 Q * entroposcope Remote host closed the connection 1127934459 Q * SiD3WiNDR Ping timeout: 480 seconds 1127934556 J * arne^ ~arne@c212209.adsl.hansenet.de 1127934570 M * arne^ hi 1127934625 M * TheSeer hey, someone from hamburg ;> 1127934629 M * TheSeer or not? 1127934637 M * arne^ yes, hamburg 1127934678 M * TheSeer ;) 1127934683 J * SiD3WiNDR luser@bastard-operator.from-hell.be 1127934716 M * arne^ i'm interested in the current state of NGNet 1127934804 M * arne^ are there any roadmaps ? 1127934922 M * TheSeer hmm.. none i'm aware of.. but then i hardly follow the ng development atm.. 1127934929 M * TheSeer try to catch Bertl when he's back 1127934936 M * TheSeer or drop a mail to the mailinglist 1127934968 M * arne^ thx 1127935058 M * daniel_hozac Bertl said the other day that ngnet was the next target on the hit list. 1127935143 Q * Nicoli Read error: Connection reset by peer 1127935153 M * liquid3649 http://pastebin.com/377098 is that normal in 'service --status-all ?? 1127935201 N * liquid__ liquid 1127935671 J * Nicoli ask@208.53.159.170 1127937449 J * entroposcope ~entroposc@user-0c992og.cable.mindspring.com 1127938164 J * mrec_ ~revenger@p54B03929.dip0.t-ipconnect.de 1127938581 Q * mrec Ping timeout: 480 seconds 1127938582 Q * mrec_ Read error: Connection reset by peer 1127938627 J * mrec ~revenger@p54B03929.dip0.t-ipconnect.de 1127938754 Q * mrec Read error: Connection reset by peer 1127938929 J * mrec ~revenger@p54B03929.dip0.t-ipconnect.de 1127939064 Q * arne^ Quit: Killed: Excess Flood 1127939138 Q * yungyuc Remote host closed the connection 1127939152 J * yungyuc ~yungyuc@220-135-53-220.HINET-IP.hinet.net 1127939332 J * jayeola ~jayeola@host86-139-77-9.range86-139.btcentralplus.com 1127939480 Q * nokoya Quit: changing servers 1127939546 Q * mrec Read error: Connection reset by peer 1127939577 J * mrec ~revenger@p54B03929.dip0.t-ipconnect.de 1127940008 J * dddd44 dhb55@218.111.178.26 1127940911 P * stefani I'm Parting (the water) 1127941718 Q * mrec Read error: Connection reset by peer 1127941726 J * mrec ~revenger@p54B03929.dip0.t-ipconnect.de 1127941811 J * nokoya ~young@hi-230-82.tm.net.org.my 1127942098 Q * mrec Read error: Connection reset by peer 1127942112 J * mrec ~revenger@p54B03929.dip0.t-ipconnect.de 1127942267 J * mess-mate ~mess-mate@82.250.121.225 1127942299 M * mess-mate hi... 1127942379 Q * mess-mate Quit: 1127942482 J * Aiken ~james@tooax6-010.dialup.optusnet.com.au 1127943969 Q * neofutur Ping timeout: 480 seconds 1127944184 Q * liquid3649 Quit: 1127944607 Q * prae Quit: Pwet 1127944678 J * neofutur ~neofutur@neofutur.net 1127944942 Q * mnemoc arion.oftc.net unununium.oftc.net 1127944970 J * mnemoc ~amery@200.75.27.15 1127947434 Q * nokoya Remote host closed the connection 1127948152 J * douglas ~douglas@douglas.user.oftc.net 1127948160 M * douglas where is bertl? 1127948162 M * douglas heh 1127948747 Q * tuxcapoeira Quit: Ex-Chat 1127948834 J * ntrs_ ~ntrs@68-188-50-87.dhcp.stls.mo.charter.com 1127949011 J * justincappos ~justin@egret.cs.arizona.edu 1127949067 Q * dddd44 Read error: Connection reset by peer 1127949073 Q * ntrs Read error: Connection reset by peer 1127949079 M * justincappos I have a question that is related to Vservers indirectly... 1127949086 M * justincappos Anyone alive here? 1127949121 P * justincappos 1127949254 Q * litage Ping timeout: 480 seconds 1127949257 Q * Johnsie Quit: G'bye! 1127949273 J * Johnsie ~john@acs-24-154-53-217.zoominternet.net 1127949822 M * mnemoc lonewolff: vserver build -m skeleton adds the minimal /dev nodes 1127949884 M * lonewolff mnemoc: so if i had an full os install and did rm /dev/* and copied over the ones that made all would be well? 1127949915 M * mnemoc if your os has a sanitized init, mostly 1127949949 M * lonewolff well yeah, i plan on cleaning up the init scripts and removing /boot /usr/src/linux* and /usr/lib/modules/* 1127949968 J * litage ~nick@203.201.96.22 1127949969 M * lonewolff its just the easiest way of getting rpm based guests running on a debian host it seems 1127950051 M * mnemoc util-vserver has yum support 1127950118 M * lonewolff thats interesting, so i could do a net install into a gues? 1127950211 J * nokoya young@hi-230-82.tm.net.org.my 1127950285 M * lonewolff its time i was in bed, thanks a lot for the help mnemoc ill look into that 1127950287 M * lonewolff night all 1127950307 J * Pirogeth anonymous@tinfoilhat.net 1127950328 N * Bertl_oO Bertl 1127950336 M * Bertl evening folks! 1127950340 M * jayeola :-) 1127950344 M * mnemoc wb Bertl 1127950356 M * Bertl tx 1127950371 M * Bertl welcome Pirogeth! nokoya! 1127950376 M * Pirogeth hihi 1127950451 M * Pirogeth i have been hunting around the wiki, and i cant find how to edit the bandwidth shaping on my vserver 1127950546 M * Bertl tc 1127950546 M * Pirogeth because the bandwidth is stuck sitting at a limit of 10.0kB/s 1127950635 M * Bertl sounds more like a router/network issue, do you have the output of testme.sh? 1127950666 M * Pirogeth i dont believe i have testme.sh 1127950673 M * Pirogeth and i know its not a net/router issue 1127950684 M * Pirogeth because i can pull 300kB/s off the same box 1127950686 M * Pirogeth on the host machine 1127950694 M * Pirogeth as opposed to encapped on the vserver 1127950710 M * Bertl that sounds interesting ... 1127950731 M * Bertl http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh 1127950750 M * Bertl (run it on the host as root, upload the output to pastebin.com or similar) 1127950895 M * Pirogeth it all suceeded 1127950902 M * Bertl url? 1127950934 M * Pirogeth http://pastebin.com/377308 1127950976 M * Bertl tx 1127951011 M * Bertl and how do you measure the troughput? 1127951532 M * Pirogeth was doing apt-get 1127951542 M * Pirogeth and the same server was pulling 300kB/s 1127951546 M * Pirogeth on the other end 1127951593 M * Bertl hmm ... well, maybe the server reduced your throughput? 1127951613 M * Bertl but let's check some things out if you like ... 1127951628 M * Pirogeth im going to try and recompile the kernel quickly w/o proc security 1127951637 M * Bertl why that? 1127951643 M * Pirogeth giving me proc errors 1127951645 M * Pirogeth left and right 1127951648 M * Pirogeth on the host system 1127951656 M * Bertl huh? 1127951676 M * Bertl what compiler did you use for the kernel if I may ask? 1127951686 M * Pirogeth gcc 1127951696 M * Bertl gcc 4.x or so? 1127951706 M * Pirogeth gcc version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu8) 1127951724 M * Bertl hmm, IIRC the ubuntu gcc was broken last time ... 1127951736 M * Pirogeth never had problems with it 1127951743 M * Pirogeth you just have to grab the right dependencies first 1127951747 M * Pirogeth otherwise it does break crap easily 1127951758 M * Bertl okay, never had _any_ proc security issues on the host :) 1127951766 M * Pirogeth a 1127951767 M * Pirogeth *ah 1127951937 J * dddd44 dhb55@218.111.178.26