1321747260 Q * dkg Quit: Reconnecting
1321747272 J * dkg ~dkg@lair.fifthhorseman.net
1321747699 Q * bonbons Quit: Leaving
1321747887 Q * petzsch Quit: Leaving.
1321758401 J * aj__ ~aj@p4FFD1DF5.dip.t-dialin.net
1321758510 Q * derjohn_mobi Read error: Operation timed out
1321759145 M * Bertl_oO off to bed now ... have a good one everyone!
1321759150 N * Bertl_oO Bertl_zZ
1321763420 Q * geos_one Ping timeout: 480 seconds
1321764499 J * chrissbx ~chrissbx@69-196-180-202.dsl.teksavvy.com
1321764566 M * chrissbx I wonder if the flower page doesn't warrant a prominent link on the linux-vserver.org site, like maybe right in the navigation on the left.
1321764624 M * chrissbx I've created a bookmark on my browser toolbar now, but before that I've +- learnt not to go to linux-vserver.org when I needed the config but google for flower page instead.
1321764658 M * chrissbx Which is surely not what the gods have meant me to do.
1321765428 J * geos_one ~chatzilla@chello080109195117.4.graz.surfer.at
1321773076 Q * Aiken Quit: Leaving
1321777024 Q * Romster Ping timeout: 480 seconds
1321777147 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1321777806 J * petzsch ~markus@p57B66FE6.dip.t-dialin.net
1321779392 J * sannes ~ace@cm-84.209.106.118.getinternet.no
1321780259 Q * aj__ Ping timeout: 480 seconds
1321780882 Q * petzsch Quit: Leaving.
1321780984 Q * Romster Ping timeout: 480 seconds
1321781830 J * Romster ~romster@202.168.100.149.dynamic.rev.eftel.com
1321782002 J * bonbons ~bonbons@2001:960:7ab:0:6082:5765:be5d:78e3
1321782196 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1321782545 Q * geos_one Quit: ChatZilla 0.9.87 [Firefox 8.0/20111120035125]
1321788504 Q * Mr_Smoke Read error: Connection reset by peer
1321788521 J * Mr_Smoke smokey@layla.lecoyote.org
1321791056 N * Bertl_zZ Bertl
1321791061 M * Bertl morning folks!
1321791106 M * Bertl chrissbx: that's exactly what the gods had in mind :)
1321791914 Q * fisted Read error: Operation timed out
1321791926 M * arekm Bertl: hi!
1321792195 J * fisted ~fisted@xdsl-87-78-216-239.netcologne.de
1321792440 J * BenG ~bengreen@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com
1321792479 Q * BenG 
1321792818 J * petzsch ~markus@p57B670EA.dip.t-dialin.net
1321792995 M * Bertl arekm: hey, how's going with the merge?
1321793955 Q * petzsch Quit: Leaving.
1321794897 J * petzsch ~markus@p57B670EA.dip.t-dialin.net
1321795356 M * arekm Bertl: was waiting for you to get some hints
1321795383 M * Bertl did you decode the oops yet? if so, can you upload that somewhere?
1321795571 M * arekm no, only have oops - http://pastebin.com/ciS5ud30
1321795608 Q * Aiken Remote host closed the connection
1321795876 M * Bertl well, then start decoding it (addr2line) and collect the relevant sections for (re)viewing ...
1321796090 M * Bertl off for now ... bbl
1321796094 N * Bertl Bertl_oO
1321796157 M * arekm that's a problem, have to redo testing
1321799556 Q * petzsch Quit: Leaving.
1321800233 J * derjohn_mob ~aj@p4FFD1DF5.dip.t-dialin.net
1321805568 Q * jeroen__ Ping timeout: 480 seconds
1321805940 J * jeroen__ ~jeroen@095-097-051-172.static.chello.nl
1321806683 M * chrissbx Hm, I'm unable to run X in a guest, even though I think I've done as told on http://linux-vserver.org/Vservers_and_X
1321806707 M * Bertl_oO what's the problem?
1321806711 M * chrissbx x:~# l /dev/mem 
1321806711 M * chrissbx crw-r----- 1 root kmem 1, 1 2011-11-19 15:29 /dev/mem
1321806724 M * chrissbx tn:/etc/vservers/x# cat bcapabilities 
1321806724 M * chrissbx SYS_RAWIO
1321806724 M * chrissbx SYS_ADMIN
1321806729 M * chrissbx tn is the host, x is the guest.
1321806736 M * chrissbx Xorg.log says:
1321806759 M * chrissbx (EE) Failed to load module "vesa" (module does not exist, 0)
1321806759 M * chrissbx (EE) Failed to load module "fbdev" (module does not exist, 0)
1321806759 M * chrissbx (EE) No drivers available.
1321806812 M * Bertl_oO well, looks like you're either missing a proper driver for your card, or the capabilities to load it 
1321806828 M * Bertl_oO note that it's not encouraged to do module loading from inside the guest
1321806863 M * chrissbx It's an intel card. - Yeah, well I don't have vesa, just uvesafb.
1321806879 M * chrissbx Intel on-board (atom machine)
1321806928 M * chrissbx I guess I'll install Xorg on the host and try there.
1321806936 M * Bertl_oO the best approach with well supported graphic cards is to use kms and have the driver available/loaded from the host
1321806954 M * Bertl_oO then the guest's Xorg can attach
1321806954 M * chrissbx How do I enable/use kms?
1321806991 M * Bertl_oO usually just loading the proper kernel module is sufficient
1321807021 M * chrissbx How do I know which ones are using kms?
1321807086 M * Bertl_oO drivers or kernels or graphic cards?
1321807087 M * chrissbx modprobe -l |grep kms  -> only drm_kms_helper.ko
1321807130 M * chrissbx Hm, well I don't know about any of these; my kernel is 3.0.7, graphics is a recent itx board from intel,
1321807138 M * Bertl_oO intel GMA support has been added around 2009
1321807164 Q * jeroen__ Ping timeout: 480 seconds
1321807201 M * chrissbx Ok, (no module with gma in its name, maybe the debian kernel config I used to start from didn't enable these), going to search for this in the .config.
1321807249 M * chrissbx Well, X on the host works, loaded i915 and drm_kms_helper.
1321807255 M * Bertl_oO http://en.wikipedia.org/wiki/Intel_GMA
1321807273 M * chrissbx Guest still says No drivers available.
1321807279 A * chrissbx checks page
1321807337 M * chrissbx I've got a D510, hence it seems I do have GMA.
1321807360 M * Bertl_oO so loading the intel driver should provide kms
1321807385 M * Bertl_oO (you still need the device to use it)
1321807391 M * chrissbx Ah, device.
1321807520 J * jeroen__ ~jeroen@095-097-051-172.static.chello.nl
1321807773 M * chrissbx Hm, I've copied the whole /dev from the host to the client, still No drivers available. I'm assuming that if X on the host loaded all necessary driver stuff, and I stop X (modules still loaded), that the devfs still contains the necessary stuff.
1321807786 M * chrissbx Wondering: how can I verify the guest has the capabilities I gave it?
1321807799 M * chrissbx (Like, do I have to prefix the cap names with CAP_ ?)
1321807876 A * chrissbx wanders off for breakfast
1321808620 M * Bertl_oO best strace -fF the X startup and upload the trace
1321808663 M * Bertl_oO vattribute --get --xid <guest>
1321808680 M * Bertl_oO (shows the flags and capabilities of a process context)
1321808868 Q * jeroen__ Ping timeout: 480 seconds
1321809553 J * jeroen__ ~jeroen@095-097-051-172.static.chello.nl
1321814238 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1321815955 M * chrissbx Bertl_oO: http://69.196.180.202:1180/.vserver/1/
1321816097 M * chrissbx (i.e., attributes seem correct, and I'm out of ideas rightnow)
1321816678 J * derjohn_foo ~aj@p4FFD3272.dip.t-dialin.net
1321816788 Q * derjohn_mob Ping timeout: 480 seconds
1321817878 Q * bzed Ping timeout: 480 seconds
1321820163 J * bzed ~bzed@devel.recluse.de
1321822417 M * Bertl_oO chrissbx: sure the intel_drv is installed inside the guest?
1321822511 Q * sannes Quit: Leaving.
1321822930 Q * bergerx Ping timeout: 480 seconds
1321822966 J * bergerx ~bergerx@46.196.250.204
1321823193 M * chrissbx Bertl_oO: yep, it is:  chris@x:~$ l /usr/lib/xorg/modules/drivers/intel_drv.so
1321823194 M * chrissbx -rw-r--r-- 2 root root 310400 2011-02-18 10:27 /usr/lib/xorg/modules/drivers/intel_drv.so
1321823245 M * chrissbx I could just give the guest all sorts of bcaps/caps; this is a fresh untampered guest so far.
1321823838 M * chrissbx SYS_RESOURCE SYS_NICE SYS_TTY_CONFIG don't help it either.
1321823869 M * chrissbx add MKNOD in the above.
1321823953 M * chrissbx Hm. The host ("tn") is 32bit userspace, the guest ("x") is 64 bit. Does this matter?
1321824563 M * Bertl_oO well, try to chroot into the guest dir, and start Xorg there
1321824607 M * Bertl_oO (you should see if you are missing any files or dev entries)
1321824743 M * chrissbx That works.
1321824768 M * Bertl_oO then next step, run strace -fF on that and compar with the strace -fF from within the guest
1321824863 M * Bertl_oO also you seem to miss SYS_MODULE inside the guest, so if the driver wants to load a kernel module it will fail
1321824875 M * Bertl_oO (note that the kernel modules must match the kernel)
1321824877 M * chrissbx ok trying with that cap
1321824889 M * chrissbx ..and module copy
1321825212 M * chrissbx Ah, that made it work (the SYS_MODULE)
1321825254 M * Bertl_oO well, basically it should work without that if the module in question is already loaded
1321825266 M * chrissbx hm, but now it works without SYS_MODULE, too
1321825267 M * Bertl_oO (i.e. you can load it from/on the host)
1321825282 M * Bertl_oO that's because I presume the module stays loaded
1321825286 M * chrissbx well as I said I started X on the host (same Debian distribution except 32bit on the host)
1321825290 M * chrissbx so not sure what's going on
1321825304 M * Bertl_oO maybe it unloaded the module for whatever reason
1321825310 M * chrissbx maybe it's the bind mount of proc and sys and dev after all that I did for the chroot
1321825321 M * chrissbx I started X multiple times
1321825331 M * chrissbx just the same as now in the guest
1321825342 M * Bertl_oO well, bind mounting proc is completely useles
1321825356 M * Bertl_oO i.e. it is a virtual filesystem and the guest already has one
1321825368 M * chrissbx The chroot.
1321825385 M * chrissbx I'm using a script for the "chrootlogin", maybe it does mount -t proc instead.
1321825392 M * chrissbx but it doesn't umount them.
1321825411 M * Bertl_oO no idea what the chrootlogin is
1321825433 M * Bertl_oO either you are inside the guest, or on the host inside a chroot
1321825457 M * chrissbx That's the name of my script, it mounts stuff on $base/proc sys dev tmp then chroots to $base
1321825458 M * Bertl_oO and yes, Xorg will need some mounts inside a chroot to work
1321825479 M * Bertl_oO and no, those mounts (or bind mounts) won't affect the guest
1321825494 M * Bertl_oO they will not even show up inside the guest
1321825525 M * chrissbx That's what I expected. Hm what about shared memory segments? Or files in /var/run etc.?
1321825536 M * chrissbx Maybe it needed to create something there that makes it work now.
1321825548 M * Bertl_oO could be, but my guess would still be on the kernel module
1321825563 M * chrissbx lsmod doesn't show any new module now.
1321825564 M * Bertl_oO i.e. I'd check 'lsmod' and then maybe reboot the host
1321825594 M * chrissbx Yep, trying reboot now. Will be offline for a moment (it's my router).
1321825629 Q * chrissbx Quit: Leaving
1321825793 J * chrissbx ~chrissbx@69-196-180-202.dsl.teksavvy.com
1321825885 M * chrissbx Heh, it doesn't work anymore, even with SYS_MODULE
1321825923 M * chrissbx Trying chroot again.
1321826019 M * chrissbx Yep. Running startx from the chroot, ctl-c, exiting chroot, vserver x start, ssh x, startx and it works.
1321826025 M * chrissbx And lsmod is unchanged.
1321826210 M * chrissbx There's a udevd still running from the chroot attempt.
1321826347 M * chrissbx Hah: it's /sys
1321826368 M * chrissbx When I umount /vservers/x/sys (which was mounted because of my chrootlogin script), it doesn't work anymore.
1321826409 M * chrissbx Don't ask me why the vserver sees the mount of that directory done in the host context.
1321826428 M * Bertl_oO you must have a very strange setup, you sure that your kernel patch/tools are up-to-date?
1321826452 M * Bertl_oO (and thus the guest isolation is working at all)
1321826695 M * chrissbx yes; kernel 3.0.7 + patch-3.0.7-vs2.3.1.diff, util-vserver 5c59135ea4cd12a66678b1106cf81050898fa595 (2011-10-05 17:18:00) (+ patches to debian subdir to build debs for me)
1321826730 M * chrissbx Configuration fresh from scratch. So, no idea.
1321826757 Q * bonbons Quit: Leaving
1321826781 M * chrissbx Let me check whether the guest really *sees* /sys; maybe it was only some daemon running in the host context.
1321826920 M * chrissbx Well, the client definitely sees the sys mount.
1321826954 M * Bertl_oO unless you disabled namespaces, that's not possible
1321826969 M * Bertl_oO i.e. mounts on the host are in a different namespace than guest mounts
1321826994 M * chrissbx I do this:
1321826995 M * chrissbx tn:~# mount --bind /sys /var/lib/vservers/x/sys
1321826995 M * chrissbx tn:~# vserver x stop
1321827000 M * chrissbx tn:~# vserver x start
1321827007 M * chrissbx ssh x; ls /sys and see the sys contents.
1321827021 M * chrissbx When I tn:~# umount /var/lib/vservers/x/sys 
1321827034 M * chrissbx the sys is still moutned inside x until I stop and start x.
1321827060 M * chrissbx The guest keeps around the state of the mount as it was at its start time.
1321827092 M * chrissbx So, that's still a separate namespace, right? It just happens to pick up what was at sys on start.
1321827180 M * chrissbx This seems similar to mount --rbind, i.e. also bind all submounts.
1321827326 M * chrissbx Anything wrong with this?
1321827429 M * Bertl_oO well, the guest cleanup should remove that actually
1321827460 M * Bertl_oO i.e. unless you somehow protected the /sys from cleanup, it should get removed on guest startup
1321827484 M * chrissbx I didn't do anything other than what I said above.
1321827516 M * chrissbx I haven't bothered about sys at all since configuring this machine.
1321827547 M * chrissbx No file in /etc/vservers mentions /sys
1321827585 M * chrissbx If you want I can do another reboot, and not use my chrootlogin script but instead simply use the above mount --bind only. 
1321827645 M * chrissbx I'm bind mounting a directory onto /usr into the guest, if that's something that might disturb it?
1321827725 M * chrissbx At least, chroot-breakout.pl can't break out. If there are any other tests you want me to run, tell me.
1321828080 M * chrissbx Is it safe to have this line in /etc/vservers/x/fstab ?:
1321828082 M * chrissbx none   /sys            sysfs   ro,nosuid,nodev,noexec  0 0
1321828131 M * chrissbx (Or should I make a static copy of /sys (and remove what's unneeded)?)
1321828511 J * derjohn_mob ~aj@p4FFD3272.dip.t-dialin.net
1321829339 J * Mr_Smoke_ smokey@layla.lecoyote.org
1321829339 Q * Mr_Smoke Read error: Connection reset by peer
1321829522 M * Bertl_oO well, the amount of bcaps added to the guest already make the guest quite insecure
1321829551 M * Bertl_oO a 'static' copy of sysfs probably won't work, as it is a virtual filesystem as well
1321829587 M * Bertl_oO you could run the guest startup with --debug and contact daniel_hozac, I think that the remaining sys mount is a bug
1321829656 M * chrissbx The readonly sys works;
1321829688 M * chrissbx I've removed all bcaps except for SYS_RAWIO and SYS_ADMIN again (and haven't checked whether I could remove these, too)
1321829785 M * chrissbx Yeah, static copy might not work (if there are huge virtual files or files only for special file ops (if sysfs uses that))
1321829834 M * chrissbx I seem to remember I actually did it though for making a usb device usable in a guest, about 5 years ago. Will look into it later.
1321829914 M * chrissbx daniel_hozac: I'll gladly help you find the bug; first finishing the rest, then run --debug or whatever you want.
1321829954 Q * derjohn_foo Ping timeout: 480 seconds
1321829993 M * chrissbx Hm for some reason I don't get any keyboard input in the guest.
1321830005 M * chrissbx Even though I copied the whole of /dev into it.
1321830018 M * chrissbx Mouse works.
1321830511 M * Bertl_oO probably a missing device or device description (input)
1321831371 M * daniel_hozac mounts that are in the guest won't be cleaned up, they're presumed to be there because someone wanted them there.
1321831532 M * chrissbx Fine for me.
1321831542 M * chrissbx Device description?
1321831597 M * chrissbx I did "mv /vservers/x/dev Trash; cp -a /dev /vservers/x/dev".
1321831630 M * chrissbx I guess I'll try with a bind mount.
1321832538 M * chrissbx Odd, even a rw bind mount of /dev doesn't work; but I've now done a fresh cp -x -a of the dev directory, now the keyboard works.
1321832581 M * chrissbx (Most likely, after a reboot of the host the dev dir has changed in a way that disables the keyboard) 
1321832673 M * chrissbx It would be good if there existed a program that could "copy over" (make available) certain devices to a guest.
1321832706 M * chrissbx Like "all usb keyboards (+ mice)", "all audio", etc.
1321832709 M * Bertl_oO devices present in a guest are 'available' so, the program is cp/rsync
1321832726 M * chrissbx Except that it's quickly not so simple anymore;
1321832743 M * Bertl_oO you can configure udev to update host and guest for example
1321832773 M * chrissbx I did write such a program in the past for a USB based microcontroller programmer device; it was rather complicated (and, as I mentioned, iirc involved copying some parts of /sys, too).
1321832787 M * chrissbx Yep, I hooked it into udev.
1321832813 M * chrissbx So what I'm saying is, it would be cool if there were one program where all such solutions were collected.
1321832830 M * Bertl_oO feel free to write one
1321832837 M * chrissbx Of course I'm kinda assuming it will pay off, which assumes some sizable number of people using vserver for different things than just internet servers.
1321832867 M * chrissbx Yeah, I'm not precluding myself from being part of this.
1321832942 M * chrissbx It's just loud thinking atm. Next thing to wonder about is whether to write it in shell, perl or python. Or C.
1321832971 M * chrissbx Always used perl here. I guess the trend is towards python, though, seeing bindings in the util-vserver tree.
1321833011 M * chrissbx Shell is just kinda painful.
1321833060 M * Bertl_oO given that testme/testsh and large parts of util-vserver are written in bash, I'd say that depends on the coder :)
1321833103 M * chrissbx Half of the programs I start in bash I rewrite in Perl later on.
1321833140 M * chrissbx I guess a core in C and then bash could be right, though.
1321833200 M * chrissbx Well, on to finish my guest, I'll see. It's rare that something comes out of my ideas.
1321833222 M * chrissbx (Unless it's just for myself.)