Solved freebsd 13.2 and virtualbox-ose

R

rmomota

Upgraded from 13.1 to 13.2 and noticed the vboxdrv is not getting loaded.

Found this in dmesg:
KLD vboxdrv.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/modules/vboxdrv.ko - unsupported file type

Reinstalled the package and it got this output:
The vboxdrv kernel module uses internal kernel APIs.

To avoid crashes due to kernel incompatibility, this module will only
load on FreeBSD 13.1 kernels.

So wasn't it supposed to get recompiled too and available in the upgrade?
 
rmomota said:
So wasn't it supposed to get recompiled too and available in the upgrade?
Click to expand...
No. This is an unfortunate edge-case (and kind of an FAQ, it affects other -kmod ports/packages as well).

The ABI is always kept stable across minor releases of the same major version. E.g. for FreeBSD 13.x on amd64, it's always FreeBSD:13:amd64, regardless of the minor version number.

Therefore, there's only one package repository for currently both FreeBSD 13.1 and FreeBSD 13.2.

The only place where this can be a problem is kernel modules. Internal kernel APIs can change even between minor releases. So, the packages offered can only match one of them. During the 3-month transition phase from one minor to the next, all packages will be built on/for the old release. This means if you upgrade to the new release before the old one is EOL, you'll have to build -kmod packages yourself from ports.

rmomota said:
out of subject why? isn't the virtualbox-ose a freebsd port?
Click to expand...
I think he referred to his own posting.
 
zirias@ said:
No. This is an unfortunate edge-case (and kind of an FAQ, it affects other -kmod ports/packages as well).

The ABI is always kept stable across minor releases of the same major version. E.g. for FreeBSD 13.x on amd64, it's always FreeBSD:13:amd64, regardless of the minor version number.

Therefore, there's only one package repository for currently both FreeBSD 13.1 and FreeBSD 13.2.

The only place where this can be a problem is kernel modules. Internal kernel APIs can change even between minor releases. So, the packages offered can only match one of them. During the 3-month transition phase from one minor to the next, all packages will be built on/for the old release. This means if you upgrade to the new release before the old one is EOL, you'll have to build -kmod packages yourself from ports.


I think he referred to his own posting.
Click to expand...
I thought that when a new version we could upgrade without breaking anything that is installed already because according to FreeBSD propaganda is that is as a very stable OS compared to Linux distros (that are not OS).
Maybe I just misunderstood this.
This means that to have my VirtualBox minikube environment to keep doing my work I will need to build ports myself?
I wasn't expecting this.
3 months? In 3 months we will have the 14 Release, right?
 
rmomota said:
I thought that when a new version we could upgrade without breaking anything that is installed already because according to FreeBSD propaganda is that is as a very stable OS compared to Linux distros (that are not OS).
Click to expand...
Is this an attempt to spread (negative) propaganda? :-/

As I just explained, this is an edge-case only (possibly) affecting kernel modules. Now have a look at the ports tree how many ports actually install kernel modules.

In your case, all you need to do is to build emulators/virtualbox-ose-kmod from the port for now. Or, alternatively, just wait with upgrading to 13.2 until 13.1 is EOL.

rmomota said:
3 months? In 3 months we will have the 14 Release, right?
Click to expand...
This has absolutely no relationship to the release cycle of 13.x.
 
rmomota said:
3 months?
Click to expand...
With every minor version upgrade there's a three month grace period. Only the last minor version of a major branch is supported. But we can't expect people to upgrade all their systems the very minute a new minor version is released. So there's a three month period in which the previous minor version (that's 13.1 in this case) is still supported. Therefor packages are still being built for 13.1 during this three month grace period. This is not a problem for 99.99% of the 31000+ ports. Known problematic ports are specifically ones that install kernel modules like the kernel module for Virtualbox. This is a known issue (it almost always happens with every new minor version upgrade) but it always seems to catch people by surprise.
 
And adding to that: Nobody seems to think it's worthwhile to come up with a solution for that edge case. Most likely because building the one, maybe two, "-kmod" ports you use manually for a short time doesn't pose any problem at all. Kernel modules also don't have tons of dependencies, so it's really an easy step.
 
It's only valid for the three months both minor versions are 'active'. There once was a note in the errata of 12.1-RELEASE:
[2019-11-04] A late issue was discovered where systems using the graphics/drm-kmod port built on FreeBSD 12.0-RELEASE will crash during boot. It is advised to remove the port prior to upgrading, and build the port instead of using the upstream binary package.
Click to expand...
But this gave the impression you always had to build it from ports, which is not the case. After the three month grace period packages will get build for the new minor version and this issue resolves itself.
 
I agree this should be documented somewhere prominent, the handbook could be a good place. At least desktop users are typically affected because they have drm-kmod installed. Although I doubt this would end questions about it 😉 but at least you could refer to the docs instead of giving the same somewhat lengthy explanation over and over again ....
 
zirias@ said:
And adding to that: Nobody seems to think it's worthwhile to come up with a solution for that edge case. Most likely because building the one, maybe two, "-kmod" ports you use manually for a short time doesn't pose any problem at all. Kernel modules also don't have tons of dependencies, so it's really an easy step.
Click to expand...

Well, building once is easy enough, but you set yourself up for failure when the pkg gets updated and you pull in the wrong kernel API's kmod via a binary update.
 
Nevertheless, it's really annoying. Each time, I wait until the precedent version is EOL (for bare metal desktop) to upgrade. And each time, people new to FreeBSD fall into this trap.

It could and should be fixed.
 
Emrion said:
Each time, I wait until the precedent version is EOL (for bare metal desktop) to upgrade.
Click to expand...
Why? Just building this one port from source is really painless....

Emrion said:
It could and should be fixed.
Click to expand...
I don't think so. Even the KBI (kernel binary interface) is meant to be stable, not sure whether that's sometimes broken or the problem is "just" that some modules need to use "internal" kernel interfaces, but in any case, it only affects extremely few packages.

drm-kmod is a prominent example because you'll typically need that on a desktop, but then, the more likely way to solve that is to eventually reintegrate it in base.

Adding all the infrastructure it would need to offer multiple versions of binary packages just for the very few that can have problems just isn't worth the huge effort for very little gain.

I'd say: It could and should be documented.
 
One place it could be put is in UPDATING, or at least /usr/ports/UPDATING. I very much agree with zirias@ and getopt that it should be documented where those who upgrade will see it. Errata is another possible place. Fortunately, those who make such decisions are smarter and more knowledgeable than I am, but it is disconcerting to upgrade, start VirtualBox and find that it's stopped working. I use bhyve for most VMs so I'm not badly affected, but I wish I had known this. Though I would have upgraded anyway, which otherwise, including NVidia drivers, was painless.

I used SirDice's method from an old post which is to run freebsd-install, then run it again before rebooting, then still before reboot, pkg upgrade -f, then shutdown -r now.
I've left out some steps that don't apply to me, the original post is at
forums.freebsd.org

FreeBSD 13 annoyances?

Anybody got any Freebsd 13 annoyances, yet? BTW, so far, I'm loving 13, so this isn't a knock on the release - it's beautiful. However, things are different and different is... well, different... and often annoying, so I have an example: One of the first things I noticed with my shiny new...
forums.freebsd.org forums.freebsd.org
 
scottro said:
I used @SirDice's method from an old post which is to run freebsd-install, then run it again before rebooting, then still before reboot, pkg upgrade -f, then shutdown -r now.
Click to expand...
Good method for doing a major version upgrade. It's not going to do much for this particular problem from a minor version upgrade. The pkg upgrade -f will just force reinstall every package, but those packages are for 13.1 right now. Thus you're simply reinstalling a "bad" package. It would work three months from now, when 13.1 is actually EoL and packages will be build for 13.2 specifically.
 
Emrion said:
That being said, IMO one should be able to use any OS without compiling anything.
Click to expand...
Which of course is still the case here. Remember, we're talking about a very rare (although well-known) edge case. And even then, compiling this port "just works" fully automated and doesn't require to install anything upfront AND you of course have the option to postpone your upgrade if you still don't want to compile....

I would even go as far as this: If it wasn't for drm-kmod being removed from base (IIRC in 11? IIRC for licensing reasons?), not even desktop users would typically ever notice the problem at all. Let's see when drm-kmod can be back in base...
 
zirias@ said:
I would even go as far as this: If it wasn't for drm-kmod being removed from base (IIRC in 11? IIRC for licensing reasons?), not even desktop users would typically ever notice the problem at all. Let's see when drm-kmod can be back in base...
Click to expand...
I didn't know this. My first install was a 11.x-RELEASE but into a VM. Well, it remains other graphics drivers (nvidia) and miscellaneous kernel modules. A definitive solution would be a repo for each release version. Maybe, it's too costly...
 
Emrion said:
Maybe, it's too costly...
Click to expand...
I'm pretty sure it is. And I don't mean just hosting a few more binary repositories for the time of the transition phase.

It would need a new design how both identifying the correct repository and checking packages whether they match your system work. Currently, they both just rely on the ABI (which doesn't change between minor versions). Now, you could of course say, let's put the minor version into the ABI as well, but that would throw out the baby with the bathwater: The whole point of the stable/x branches is to keep the ABI stable, and this is what enables simple and painless upgrades from one minor release to the next.

So, what would really be needed is for example an additional "kernel-version" info only for packages containing kernel modules. They'd need special treatment by pkg during compatibility checking and also for knowing from where to download. Of course, this would have effects all down to the ports framework used to build these packages. And all this for a handful of packages....

Emrion said:
Well, it remains other graphics drivers (nvidia) and miscellaneous kernel modules.
Click to expand...
Only few are affected at all in practice, unfortunately I can't even tell which ones.

I think the only way forward here is to think about a way how to document that pitfall adequately.
 
Emrion said:
A definitive solution would be a repo for each release version. Maybe, it's too costly...
Click to expand...
Have a look at how many builds there are. There's generally two ports trees (quarterly and latest) for each version (12.4, 13.1) and each architecture (amd64, i386, arm64, etc). This multiplies to a large number quite quickly. There's only a finite amount of resources they have available.

 
Yes, I suspected that. However, there is probably a good solution like zirias began to elaborate.

As for the documentation thing, not all people read it and especially beginners. So, anyway this question will be posted again and again, I fear.
 
You must log in or register to reply here.
Back
Top