After setup-headers.sh init_module denied, header or bios problem?

[thegallivanter]

Hi guys, thank you for your nice work. The existence of stuff like crouton really convinced me to get a chromebook. After getting my hands dirty everything seems to work like I want it to. However being able to run virtual machines would be the cherry on the cake. Im now trying to get that to work with your scripts.

After running the setup-headers.sh script i get this error:

[ 499.362905] Chromium OS LSM: init_module denied module="/lib/modules/3.8.11/updates/dkms/vboxdrv.ko" pid=22154 cmdline="modprobe vboxdrv" [ 499.798884] systemd-logind[22246]: Failed to enable subscription: Launch helper exited with unknown return code 1 [ 499.798918] systemd-logind[22246]: Failed to fully start up daemon: Input/output error

You think this is a problem with the headers and I should perform building the headers step by step, or should I change something in my bios? I expected to need to change something in the bios but havent encountered it yet.

My kernel is version 3.8 on an acer c720p. My chroot build is jessie. I hope this is the right place to ask, this isnt really an 'issue' with your project its more like troubleshooting the issue I ran into.

[divx118]

Module locking is still on. You need to change the kernelflags See https://github.com/dnschneid/crouton/wiki/Repack-kernel-to-Enable-VT_x-for-Virtualbox
Remove the /sys/module/lsm/parameters/module_locking related lines from your /etc/rc.local.

[thegallivanter]

Thanks, its going in the right direction. The setup headers script didnt throw an error anymore. Virtual box not quite working yet on this end. Ok so I saved kernel A (?) to /temp/x.2, edited it and 'repacked' it. So VT is now enabled and module locking disabled if thats correct. When I enter my chroot now, I get this warning:

WARNING: /etc/rc.local failed with code 1

Installing virtualbox did throw an error about a module missing. Virtualbox does start but then warns me:

WARNING: The character device /dev/vboxdrv does not exist.
 Please install the virtualbox-dkms package and the appropriate
 headers, most likely linux-headers-3.8.11.

While dkms is already installed. When I try to start a VM nonetheless, it says :

Kernel driver not installed rc:-1908

I dont know what rc stands for but entering my chroot and starting a VM both mention it. Maybe I did something wrong with the repacking? I never specified a letter for a kernel, if theres different kernels maybe I should specify it when repacking?

[divx118]

Did you also remove the /sys/module/lsm/parameters/module_locking related lines from your /etc/rc.local? So it doesn't throw the error.
So like below.

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# 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
if [ `find /lib/modules/"\`uname -r\`" -name vboxdrv.ko` ]; then

    modprobe vboxdrv
    modprobe vboxpci
    modprobe vboxnetadp
    modprobe vboxnetflt

    i="0"
    while [ $i -lt 5 ]; do
        loaded=$( cat /proc/modules|grep -o vboxdrv ) || loaded="empty"
        if [ "$loaded" = "vboxdrv" ]; then
            break
        fi
        sleep 1
        i=$((i+1))
    done

fi

exit 0

[thegallivanter]

I edited the rc.local and removed those 4 lines. Then I ran the setup-headers.sh inside my chroot again and removed and reinstalled virtualbox. Then I logged out my chroot, booted it again and tried to start the VM. Then I got the same errors as before.

If I try to run modprobe vboxdrv inside my chroot from that rc.local file I get this error: modprobe: ERROR: could not insert 'vboxdrv': Operation not permitted

[divx118]

Then you don't have module_locking disabled. You can check if the right kernel flags are set by doing cat /proc/cmdline
I am busy to make a script to do it in an easier way. Once I have that done I will update setupheaders.sh and the rc.local script to avoid these kind of problems. However it will take some time, work is taken up most of my time lately.

[thegallivanter]

hmm youre right funny im pretty sure i did the whole /tmp/x.2 thing ill do it again Thanks!

[divx118]

Note that on a chromeos update you will have to do it again. Also don't forget: First one to allow booting a not signed kernel and the second to avoid crouton setting the first back to 1.

$ sudo crossystem dev_boot_signed_only=0
$ sudo crossystem dev_boot_usb=1 dev_boot_legacy=1

[thegallivanter]

When I run the make_dev_ssd.sh script again on the x.2 file where I added disablevmx=off and lsm.module_locking=0, it reports that it succesfully resigned 1 kernel on device /dev/sda. Cat x.2 shows the two variables I added. But then cat /proc/cmdline doesnt have those two new variables.

[divx118]

Argh sorry, I should update the wiki. It depends on which kernel chromeos boots next. On chromeos there are 2 kernels and 2 rootfs partitions it switches between those 2 on an update or if 1 fails to boot. So you probably using kernel B now which is on partition 4. Replace the 2 with 4 and it should work. My script will handle this automatically in the future.
FYI partitions are ordered 2 - Kernel A 3 - Rootfs A and 4 - Kernel B 5 - rootfs B.

[thegallivanter]

Ha ok, you must get a lot of clueless people like me with these problems. Sorry about that. A whole life of windows only makes this stuff hard.

I now did the same for partition 4, ran setup-headers.sh inside the chroot and installed virtualbox and rebooted again. During installation when it tries to teststart virtualbox modules it does give an error saying it is 'not suited to run k'. However booting into my chroot no longer gives the rc error and starting virtualbox also doesnt show an error any more. Then when I start a VM it doesnt throw an error any more either, but then my system crashes and reboots.

Is there something else I could have messed up?

You had me set the dev_boot variables with crossystem. There are similar variables in the bios that I didnt set, could something like that be a problem?

By the way should rc.local be edited in chrome os or in the chroot? I did both now.

Thanks a bunch for your help

[divx118]

No, You are on the right track. Only my kernel headers on the ppa are a bit out of date. I try to update them this weekend. Probably this will fix the crash/reboot.

On Sat, Mar 14, 2015 at 1:22 PM, Leo300MHz notifications@github.com wrote:

Ha ok, you must get a lot of clueless people like me with these problems. Sorry about that. A whole life of windows only makes this stuff hard.

I now did the same for partition 4, ran setup-headers.sh inside the chroot and installed virtualbox and rebooted again. During installation when it tries to teststart virtualbox modules it does give an error saying it is 'not suited to run k'. However booting into my chroot no longer gives the rc error and starting virtualbox also doesnt show an error any more. Then when I start a VM it doesnt throw an error any more either, but then my system crashes and reboots.

Is there something else I could have messed up?

You had me set the dev_boot variables with crossystem. There are similar variables in the bios that I didnt set, could something like that be a problem?

By the way should rc.local be edited in chrome os or in the chroot? I did both now.

Thanks a bunch for your help

— Reply to this email directly or view it on GitHub https://github.com/divx118/crouton-packages/issues/12#issuecomment-80406762 .

[divx118]

Ok, updated the headers for 3.8.11 amd64.
Following should pull them in. Follow on screen instructions.

$ sudo apt-get update
$ sudo apt-get upgrade

If you installed virtualbox with apt-get it should automatically recompile the modules. If you downloaded virtualbox from the site, you should do following to recompile:

$ sudo /etc/init.d/vboxdrv setup

Let me know if it now works for you.

[thegallivanter]

It gave a warning that there already were kernels with the same version number installed. I told it to continue anyways. Then I rebooted the chroot. At the first boot the chroot didnt run. At the second boot the chroot did run but it is unresponsive to any input.

[divx118]

Yep, continue anyway for the installed kernel is good. It sees the chromeos kernel which of course has the same version. It doesn't overwrite the chromeos kernel since you are in a chroot.
Hmm strange that the chroot is unresponsive. That shouldn't be a problem related to this.
Is it immediately unresponsive when starting it? Try updating your chroot with:

$ sudo sh ~/Downloads/crouton -u -n jessie

I can later today test them myself, but currently am busy with some other stuff.

[divx118]

I tried the new 3.8.11 kernel headers on a trusty (ubuntu) chroot. They work just fine for me. I will later also try them on a jessie chroot.

[divx118]

I didn't have time yet to test jessie. However updated all relevant kernel headers for the different architectures and kernels. Also included now the script to easy change the kernel flags and updated the README.md with the usage.

[DennisLfromGA]

@divx118,

That is a great script - I wish I could write'm like that. :+1: I'll use it as a study reference... ;)

[divx118]

@DennisLfromGA thanks :). There are still a few todo's in it, but that is for later. BTW if you find anything not working correctly or see some things that could be improved I like to hear it.

[DennisLfromGA]

@divx118,

Will do. I have a 128GB SSD sitting on my desk waiting for me to gather the courage to install it in my HP Chromebook 14 - it looks like a daunting task. Once done though, I'm hoping to try out various vm's.

[thegallivanter]

Last time I posted here I went on a holiday, then when I came back my chromebook had auto-updated so I needed to perform all the system edits I had done previously, before I could try your script again. I tried it just now and it works! None of the previous errors showed up. Thanks a bunch. Now downloading a windows 8.1 ISO file from the MS servers to install it as a VM, so I can also run windows only software in those few cases that its necessary.

Is there a way to automatically run "initctl stop update-engine" on boot so it doesnt auto-update any more? Its not always convenient to lose access to the VM so I would rather have it update when I choose.

[divx118]

@Leo300MHz To regain access you normally only need to run the change-kernel-flags script again in a cros shell. This will disable module_locking, after a chromeos update.

$ cd ~/Downloads
$ wget https://raw.githubusercontent.com/divx118/crouton-packages/master/change-kernel-flags
$ sudo sh ~/Downloads/change-kernel-flags

Sometimes new kernel headers will be needed, which can be installed if I already uploaded them with the following command in your chroot shell.

$ sudo apt-get update && sudo apt-get upgrade

To start something at bootup you will need to make your rootfs rw, else it will not be possible.

[johnthomas22]

Brilliant stuff. Now have an Oracle upgrade practise environment running on a Chromebook Pixel. Running an upgrade with two of four CPUs, and the virtual storage on a 128GB SD card!

Thanks for the great help. (The last step that resolved the vbox driver errors was your lines above downloading the change-kernel-flags script. )