Pixel 2015: unable to modprobe vboxdrv

[davidradkowski]

Retried few times already, to no avail :(

Every single time I get following error in dmesg:

supdrvGipCreate: failed to allocate the GIP page. rc=-26

[pigeonflight]

Getting the same error on a Dell Chromebook 13 I'm on the developer channel.

Version 54.0.2830.0 dev (64-bit) Platform 8714.0.0 (Official Build) dev-channel lulu Firmware Google_Lulu.6301.136.57

[forrestgit]

me too

[jamebus]

Looks like the kernel ABI has changed and we'll need new header packages.

[ferdbold]

I'm having issues as well on a Dell Chromebook 13. Retried a few times with various targets (xfce, kde, gnome) to no avail.

Version 53.0.2785.103 (64-bit) Platform 8530.81.0 (Official Build) stable-channel lulu Firmware Google_Lulu.6301.136.57

➜  ~ vboxmanage --version
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
         available for the current kernel (3.14.0) or it failed to
         load. Please recompile the kernel module and install it by

           sudo /sbin/vboxconfig

         You will not be able to start VMs until this problem is fixed.

[czenzel]

+1 Same issue on the Chromebook 2015.

[bumblebeers]

Hey, I'm here from #2793. I was actually having this same problem a few months ago on this same machine (Pixel 2015). I was on the dev channel at that point, so I could get the Play store. I ended up swapping back to the stable channel and reinstalling my chroot. After that, everything worked as expected and I was able to compile and install the headers and setup Virtualbox no problem. Now, I've updated my chromebook, still on the stable channel, and am having the same issue again. I can't help but wonder if it has something to do with ARC or the SELinux implementation for the Play Store. But then why would we be having issues on the Dell Chromebook 13...??

[bumblebeers]

I just did a powerwash and installed a fresh chroot, and I'm having the same problem.

crouton: version 1-20161010184059~master:0e57cac4 release: trusty architecture: amd64 xmethod: xorg targets: audio,core,cli-extra,extension,keyboard,x11,touch,xorg,gnome-desktop host: version 8530.93.0 (Official Build) stable-channel samus kernel: Linux localhost 3.14.0 #1 SMP PREEMPT Mon Sep 26 14:47:33 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux freon: yes

Version 53.0.2785.144 (64-bit) Platform 8530.93.0 (Official Build) stable-channel samus ARC Version 3301557 Firmware Google_Samus.6300.174.0

dmesg.txt

Here are my compiled .deb files just for kicks:

https://drive.google.com/open?id=0B5e6BkGq8HNfRDcxR3hVUmxDVHM https://drive.google.com/open?id=0B5e6BkGq8HNfZkdGVGtMYmRnTFE

Anything else I can provide to help please let me know I am at whit's end.

[bumblebeers]

From dmesg above

audit: type=1400 audit(1476156294.812:307): avc: denied { execute } for pid=25168 comm="vboxballoonctrl" name="VBoxBalloonCtrl" dev="sda1" ino=1594219 scontext=u:r:chromeos:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1

I really think this has something to with SELinux as I described in my first comment. Is there a way to totally disable SELinux so I could test this?

[drinkcat]

I really think this has something to with SELinux as I described in my first comment. Is there a way to totally disable SELinux so I could test this?

The line in dmesg says permissive=1, so nothing was actually blocked.

One thing that could have happened is that, for ARC++ support, the 3.14 kernel has changed quite a bit (new config options, possibly some ABI changes).

[bumblebeers]

@drinkcat Any idea how I might confirm this?

[drinkcat]

Huh, I just noticed that the earlier reports are on lulu R53/54, which clearly does not have ARC++... So I'm pretty sure this has nothing to do with SELinux.

So, I'm still not clear what broke, but generate new Linux kernel header files seems to be the right thing to try, first (I'm actually not sure how @divx118 did that).

If that still fail, you could try to bisect the kernel, I can provide instructions for that if you have time and motivation.

[divx118]

Sorry guys, been too occupied lately. I indeed think new kernel headers are the way to go. However if you follow the guide in the wiki you will build from the latest kernel source which can get you into problems as some new changes are in the kernel source that aren't in the released kernels for dev, beta or stable. So you probably need to checkout the kernel at an earlier time and then build the headers. @drinkcat is there any easy way to checkout the kernel source for the different channels instead of building the latest so the kernel headers are in sync with the released kernels? Normally I just build the latest source which worked fine 99% of the time, however lately with so many changes in the kernel this is not the way to continue.

[drinkcat]

Channels, not really, but each release (e.g. 53), has it's own branch in the repo, e.g.: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/release-R53-8530.B-chromeos-3.14

[divx118]

@drinkcat Ah ok, should be good enough. Thanks. @Pdbrantley try building the kernel headers with the above mentioned branch, that should be the right one for your kernel.

[bumblebeers]

@divx118 Thanks! I'll try as soon as I get off work this evening. Will update with results.

[bumblebeers]

No Luck! Recompiled from the reccomended source. Still getting the same error.

Here is dmesg:

dmesg.txt

I'll try to update with more info tomorrow morning.

[drinkcat]

Trying to figure out what's going on in Virtualbox source code (/var/lib/dkms/virtualbox/4.3.36/source/vboxdrv):

supdrvGipCreate: failed to allocate the GIP page. rc=-26

=> errno 26 is ETXTBSY (that's an extremely uncommon error code...)

Due to this call failing:

    rc = RTR0MemObjAllocCont(&pDevExt->GipMemObj, RT_UOFFSETOF(SUPGLOBALINFOPAGE, aCPUs[cCpus]), false /*fExecutable*/);
==> RTR0MemObjAllocContTag((pMemObj), (cb), (fExecutable), RTMEM_TAG)
==> rtR0MemObjNativeAllocCont(pMemObj, cbAligned, fExecutable)

(which then calls many Linux kernel functions)

But, back to the ETXTBSY error, it most likely comes from include/linux/fs.h, get_write_access or deny_write_access, but then I have no idea where these calls come from.

Somebody should try to instrument rtR0MemObjNativeAllocCont in vboxdrv (add printk's...), and see exactly which calls are being made, and where exactly the failure happens.

I did have a cursory look at kernel 3.14 diffs between R51 and R53, and I don't see anything of interest. But again, it used to work (right?), so bisecting the kernel is definitely something that could be tried. It's long and boring, but relatively easy.

[kdavh]

I'm in the same boat as @Pdbrantley . Virtualbox broke for me on updating to Chrome OS v53 on Pixel 2015. I'm not familiar enough with linux kernels etc, so I'm glad you all are looking into it.

[bumblebeers]

@drinkcat Sorry, I've been busy and haven't had much time to devote to this lately. I really appreciate all of your help.

To answer your question, yes it did work. Right up to the point when the play store was brought to the stable channel. I'm assuming R53.

Unfortunately we have gotten a little out of my depth, but with that being said, I'm willing to put in the time and effort to get this working, hopefully with minimal hand-holding on your part.

I'm not really sure how I would go bout "instrument[ing] rtR0MemObjNativeAllocCont in vboxdrv" but I'm happy to give it a shot if someone could point me in the right direction.

Also, I'm down for bisecting the kernel from R51 to R53, but I'm not quite sure how I would actually be able to test it. I know that I won't really be able to spot the problem from source. I guess I could compile and test headers on each commit, but good lord, that would take forever... Any better ideas on this?

[drinkcat]

I'm not really sure how I would go bout "instrument[ing] rtR0MemObjNativeAllocCont in vboxdrv" but I'm happy to give it a shot if someone could point me in the right direction.

You need to find a way to rebuild vboxdrv kernel driver from source, and add some printk("XYZ") at various places in the code (which will then show up in dmesg), until we understand exactly which call is failing.

Also, I'm down for bisecting the kernel from R51 to R53, but I'm not quite sure how I would actually be able to test it. I know that I won't really be able to spot the problem from source. I guess I could compile and test headers on each commit, but good lord, that would take forever... Any better ideas on this?

One should bisect the kernel itself, not the headers (by rebuilding it using a Chromium OS SDK chroot). It only takes log(number of commits) to do. The idea is that you start from a range x..y (where x is good, y is bad), and then test the commit halfway between x and y, until you find the bad commit.

But if it's related to ARC++ enabling, it might be very tricky... Let's try the tracing approach first.

[sclaughl]

I'm in the same boat -- upgraded Chrome OS on my pixel and am now unable to run virtualbox. I tried using the crouton-packages/README.md approach, and when that failed I followed the more involved instructions at "Build kernel headers and install Virtualbox (x86)" from the crouton wiki. I took care to use the chromeos-3.14 branch of the kernel repo (since my chrome os is running 3.14.0). At any rate, I'm having no luck, and I'm not sure what to do next. But I'm happy to help in any way I'm able, so please let me know if there's anything I can do..?

[sudonotpseudo]

@divx118 Thanks, I will continue to follow here.

[divx118]

Ok, tested it on 3.8.11 kernel

Version 55.0.2883.29 dev (64-bit)
Platform 8872.27.0 (Official Build) dev-channel falco
Firmware Google_Falco.4389.92.0

and have the same issues loading vboxdrv.ko results in

[  807.320038] Chromium OS LSM: init_module locking-ignored module="/home/chronos/user/Downloads/kernel/vboxdrv.ko" pid=11707 cmdline="insmod vboxdrv.ko"
[  807.332058] vboxdrv: Found 2 processor cores
[  807.332235] supdrvGipCreate: failed to allocate the GIP page. rc=-26

This is with freshly build kernel headers on branch release-R55-8872.B-chromeos-3.8 . I will follow @drinkcat advice and see if I can add some printk to the driver source.

[bumblebeers]

configure.log.txt

I've been attempting to compile vbox and add in some printk as recommended, but have had issues compiling, well issues configuring actually. Specifically with libvpx and vpx.pc. I've attached configure.log if you run into the same problem or have a solution please let me know, otherwise I will keep working at it.

Also, just a quick note, I am compiling in my chroot. Figured that would give it the best chance of actually working when complete. I was wondering though if I should just compile for redistribution on another machine just so I can actually get a .deb file with the printk inserted. Thoughts on this?

[divx118]

@Pdbrantley For building the module again, I just cd into /var/lib/dkms/virtualbox/5.0.24/build/vboxdrv and then use sudo make vboxdrv and to clean sudo make clean Not my choice building as root, but in this case, just for testing it is the easiest fastest way. The vboxdrv.ko will turn up in the same folder as where you build. So you can use in the same folder sudo insmod ./vboxdrv.ko For now, to see what is going wrong it will be enough to only build the vboxdrv.ko since that is the first one to be loaded the other modules depend on it. If that fails the rest will also fail.

[divx118]

@drinkcat @Pdbrantley Ok, had a bit of time tonight and traced the failing call back to file /var/lib/dkms/virtualbox/5.0.24/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c replace 5.0.24 with whatever version you have. https://gist.github.com/divx118/eb237697872bf2a624bf21b27720d104 line 731 and 738 both fail with -26 . This is due to line 323 paPages = 0 and then return -26 on line 338

Still need to look into it further, but for now a little update. Maybe someone has already an idea? :)

[drinkcat]

Had a quick look, and I have no clue... I think you'd need to start tracing into __alloc_pages_nodemask in mm/page_alloc.c. I'm also curious if vbox code sets __GFP_REPEAT.

[divx118]

@drinkcat Didn't have much time yet to dive into it deeper. vbox code, only sets it when cPages > 255 cPages is 1, so __GFP_REPEAT is not used. I see if I have some time tracing __alloc_pages_nodemask in mm/page_alloc.c.

[bumblebeers]

I haven't been able to donate much time to this, and it's pretty much over my head now anyway, but I wanted to post an update.

Just got a stable channel update. Installed and custom compiled new headers using my new release branch: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/release-R55-8872.B-chromeos-3.14 and experienced the same problem.

Not much help I know, but just wanted to add the info.

[divx118]

I also have been to busy to investigate it further. However thanks for the update @Pdbrantley

If someone is really desperate to run virtualbox, I suggest for the mean time enable legacy usb boot and use a fast sd-card or USB stick to install a regular linux distro on. I did it in the past with a fedora distro and it worked very well and fast. You just can't switch that easily to chromeos, but you have to reboot to start chromeos.

[kdavh]

Thanks for the update. Personally, I've resigned myself to a remote ssh development setup on my Chromebook, which is working pretty well.

On Dec 23, 2016 08:42, "Pdbrantley" notifications@github.com wrote:

I haven't been able to donate much time to this, and it's pretty much over my head now anyway, but I wanted to post an update.

Just got a stable channel update. Installed and custom compiled new headers using my new release branch: https://chromium.googlesource.com/chromiumos/third_party/ kernel/+/release-R55-8872.B-chromeos-3.14 and experienced the same problem.

Not much help I know, but just wanted to add the info.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/divx118/crouton-packages/issues/45#issuecomment-269015846, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsuIXX8bMNLy7a6zpQ4uSIqGY3SEzyRks5rK_oPgaJpZM4JoB9k .

[bumblebeers]

Hey, I'm not really making any headway on this issue, and it doesn't look like anyone else is either. @divx118 That is a good suggestion to install ubuntu natively, but I really need to be able to switch quicker than that. I'm don't really care about having the Play store, actully I den't even have it enabled because it was making the cosh window really buggy.

So I was wondering if it would be possible to get a previous firmware version and make a recovery USB from it to downgrade? I guess the main problem for this would be actually finding an old version of the firmware from back when it was still working. Any ideas??

[AndyRJay]

You can use the Recovery tool, and create from local image file(click gear image) to use a previous version. You just need the image file.

I think these are still active depending how far back you want to go , but don't guarantee they will work,

If you contact Pixel support they can give specific URL to the older images, you just have to stop it updating again.

https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_7647.84.0_samus_recovery_stable-channel_mp.bin.zip

https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_7262.57.0_samus_recovery_stable-channel_mp.bin.zip

[bumblebeers]

@AndyRJay Thanks for the links! How did you get those. I'm looking for Platform: 8172.47.0 (version 51). I tried just changing the url, but no dice. I emailed Google support and am waiting on a response form them, but I don't have high hopes. They were no help at all on the phone. I tried the links above, but were not able to flash them: "An unexpected error has occurred". I think maybe because they are too old, but I'm not sure...

[AndyRJay]

Ooops forgot to say which model you got ? 2015 one or the older one ?

I get the urls as I log them on my firewall. I would recommend blocking the download url / host so you can control when its safe to upgrade chrome until all parts available as it can be a pain in the a**.

I will see if I can find that download, tonight or tomorrow.

[bumblebeers]

@AndyRJay I have the 2015 model (SAMUS E25-H7R-W5L). You would be my hero if you could find that download. Thanks so much for your help!

[AndyRJay]

You looked on here @Pdbrantley

https://productforums.google.com/forum/#!forum/chromebook-central

[AndyRJay]

@Pdbrantley https://productforums.google.com/forum/#!topic/chromebook-central/ZLlLP_B1X40;context-place=topicsearchin/chromebook-central/introducing aka v51

[bumblebeers]

@AndyRJay Yeah, read through that post earlier, but doesn't contain any kind of download links for the bin file. Searched through the product forums and couldn't find anything, so I just started a new topic. Hoping to get some good replys.

[bumblebeers]

Happened to have a Google Apps reseller account. Contacted support through that, and they will absolutely not give out Chrome OS download links. So unless you or someone else in the community has the links saved looks like we are out of luck.

[AndyRJay]

@Pdbrantley did some digging as I tend to keep recovery sticks just in case, they appear to have done some changes that create issues when trying to restore from a valid but older recovery stick, so post vierification it fails. I will see if I can see what they do and worse case I can send you and old recovery USB as I have a .51 on an old 4GB freecom stick

[webwizardworks]

@divx118, I want to take a moment to thank you for the contribution you have given us. The ability to install VB is/was a miraculous bonus and worked so well. Thank you very much!

Given the challenges in getting this working again, is it likely we will see a stable and lasting solution or do we need to move on?

[divx118]

@webwizardworks I still want to take a look at it one more time, just to know what is causing this. However for using a virtualbox, I would suggest using legacy boot. I myself have now a dual boot system with galliumos (which under the hood is xubuntu). https://galliumos.org/ and installed virtualbox on there. I used the chrx method on my new acer chromebook 14 for work with intel i5 cpu and 64Gb ssd. https://wiki.galliumos.org/Installing#chrx_Installation Running virtualbox on chromeos will always be a pain, because you can't control the kernel. So on every chromeos update you will have a risk of breaking your virtualbox. So a stable and lasting solution will always be an illusion on chromeos. Not updating chromeos will be IMHO defeat the whole purpose of running chromeos in the first place.

[webwizardworks]

@divx118, I appreciate your comments and understand the ever changing kernel issue. I picked up another Chromebox for the sole purpose of setting up Linux/VB install, thanks for the galliumos info. Is 64gb big enough or are you also using an external drive?

[divx118]

@webwizardworks 64Gb is big enough for me. I used a 45Gb partition for the galliumos I must check how much is used, but I expect nothing over 4/5 Gb with all the programs I have installed. My virtualbox image should fit on it easily, but I used an external 16Gb SD-card for that, just to have some future space for git clones building stuff etc. On my virtualbox I have a bare windows 7, just to run itunes for my wifes iphone and to have windows present if I am helping some friends with computer stuff. I know I could run wine, but a virtualbox image is more convenient for me and I can easily contain all the microsoft trash :).

[DovW]

I am multi-booting with Legacy boot (no kernel partitions - just vmlinuz in root boot directory) into Pixel 2015 (samus) Chrome OS build 56 54 copied on top of on a very recent Chromium OS build 59 ( kernel (4.4.44-07357-g1ff8560) on 2 partitions (ROOT and STATE) on a Dell Inspiron PC laptop and have Chrome OS and Ubuntu Trusty in crouton working well.

I followed the instructions to Build kernel headers and install Virtualbox (x86) and successfully built and installed chromeos kernel packages and I am getting failures with the change-kernel-flags script (almost certainly because I don't have kernel partitions) which probably explains my failures loading vboxdrv.

In /proc/cpuinfo I have a vmx entry but running dmidecode from inside the chroot I see no flag for vmx. Is there a way to get past this problem and if I do will I be affected by this bug

Since I am booting from grub multibooting running Chromium OS kernel from Chromium OS builds I build myself now realize that I can build it with --boot_args I added 'disablevmx=off lsm.module_locking=0' to my grub menuentry that should resolve all of my issues - going to try that

I am able to load the modules but my PC reboots when I start a VM - this is what I get from dmesg:

Oops#1 Part1

<4>[ 967.381714] FS: 000078d5f5aa5740(0000) GS:ffff88021fa00000(0000) knlGS:0000000000000000 <4>[ 967.381715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 967.381716] CR2: 0000000000000080 CR3: 000000007c1bd000 CR4: 00000000001406f0 <4>[ 967.381717] Stack: <4>[ 967.381718] 0000000000000001 ffff88007c19bd40 ffffffffc07005e5 0000000000000000 <4>[ 967.381721] ffffffffbcb160c0 ffff88007c19bd68 8000000000000025 0000000000000000 <4>[ 967.381723] 0000000000000001 0000000000000246 00000000024002c0 ffff8800b2ed6868 <4>[ 967.381725] Call Trace: <4>[ 967.381736] [] rtR0MemObjNativeMapUser+0xbf/0x231 [vboxdrv] <4>[ 967.381744] [] VBoxHost_RTR0MemObjMapUserTag+0x14a/0x197 [vboxdrv] <4>[ 967.381752] [] SUPR0GipMap+0x119/0x2a2 [vboxdrv] <4>[ 967.381759] [] ? rtR0MemAllocEx+0x132/0x201 [vboxdrv] <4>[ 967.381764] [] supdrvIOCtl+0xfb0/0x2ac9 [vboxdrv] <4>[ 967.381767] [] ? __might_fault+0x35/0x37 <4>[ 967.381771] [] VBoxDrvLinuxIOCtl_4_3_40+0x165/0x1e0 [vboxdrv] <4>[ 967.381775] [] do_vfs_ioctl+0x42e/0x501 <4>[ 967.381778] [] ? security_file_ioctl+0x35/0x49 <4>[ 967.381780] [] SyS_ioctl+0x57/0x79 <4>[ 967.381782] [] entry_SYSCALL_64_fastpath+0x1c/0x74 <4>[ 967.381784] Code: 44 00 00 55 31 d2 be 30 00 00 00 48 89 e5 53 48 89 fb 48 c7 c7 55 f5 7f bc e8 a7 84 8e ff 48 ba 01 00 00 00 ff ff ff ff 48 89 d8 48 0f c1 10 85 d2 74 05 e8 8a cc af ff 65 48 8b 04 25 80 ae <1>[ 967.381811] RIP [] down_write+0x2d/0x4b <4>[ 967.381815] RSP <4>[ 967.381816] CR2: 0000000000000080

[DovW]

Did not get anywhere with Virtualbox and so I switched to qemu and I was able to boot up Win 7 on Ubuntu Trusty in Crouton without needing to build any custom kernels.

Maybe that's a better idea for those stuck with this Virtualbox bug...

[divx118]

@DovW thanks for the suggestion. Virtualbox is indeed a bit of a dead end currently on crouton. To get virtualbox working I recommend a dual boot like mentioned above https://github.com/divx118/crouton-packages/issues/45#issuecomment-281434222 I will try qemu. Sounds interesting see how well that works.

[DovW]

@divx118 I've got to admit that I'm very spoiled and I like hacked solutions - I'm not on a Chromebook at all - I'm on a quadcore core i5 PC with 8GB RAM and 1TB harddrive originally multibooting only into Win 10 and Ubuntu, on each of which I run VMs (including Mac OS) in virtualbox and VMware, but for initial bootup speed, UI experience and now Android integration my primary boot is now Pixel 2015 Chrome OS on legacy boot into a Chromium OS kernel and I want to be able to do most everything without reboot - which crouton+qemu now gives me

[DovW]

As an update, I am not sure whether my suggestion of using qemu instead of virtualbox is very practical because from my understanding of this issue in order for qemu to run reasonably there is a need for the KVM kernel modules.

In my case since I am anyway running on a multibooted PC and since because of my setup I anyway can't get automatic Chrome OS updates I got the KVM modules by building an entire Chromium OS image as detailed here and then because I want Chrome OS and not Chromium OS for the full UI and Android integration I copied over (preserving all permissions) all the files from the ROOT and STATE partition mounts in the appropriate Chrome OS Recovery image on to my ROOT and SAVE partitions on my PC.

Anyone wanting a kernel with KVM modules on their Chromebook would have to choose between either running Chromium OS instead of Chrome OS (and in the process losing Android integration on select models) or to get the best of a Chromium OS kernel with KVM modules and their usual Chrome OS on top they would have to forego automatic updates and do the following hack:

1) install the KVM Chromium OS image (as detailed here)

2) copy over with preserved permisssions all of the files on the ROOT and STATE filesystems in the Chrome OS Recovery image onto their Chromebook ROOT and STATE filesystems (for example for those models that support it by either multibooting into Linux or for those without the space for a Linux Install booting into a Linux USB with the appropriate filesystems copied with preserved permisssions into ROOT and SAVE folders on the USB)

That last hack may be far too heavy a price for any but the most stubbornly persistent and substituting Chromium OS for Chrome OS may not be desirable for most and so for those whose models either natively support multibooting or support custom firmware, @divx118 's suggestion of multibooting for virtualbox support (and/or for that matter installing and directly booting into supported OSs) could be a far better option.