Solved freebsd 13.2 and virtualbox-ose

That is how you get ZFS or NVidia drivers on Linux. If the kernel or the target package change, then the kernel module is recompiled.
This was precisely an incentive for me to replace a Linux install with FreeBSD recently. With the Linux kernel receiving frequent minor updates, most routine package upgrades result in a recompilation of the nvidia module, which gets quickly annoying. I certainly prefer the FreeBSD annoyance of building it once every few months!
 
I use a slightly different method for virtualbox-ose-kmod

Code:
portsnap fetch update
cd /usr/ports/emulators/virtualbox-ose-kmod/ && make

To speed up the build, as mentioned by others, install dependencies using pkg before running make

Note I am not doing a make install
Once make completes you can do something like ...

Code:
cp /usr/ports/emulators/virtualbox-ose-kmod/work/stage/boot/modules/vboxdrv.ko ~/kmods/
# then load the module and start virtualbox-ose
kldload ~/kmods/vboxdrv.ko

If above works then we can do some cleaning up

Code:
pkg autoremove
rm -rf /usr/ports/*/*/work

Now we wait 3 months for pkg to catch up or repeat if needed, we are still using fully the pkg system so things are somewht clean
 
  • Thanks
Reactions: grz
Is a comeback of drm-kmod in base actually planned/wanted by the developers?
I've heard about that at least once. Not sure you can call that "planned", but "wanted" at least by some people relevant in that area. And it certainly makes sense because there already is this very close dependency on the kernel.

I thought it was moved to ports so that support for newer graphics hardware could be made available without users having to wait for the next stable release, which is a positive change.
I think this is more or less an urban myth. More often than not, newer drivers will also need changes to the in-kernel linuxkpi stuff, so can't be delievered independently anyways. And besides, there aren't so many changes in the drivers that the FreeBSD minor releases wouldn't normally be enough...

From what I've heard (maybe that's a myth as well?), the reason to move these drivers to ports was licensing, there was some GPL'd code needed to upgrade them (upgrades in base were stalled for that reason). The need for that should be eliminated by now.
 
For everyone's amusement, I should mention that you only have to build virtualbox-ose-kmod from ports. If you misread a thread and rebuild virtualbox-ose from ports, that takes awhile. Guess how I know this? :)

Thinking, gee, they said it only takes a short while, rereading the post and saying, Oops had its funny side.
 
The problem on my method is that when using git repositories I'm using 1.6GB extra for the git database for src and another 1.2GB for ports, almost 3GB just for the git database.
/usr/src
$ du -sh .git
1.6G .git
/usr/ports
$ du -sh .git
1.2G .git

Ok, I could just delete that .git after clone but then no more 'git pull' to update code.
Good I don't have problems with disk space for now so I'll just leave it there.
 
For everyone's amusement, I should mention that you only have to build virtualbox-ose-kmod from ports. If you misread a thread and rebuild virtualbox-ose from ports, that takes awhile. Guess how I know this? :)

Thinking, gee, they said it only takes a short while, rereading the post and saying, Oops had its funny side.
Did the same. See my previous post. ;)

By the way, even if it isn't mandatory, think to update your bootcodes: https://forums.freebsd.org/threads/update-of-the-bootcodes-for-a-gpt-scheme.80163/

I saw that the efi loader isn't updated even when /boot/efi is mounted (this is the case by default if you start by a 13.x-RELEASE installation). I noticed that you have a copy of loader.efi in /boot/efi/efi/freebsd. Don't know why, but updated it too.
 
Did the same. See my previous post. ;)

By the way, even if it isn't mandatory, think to update your bootcodes: https://forums.freebsd.org/threads/update-of-the-bootcodes-for-a-gpt-scheme.80163/

I saw that the efi loader isn't updated even when /boot/efi is mounted (this is the case by default if you start by a 13.x-RELEASE installation). I noticed that you have a copy of loader.efi in /boot/efi/efi/freebsd. Don't know why, but updated it too.
I use MBR so that a no problem to me.
Yes I know, GPT is the new stuff, manage partitions with more capacity, etc, but I don't use zetabytes HDDs so I just keep the old MBR.

But it's good to know that bootcodes need update also.
 
Upgraded my server/router/multimedia machine to 13.2-RELEASE. The graphic driver graphics/drm-510-kmod didn't need to be recompiled. No more problem than I got with 13.1-RELEASE so far (though, a big one with vlc since several weeks).
 
13.2 was released yesterday (11 April), so until 11 July 13.1 will still be the default one for pkgs builds. However, Virtualbox (according to its commit history) doesn't get updates too often, just every ~3 month. You shuold be fine for the time being.
There is a new version of emulators/virtualbox-ose and emulators/virtualbox-ose-kmod in the latest repo. I upgraded virtualbox-ose and not virtualbox-ose-kmod (because it is locked). That runs as is. But, maybe I should also lock virtualbox-ose. I will see.
 
I just updated both packages in the course of a regular package upgrade. The new versions are working fine for me. (using latest, not quarterly.)

virtualbox-ose-6.1.36_2
virtualbox-ose-kmod-6.1.36_1
 
I just updated both packages in the course of a regular package upgrade. The new versions are working fine for me. (using latest, not quarterly.)

virtualbox-ose-6.1.36_2
virtualbox-ose-kmod-6.1.36_1
Did you reboot the machine or reload vboxdrv.ko?
 
You're quite right. I hadn't rebooted or reloaded and it did break things. I'll blame it on having a senior moment and simply forgetting the obvious. I had to reinstall kmod from ports which wound up installing gcc from ports. Sorry for the incorrect info, I see I'm going to have to lock the kmod, which, in hindsight, I really should have done before doing a pkg upgrade.
 
which wound up installing gcc from ports.
It doesn't matter how dependencies are installed, so if you only build from ports to circumvent the in-kernel-ABI changes, but use packages otherwise ... best make sure to install all the build-deps using pkg upfront.
 
Is this still an issue? I can't seem to get the vboxdrv kernel module to load on 13.2, and we're three months after when this initial discussion was raised?

I have a fresh build of FreeBSD 13.2, virtualbox kernel modules don't seem to work

pkg install virtualbox-ose-kmod returns something about it only working with 13.1 kernels

Trying to build ports virtualbox-ose-kmod took 12 hours and then failed due to not finding the kernel source tree, which I'll try to install a bit later. Seems a bit obtuse having to compile for 12 hours (or an amount of time on better hardware...) for each instance of 13.2 that wants to run virtualbox though?
 
I think, if you have /usr/src installed, that just compiling the kmod should be very quick. Installing /usr/src/ is pretty easy.
Code:
git clone -b releng/13.2 --depth 1 https://git.freebsd.org/src.git /usr/src
And should not take very long.
 
Ideally quarterly packages like the one above should work with the latest release, without having to compile them locally.
 
I got it working, it took hours, I had to uninstall the pkg versions and compile virtualbox-ose and virtualbox-ose-kmod and dependencies using ports. Basically a day lost, and a fair bit of electricity too. Inconvenient, but it is what it is, especially as I'm not offering any solutions (due to not knowing any!).
 
I did
cd /usr/ports/emulators/virtualbox-ose-kmod
make install

It spiralled off and did all the science and mathematicals. Is there a more optimal command?
That will also build and install any missing build requirements.

Code:
     Example 2: Installing Dependencies with pkg(8)

       The following example shows how to build and install a port without
       having to build its dependencies.  Instead, the dependencies are
       downloaded via pkg(8).

         # make install-missing-packages
         # make install

       It is especially useful, when the dependencies are costly in time and
       resources to build (like lang/rust).  The drawback is that pkg(8)
       offers only packages built with the default set of OPTIONS.
 
Back
Top