Cannot install kernal modules

[rumpaar1]

HP Chromebook 14 (x86)

I started with running the change-kernel-flags script in crosh, rebooted, then running the setup-headers.sh on the chroot. I then rebooted again and installed virtualbox. However the 'Recompiling kernel modules' part of the setup failed and virtualbox would not run any vm's. I looked at the logs and realized that gcc was not installed. I installed gcc and ran the /sbin/rcvboxdrv setup. During this the chromebook completely rebooted. /etc/rc.local also fails on starting the chroot. I tried uninstalling then reinstalling virtualbox, install also causes the chromebook to restart, at the 'Recompiling kernel modules' stage. I have removed virtualbox and removed the virtualbox stuff from /etc/rc.local. Any tips on how to get virtualbox working?

[divx118]

@rumpaar1
I updated the 3.8.11 kernel headers and it should be fixed now. Just follow the steps in the README.md again and it should work now.

[tr0043t]

Update/upgrade and modules recompile OK, but no luck getting the drivers loaded. When I start the chroot, there is a flash of an unusual and quite long error message that I've been unable to read yet. Would that error be captured in a log somewhere? The chroot does start afterwards, but the vb drivers are not loaded. Thanks.

[divx118]

@laurenweinstein1 I think you somehow messed up your rc.local. Just follow steps below.

$ sudo enter-chroot -n <chrootname>
$ cd /etc
$ sudo rm rc.local
$ sudo wget https://raw.githubusercontent.com/divx118/crouton-packages/master/rc.local
$ exit

After exit enter your chroot normally.
If this doesn't help, then try loading the modules from the command line in the chroot and see if that produces some errors.

$ sudo modprobe vboxdrv
$ sudo modprobe vboxpci
$ sudo modprobe vboxnetadp
$ sudo modprobe vboxnetflt

[tr0043t]

Even though the modules compiles threw no errors, modprobe is reporting not
found for them. Here's the load code from my rc.local. Thanks.

Module ops for VirtualBox (Lauren: 4/11/15)

umount bindmounts /lib/modules from enter-chroot

for m in cat /proc/mounts | /usr/bin/cut -d ' ' -f2 | grep /lib/modules| grep -v "^/$"; do
umount "$m"
done

try to load vboxdrv modules

if [ find /lib/modules/"\uname -r" -name vboxdrv.ko ]; then
# check if module_locking is disabled
if ! grep -q "module_locking=0" /proc/cmdline; then
exit 2
fi
modprobe vboxdrv
modprobe vboxpci
modprobe vboxnetadp
modprobe vboxnetflt
fi

echo END >> /e/etc/startup.log

On Sun, May 1, 2016 at 8:28 AM, Maurice van Kruchten <
notifications@github.com> wrote:

@laurenweinstein1 https://github.com/laurenweinstein1 I think you
somehow messed up your rc.local. Just follow steps below.

$ sudo enter-chroot -n
$ cd /etc
$ sudo rm rc.local
$ sudo wget https://raw.githubusercontent.com/divx118/crouton-packages/master/rc.local
$ exit

After exit enter your chroot normally.
If this doesn't help, then try loading the modules from the command line
in the chroot and see if that produces some errors.

$ sudo modprobe vboxdrv
$ sudo modprobe vboxpci
$ sudo modprobe vboxnetadp
$ sudo modprobe vboxnetflt

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#35 (comment)

[divx118]

Hmm it looks ok, however I am afraid /lib/modules wasn't unmounted when you recompiled the modules, or isn't unmounted when you trying to load the modules.
Problem is crouton does a bindmount on /lib/modules from chromeos on /lib/modules in the chroot. This will make /lib/modules readonly, that is why we need to unmount it when installing kernel headers or compiling the modules and when loading the modules.
So I suggest entering the chroot, and redo the steps for upgrading and compiling the modules while you are sure /lib/modules is unmounted. You can check that with the following command in the chroot.

$ cat /proc/mounts | /usr/bin/cut -d ' ' -f2 | grep /lib/modules| grep -v "^/$"

If it is producing any output then unmount it with

$ sudo umount /lib/modules

When your rc.local is ok it should have been unmounted when you enter the chroot.

You can also just redo running the script setup-headers.sh this will take care of the above and should be the easiest way. Then recompile the modules and exit reenter the chroot.

[tr0043t]

The mount check shows /lib/modules to already be unloaded. The new
compilation of the modules (after its usual dkms warnings) fails with:
Chromium OS LSM: init_module denied
module="/lib/modules/3.8.11/misc/vboxdrv.ko" pid=19147
cmdline="/sbin/modprobe vboxdrv"

On Sun, May 1, 2016 at 11:32 PM, Maurice van Kruchten <
notifications@github.com> wrote:

Hmm it looks ok, however I am afraid /lib/modules wasn't unmounted when
you recompiled the modules, or isn't unmounted when you trying to load the
modules.
Problem is crouton does a bindmount on /lib/modules from chromeos on
/lib/modules in the chroot. This will make /lib/modules readonly, that is
why we need to unmount it when installing kernel headers or compiling the
modules and when loading the modules.
So I suggest entering the chroot, and redo the steps for upgrading and
compiling the modules while you are sure /lib/modules is unmounted. You can
check that with the following command in the chroot.

$ cat /proc/mounts | /usr/bin/cut -d ' ' -f2 | grep /lib/modules| grep -v "^/$"

If it is producing any output then unmount it with

$ sudo umount /lib/modules

When your rc.local is ok it should have been unmounted when you enter the
chroot.

You can also just redo running the script setup-headers.sh this will take
care of the above and should be the easiest way. Then recompile the modules
and exit reenter the chroot.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#35 (comment)

[divx118]

Ah ok then all you have to do now is run the change-kernel-flags script again. You get that error when module_locking is not turned off. The change-kernel-flags script takes care of that. You have to do it after every chromeos update.

[tr0043t]

That's it -- back in business. I have a script I normally run after each CrOS update to put all that back in place, but I hadn't run it again since this current header situation popped up. THANKS!

L

On Mon, May 2, 2016 at 10:37 AM, Maurice van Kruchten <
notifications@github.com> wrote:

Ah ok then all you have to do now is run the change-kernel-flags script
again. You get that error when module_locking is not turned off. The
change-kernel-flags script takes care of that. You have to do it after
every chromeos update.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#35 (comment)

[divx118]

Great, going to close this now.