dmesg KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type cat /etc/pkg/FreeBSD.conf url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest", I did "pkg upgrade -f" after upgrade from 13.0 to 13.1, just in case the question comes up.
Binary packages (including kernel modules) are always build on the oldest supported FreeBSD version on that branch. So in this case all FreeBSD 13.x packages are build on 13.0. This works fine for all userland applications because there is binary compatibility guaranteed for it. This is not true for kernel modules so they need to be build on 13.1 otherwise you get that error message and it won't load. Now you have two options: 1) build the emulators/virtualbox-ose-kmod port on 13.1 yourself 2) wait until 13.0 is EoL and packages are build on 13.1, this is in exact 3 months from now
(In reply to Bernhard Froehlich from comment #1) That should be the opposite. Newest release builds latest packages. Pretty sure it's not the first time that comes up. However thanks for the fast reply.
Probably you haven't noticed but there is only one package set per branch (eg FreeBSD 13.x). So building them with 13.1 would mean they won't work on 13.0 because binary compatibility only works in one direction. So there isn't much we can do. A possible improvement would be to have a small package set (eg. all ports with USES=kmod) which is build per release and provided in a separate package repository but there are many problems to fix before this can become a reality and I don't know anyone working on that.
(In reply to Bernhard Froehlich from comment #3) Yeah, but waiting until your system is EOL, then upgrade to the newest RELEASE just to find out that there is a BUG (maybe), leaves you with a non working system, or rollback to a EOL Release. Plus much less Users with pkg and the need for a kernel-module will test the new release. Please don't get me wrong, i understand the reasons behind it, but it's also not optimal.
You can always build the kernel module ports on the machine yourself. They usually have very few dependencies so no big deal. It's the same for DRM kmod, wireguard kmod etc. so really nothing vbox specific.
(In reply to Bernhard Froehlich from comment #5) Yes i know and already did, just saying, if someone is new and installs the latest RELEASE wants to got the pkg-way (the obvious way) and is then told "hey just wait 3 month", that's kind of hmm...how to say it...unsatisfactory ;)
(In reply to Bernhard Froehlich from comment #5) (In reply to Bernhard Froehlich from comment #5) >It's the same for DRM kmod Well no, DRM works.
I'd like to point out that for the wireguard-kmod package it didn't "fail to load" if_wg.ko after the upgrade -- it caused a panic whenever someone connected to wireguard on the FreeBSD box. If it had noted something like what the vboxdrv.ko did -- "KLD vboxdrv.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type -- I would have been much happier.
Workaround that won't annoy you every time the port is updated: Install from source manually once: cd /usr/ports/emulators/virtualbox-ose-kmod make clean deinstall reinstall Configure your system to update from source from here on: pkg install auto-admin auto-mark-install-from-source emulators/virtualbox-ose-kmod kbi Now just use "auto-update-system" to upgrade your packages, ports, and base, and it will automatically rebuild emulators/virtualbox-ose-kmod from source after the ports tree us updated. The auto-update-system script lets you choose which components to update, but it's generally best to update packages and ports at the same time to keep them in sync and avoid version mismatches. Mixing binary packages and ports will lead to problems if your ports tree is out of sync with the binary package repo. "auto-update-system --defaults" will update everything without prompting. This should work find for quarterly on any architecture and latest on amd64, where binary packages are built continuously and generally don't lag behind ports by more than a few days. Latest binary packages may not keep up with the ports tree on other architectures, so mixing latest packages and ports will be risky.