Re: Virtualbox kernel module on 11-CURRENT

From: Kevin Oberman <rkoberman_at_gmail.com>
Date: Tue, 7 Jun 2016 14:13:03 -0700
On Tue, Jun 7, 2016 at 1:04 AM, Guido Falsi <mad_at_madpilot.net> wrote:

> On 06/07/16 02:23, Rafael Rodrigues Nakano wrote:
> > Hello,
> >
> > I tried installing virtualbox from packages, building it from sources,
> > trying the GENERIC kernel but everytime I can't start the kernel module
> > 'vboxdrv', it says:
> > "KLD vboxdrv.ko: depends on kernel - not available or version mismatch.
> > linker_load_file: Unsupported file type"
> >
>
> The virtualbox module needs to be in full sync with the kernel. Most
> probably the sources being used by the cluster for building packages on
> head are a little different from yours, so the kernel module is not in
> sync.
>
> You will need to build the kernel module yourself to actually match your
> kernel sources.
>
> It's not really a problem or a bug, it's how it works. On head there is
> no warranty about the KBI. This cannot happen on releases and stable
> because the KBI is not going to change there.
>
> --
> Guido Falsi <mad_at_madpilot.net>
>

I don't think this is true. While shareable libraries have fixed ABIs, I
believe the KBI can change even in STABLE branches.  If a security fix
requires it, it might even change in a RELEASE. I my be wrong about this,
but I recall having to re-build the VB kmod port even withing a minor
version (i.e. STABLE).

In any case, I do strongly recommend the use of PORTS_MODULES in
/etc/src.conf to assure that the kernel modules always get re-built when
the kernel is re-built. so that the sources, the kernel, and the module are
in sync. The PORTS_MODULES are re-installed as a part of the "make
installkernel", so things are almost safe, but beware of "make
reinstallkernel" as it does not do the right thing. (See
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201779)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman_at_gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Received on Tue Jun 07 2016 - 19:13:05 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:05 UTC