Page 1 of 1
Driver mismatch on Debian Lenny
Posted: 28. Aug 2008, 16:05
by melektaus
Hi, I've tried searching for this on google and found this forum, where I've also searched but not really found a solution yet.
I'm running debian lenny, on an AMD X2 64 processor with a 32 bit userland (lenny i386).
I'm using (I think - typing this from memory atm) kernel 2.6.25-amd64 and the latest version of virtualbox-ose, 1.6.2-dfsg-4.
I have installed the module using module assistant:
Code: Select all
m-a update
m-a prepare
m-a a-i virtualbox-ose
modprobe vboxdrv
When I try to start a virtual machine, I get a driver mismatch error. From modinfo I can see the version of the module is 1.6.2_OSE (0x00070002), and I think the version of the client is the same, but am having trouble working out how to do that.
Any ideas? I'll be with the machine in a few hours so will be able to try some stuff out.
Posted: 28. Aug 2008, 17:24
by Sasquatch
If you installed it through the repo, there should also be a kernel module for it. If that all fails, install the Binary version from the website. You need the Kernel Headers too for creating kernel modules.
Posted: 29. Aug 2008, 00:26
by melektaus
I've now noticed there's a newer kernel version with modules package so I've tried installing that.
I'm now on 2.6.26-1-amd64, with the appropriate modules package, but still having the same issue.
Looking in the logs I have found:
Code: Select all
Support driver version mismatch: DriverVersion=too-old ClientVersion=0x70002
From modinfo I get:
Code: Select all
filename: /lib/modules/2.6.26-1-amd64/extra/virtualbox-ose/vboxdrv.ko
version: 1.6.2_OSE (0x00070002)
license: GPL
description: VirtualBox Support Driver
author: Sun Microsystems, Inc.
srcversion: 6B5C0862CA2306A1F17E574
depends:
vermagic: 2.6.26-1-amd64 SMP mod_unload modversions
parm: force_async_tsc:force the asynchronous TSC mode (int)
As you can see the version is the same, however on the module it's got a few more 0's on the left hand side. This really shouldn't matter as the decimal value is the same, but if it's doing a string match (which would be horrible) then I can see how it would fail.
I'm going to try some more kernels and see how I get on, in the meantime I would be grateful for any more light that can be shed on this.
Posted: 29. Aug 2008, 00:40
by melektaus
Bit of an update, I've changed my kernel to 2.6.26-1-686, and it all works fine. It's a bit of a bodge, as the amd64 kernel would be better suited for my machine, but what the hey.
FYI it doesn't seem to be what I thought it was with the extra padding, as this is still in place. Oh well at least I can play with it a bit for now.
Posted: 29. Aug 2008, 09:18
by frank
Note that with current versions of VirtualBox, you either have to use a 32-bit kernel with 32-bit userland or you have to use a 64-bit kernel with 64-bit userland. A 64-bit kernel with 32-bit userland is not possible.
Posted: 29. Aug 2008, 10:10
by melektaus
Thanks for that info. You say "current versions" - is there any plan to make this work in future versions or is it just too much pain for too little gain?
Posted: 30. Aug 2008, 11:47
by rewolff
FYI, I figured this out the hard way as well.
Trying to install the 64bit kernel module crashes because the 64bit installer executable doesn't run. And trying to install the 32bit kernel module of course doesn't work.
I have a nice 8Gb machine that would be ideal to run VirtualBox, but it has 32bit userland. We don't have applications to run on that machine that require large addressing space. The up to 7G of disk cache or the ability to run several large memory intensive apps parrallel is why the machine has a lot of memory. And running several VirtualBox servers there sounds like a good application.
Posted: 2. Sep 2008, 11:24
by frank
rewolff: You could use a 32-bit bigsmp kernel as well. This uses the PAE mode which still provides only 4GB per process but several processes can use more than 4GB RAM.
melektaus: Currently not planned since there are tons of other more important issues to fix/implement.