Solved Virtualbox kernel module fails to load on FreeBSD 13.1-RELEASE

D

drr

After installing FreeBSD 13.1-RELEASE on my desktop today, Virtualbox fails to start. kldload vboxdrv results in the following error:
Code: 
kldload: an error occurred while loading module vboxdrv. Please check dmesg(8) for more details.

dmesg reports the following:
Code: 
KLD vboxdrv.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type

Anyone else experiencing this issue?
 
Thanks T-Daemon. Yes, I have these installed from binary packages. I have not built anything from ports yet and I may wait for the updated packages to land in pkg.
 
drr said:
I have not built anything from ports yet and I may wait for the updated packages to land in pkg.
Click to expand...
That will be three months from now, then 13.0-RELEASE will be officially End-of-Life and packages will be built for 13.1-RELEASE.
 
  • Thanks
Reactions: drr
My VirtualBox package seems to be running fine, as long as I kldunload the vmm module (which is used for bhyve.) I upgraded using freebsd-update and didn't reinstall the VirtualBox package and vboxdrv.ko is loaded. Maybe i just got lucky with this one? I do have packages set to pull latest. (The only thing I rebuilt was dwm, which I install from ports, as I have a custom config.h). NVidia is also working without problem, I actually have that package locked as I have an old NVidia card and if it upgrades, X stops working,
I used bectl to create a new boot environment in case I had issues, but the upgrade (using freebsd-update) was problem free for me.
 
If you have x11/nvidia-driver-390 (or the 340 version) installed you don't have to worry about it being upgraded to x11/nvidia-driver. That's not going to happen. The 390 (or 340) is part of the port/package's name, thus it will never "automagically" upgrade it to some other port/package.
 
  • Thanks
Reactions: drr
The video card is, according to pciconf -lv GK208 [GeForce GT 635]
The driver is nvidia-driver-470.63.01_1. Up until a few months ago, (don't remember when) just updating the nvidia-driver, without specifying a version, worked well. At present, it's at version 510. There is a message in the Makefile that it's dropped support for a number of cards and one should now use, for many cards, nvidia-driver-xxx and to check NVidia README (appendix) to see if you need to start using legacy drivers.

Looking through that, it shows that the nvidia-370 driver which I don't show in my ports directory, supports the 635M (Nothing about 635). This list of legacy drivers doesn't include nvidia-driver-470.

I should point out, if it's not obvious, that I know little about it. I used to just install nvdia-driver. When that stopped working, I went to the highest legacy version I saw, the nvidia-470, and when that worked, I stopped researching.
 
SirDice said:
That will be three months from now, then 13.0-RELEASE will be officially End-of-Life and packages will be built for 13.1-RELEASE.
Click to expand...
Thanks SirDice.
I have been using pkg due to my lack experience and knowledge in building from ports, compile times, etc. If I wish to stick to binary packages, would it be advisable to continue using 13.0-RELEASE till its End-of-Life?; And what would I miss out?
 
Just upgrade now to 13.1. 99.9% of the packages will run just fine, you have nothing to worry about those. It's only a couple of kernel modules that could potentially break (I'm not even sure they are broken due to changes between 13.0->13.1).
 
Just to update that I have switched to the 'quarterly' branch of FreeBSD 13.1-RELEASE and it has emulators/virtualbox-ose version
6.1.32_3 binary package, which works perfectly fine for me.

I guess only the version 6.1.34 binary package in the 'latest' branch is having the kernel module build differences.
 
How did u fix the problem ? I'm having a lot of problems installing VirtualBOX on 13.1. You can read the two threads that I've started :

forums.freebsd.org

Solved - ld: error: undefined symbol: soap_open_logfile error while compiling VirtualBOX

Hello. I was trying to virtualize Windows 10 with VirtualBOX on : # freebsd-version -kru 13.1-RELEASE 13.1-RELEASE 13.1-RELEASE # uname -aKU FreeBSD marietto 13.1-RELEASE FreeBSD 13.1-RELEASE n250232-e981f9a8e335 GENERIC amd64 1301000 1301000 ,but I've got this error : at this point I've...
forums.freebsd.org forums.freebsd.org
forums.freebsd.org

Solved - /out/freebsd.amd64/debug/bin/src/vboxdrv/vboxdrv.ko.debug: No such file or directory

Hello. it's again me that I'm trying to install VirtualBOX on FreeBSD 13.1-RELEASE. I see that the procedure to install it is changed on FreeBSD 13.1. Now I should install virtualbox-ose-kmod instead of virtualbox-ose,as explained here ...
forums.freebsd.org forums.freebsd.org
 
Upgraded to 13.1, having the same problem. Switched pkg to "pkg+http://pkg.FreeBSD.org/${ABI}/quarterly" and it also has virtualbox-ose-kmod-6.1.34_1.

Got sources from "https://download.freebsd.org/ftp/releases/amd64/13.1-RELEASE/src.txz", port tree via portsnap, port build fails:

Code: 
===>  Patching for virtualbox-ose-6.1.34
===>   virtualbox-ose-6.1.34 depends on file: /usr/local/share/kBuild/tools/GXX3.kmk - found
===>  Applying extra patch /usr/ports/emulators/virtualbox-ose/files/extrapatch-src-VBox-Devices-PC-ipxe-Makefile.kmk
===>  Applying FreeBSD patches for virtualbox-ose-6.1.34 from /usr/ports/emulators/virtualbox-ose/files
1 out of 2 hunks failed--saving rejects to src/VBox/HostDrivers/Support/freebsd/Makefile.rej
===>  FAILED Applying FreeBSD patch-src-VBox-HostDrivers-Support-freebsd-Makefile
===> Cleanly applied FreeBSD patch(es)  patch-Config.kmk patch-configure patch-include-iprt-x86.h patch-include_VBox_com_array.h patch-include_iprt_string.h patch-src-VBox-Additions-common-VBoxGuest-VBoxGuest-freebsd.c patch-src-VBox-Additions-common-VBoxGuest-freebsd-Makefile patch-src-VBox-Additions-common-VBoxGuest-freebsd-files_vboxguest patch-src-VBox-Additions-x11-Installer-98vboxadd-xclient patch-src-VBox-Additions-x11-Installer-vboxclient.desktop patch-src-VBox-Devices-Network-slirp-bsd-sys-mbuf.h
===> FAILED to apply cleanly FreeBSD patch(es)  patch-src-VBox-HostDrivers-Support-freebsd-Makefile

There seem to be a mismatch somewhere, please point me in the right direction.
 
Thamks SirDice, but it was set to latest on my machine. Tried to switch but always got virtualbox-ose-kmod-6.1.34_1.
 
karel said:
Tried to switch but always got virtualbox-ose-kmod-6.1.34_1.
Click to expand...
What version were you expecting to see?

(Note that a new quarterly was branched off less than a week ago, so latest and quarterly are pretty much the same right now).
 
Just need VirtualBox, so vboxdrv.ko should load. Patching issues indicate I have some mismatch in version of ports or sources. Or maybe port is broken.
 
karel , my previous post may have caused you some confusion. At the time of writing that post, the 'quarterly' branch had an older version of emulators/virtualbox-ose-kmod, than the 'latest' branch, which was not affected by this version mismatch issue. As SirDice has pointed out, the recent 'quarterly' update has brought the version of this package forward.

I think since version '6.1.34_1', emulators/virtualbox-ose-kmod has been tied to a specific release branch for stability. If I understood the maintainer of the port correctly, the 'binary package' is compiled to the lowest version of the release, which is currently 13.0. I can confirm that the latest binary package of emulators/virtualbox-ose works perfectly on 13.0.

I think the version mismatch issue will go away when 13.0 reaches EOL (3 months from the release of 13.1) and 13.1 becomes the lowest version. Till then, the solution may be to use the port instead of the binary package. I do not think the port could be broken as a binary package exists, but I am no expert in ports.
 
drr said:
I think since version '6.1.34_1', emulators/virtualbox-ose-kmod has been tied to a specific release branch for stability.
Click to expand...
It's not related to stability. But changes in the kernel could cause kernel modules built for previous versions to fail.

drr said:
If I understood the maintainer of the port correctly, the 'binary package' is compiled to the lowest version of the release, which is currently 13.0.
Click to expand...
Yes. FreeBSD 13.0 is still supported, so packages are built for that. Which is not a problem for 99.9% of the ports/packages. Certain third party kernel modules (like emulators/virtualbox-ose-kmod) can have problems though.

drr said:
I think the version mismatch issue will go away when 13.0 reaches EOL (3 months from the release of 13.1)
Click to expand...
Yep. That's 31 August. Then 13.0 is EoL and packages will be built for 13.1 specifically.


karel said:
Code: 
===> Patching for virtualbox-ose-6.1.34
Click to expand...
You only have to rebuild emulators/virtualbox-ose-kmod, not virtualbox itself (emulators/virtualbox-ose).
 
  • Thanks
Reactions: drr
So I pulled down a fresh ports tree and sources via git and my build problem was gone.

Code: 
git clone --depth 1 https://git.freebsd.org/ports.git /usr/ports
git clone https://git.freebsd.org/src.git /usr/src
cd /usr/src ; git switch releng/13.1

Created module from virtualbox-ose-kmod port loads and VirtualBox runs great on FreeBSD 13.1.

Thank you.
 
  • Like
Reactions: drr
karel said:
So I pulled down a fresh ports tree and sources via git and my build problem was gone.

Code: 
git clone --depth 1 https://git.freebsd.org/ports.git /usr/ports
git clone https://git.freebsd.org/src.git /usr/src
cd /usr/src ; git switch releng/13.1

Created module from virtualbox-ose-kmod port loads and VirtualBox runs great on FreeBSD 13.1.

Thank you.
Click to expand...

this command :

Code: 
git clone --depth 1 https://git.freebsd.org/ports.git /usr/ports

and these commands :

Code: 
portsnap fetch extract
portsnap fetch update

are they equivalent ? at the end I get the same result ? before to give this command :

Code: 
git clone --depth 1 https://git.freebsd.org/ports.git /usr/ports

should I delete the old ports tree ?
 
ziomario said:
are they equivalent ?
Click to expand...
They both fetch a ports tree, yes. They're not exactly equivalent, but it's close enough. Don't use both tools though, that's going to fail. Use one or the other.

ziomario said:
should I delete the old ports tree ?
Click to expand...
For a git clone ... the destination directory has to be empty (or not exist at all). So, yes, or move it out of the way.
 
Hello,
I have the same problem on FreeBSD 13.1 with virtualbox-ose-6.1.34 and virtualbox-ose-kmod-6.1.34_1. I was to try to compile those packages from the ports when I remember that the legacy version is available virtualbox-ose-legacy-5.2.44_11 virtualbox-ose-kmod-legacy-5.2.44_6 in the binary repositories. So I have install these packages and the kernel modules load without error. I can wait that the none legacy version be compiled for 13.1 before return to it.
 
Hi all! This may not be the best or cleanest solution, but it's working for me, until package binary is upgraded:

1. Download SRC tree from this link, and expand on /usr/src:
https://download.freebsd.org/releases/amd64/13.1-RELEASE/src.txz

2. Install virtualbox-ose and virtualbox-ose-kmod from pkg
# pkg install virtualbox-ose virtualbox-ose-kmod

3. Build kernel module from this ports, but do not install, just build it:
# cd /usr/ports/emulators/virtualbox-ose-kmod
# make

4. Copy just built modules into /boot/modules and overwrite existing ones (installed from packages):
# cd
/usr/ports/emulators/virtualbox-ose-kmod/work/stage/boot/modules
# cp *.ko /boot/modules

You should have these three modules:
vboxdrv.ko
vboxnetadp.ko
vboxnetflt.ko

5. Regenerate hint files to avoid boot warning:
# kldxref /boot/modules/

Hope it helps!
Regards :)
 
fyamamoto said:
3. Build kernel module from this ports, but do not install, just build it:
Code: 
 # cd /usr/ports/emulators/virtualbox-ose-kmod
# make

4. Copy just built modules into /boot/modules and overwrite existing ones (installed from packages):
Code: 
 # cd
/usr/ports/emulators/virtualbox-ose-kmod/work/stage/boot/modules
# cp *.ko /boot/modules
Click to expand...
Instead op copying the files manually you could also do a
Code: 
make reinstall

I am not sure if this is necessary?
Code: 
kldxref /boot/modules
 
You must log in or register to reply here.
Back
Top