1228091447 Q * znyto Remote host closed the connection 1228092223 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com 1228095080 J * chI6iT41 ~chigital@tmo-100-163.customers.d1-online.com 1228096355 M * Bertl off to bed now .. have a good one everyone! cya! 1228096362 N * Bertl Bertl_zZ 1228096521 Q * hparker Quit: Quit 1228097052 J * hparker ~hparker@2001:470:1f0f:32c:212:f0ff:fe0f:6f86 1228098122 N * quinq qzqy 1228099136 Q * pmenier Ping timeout: 480 seconds 1228099170 J * pmenier ~pmenier@ACaen-152-1-13-136.w83-115.abo.wanadoo.fr 1228101816 Q * chI6iT41 Ping timeout: 480 seconds 1228106271 Q * derjohn_mob Ping timeout: 480 seconds 1228108951 Q * esa Ping timeout: 480 seconds 1228109057 Q * FireEgl Ping timeout: 480 seconds 1228110067 Q * balbir_ Ping timeout: 480 seconds 1228110151 J * FireEgl FireEgl@173-16-9-10.client.mchsi.com 1228112165 Q * pmenier Quit: Konversation terminated! 1228113088 J * derjohn_mob ~aj@e180193078.adsl.alicedsl.de 1228113252 J * balbir_ ~balbir@59.145.136.1 1228114789 J * mtg ~mtg@dialbs-088-079-143-204.static.arcor-ip.net 1228115328 J * doener_ ~doener@i577BA9E4.versanet.de 1228115431 Q * doener Ping timeout: 480 seconds 1228116601 Q * larsivi Ping timeout: 480 seconds 1228116673 Q * hparker Quit: Read error: 104 (Peer reset by connection) 1228116681 J * hparker ~hparker@2001:470:1f0f:32c:212:f0ff:fe0f:6f86 1228119341 Q * derjohn_mob Ping timeout: 480 seconds 1228120842 Q * arekm Quit: leaving 1228121023 J * arekm arekm@carme.pld-linux.org 1228121108 J * chI6iT41 ~chigital@tmo-100-252.customers.d1-online.com 1228121616 J * esa ~esa@ip-87-238-2-45.static.adsl.cheapnet.it 1228121908 J * yarihm ~yarihm@whitehead2.nine.ch 1228122582 J * larsivi ~larsivi@85.221.53.194 1228122916 J * davidkarban ~david@193.85.217.71 1228123016 Q * chI6iT41 Ping timeout: 480 seconds 1228124381 J * gnuk ~F404ror@pla93-3-82-240-11-251.fbx.proxad.net 1228124381 Q * ktwilight_ Read error: Connection reset by peer 1228124452 J * ktwilight_ ~ktwilight@198.114-66-87.adsl-dyn.isp.belgacom.be 1228124598 J * pmenier ~pme@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr 1228124937 J * _nono_ ~gomes@libation.ircam.fr 1228125363 Q * hparker Quit: Read error: 104 (Peer reset by connection) 1228125923 J * hparker ~hparker@2001:470:1f0f:32c:215:f2ff:fe60:79d4 1228126627 Q * kiorky Quit: leaving 1228126667 J * kiorky ~kiorky@cryptelium.net 1228129265 Q * _nono_ cation.oftc.net magnet.oftc.net 1228129265 Q * pmenier cation.oftc.net magnet.oftc.net 1228129265 Q * davidkarban cation.oftc.net magnet.oftc.net 1228129265 Q * yarihm cation.oftc.net magnet.oftc.net 1228129265 Q * Guy- cation.oftc.net magnet.oftc.net 1228129265 Q * ensc cation.oftc.net magnet.oftc.net 1228129265 Q * gcj cation.oftc.net magnet.oftc.net 1228129265 Q * cehteh cation.oftc.net magnet.oftc.net 1228129265 Q * Hollow cation.oftc.net magnet.oftc.net 1228129265 Q * vasko cation.oftc.net magnet.oftc.net 1228129265 Q * duckx cation.oftc.net magnet.oftc.net 1228129265 Q * grobie cation.oftc.net magnet.oftc.net 1228129265 Q * baggins cation.oftc.net magnet.oftc.net 1228129265 Q * Radiance cation.oftc.net magnet.oftc.net 1228129265 Q * mEDI_S cation.oftc.net magnet.oftc.net 1228129265 Q * Hunger cation.oftc.net magnet.oftc.net 1228129265 Q * bzed cation.oftc.net magnet.oftc.net 1228129265 Q * kaner cation.oftc.net magnet.oftc.net 1228129265 Q * meebey cation.oftc.net magnet.oftc.net 1228129265 Q * SpComb cation.oftc.net magnet.oftc.net 1228129265 J * vasko ~vasko@unreal.rainside.sk 1228129265 A * vasko is gone. Gone since Tue Sep 16 17:08:00 2008 1228129266 J * SpComb terom@zapotek.paivola.fi 1228129267 J * grobie ~grobie@valgrind.schnuckelig.eu 1228129268 J * kaner ~kaner@zzz.strace.org 1228129269 J * Guy- ~korn@elan.rulez.org 1228129269 J * bzed ~bzed@devel.recluse.de 1228129274 J * _nono_ ~gomes@libation.ircam.fr 1228129275 J * ensc ~irc-ensc@77.235.182.26 1228129275 J * yarihm ~yarihm@whitehead2.nine.ch 1228129276 J * Hollow ~hollow@shiva.xnull.de 1228129276 J * baggins ~baggins@kenny.mimuw.edu.pl 1228129280 J * pmenier ~pme@LNeuilly-152-22-72-5.w193-251.abo.wanadoo.fr 1228129286 J * cehteh ~ct@pipapo.org 1228129286 J * Radiance ~Radiance@193.16.154.187 1228129286 J * duckx ~Duck@81.57.39.234 1228129286 J * gcj ~chris@cpc3-cmbg7-0-0-cust452.cmbg.cable.ntl.com 1228129286 J * davidkarban ~david@193.85.217.71 1228129295 J * meebey meebey@booster.qnetp.net 1228129308 J * Hunger Hunger.hu@Hunger.hu 1228129326 J * mEDI_S ~medi@snipah.com 1228130822 Q * xdr Remote host closed the connection 1228131003 J * xdr ~xdr@118-173-96-87.cust.blixtvik.se 1228132885 J * awk ~awk@gw1.security.web.za 1228132902 M * awk hello ? 1228132904 M * awk nukleuz:/# init q 1228132905 M * awk init: /dev/initctl: No such file or directory 1228132914 M * awk hmm, how would i resolve this with a vserver? 1228133007 M * derjohn awk, plain oder sysv init style ? 1228133054 M * derjohn within a guest you usually dont have a initctl (that named pipe would gibe the guest access to the the hosts (!) init. 1228133093 M * awk hmm, well i have this, 1 sec... 1228133107 M * awk SV:123456:respawn:/command/svscanboot 1228133115 M * awk I have that added to my inittab... 1228133275 M * awk what other method could I use..... 1228133335 M * arekm kill -9 1? ;) 1228133350 M * awk lol, I need to respawn this 1228133367 M * awk there has to be a way to use 'inittab' from the guest... 1228133423 M * arekm on host kill -9 1 works fine so I assume guest won't be different 1228133606 M * awk there has to be a way to use 'inittab' from the guest.../ 1228133609 M * awk errr 1228133618 M * awk so I should just script that 1228133834 M * arekm do you use plain init style anyway? 1228133896 M * awk yes 1228133941 M * arekm here from guest: # init q; tail -n 1 /var/log/daemon 1228133941 M * arekm Dec 1 13:18:53 multifax init: Re-reading inittab 1228133982 M * awk how did you get that right? 1228134020 M * arekm just using plain init style was enough 1228134237 M * awk so i just need sysv? 1228134422 M * awk hrm 1228134572 M * awk so no 1228134588 M * awk arekm: what could be missing that causes mine not to work? 1228134623 M * awk init: /dev/initctl: No such file or directory 1228134626 M * awk I keep getting this? 1228134736 M * awk should i just allow flags to allow *dev inside the guest 1228134757 M * arekm do you really use plain init style in vserver guest? 1228134787 M * arekm ls -l /etc/vservers/name/apps/init/style ? 1228134883 M * awk nothing there, must I just echo simple > style? 1228134905 M * arekm echo plain > style 1228134931 M * arekm where "name" is your guest name of course 1228135036 M * awk thanks 1228135534 N * Bertl_zZ Bertl 1228135537 M * Bertl morning folks! 1228135566 M * awk hello _zZ 1228135576 M * Bertl just to clarify, initctl is perfectly fine (and safe) inside a guest with plain init style 1228135611 M * Bertl it is created by init (inside the guest) at startup 1228135625 M * awk thanks.... yes, just never had that marked 1228135626 M * awk :) 1228135630 M * awk thanks arekm 1228135638 M * awk so I should be able to use shutdown and reboot now? 1228135645 M * awk should also fix klogd message 1228135662 M * Bertl you can use shutdown and reboot with plain init style and with sysv init 1228135689 M * Bertl klogd is not related, it needs the syslog virtualization enabled (but doesn't make sense to run anyway) 1228135717 M * awk ofcourse 1228135720 M * awk does it actually work? 1228135731 M * Bertl what? 1228135754 M * awk klog? 1228135760 M * awk can it actually get kern logs? 1228135775 M * Bertl nope, the klogd virtualization is a dummy stub 1228135785 M * Bertl i.e. you will read nothing forever :) 1228135794 M * awk lol 1228136180 M * Bertl in theory it would work, but we couldn't figure what messages we would want a guest to receive ... i.e. we didn't find any kernel message which would be meaninful to a guest 1228136209 M * arekm oom killing guest processes 1228136242 M * Bertl yeah, maybe that would make sense 1228136258 M * awk what about 1228136264 M * awk firewall logs for that ip 1228136265 M * awk :) 1228136318 M * Bertl there are many cases where you do not want the guest to know that it is nat-ed or blocked ... 1228136343 M * Bertl but as a matter of fact, this is a good candidate for a host policy daemon too 1228136354 M * Bertl (like the iptables stuff itself would be :) 1228136370 M * arekm iptables is candidate for netns support ;> 1228136391 M * Bertl not necessarily .. many folks don't want the additional overhead for their guests 1228136415 M * Bertl (especially if it can be done with a policy, and without it :) 1228136694 Q * Mojo1978 Remote host closed the connection 1228137094 N * qzqy quinq 1228137334 M * awk hmm, nie 1228138132 N * Bertl Bertl_oO 1228138336 J * Pazzo ~ugelt@reserved-225136.rol.raiffeisen.net 1228139241 Q * awk 1228141344 J * znyto ~znyto__@tor-irc.dnsbl.oftc.net 1228141352 Q * znyto 1228141371 J * znyto debian-tor@tor-irc.dnsbl.oftc.net 1228141552 J * geb ~geb@79.82.4.112 1228141745 Q * larsivi Remote host closed the connection 1228146022 Q * fosco Quit: leaving 1228146496 J * dowdle ~dowdle@scott.coe.montana.edu 1228146591 J * pflanze ~chris__@77-56-73-53.dclient.hispeed.ch 1228147430 Q * davidkarban Remote host closed the connection 1228147473 N * Bertl_oO Bertl 1228147617 J * davidkarban ~david@193.85.217.71 1228147656 Q * balbir_ Ping timeout: 480 seconds 1228148672 J * fosco fosco@212.85.148.86 1228151936 J * balbir_ ~balbir@122.166.168.57 1228151988 Q * davidkarban Quit: Ex-Chat 1228152144 J * esa` ~esa@ip-87-238-2-45.static.adsl.cheapnet.it 1228152335 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d 1228152436 Q * esa Ping timeout: 480 seconds 1228152682 J * larsivi ~larsivi@9.80-202-30.nextgentel.com 1228154487 Q * pmenier Remote host closed the connection 1228156149 J * cga ~weechat@94.36.88.11 1228157071 Q * larsivi Ping timeout: 480 seconds 1228157942 J * dna ~dna@52-200-103-86.dynamic.dsl.tng.de 1228158963 J * jsullivan ~jsullivan@cpe-76-178-208-188.maine.res.rr.com 1228159191 Q * mtg Quit: Verlassend 1228159754 Q * cga Quit: WeeChat 0.2.6 1228159783 N * quinq qzqy 1228159961 Q * nou Ping timeout: 480 seconds 1228159981 N * qzqy quinq 1228160240 M * jsullivan Hello, all. 1228160246 M * Bertl hey! 1228160255 M * jsullivan I'm working on integrating VServer and NX . . . 1228160265 M * jsullivan which, of course, requires running X in the guest. 1228160270 M * jsullivan Or at least so I suppose. 1228160286 M * jsullivan I noticed this requires creating /dev/mem on the guest. 1228160287 M * Bertl I would asume it doesn't require it 1228160302 M * jsullivan Ah, that might solve my problem right there. 1228160310 M * Bertl but yes, X requires /proc/mem 1228160317 M * jsullivan Doesn't NX run a server and client on the host? 1228160334 M * jsullivan Then the agent speaks to the agent on the remote desktop? 1228160342 M * Bertl well, I have no idea about the internals, but I presume it should be similar to vnc 1228160370 M * Bertl and xvnc + vncviewer does not require any X (hardware video card) running 1228160378 M * jsullivan Hmm . . . I think it's a very different architecture which is why it is so much faster but I'm no expert. 1228160397 M * jsullivan I'll try it without X and see how far I get but I think I've tried that before and flopped. 1228160404 M * Bertl the question is, what would be the purpose to use a hardware X11 on the 'server'? 1228160426 M * jsullivan I think it runs both Xserver and Xclient on the host hardware . . . 1228160436 M * jsullivan in effect, spoofing the response. 1228160446 M * jsullivan It then communicates to the XServer on the client. 1228160469 M * jsullivan Thus the apps on the vserver host are talking to an XServer running on the vserver host. 1228160473 M * jsullivan well guest actually. 1228160496 M * Bertl as I said, it sounds inefficient to me to run stuff on hardware video cards, if the actual image is generated on a different machine 1228160507 M * jsullivan Since there is an XServer running on the NX server (which is the vserver guest) . . . 1228160515 M * jsullivan I assumed I needed X on the vserver guest. 1228160537 M * jsullivan Good point - I'm not sure if it hits the hardware video card. 1228160543 M * Bertl the terms server and client are a little unintuitive for X11 1228160560 M * Bertl the thing you run on real hardware is actually the client 1228160570 M * jsullivan Yes, I gather the client is the app and the server is the receiver of the screens info. 1228160576 M * Bertl (although it is labeled X server :) 1228160595 M * jsullivan Thus if I'm doing standard X forwarding, the client runs on the server and the server on the remote client. 1228160607 M * jsullivan I believe that's where NX derives some of its magic. 1228160617 M * Bertl for example, you can run any X app inside a guest, without installing X11 on the guest 1228160630 M * jsullivan Yes, e.g., SSH forwarding. 1228160631 M * jsullivan correct? 1228160634 M * Bertl yep 1228160653 M * jsullivan But I believe NX performs so quickly in a WAN environment . . 1228160656 M * Bertl so I presume you need hardware support on the machine you want the apps to show stuff 1228160664 M * jsullivan by running a proxy XServer on the server. 1228160674 M * jsullivan This the app gets an immediate response. 1228160699 M * jsullivan The proxying server then sends compressed information to the real XServer unless that info has already been cached. 1228160704 M * Bertl still doesn't need (and doesn't make senso) to use hardware for that 1228160714 M * jsullivan OK - I can play with that in my lab . . 1228160716 M * Bertl *sense 1228160719 M * jsullivan and not take up the list's time. 1228160731 M * Bertl well, keep us posted :) 1228160743 M * jsullivan However, coming back to /dev/mem assuming I do need to run XServer on the vserver guest . . . 1228160754 M * jsullivan This is a multi-tenant environment . . 1228160762 M * jsullivan and I'm a little concerned about the security implications. 1228160776 M * jsullivan I gather Ubuntu 8.0.4 + restricts access to .dev.mem to only device memory. 1228160785 M * jsullivan However, I'm even a little uncomfortable with that. 1228160795 M * Bertl yes, giving full /proc/mem access is definitely opening up your kernel to that guest 1228160800 M * jsullivan Is there a reason to be a little concerned about the security implications . . 1228160809 M * jsullivan of using /dev/mem in a vserver guest? 1228160821 M * Bertl no, the guest will be able to compromise your kernel easily 1228160837 M * jsullivan Hmm . . . 1228160855 M * Bertl recent kernels, 2.6.27+ support restricted /proc/mem acccess 1228160857 M * jsullivan and am I correct to assume there is no other way to run an XServer in a guest (should that be necessary)? 1228160885 M * Bertl on real hardware, no, Xvnc (X server) needs no hardware and thus no /proc/mem 1228160928 M * jsullivan OK - so /proc/mem is only for accessing the hardware device and I may be able to run X without it? 1228160941 M * Bertl yep 1228160968 M * jsullivan and if I can't, it's a choice between a gaping memory hole and not using X? 1228160974 M * jsullivan security hole. 1228160981 M * Bertl kind of 1228160998 M * daniel_hozac you can. 1228161027 M * jsullivan Sorry, I can what? 1228161040 M * daniel_hozac run X without it. 1228161051 M * daniel_hozac worst case scenario, you use the dummy driver. 1228161058 M * jsullivan Even in a debian based distro? 1228161074 M * daniel_hozac umm, i don't see why not? 1228161089 M * jsullivan OK - I'm a bit out of my depth here . . 1228161106 M * jsullivan so create the dummy driver and link it so /dev/mem . . 1228161109 M * jsullivan to fool X? 1228161112 M * Bertl nah :) 1228161125 M * Bertl Xorg is modular, you need a vide card driver 1228161142 M * Bertl and there is one called 'dummy' which supports a dummy video card 1228161153 M * jsullivan Ah, got it. 1228161155 M * Bertl and thus, can be run without any real hardware 1228161168 M * Bertl consequently no need to access /proc/mem :) 1228161184 M * jsullivan Ah, that sounds promising. 1228161198 M * jsullivan Let me do some of my own homework so I don't tie you folks up. 1228161202 M * jsullivan Thanks very much. 1228161402 M * Bertl np 1228161445 Q * Radiance Ping timeout: 480 seconds 1228161541 N * quinq qzqy 1228161590 Q * yarihm Quit: Leaving 1228161591 N * qzqy quinq 1228161733 J * cga ~weechat@94.36.88.11 1228161961 Q * cga 1228163645 J * cga ~weechat@94.36.88.11 1228164033 M * jsullivan Before I start digging into the bowels of X and vserver, I thought I should clean up . . . 1228164043 M * jsullivan my ubuntu guest running on my Centos host. 1228164052 M * jsullivan I get bunches of errors on boot. 1228164066 M * jsullivan I've cleaned most but still have some lingering bits I've not been able to resolve by googling. 1228164084 M * jsullivan I get this constantly: 1228164089 M * jsullivan Could not load /lib/modules/2.6.22.19-vs2.3.0.34.1/modules.dep 1228164108 M * jsullivan I'm assuming the guest should not and cannot load modules. 1228164116 M * Bertl well, remove everything kernel, modules, and hardware related 1228164121 M * jsullivan Is this message a problem or only cosmetic? 1228164135 M * Bertl not aproblem if your guest starts up as expected 1228164153 M * Bertl the environment will block such attempts, unless you give excessive caps 1228164158 M * jsullivan OK - it was a pretty vanilla vserver-build for ubuntu. 1228164176 M * jsullivan I also get lots of /proc errors. 1228164190 M * jsullivan Is this something I'm supposed to fix by fiddling with prochide? 1228164199 M * Bertl what kind of errors? 1228164219 M * jsullivan Just grabbing some now. 1228164222 M * jsullivan IOError: [Errno 2] No such file or directory: '/proc/bus/pci/devices' 1228164236 M * Bertl hardware detection, see point 1 :) 1228164258 M * fitzdsl hi 1228164259 M * jsullivan and /etc/rc3.d/S16ssh: 168: cannot create /proc/15312/oom_adj: Operation not permitted 1228164289 M * Bertl that is a distro oddity, it is not supposed to mess with oom adjustments 1228164295 M * jsullivan Strange, I'm not starting X. 1228164302 M * jsullivan Even kdm is not set as executable. 1228164332 M * jsullivan OK - so I am guessing I can ignore the ssh error. 1228164342 M * Bertl yes, definitely 1228164344 M * jsullivan Is the other from some kind of auto-probing? 1228164355 M * Bertl I presume so 1228164363 M * jsullivan I do notice when I attemtped to startx . . 1228164368 M * Bertl most distros do hardware checks/detection when booting up 1228164371 M * jsullivan it complaing about PCI devices. 1228164382 M * Bertl i.e. you should better remove those checks 1228164383 M * fitzdsl i wanted to know if it was normal that when a vserver is affected to a cgroup, process created during the launch and by ssh connexion was rightly affected, but process created in enterring directly on the vserver with "vserver my_vs enter" was not affected to the corresponding cgroup 1228164392 M * jsullivan Could not get primary PCI info 1228164425 M * Bertl fitzdsl: yes, kind of expected, the enter is a maintainance backdoor with separate rules/features/etc 1228164471 M * Bertl fitzdsl: it might be that future util-vserver will handle that properly and put you in the same cgroup (maybe trunk already does, daniel_hozac will know) 1228164499 M * fitzdsl ok, so if i want to affect every process i have to work on my vs only by ssh ? 1228164547 M * fitzdsl i run the cvs version of util-vserver 1228164566 M * daniel_hozac it does now :) 1228164583 M * fitzdsl :) 1228164602 M * fitzdsl on the trunk ? 1228164639 M * daniel_hozac yes. 1228164669 J * gawain ~gawain@port-92-195-58-211.dynamic.qsc.de 1228164699 M * gawain hi there. 1228164733 M * gawain does anybody knows about a problem, that the network interfaces disappear in the vm during operation? 1228164738 M * fitzdsl ok, i'll check that, thx 1228164750 M * Bertl gawain: yep, it's a mainline feature :) 1228164763 M * gawain i start the vm with vserver ... start and the eth0 is there. 1228164790 M * gawain and then some minutes later eth0 goes down. 1228164790 M * Bertl for each network, there is a primary, and every other IP will become a secondary 1228164837 M * gawain every vserver has its own ipö 1228164839 M * gawain ip 1228164917 M * gawain with the old 2.6.22 kernel this problem didnt appear. did something change with 2.6.26 ? 1228165024 M * gawain and this disappearence happens without shutting down any vserver. 1228165059 M * Bertl no, actually the old kernel handled that exactly the same way 1228165072 M * Bertl but it might be that udev/ifplugd is biting you here 1228165177 M * gawain how can i test that? 1228165388 M * Bertl well, you can disable it for a start, if the issue goes away, that's it 1228165501 M * daniel_hozac i think it's more likely to be dhcp. 1228165527 M * Bertl dhcp shouldn't take down the interface, or is that a new feature? 1228165564 Q * cga Quit: WeeChat 0.2.6 1228165659 M * gawain dhcp is not installed 1228165880 M * Bertl try to enable 'promote secondaries' and see if that solves your issues 1228165909 M * Bertl it might do the trick even with ifplugd/udev or whatever messing with your IPs 1228165963 J * infowolfe ~infowolfe@c-76-105-247-52.hsd1.or.comcast.net 1228166530 M * gawain ok. i will try. 1228166550 M * Bertl what host distro are you on? 1228166614 M * gawain debian lenny 1228166622 M * gawain vserver too 1228166635 M * Bertl yeah, the reports on debian increased of this 'issue' 1228166653 M * Bertl i.e. it would be interesting to know what actually messes with the IPs 1228166668 J * derjohn_mob ~aj@e180193078.adsl.alicedsl.de 1228166685 M * gawain i cannot find anything in the logs. 1228166726 M * Bertl yep, nothing in dmesg either, IIRC 1228166751 M * Bertl how long does it take till your guest IPs disappear? 1228166788 M * gawain what i've seen: i entered the vm, ifconfig -> lo, eth0... i enter svn up (ssh+svn) and get an error, name resolving doesnt work... ifconfig-> eth0 is gone 1228166814 M * Bertl yep, on the host side this will look similar 1228166844 M * Bertl but _something_ on the host has to be responsible for removing the 'primary' ip 1228166857 M * gawain the time i cannot tell. several minutes. 1228166859 M * Bertl which will kill all your secondaries too 1228166874 M * Bertl so it is fairly reproduceable on your setup? 1228166897 M * gawain the host has always its ip and is always accessable (i'm logged in by ssh) 1228166963 M * Bertl well, you won't notice if it goes away for the fraction of a second 1228166991 M * gawain thats true. hm 1228167030 M * Bertl it would be interesting to do a periodical process listing 1228167042 M * Bertl together with 'ip addr ls' on the host 1228167063 M * Bertl and to investigate what processes are active when the IP(s) disappear 1228167163 Q * ghislainocfs2 Quit: Leaving. 1228167466 Q * derjohn Ping timeout: 480 seconds 1228167510 J * derjohn ~derjohn@dslb-084-059-024-004.pools.arcor-ip.net 1228167658 Q * bonbons Quit: Leaving 1228167990 Q * doener_ Quit: leaving 1228168046 Q * dna Ping timeout: 480 seconds 1228168275 Q * geb Quit: Quitte 1228168691 M * jsullivan Well, making some progress on X. 1228168704 M * Bertl excellent! 1228168712 M * jsullivan It looks like Ubuntu was probing for devices which didn't work well on a vserver guest. 1228168722 M * jsullivan Hence the PCI error messages. 1228168751 M * jsullivan At this point I'm just trying to get basic X before playing with NX. 1228168758 M * jsullivan If I tell it to use a vga driver . . 1228168764 M * jsullivan it works but is, of course, ugly. 1228168774 M * jsullivan However, if I tell it to use anything else . . 1228168782 M * jsullivan intel, fbdev . . 1228168785 M * jsullivan it can't find it. 1228168788 M * Bertl you need additional capabilities 1228168791 M * jsullivan SYS_RAWIO 1228168799 M * jsullivan is enabled as per the wiki. 1228168811 M * jsullivan The drivers are in the file system. 1228168816 M * jsullivan Where else should I look? 1228168831 M * Bertl /proc/mem access and probably the pci info 1228168859 M * Bertl but the simplest way is to use strace -fF and see where it fails 1228168859 M * jsullivan I did a MAKENODE -d /vservers//dev mem 1228168872 M * jsullivan Shouldn't that have taken care of /proc/mem? 1228168879 M * Bertl how so? 1228168903 M * jsullivan Pardon the ignorance of a management type thrown into buiding devices :( 1228168912 M * jsullivan I inferred that from our earlier discussion. 1228168936 M * jsullivan Do I need to play with vprochide or whatever the file is called? 1228168955 M * Bertl /dev/ nodes and /proc are mostly unrelated 1228168970 M * Bertl if your X needs /proc/mem access, you need to make that visible 1228168987 M * Bertl if it needs /dev/mem access, copying (or creating) that node is sufficient 1228169002 M * jsullivan OK - I'll go play with that. Thanks, as always. 1228169121 J * dna ~dna@52-200-103-86.dynamic.dsl.tng.de 1228169644 Q * gawain Quit: KVIrc 3.4.0 Virgo http://www.kvirc.net/ 1228170215 M * jsullivan Ouch! 1228170244 M * jsullivan Well . .. based upon the MOREUbuntu multi-seat documentation . . 1228170257 M * jsullivan I unhid /proc/mtrr and /proc/bus 1228170296 M * jsullivan I then used dpkg-reconfigure xserver-org . . 1228170299 Q * Adrinael Ping timeout: 480 seconds 1228170303 M * jsullivan and it did nasty things to everything! 1228170313 M * jsullivan tabs didn't work, 1228170316 M * jsullivan screens turned blue. 1228170320 M * jsullivan My face turned red. 1228170346 M * jsullivan And it still can't find the intel driver! 1228170397 M * jsullivan After much googling, I'm not much further (though maybe a bit wiser). 1228170419 M * jsullivan Any other walls I can beat my head against to try to get this XServer working in my ubuntu guest? 1228170479 M * jsullivan I recognize I do not understand the concepts well which is why I'm trying to follow the cookbooks . . but the cookbook instructions don't seem to be working for me :( 1228170502 J * Adrinael adrinael@rid7.kyla.fi 1228171090 Q * dna Quit: Verlassend 1228171339 N * quinq qzqy 1228171362 M * Bertl what does strace -fF give you? 1228171386 M * jsullivan I'm working through it now. 1228171395 M * jsullivan I wish I knew what I was looking at :( 1228171404 M * jsullivan This, however, is suspicious: 1228171422 M * Bertl compare it between a run on the host and guest 1228171428 M * jsullivan open("/usr/lib/xorg/modules/drivers/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 4 1228171444 M * Bertl that means it worked :) 1228171447 M * jsullivan getdents(4, /* 55 entries */, 4096) = 1376 1228171450 M * jsullivan Yes, but then . . . 1228171460 N * qzqy quinq 1228171475 M * jsullivan stat64("intel_drv.so", 0xbfb86894) = -1 ENOENT (No such file or directory) 1228171485 M * jsullivan But the file is there is is readable by root. 1228171563 M * Bertl is it? 1228171585 N * quinq qzqy 1228171621 M * jsullivan I'll check again but it sure looked that way. 1228171631 M * jsullivan And strace is still running much further. 1228171636 M * jsullivan Give me a second to double check. 1228171650 N * qzqy quinq 1228171683 M * jsullivan root@x2go:/usr/lib/xorg/modules/drivers# ls -l intel* 1228171695 M * jsullivan -rw-r--r-- 2 root root 310936 Apr 10 2008 intel_drv.so 1228171734 M * Bertl you are doing that from inside the guest now? 1228171739 M * jsullivan I'm sure I must be missing something stupid as I'm sure people do this all day long. 1228171743 M * jsullivan Yes. 1228171752 M * jsullivan Well . . . 1228171765 M * jsullivan I did the strace from vserver x2go enter 1228171773 M * jsullivan I'm observing the files from an ssh session. 1228171778 M * jsullivan I assume that shouldn't matter. 1228171796 M * Bertl emphasis on _shouldn't_ :) 1228171906 M * jsullivan Hmm . . . as I look further in the trace . . 1228171912 M * jsullivan it seems like it found the driver . . . 1228171937 M * jsullivan write(0, "(II) intel: Driver for Intel Int"..., 58) = 58 1228171945 M * jsullivan I'm guessing that means it found it. 1228171950 M * jsullivan But then . . 1228171969 M * jsullivan write(0, "Intel Integrated Graphics Device", 32) = 32 1228171981 M * Bertl comapre the traces between a start on the host (via chroot into the guest) and the guest 1228171983 M * jsullivan write(0, "(II) Primary Device is: ISA\n", 28) = 28 1228171983 M * jsullivan write(2, "(EE) No devices detected.\n", 26) = 26 1228171983 M * jsullivan write(0, "(EE) No devices detected.\n", 26) = 26 1228171989 M * Bertl (please use paste.linux-vserver.org for everything longer than 3 lines) 1228172006 M * jsullivan Nope - just those three lines. 1228172024 M * Bertl and make sure that the pci info is in proc/sys, otherwise it won't be able to find the devices 1228172061 M * jsullivan Let me take a look at that as it seemed to be laid out a little differently than I expected. 1228172108 M * jsullivan [root@testvserver1 sys]# ls /proc/sys 1228172109 M * jsullivan debug dev fs kernel net sunrpc vm vserver 1228172113 N * quinq qzqy 1228172134 N * qzqy quinq 1228172137 M * jsullivan I think it's under bus 1228172145 M * jsullivan I did expose /proc/bus 1228172155 M * jsullivan Does that expose everything underneath it? 1228172240 M * Bertl not by default 1228172277 M * jsullivan Ah, so I need to expose /proc/bus/pci explicitly. 1228172280 M * jsullivan I didn't do that. 1228172286 M * jsullivan I'll make that change. 1228172297 M * daniel_hozac or /proc/bus/ 1228172300 M * jsullivan I also wonder if I shouldn't simply copy over the xorg.conf from the host 1228172329 M * jsullivan I did expose /proc/bus/ 1228172336 M * jsullivan but I gather it does not flow down? 1228172368 M * Bertl so what was it, /proc/bus or /proc/bus/ ? 1228172372 M * daniel_hozac /proc/bus/ will recurse, /proc/bus won't. 1228172385 M * daniel_hozac in vprocunhide's configuration, anyway. 1228172389 M * jsullivan Ah, got it. 1228172393 M * jsullivan I'l double check. 1228172400 M * jsullivan OK - let me get to work with that. 1228172406 M * jsullivan Thanks for your help as always. 1228172406 Q * dowdle Remote host closed the connection 1228172666 M * jsullivan Getting there. 1228172677 M * jsullivan Now instead I get errors about allocating ring buffer space. 1228172698 M * jsullivan I'll go fight with that now. 1228172700 M * jsullivan thanks. 1228174590 J * Naven n@ievil.pl 1228174620 M * Naven hi 1228174648 M * Naven does linux-vserver support ip fail-over addresses ? 1228174679 Q * znyto Quit: i need sleep 1228174991 M * Naven i got server in ovh and i got 1 IP fail-over address 1228174999 M * Naven on what i run vserver 1228175018 M * Naven but when i want to login on my vserver i am redirecting to root server 1228175027 M * Bertl it supports any addresses Linux supports 1228175081 M * Bertl see http://linux-vserver.org/Frequently_Asked_Questions#When_I_try_to_ssh_to_the_guest.2C_I_log_into_the_host.2C_even_if_I_installed_sshd_on_the_guest._What.27s_wrong_here.3F 1228175101 M * daniel_hozac (we should do something about those links...) 1228175130 M * Bertl like have them contain the answer too :) 1228175152 M * Bertl well an FAQ number would be nice 1228175189 M * Bertl FAQ #1 ssh, FAQ #2 secondaries, FAQ #3 debian kernel ... :) 1228175211 M * daniel_hozac hehe 1228175320 M * Bertl Naven: does that fix your problem? 1228175377 M * Naven Bertl: ok, now it works ;> 1228175388 M * Bertl excellent! 1228175391 M * Naven i just install ssh on vserver and change ssh port to other 1228175397 M * Naven just so simple :)