1402446123 J * fisted_ ~fisted@xdsl-81-173-185-157.netcologne.de 1402446451 Q * fisted_ Remote host closed the connection 1402446572 Q * fisted Ping timeout: 480 seconds 1402447294 J * fisted ~fisted@xdsl-84-44-224-69.netcologne.de 1402448095 M * Bertl off to bed now ... have a good one everyone! 1402448108 N * Bertl Bertl_zZ 1402466162 J * Ghislain ~aqueos@adsl1.aqueos.com 1402470438 Q * ntrs Read error: Operation timed out 1402470628 Q * zerick Ping timeout: 480 seconds 1402470973 Q * Aiken Remote host closed the connection 1402472265 J * Aiken ~Aiken@d63f.h.jbmb.net 1402473229 J * beng_ ~BenG@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net 1402477534 Q * mcp Remote host closed the connection 1402477542 Q * jrklein Remote host closed the connection 1402477544 J * jrklein ~osx@proxy.dnihost.net 1402481860 J * mcp ~mcp@wolk-project.de 1402485079 M * beng_ hi all 1402485102 M * beng_ any reason when I broadcom pcie WAN card wouldn't work in a vserver kernel 1402485114 M * beng_ but would work in a non-vserver kernel? 1402485120 M * beng_ config almost identical 1402485153 M * clopez same kernel version? 1402485251 N * Bertl_zZ Bertl 1402485265 M * Bertl morning folks! 1402485277 M * webhat good morning! 1402485545 M * beng_ clopez, yes same kernel version 1402485596 M * Bertl sounds strange 1402485713 M * beng_ strange indeed 1402485720 M * beng_ no erros at all on modprobe 1402485725 M * beng_ no errors at all on modprobe 1402485734 M * beng_ well, I say same kernel 1402485743 M * beng_ but actually one is the debian kernel 1402485750 M * Bertl LOL 1402485754 M * beng_ one is the beng kernel 1402485758 M * beng_ but both 3.2 1402485764 M * beng_ the Debian one works though 1402485776 M * Bertl so they probably added a patch for that card 1402485785 M * beng_ it a DKMS module 1402485792 M * beng_ proprietary wl module 1402485802 M * beng_ necessary for the particular broadcom card 1402485815 M * Bertl in that case, make sure to build it with the correct kernel headers 1402485824 M * Bertl (and kernel sources) 1402485828 M * beng_ dkms should take care of that 1402485834 M * beng_ and appears to 1402485867 M * clopez beng_: the beng kernel and the Debian one are not the same 1402485873 M * beng_ I know 1402485883 M * beng_ debian is heavily patched 1402485886 M * clopez the Debian kernel has a *ton* of patches on top... maybe one of this patches is making your device working 1402485908 M * beng_ but surely the wl dkms module should compile cleanly for a whole load of kernels? 1402485920 M * beng_ the nvidia DKMS packages works fine for both 1402485926 M * clopez it would help if you can get the sources for both kernels (the Debian one with the patches applied) and compare the sources looking for diferences on the code for your driver 1402485963 M * beng_ there won't be any differences clopez, as its a dkms package which is automatically compiled for any kernel present 1402485985 M * beng_ I'm wondering if there's some DKMS hiccup and the wrong module is being loaded 1402486000 M * clopez the driver is the propietary wl broadcom WLAN driver? 1402486028 M * beng_ yes 1402486047 M * clopez I guess it could be related to the config 1402486052 M * beng_ could be 1402486056 M * beng_ I've diffed the config 1402486070 P * undefined 1402486079 M * beng_ the brcm80211 isn't compiled for my kernel 1402486081 M * clopez upload the diff to pastebin or something like that 1402486100 M * beng_ but that shouldn't affect the wl driver 1402486114 M * clopez beng_: it can affect if you don't blacklist it 1402486142 M * clopez check this wiki: https://wiki.debian.org/wl 1402486146 M * beng_ yes but it's NOT present on the kernel where the wl does not work 1402486195 M * clopez and is present any of this drivers? b44 b43 b43legacy ssb brcmsmac 1402486735 M * Bertl first step, try with a beng kernel _without_ linux-vserver patch 1402486764 M * Bertl i.e. same build system, same config, etc, but omit the Linux-VServer patch 1402487724 M * beng_ good idea Bertl 1402487730 M * beng_ I've done some more research 1402487750 M * beng_ the entire thing with the brcm drivers and 3.2 kernels is a bit messed up 1402487771 M * beng_ and I think Debian have patched it in some respects 1402487786 M * beng_ I've not idea if wl driver uses any of there resources 1402487829 M * beng_ I've a new config to try, but I don't really want to spend a huge amount of time on an old kernel with a proprietary driver 1402487849 M * beng_ will wait until a 3.2.60 is avaialable or higher then try on some new buidl 1402487852 M * beng_ builds 1402487858 M * beng_ thanks for the help all 1402487894 M * beng_ https://bbs.archlinux.org/viewtopic.php?id=133059 <- some pointers on config wierdness and kernel changes 1402488086 Q * beng_ Quit: I Leave 1402488339 N * clopez Guest13276 1402488346 J * clopez ~tau@neutrino.es 1402488608 Q * Guest13276 Ping timeout: 480 seconds 1402489075 Q * guerby Read error: Connection reset by peer 1402489101 J * guerby ~guerby@ip165-ipv6.tetaneutral.net 1402489708 J * fisted_ ~fisted@xdsl-87-78-230-222.netcologne.de 1402490160 Q * fisted Ping timeout: 480 seconds 1402490161 N * fisted_ fisted 1402490662 J * beng_ ~BenG@cpc29-aztw22-2-0-cust128.18-1.cable.virginm.net 1402493135 Q * Aiken Remote host closed the connection 1402494154 J * BlackPanx_ ~oftc-webi@APN-122-106-161-gprs.simobil.net 1402494166 M * BlackPanx_ hello everyone 1402494204 M * BlackPanx_ i have a quick question about mounting device inside guest. i know i can enter the management namespace by doing: vnamespace -i 0 -e -- /bin/bash 1402494225 M * BlackPanx_ then i should see devices from host and i can mount let's say /dev/sdb1 to /mnt 1402494256 M * BlackPanx_ is that enough for running guest to see this in operational namespace ? or do i need to so something else ? 1402494314 M * BlackPanx_ i know i can do: vnamespace -e mount -n /dev/ /vservers//place/you/want/to/mount/it 1402494320 M * BlackPanx_ this does mount stuff 1402494332 M * BlackPanx_ but then no fstab, nor mtab is populated with this entry 1402494347 M * BlackPanx_ meaning df -h / mount etc commands don't show this disk at all 1402494354 M * BlackPanx_ it is mounted, but i can't see disk usage etc 1402494395 M * BlackPanx_ that's pretty big handicap for me. i don't know how much space i have free while i'll copy stuff over to the external device... 1402494424 M * BlackPanx_ i would like my guest to keep running while i copy stuff for next few hours... 1402494509 M * BlackPanx_ if i give ccapablilities like binary_mount and secure_mount, and sys_admin to bcapabilities... should i see the /dev/sdb1 in guest and be able to mount it as i like ? 1402495009 J * undefined ~undefined@00011a48.user.oftc.net 1402499057 J * zerick ~eocrospom@190.187.21.53 1402501159 Q * click Ping timeout: 480 seconds 1402502184 Q * BlackPanx_ Remote host closed the connection 1402502195 N * l0kit Guest13294 1402502201 J * l0kit ~1oxT@0001b54e.user.oftc.net 1402502598 Q * Guest13294 Ping timeout: 480 seconds 1402503166 J * bonbons ~bonbons@2001:a18:201:f401:75f8:19c9:ed57:6c00 1402505782 Q * bonbons Quit: Leaving 1402505863 J * bonbons ~bonbons@2001:a18:201:f401:75f8:19c9:ed57:6c00 1402506627 Q * geb Ping timeout: 480 seconds 1402507571 Q * zerick Ping timeout: 480 seconds 1402508084 J * zerick ~eocrospom@190.114.249.148 1402508853 J * click click@ice.vcon.no 1402513018 Q * bonbons Quit: Leaving 1402513061 J * bonbons ~bonbons@2001:a18:201:f401:75f8:19c9:ed57:6c00 1402518937 J * Aiken ~Aiken@d63f.h.jbmb.net 1402519878 Q * bonbons Quit: Leaving 1402519886 J * shaggy63 ~packethel@c-24-12-82-97.hsd1.in.comcast.net 1402519938 M * shaggy63 If I have the same file on one vserver in different directories will they be hardlinked with hashify? 1402520068 M * Bertl with the proper config, yes 1402520090 M * shaggy63 proper config? 1402520098 M * undefined Bertl: meaning the directories (in which the files are found in) are not excluded? 1402520111 M * Bertl yes, for example 1402520426 M * shaggy63 Thanks 1402520588 Q * beng_ Quit: I Leave 1402520769 J * Mr_Smoke_ smokey@87-231-49-246.rev.numericable.fr 1402521187 Q * Mr_Smoke Ping timeout: 480 seconds 1402522629 N * Mr_Smoke_ Mr_Smoke 1402522794 M * Mr_Smoke Hi, again 1402522816 M * Mr_Smoke The topic says 3.6.x is "stable" … but 3.6 isn't even a longterm kernel 1402522823 M * Mr_Smoke What's the recommendation then? 1402522967 M * Bertl the latest and greatest if it works for you, otherwise always the latest stable 1402522983 M * Bertl or long term or whatever you may call it 1402523043 M * Bertl at the moment, that seems to be 3.10.43 1402523066 M * Mr_Smoke Ok so I'll need to try if the patch for 3.10.40 applies properly then 1402523095 M * Mr_Smoke Hm Corey says it doesn't :/ 1402523144 M * Mr_Smoke Oh, a patch for the patch then :) 1402523174 M * Mr_Smoke 3.12.22 is longterm, too 1402523192 M * Mr_Smoke Ah but no vs patch. Ok I'll try the 3.10 branch then 1402523347 M * Mr_Smoke Thanks for the hints :) 1402523372 M * Bertl no problem 1402523621 Q * zerick Read error: Connection reset by peer 1402524577 J * zerick ~eocrospom@190.114.249.148 1402525770 J * Ghislain1 ~aqueos@adsl1.aqueos.com 1402525770 Q * Ghislain Read error: Connection reset by peer 1402525844 Q * Ghislain1 1402525949 Q * zerick Read error: Connection reset by peer 1402526903 J * zerick ~eocrospom@190.114.249.148