Kernel driver load for Trusty/Crouton suddenly failing (VirtualBox) about crouton-packages HOT 27 CLOSED

@laurenweinstein1 You are probably experiencing #26 can you post the output of uname -a ?

from crouton-packages.

Linux localhost 3.8.11 #1 SMP Tue Jan 5 21:57:29 PST 2016 x86_64 x86_64 x86_64 GNU/Linux

Noting that there's no panic, the drivers just aren't loading. I've been using the same headers for ages, if they've changed that would likely be involved. I built them myself originally via instructions from here, but haven't touched any of that in quite some time. Thanks.

L

from crouton-packages.

@laurenweinstein1 Did you run the script change-kernel-flags again. So you disable module_locking and are able to load modules?
Open a crosh shell and follow on screen instructions:

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

You need to do this after each chromeos update.

Edit: It could also be that your kernel headers are too old and have to be rebuild. You can follow the wiki again or use https://github.com/divx118/crouton-packages/blob/master/README.md

from crouton-packages.

That's all part of my standard scripts. Running them again (which I did
try, by the way) doesn't make any difference, since unlocking and rw both
report that they're already done. This is the first time these have failed
to permit the driver loads since I first got this going way back.

On Sun, Jan 10, 2016 at 3:30 PM, Maurice van Kruchten <
[email protected]> wrote:

@laurenweinstein1 https://github.com/laurenweinstein1 Did you run the
script change-kernel-flags again. So you disable module_locking and are
able to load modules?
Open a crosh shell and follow on screen instructions:

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

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

from crouton-packages.

You probably need to rebuild the kernel headers. I will check if the headers in the git here still works. I am on the same kernel 3.8.11 version.

from crouton-packages.

I'm not sure I remember the exact process to pull in the appropriate new sources and rebuild. Everything required would still be here though. Can you point me in the right direction? In particular, I don't want to muck up the Trusty crouton chroot itself in the process. That happened once and it wasn't pretty. Thanks.

from crouton-packages.

@laurenweinstein1 You can just use https://github.com/divx118/crouton-packages/blob/master/README.md So the kernel headers I build. Or backup your chroot first then follow the wiki on crouton github. So if you mess things up you can always restore.

from crouton-packages.

It should be safe to run your script so long as I save my rc.local to
restore afterwards, right? Thanks!

On Sun, Jan 10, 2016 at 3:56 PM, Maurice van Kruchten <
[email protected]> wrote:

@laurenweinstein1 https://github.com/laurenweinstein1 You can just use
https://github.com/divx118/crouton-packages/blob/master/README.md So the
kernel headers I build. Or backup your chroot first then follow the wiki on
crouton github. So if you mess things up you can always restore.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

from crouton-packages.

I ran your script but aborted out. Actually, I said OK to the headers
install in the script (my headers are in my home directory, with another
protection copy) but chickened out at the kernel image install. Then
restored my own rc.local. So I was able to get back into my system OK.

I made a new backup of the chroot to an external drive, but those scripts I
downloaded are where I got fouled up once before and blew away the chroot
completely. I do not fully understand what they are doing, nor am I sure
about the state of my system now, given that I did NOT abort the headers
install ("last chance to move your headers out of the way") when the script
complained that I already had a 3.8.11 directory. Obviously aborting at the
kernel image install apparently saved the system.

Any guidance appreciated so I can figure out where am I and the next best
steps to take. I just can't afford to have this system go down right now
and have to depend on that backup being restored.

Thanks.

L

On Sun, Jan 10, 2016 at 3:56 PM, Maurice van Kruchten <
[email protected]> wrote:

@laurenweinstein1 https://github.com/laurenweinstein1 You can just use
https://github.com/divx118/crouton-packages/blob/master/README.md So the
kernel headers I build. Or backup your chroot first then follow the wiki on
crouton github. So if you mess things up you can always restore.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

from crouton-packages.

I went ahead and built the new headers from scratch -- they built OK. I also saved the existing contents of /lib/modules/3.8.1 and moved them aside after unloading all modules. However, I'm getting errors when I attempt to load the new modules. I don't recall seeing this dkms.conf error before. Any ideas? Thanks.

#sudo dpkg -i linux-image-3.8.11_3.8.11-10.00.Custom_amd64.deb
(Reading database ... 216829 files and directories currently installed.)
Preparing to unpack linux-image-3.8.11_3.8.11-10.00.Custom_amd64.deb ...
Examining /etc/kernel/preinst.d/
Done.
Unpacking linux-image-3.8.11 (3.8.11-10.00.Custom) over (3.8.11-10.00.Custom) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.8.11 /boot/vmlinuz-3.8.11
Setting up linux-image-3.8.11 (3.8.11-10.00.Custom) ...
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.8.11 /boot/vmlinuz-3.8.11
run-parts: executing /etc/kernel/postinst.d/dkms 3.8.11 /boot/vmlinuz-3.8.11
Error! Could not locate dkms.conf file.
File: does not exist.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.8.11 /boot/vmlinuz-3.8.11
run-parts: executing /etc/kernel/postinst.d/pm-utils 3.8.11 /boot/vmlinuz-3.8.11
run-parts: executing /etc/kernel/postinst.d/update-notifier 3.8.11 /boot/vmlinuz-3.8.11

(trusty)lauren@localhost:$ sudo dpkg -i linux-headers-3.8.11_3.8.11-10.00.Custom_amd64.deb
dpkg: warning: downgrading linux-headers-3.8.11 from 20150314 to 3.8.11-10.00.Custom
(Reading database ... 216838 files and directories currently installed.)
Preparing to unpack linux-headers-3.8.11_3.8.11-10.00.Custom_amd64.deb ...
Unpacking linux-headers-3.8.11 (3.8.11-10.00.Custom) over (20150314) ...
Setting up linux-headers-3.8.11 (3.8.11-10.00.Custom) ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 3.8.11 /boot/vmlinuz-3.8.11
Error! Could not locate dkms.conf file.
File: does not exist.
(trusty)lauren@localhost:$ cat /proc/mounts | grep /lib/modules
(trusty)lauren@localhost:~$

from crouton-packages.

That kernel replacing warning you got shouldn't be a problem if you didn't make the chromeos rootfs writable it can't replace the kernel. Also it will be installed in the /boot of your chroot not in /boot of your chromeos.

Normally the dkm.conf shouldn't be a problem. Did you install your virtualbox from the ubuntu repo or from the oracle page? If from the oracle page you can sudo /etc/init.d/vboxdrv setup to rebuild the modules.
See if you got them:

$ sudo find /lib/modules -name *.ko | grep vbox

Then you can try to load them manually

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

When you installed from ubuntu there is a different way to rebuild them, I have written it down somewhere and see if I can find it again.
EDIT: All the above commands need to be executed in a chroot

from crouton-packages.

I actually am rw so I guess it's a good thing I stopped at that point --
that's apparently how I rendered Trusty unbootable originally when I first
set this up.

The vbox drivers are missing, only old ones are present:

/lib/modules/old/3.8.11/updates/dkms/vboxpci.ko
/lib/modules/old/3.8.0-31-generic/misc/vboxpci.ko

I believe (I can't swear to this) that my original vbox install was from
oracle, not Ubuntu. All my upgrades of vbox have definitely been by
downloading the oracle packages directly.

So I guess I'll go ahead with vboxdrv setup and try load manually. I'll let
you know how it goes. Thanks!

L

On Sun, Jan 10, 2016 at 11:54 PM, Maurice van Kruchten <
[email protected]> wrote:

That kernel replacing warning you got shouldn't be a problem if you didn't
make the chromeos rootfs writable it can't replace the kernel. Also it will
be installed in the /boot of your chroot not in /boot of your chromeos.

Normally the dkm.conf shouldn't be a problem. Did you install your
virtualbox from the ubuntu repo or from the oracle page? If from the oracle
page you can sudo /etc/init.d/vboxdrv setup to rebuild the modules.
See if you got them:

$ sudo find /lib/modules -name *.ko | grep vbox

Then you can try to load them manually

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

When you installed from ubuntu there is a different way to rebuild them, I
have written it down somewhere and see if I can find it again.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

from crouton-packages.

$ sudo /etc/init.d/vboxdrv setup
Stopping VirtualBox kernel modules ...done.
Uninstalling old VirtualBox DKMS kernel modulesError! Could not locate
dkms.conf file.
File: does not exist.
...done.
Trying to register the VirtualBox kernel modules using DKMSError! DKMS tree
already contains: vboxhost-5.0.10
You cannot add the same module/version combo more than once.
...failed!
(Failed, trying without DKMS)
Recompiling VirtualBox kernel modules ...failed!
(Look at /var/log/vbox-install.log to find out what went wrong)
(trusty)lauren@localhost:~$

On Sun, Jan 10, 2016 at 11:54 PM, Maurice van Kruchten <
[email protected]> wrote:

That kernel replacing warning you got shouldn't be a problem if you didn't
make the chromeos rootfs writable it can't replace the kernel. Also it will
be installed in the /boot of your chroot not in /boot of your chromeos.

Normally the dkm.conf shouldn't be a problem. Did you install your
virtualbox from the ubuntu repo or from the oracle page? If from the oracle
page you can sudo /etc/init.d/vboxdrv setup to rebuild the modules.
See if you got them:

$ sudo find /lib/modules -name *.ko | grep vbox

Then you can try to load them manually

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

When you installed from ubuntu there is a different way to rebuild them, I
have written it down somewhere and see if I can find it again.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

from crouton-packages.

Looks like it couldn't find the kernel. I'll try again:

cat /var/log/vbox-install.log
Uninstalling modules from DKMS
Attempting to install using DKMS
Failed to install using DKMS, attempting to install without
Makefile:185: *** Error: unable to find the sources of your current Linux
kernel. Specify KERN_DIR= and run Make again. Stop.

On Sun, Jan 10, 2016 at 11:54 PM, Maurice van Kruchten <
[email protected]> wrote:

That kernel replacing warning you got shouldn't be a problem if you didn't
make the chromeos rootfs writable it can't replace the kernel. Also it will
be installed in the /boot of your chroot not in /boot of your chromeos.

Normally the dkm.conf shouldn't be a problem. Did you install your
virtualbox from the ubuntu repo or from the oracle page? If from the oracle
page you can sudo /etc/init.d/vboxdrv setup to rebuild the modules.
See if you got them:

$ sudo find /lib/modules -name *.ko | grep vbox

Then you can try to load them manually

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

When you installed from ubuntu there is a different way to rebuild them, I
have written it down somewhere and see if I can find it again.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

from crouton-packages.

I put the KERN_DIR specification in vboxdrv. And got this. Perhaps it wants
it as an environment variable?

Uninstalling modules from DKMS
Attempting to install using DKMS
Failed to install using DKMS, attempting to install without
Makefile:185: *** Error: unable to find the sources of your current Linux
kernel. Specify KERN_DIR= and run Make again. Stop.

On Sun, Jan 10, 2016 at 11:54 PM, Maurice van Kruchten <
[email protected]> wrote:

That kernel replacing warning you got shouldn't be a problem if you didn't
make the chromeos rootfs writable it can't replace the kernel. Also it will
be installed in the /boot of your chroot not in /boot of your chromeos.

Normally the dkm.conf shouldn't be a problem. Did you install your
virtualbox from the ubuntu repo or from the oracle page? If from the oracle
page you can sudo /etc/init.d/vboxdrv setup to rebuild the modules.
See if you got them:

$ sudo find /lib/modules -name *.ko | grep vbox

Then you can try to load them manually

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

When you installed from ubuntu there is a different way to rebuild them, I
have written it down somewhere and see if I can find it again.

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

from crouton-packages.

Got it working. Changed to an environment variable and vboxdrv setup built the drivers and started them, VB is now running properly. Some problem in my rc.local is preventing them from starting at boot as they used to -- but they load manually and I'll figure it out. Thanks very much!

Update: It's a mismatch in the rc.local uname check for the drivers vs. their actual location, or something related. Easy to fix in various ways. Thanks again.

Best,

L

from crouton-packages.

@laurenweinstein1 Thanks for reporting back, sorry I didn't have much time to help you with this. Glad you solved it on your own. I agree /etc/rc.local should be improved, something still on my todo list.

from crouton-packages.

Looks like I have to re-open this. Trouble. Everything seemed to be working, but the ubuntu updater now keeps trying to download and install a 3.8.11 binary image. Apparently it fails the install, but keeps trying. Worse, after a boot it took me three tries to get back into the chroot. It kept failing and I see now that my rc.local hasn't run. So something is amiss! I'm going to take a chance and try reboot again.

from crouton-packages.

I've solved the booting/rc.local problem. But ubuntu updater keeps insisting it wants to download and install a 3.8.11 image -- the latter presumably fails, of course. Can you suggest a way to stop it? Thanks!

from crouton-packages.

Trouble. Everything seemed to be working, but the ubuntu updater now keeps trying to download and install a 3.8.11 binary image. Apparently it fails the install, but keeps trying. Worse, after a boot it took me three tries to get back into the chroot. It kept failing and I see now that my rc.local hasn't run. So something is amiss! I'm going to take a chance and try reboot again.

UPDATE:
I've solved the booting/rc.local problem. But ubuntu updater keeps insisting it wants to download and install a 3.8.11 image -- the latter presumably fails, of course. Can you suggest a way to stop it? Thanks!

from crouton-packages.

Here's what the updater keeps trying to download/install: Linux kernel binary image for version 3.8.11.

L

from crouton-packages.

Looks like there are more related problems. Tried to do a crouton-update -- noticed an error about trying to install a 3.8.11 image. The update stalled out with an incomplete chroot setup. I continued it and there were more errors. The chroot ultimately started -- but obviously there's a configuration problem now I'd like to fix. Here are some of the errors I was able to capture initially before the script aborted out the first time:

Fetched 5121 B in 16s (302 B/s)
Reading package lists... Done
Ensuring system is up-to-date...
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
wine
The following packages will be upgraded:
linux-image-3.8.11
1 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Need to get 0 B/6860 kB of archives.
After this operation, 650 kB disk space will be freed.
Preconfiguring packages ...
(Reading database ... 216838 files and directories currently installed.)
Preparing to unpack .../linux-image-3.8.11_20150314_amd64.deb ...
Ok, aborting, since modules for this image already exist.
dpkg: error processing archive /var/cache/apt/archives/linux-image-3.8.11_20150314_amd64.deb (--unpack):
subprocess new pre-installation script returned error exit status 1
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.8.11 /boot/vmlinuz-3.8.11
Errors were encountered while processing:
/var/cache/apt/archives/linux-image-3.8.11_20150314_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to complete chroot setup.

from crouton-packages.

@laurenweinstein1 Yes, that is because crouton does a sudo apt-get update && sudo apt-get upgrade however that will fail. I think it has to do with the fact that you previously aborted the install script. What happens if you run sudo apt-get update && sudo apt-get upgrade in the chroot? You can safely install linux-image-3.8.11_20150314_amd64.deb it will do no harm to your chromebook. Like I said before it will be installed in /boot of your chroot and is not used by chromeos or your chroot. I don't know if it is to late for that, but you could also first try removing /etc/apt/sources.list.d/crouton-packages.list and then run sudo apt-get update && sudo apt-get upgrade . /etc/apt/sources.list.d/crouton-packages.list contains the source of this git repo, maybe it removes the the willingness of apt-get to install/upgrade that package.

from crouton-packages.

This is very strange. I'm now getting apt-get not found when I try to run it on the CrOS side. Presumably somehow due to the forced abort of the setup script. I'm also having a problem with having to try several times to flip back to CrOS from Trusty before I get the window tabs and such -- but I've been seeing that recently and I don't think it's related to this problem. I'm willing to try pretty much anything that doesn't have a high risk of my being locked out of the chroot. Thanks.

from crouton-packages.

Not in cromeos, in your chroot. Just to clarify, when you start an update with the crouton script the crouton scripts enters your chroot at one point to do sudo apt-get update && sudo apt-get upgrade. Safest way is to remove my source file /etc/apt/sources.list.d/crouton-packages.list``in the chroot, then runsudo apt-get update && sudo apt-get upgrade` After it completes succesfully your chroot can also be updated with the crouton script again.

from crouton-packages.

Bingo. Everything now appears back to normal, and crouton-update also worked. I have to admit I do not fully understand the intricacies of the CrOS/Crouton/chroot architecture. Thanks again!

from crouton-packages.

np

from crouton-packages.