On 06/07/16 23:13, Kevin Oberman wrote:
> On Tue, Jun 7, 2016 at 1:04 AM, Guido Falsi <m...@madpilot.net
> <mailto:m...@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 <m...@madpilot.net <mailto:m...@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).

I'm unable to find a final statement about KBI stability, but freezing
it is an essential step in the new major release schedule:


(KBI freeze begins      24 June 2016)

If the promise has not been maintained in the past it's a sad event and
a mistake, but the promise is still valid in it's intent.

BTW at present the cluster building packages for 10.x is running on
10.1, so the kernel modules built by it are built on 10.1 and will work
on 10.3. This would be impossible without KBI being frozen.

Mistakes do happen unluckily.

> 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)

Yes leveraging PORTS_MODULES is a good solution, although I don't like
mixing the system build process with the port one so I prefer manually
doing the modules part.

Guido Falsi <m...@madpilot.net>
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to