=== Guest34418 is now known as lag
=== lag is now known as Guest66638
=== yofel_ is now known as yofel
[20:10] <basix> hello everyone... can someone let me know what the issue is here? I am unable to get a useable kernel module compiled on ANY of the mainline kernels in the ubuntu kernel-ppa repository. Heres the bug and some info from a virtualbox developer who says the issue is that the headers somehow don't match the kernel. https://www.virtualbox.org/ticket/9891
[20:11] <basix> i am currently running 3.1.2 but i'll be upgrading to 3.1.6 and checking if the issue still persists
[20:11] <basix> this is the kernel ppa i am currently using : http://kernel.ubuntu.com/~kernel-ppa/mainline/
[20:20] <basix> anybody?
[20:21] <apw> basix, the compiler the mainline kernels are built with don't match those on the system most likely
[20:21] <apw> basix, they are only intended for testing
[20:22] <basix> apw, how do i find out the compiler used to build mainline kernels? Also, shouldn't this be an issue with the regular ubuntu kernels as well? I mean a user can always upgrade / downgrade GCC on his system and when a package like virtualbox, vmware tries to build it's kernel modules, it'll cause such issues.
[20:23] <basix> apw, i agree they are intended for testing. i wanted to test out the latest virtualbox but unfortunately i cant build any version on my system currently
[20:23] <apw> basix, we build the mainline kernels on lucid
[20:24] <basix> apw, i am using natty 
[20:24] <apw> basix, so reboot into an official kernel, those are built in a chroot that matches your system
[20:24] <basix> apw, my wireless has a bunch of issues if i boot into an official kernel
[20:24] <basix> apw, as well as sleep / power issues and thats the whole reason i am on a mainline kernel
[20:26] <basix> apw, are there source packages for the mainline kernel so i can rebuild it natively on my system and that should fix the issue, right?
[20:27] <apw> basix, yes i expect if you build it on natty it would work ok
[20:28] <basix> apw, so are there any source packages or do i need to build one myself?
[20:28] <apw> basix, there are no source packaged, but there is file COMMIT which contains the linus commit to checkout -- and a set of patches which if applied gives you the tree the builder used
[20:28] <basix> ok
[20:29] <apw> external modules are a royal pain, those guys should jsut submit their stuff upstream
[20:29] <basix> apw, alternatively if i setup a lucid chroot and build the modules in there, would that work as well?
[20:30] <apw> basix, i would hope that would work also; that might make more sense
[20:30]  * apw wonders if we could build vb modules with them ... hmmm
[20:31] <basix> apw, haha yes. also i suspect this is an issue not just affecting virtualbox. i tried installing vmware and it too had the same issue.
[20:31] <apw> basix, yep, yet another external module... pain in the ass always
[20:32] <basix> any idea what the overall process to build these modules would look like inside a chroot? I haven't build modules in some time let alone inside a chroot. 
[20:32] <apw> the problem is that people want to use these kernels on a range of series, and we don't really have compute or the space to build for every conceivable combination
[20:32] <apw> basix, it should be identicle
[20:33] <basix> after i create a chroot for lucid, do i install gcc and other build essentials and build those modules in that chroot?
[20:33] <apw> oh and ... you should mention to vb pepople that they are compiler sensitive so their build really ought to check
[20:33] <basix> i think i will reopen the bug
[20:34] <basix> but i need to be 100% certain it is a compiler
[20:34] <basix> apw, so i already have a chroot
[20:34] <basix> apw, when i look in /lib/modules inside the chroot there are no headers which kinda makes sense because it's a clean root
[20:36] <basix> apw, i will just install the header package inside the chroot as well as virtualbox. it should then go through the process of building the modules as usual and i can then copy those modules out of the chroot. does that sound reasonable?
[20:39] <basix> apw, sudo debootstrap --variant=buildd --arch amd64 lucid /srv/chroot/lucid_x86_64 http://archive.ubuntu.com/ubuntu <- does this look ok?
[20:41] <apw> basix, heh, it looks believable
[20:41] <basix> ??
[20:43] <apw> basix, i have no idea if its purfect of the top of my head, i use some prebuilt ones the majority of the time
[20:44] <basix> apw, ok
[21:31] <basix> apw, it's a no go. i was able to compile the modules. they got 'modprobed' without any issues within the chroot but when i copied them outside the chroot into /lib/modues/$(uname -r)/misc, it seems the issue persisted. do i need to run depmod or is there some sort of a module cache that i need to clear to ensure the older modules are not loaded?
[21:33] <basix> brb
[21:50] <basix> apw, ok...so i was able to 'modprobe
[21:50] <basix>  the modules from within the chroot
[21:51] <basix> apw, that worked but outside the chroot, it still causes the panic. i wonder if it has to do with something at the runtime
[23:24] <basix> apw, for posterity's sake, i am pinging you. thanks for all your help. i got the modules to build inside the lucid chroot and that fixed the issue. there were some old modules remaining in /lib/modules/3.1.2-030102-generic/updates/dkms which made it seem that the issue was not fixed since modprobe was favoring that path over /lib/modules/$(uname -r)/misc where the newly built modules were. After I replaced the modules in the dkms directory, I was 
[23:24] <basix> able to modprobe all the virtualbox modules successfully and able to restart virtualbox and run a VM. This is Virtualbox 4.1.8 on kernel 3.1.2.