Call for testing: pkgbase support in 15.0

fmc000 · Tuesday at 9:30 AM

Well, as expected it was just a matter of time. Now https://pkg.freebsd.org/FreeBSD:15:amd64/ shows also kmods_latest_0 and of course it works.

Code:

The following 3 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        drm-66-kmod: 6.6.25.1500066_5 -> 6.6.25.1500067_5 [FreeBSD-ports-kmods]
        gpu-firmware-intel-kmod-tigerlake: 20230625.1500066 -> 20230625.1500067 [FreeBSD-ports-kmods]
        wifi-firmware-iwlwifi-kmod-ax210: 20241017.1500066_2 -> 20241017.1500067_2 [FreeBSD-ports-kmods]

Number of packages to be upgraded: 3

Yes, virtualbox-ose-kmod-72-7.2.2.1500067 is not yet there but it's just a matter of waiting for a few more days.

Erichans · Tuesday at 11:36 AM

Useradd said:
I can wait a bit. I'm doing this on my test machine which I use to test upgrades which might impact my main PC, which would be a disaster. I have even tried reinstalling 14.3-RELEASE on my test machine but that fails too now because of the Nvidia driver change.

As I understand it, you are waiting until the right version of the nvidia driver shows up in the pkg repository.
Have you considered using either the scfb or the vesa driver as mentioned in 5.2. Graphics Drivers as a temporary solution? You won't have accellerated graphics but this at least allows the use of a DE.

Useradd · Tuesday at 12:45 PM

Erichans said:
As I understand it, you are waiting until the right version of the nvidia driver shows up in the pkg repository.
Have you considered using either the scfb or the vesa driver as mentioned in 5.2. Graphics Drivers as a temporary solution? You won't have accellerated graphics but this at least allows the use of a DE.

Yes, xorg has been complaining about a slight mismatch between the version of the driver it supports and the one that is installed.

I tried disabling the FreeBSD-ports-kmods repository just now (as suggested earlier in this thread) and now I can get a graphical display. I don't fully understand the consequences of disabling the FreeBSD-ports-kmods repository so I have made an note of your suggestion about SCFB because I keep old GPU cards as long as they still work and this problem will likely occur again if old drivers are removed once they are no longer supported. I don't expect high performance from old cards anyway.

It's a long time since I read that section in the Handbook.

Starcat · Tuesday at 7:17 PM

I started with a BETA1 ISO (i.e. https://download.freebsd.org/releas...ES/15.0/FreeBSD-15.0-BETA1-amd64-bootonly.iso), but it didn't appear to in fact be BETA1:

Code:

# uname -a
FreeBSD skulltrail 15.0-STABLE FreeBSD 15.0-STABLE stable/15-n280665-6eb4708a84d7 GENERIC amd64
# uname -KrU
15.0-STABLE 1500500 1500500
# pkg -vv | sed -nE -e '/(OSVERSION|ABI)/ p' -e '/^Repositories:/,$ p'
IGNORE_OSVERSION = false;
ABI = "FreeBSD:15:amd64";
ALTABI = "freebsd:15:x86:64";
OSVERSION = "1500500";
Repositories:
  FreeBSD-ports: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/latest",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
  FreeBSD-ports-kmods: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/kmods_latest",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
  FreeBSD-base: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/base_latest",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
#

So I created a /usr/local/etc/pkg/repos/FreeBSD.conf file:

Code:

FreeBSD: { enabled: NO }

FreeBSD-base: {
  url: "pkg+https://pkg.freebsd.org/${ABI}/base_release_0",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

FreeBSD-ports-kmods: {
  url: "pkg+https://pkg.freebsd.org/${ABI}/kmods_latest_0",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

FreeBSD-ports: {
  url: "pkg+https://pkg.freebsd.org/${ABI}/latest",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkg",
  enabled: yes
}

After running pkg upgrade and restarting the system, I now appear to be running BETA1:

Code:

# uname -KrU
15.0-BETA1 1500067 1500067
#

Strange, eh? My guess is that the ISO wasn't tested...

Erichans · Tuesday at 7:43 PM

Starcat said:
I started with a BETA1 ISO (i.e. https://download.freebsd.org/releas...ES/15.0/FreeBSD-15.0-BETA1-amd64-bootonly.iso), but it didn't appear to in fact be BETA1:

Code:

[...]

So I created a /usr/local/etc/pkg/repos/FreeBSD.conf file:

Code:

FreeBSD: { enabled: NO } FreeBSD-base: { url: "pkg+https://pkg.freebsd.org/${ABI}/base_release_0", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes } FreeBSD-ports-kmods: { url: "pkg+https://pkg.freebsd.org/${ABI}/kmods_latest_0", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes } FreeBSD-ports: { url: "pkg+https://pkg.freebsd.org/${ABI}/latest", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/share/keys/pkg", enabled: yes }

After running pkg upgrade and restarting the system, I now appear to be running BETA1:

Code:

# uname -KrU 15.0-BETA1 1500067 1500067 #

Strange, eh? My guess is that the ISO wasn't tested...

That's how my settings looked like in the end, but I travelled the road from 14.2-RELEASE, using the normal upgrade; then changing the ports repostories back to latest and running pkgbasify

I think it would be a good idea to report this as mentioned in FreeBSD 15.0-BETA1 Now Available (I havent seen this being mentioned on either the MLs or as a PR).

Starcat · Tuesday at 8:27 PM

Erichans said:
That's how my settings looked like in the end, but I travelled the road from 14.2-RELEASE, using the normal upgrade; then changing the ports repostories back to latest and running pkgbasify

I think it would be a good idea to report this as mentioned in FreeBSD 15.0-BETA1 Now Available (I havent seen this being mentioned on either the MLs or as a PR).

I submitted a problem report.

PR 290238

Erichans · Tuesday at 8:31 PM

Starcat said:
I submitted a problem report.

PR 290238

Small remark on the version tagged: BETA1 is already on the releng/15 branch, definitely not -CURRENT anymore.

Starcat · Tuesday at 8:40 PM

Erichans said:
Small remark on the version tagged: BETA1 is already on the releng/15 branch, definitely not -CURRENT anymore.

Is that just plain CURRENT then?

Erichans · Tuesday at 8:46 PM

Starcat said:
Is that just plain CURRENT then?

As there isn't an official 15.0-RELEASE, that tag hasn't appeared yet. The selection most suitable would then be "15.0-STABLE"

Erichans · Tuesday at 11:39 PM

Starcat said:
OSVERSION = "1500500";

This is the version string belonging to ALPHA5. You may have downloaded and installed packages belonging to it; such installed packages will block updating via the normal way as their version number is higher that of any version number occuring for packages of the BETA packages. To resolve that, see the below example sequence for drm-66-kmod of this and what does and does not work; using -f is necessary to update these ALPHA5 packages to BETA1 packages:

Rich (BB code):

[1-0] #  pkg query -x '[%R] %n %v' '^drm-66-kmod' | column -t
[FreeBSD-ports-kmods]  drm-66-kmod  6.6.25.1500500_5    --> this package is from ALPHA5 of the stable/15 branch
[2-0] # pkg -vv | sed -nE -e '/^OSVERSION/ p' -e '/^Repositories:/,$ p'
OSVERSION = "1500067";   --> version string of 15.0-BETA1 of the releng/15 branch
Repositories:
  FreeBSD-ports: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/latest",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
  FreeBSD-ports-kmods: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/kmods_latest_0",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
  FreeBSD-base: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/base_release_0",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
[3-0] # pkg rquery -x '[%R] %n %v' '^drm-66-kmod' | column -t
[FreeBSD-ports]        drm-66-kmod  6.6.25.1500066_5
[FreeBSD-ports-kmods]  drm-66-kmod  6.6.25.1500067_5   --> this is what is desired: the highest numbered version of drm-66-kmod
[4-0] # pkg upgrade drm-66-kmod
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
Your packages are up to date.  --> the upgrade fails--as is to be expected--because: 6.6.25.1500500_5 > 6.6.25.1500067_5
[5-0] # pkg upgrade -f drm-66-kmod
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be DOWNGRADED:
        drm-66-kmod: 6.6.25.1500500_5 -> 6.6.25.1500067_5 [FreeBSD-ports-kmods]

Number of packages to be downgraded: 1

Proceed with this action? [y/N]: y
[1/1] Downgrading drm-66-kmod from 6.6.25.1500500_5 to 6.6.25.1500067_5...
[1/1] Extracting drm-66-kmod-6.6.25.1500067_5: 100%
[6-0] #  pkg query -x '[%R] %n %v' '^drm-66-kmod' | column -t
[FreeBSD-ports-kmods]  drm-66-kmod  6.6.25.1500067_5   --> shows the correct installed version from FreeBSD-ports-kmods

You can also force a reinstall of all installed packages derived from the ports tree by using:
pkg upgrade -f -r FreeBSD-ports
pkg upgrade -f -r FreeBSD-ports-kmods

T-Aoki · Wednesday at 12:30 AM

Erichans said:
definitely not -CURRENT anymore.

Correction: not-STABLE anymore.

Erichans said:
This is the version string belonging to ALPHA5.

Precisely, OSVERSION 1500500 means "the first stable branch tied to 15.0".
Once releng/15.1 is branched from stable/15 in the future, it would become 1501500 from 15005xy.

And "-STABLE", "-RELEASE", "-ALPHA5" is managed by newvers.sh.
Note that linked is for stable/15.

Starcat · Wednesday at 12:35 AM

Erichans said:

This is the version string belonging to ALPHA5. You may have downloaded and installed packages belonging to it; such installed packages will block updating via the normal way as their version number is higher that of any version number occuring for packages of the BETA packages. To resolve that, see the below example sequence for drm-66-kmod of this and what does and does not work; using -f is necessary to update these ALPHA5 packages to BETA1 packages:

Rich (BB code):

[1-0] #  pkg query -x '[%R] %n %v' '^drm-66-kmod' | column -t
[FreeBSD-ports-kmods]  drm-66-kmod  6.6.25.1500500_5    --> this package is from ALPHA5 of the stable/15 branch
[2-0] # pkg -vv | sed -nE -e '/^OSVERSION/ p' -e '/^Repositories:/,$ p'
OSVERSION = "1500067";   --> version string of 15.0-BETA1 of the releng/15 branch
Repositories:
  FreeBSD-ports: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/latest",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
  FreeBSD-ports-kmods: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/kmods_latest_0",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
  FreeBSD-base: {
    url             : "pkg+https://pkg.FreeBSD.org/FreeBSD:15:amd64/base_release_0",
    enabled         : yes,
    priority        : 0,
    mirror_type     : "SRV",
    signature_type  : "FINGERPRINTS",
    fingerprints    : "/usr/share/keys/pkg"
  }
[3-0] # pkg rquery -x '[%R] %n %v' '^drm-66-kmod' | column -t
[FreeBSD-ports]        drm-66-kmod  6.6.25.1500066_5
[FreeBSD-ports-kmods]  drm-66-kmod  6.6.25.1500067_5   --> this is what is desired: the highest numbered version of drm-66-kmod
[4-0] # pkg upgrade drm-66-kmod
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
Your packages are up to date.  --> the upgrade fails--as is to be expected--because: 6.6.25.1500500_5 > 6.6.25.1500067_5
[5-0] # pkg upgrade -f drm-66-kmod
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be DOWNGRADED:
        drm-66-kmod: 6.6.25.1500500_5 -> 6.6.25.1500067_5 [FreeBSD-ports-kmods]

Number of packages to be downgraded: 1

Proceed with this action? [y/N]: y
[1/1] Downgrading drm-66-kmod from 6.6.25.1500500_5 to 6.6.25.1500067_5...
[1/1] Extracting drm-66-kmod-6.6.25.1500067_5: 100%
[6-0] #  pkg query -x '[%R] %n %v' '^drm-66-kmod' | column -t
[FreeBSD-ports-kmods]  drm-66-kmod  6.6.25.1500067_5   --> shows the correct installed version from FreeBSD-ports-kmods

You can also force a reinstall of all installed packages derived from the ports tree by using:
pkg upgrade -f -r FreeBSD-ports
pkg upgrade -f -r FreeBSD-ports-kmods

Thank you for that great information, but it doesn't seem to apply in this case.

Code:

# pkg upgrade -f drm-66-kmod
Updating FreeBSD-ports repository catalogue...
FreeBSD-ports repository is up to date.
Updating FreeBSD-ports-kmods repository catalogue...
FreeBSD-ports-kmods repository is up to date.
Updating FreeBSD-base repository catalogue...
FreeBSD-base repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be REINSTALLED:
    drm-66-kmod-6.6.25.1500067_5 [FreeBSD-ports-kmods]

Number of packages to be reinstalled: 1

Proceed with this action? [y/N]: N
# pkg info drm-66-kmod
drm-66-kmod-6.6.25.1500067_5
Name           : drm-66-kmod
Version        : 6.6.25.1500067_5
Installed on   : Tue Oct 14 15:11:00 2025 CDT
Origin         : graphics/drm-66-kmod
Architecture   : FreeBSD:15:amd64
Prefix         : /usr/local
Categories     : graphics kld
Licenses       : BSD2CLAUSE, GPLv2, MIT
Maintainer     : x11@FreeBSD.org
WWW            : https://github.com/freebsd/drm-kmod/
Comment        : Direct Rendering Manager GPU drivers
Annotations    :
    FreeBSD_version: 1500067
    repo_type      : binary
    repository     : FreeBSD-ports-kmods
Flat size      : 18.0MiB
Description    :
amdgpu, i915, and radeon DRM drivers modules.
Currently corresponding to Linux 6.6 DRM.
This version is for FreeBSD 15 1500031
and above.
#

On a related note, drm-66-kmod-6.6.25.1500067_5 seems broken. It causes my system to panic. I have a Radeon HD 7790.

Erichans · Wednesday at 12:50 AM

Starcat said:
On a related note, drm-66-kmod-6.6.25.1500067_5 seems broken. It causes my system to panic. I have a Radeon HD 7790.

This seems a rather ordinary AMD graphics card, please feel free to open a new thread for that, but if you have a reproducable panic with all the correct config settings then a PR seems to be in order; this may be related to the driver, the kernel, or even limited to the Linux KPI layer. To complete such a PR try first if you can get your graphics working with drm-61-kmod, then you can mention that in a PR. If you experience problems with drm-61-kmod, please start a new thread.

fmc000 · Wednesday at 2:34 AM

You may also try drm-latest-kmod, which at the moment is based on Linux 6.9. Be aware that in my case (Intel) it didn't work well with Xorg (no problems with Wailand though).

rbranco · Wednesday at 6:43 AM

fmc000 said:
You may also try drm-latest-kmod, which at the moment is based on Linux 6.9. Be aware that in my case (Intel) it didn't work well with Xorg (no problems with Wailand though).

In my case it was the opposite with XOrg. Not using Wayland as I'm using MATE with FreeBSD.

rootbert · Wednesday at 2:34 PM

I really do not like that you can now destroy your system with pkg, they should have kept pkg and pkgbase in a separate database with a separate command. This is so linuxy, which I have tried to avoid for 10 years now. Also, on a pkgbasified system, you still have freebsd-update, so you have two ways to update which leaves your system in an uncertain state. Other than that, the idea of pkgbase is great, I just do not like the way they have implemented it.

Starcat · Wednesday at 2:41 PM

fmc000 said:
You may also try drm-latest-kmod, which at the moment is based on Linux 6.9. Be aware that in my case (Intel) it didn't work well with Xorg (no problems with Wailand though).

Thank you, that was a great suggestion. Sadly, I haven't even installed X11 or a DE.

amdgpu is still broken and causes the kernel to panic with a page fault upon boot.

drm-kmod worked fine under FreeBSD 14.x.

Erichans · Wednesday at 3:00 PM

rootbert said:
I really do not like that you can now destroy your system with pkg, they should have kept pkg and pkgbase in a separate database with a separate command. This is so linuxy, which I have tried to avoid for 10 years now. Also, on a pkgbasified system, you still have freebsd-update, so you have two ways to update which leaves your system in an uncertain state. Other than that, the idea of pkgbase is great, I just do not like the way they have implemented it.

The number of vital 'base' packages has increased (it once was 2). Using 15.0-BETA1, I have:

Code:

 # pkg query -e '%V=1' '%V [%R] %o %n %v'| column -t|nl
     1  1  [FreeBSD-base]  base/FreeBSD-clibs              FreeBSD-clibs              15.0.b1.20251012072228
     2  1  [FreeBSD-base]  base/FreeBSD-runtime            FreeBSD-runtime            15.0.b1.20251013072425
     3  1  [FreeBSD-base]  base/FreeBSD-set-base           FreeBSD-set-base           15.0.b1.20251012072228
     4  1  [FreeBSD-base]  base/FreeBSD-set-base-jail      FreeBSD-set-base-jail      15.0.b1.20251012072228
     5  1  [FreeBSD-base]  base/FreeBSD-set-devel          FreeBSD-set-devel          15.0.b1.20251012072228
     6  1  [FreeBSD-base]  base/FreeBSD-set-lib32          FreeBSD-set-lib32          15.0.b1.20251012072228
     7  1  [FreeBSD-base]  base/FreeBSD-set-minimal        FreeBSD-set-minimal        15.0.b1.20251012072228
     8  1  [FreeBSD-base]  base/FreeBSD-set-minimal-jail   FreeBSD-set-minimal-jail   15.0.b1.20251012072228
     9  1  [FreeBSD-base]  base/FreeBSD-set-optional       FreeBSD-set-optional       15.0.b1.20251012072228
    10  1  [FreeBSD-base]  base/FreeBSD-set-optional-jail  FreeBSD-set-optional-jail  15.0.b1.20251012072228
    11  1  [FreeBSD-base]  base/FreeBSD-set-src            FreeBSD-set-src            15.0.b1.20251012072228
    12  1  [FreeBSD-base]  base/FreeBSD-set-tests          FreeBSD-set-tests          15.0.b1.20251012072228

As these are marked vital, these are very hard to delete accidentally. (I have not done any experimenting what the result is of deleting all base packages except those marked vital.)

"Also, on a pkgbasified system, you still have freebsd-update, so you have two ways to update which leaves your system in an uncertain state."
It was announced, IIRC on the pkgbase ML, that freebsd-update—Edit: for the 15 branch—would be based on the underlying base packages environment and its accompanying procedures; I've not seen anything that that has changed. This means that it is different from freebsd-update(8) under previous branches before the 15 branch. Therefore, I really doubt this "duality" could leave an installed OS in a "uncertain state".

rootbert · Wednesday at 3:39 PM

well, I pkgbasified a 14.3 system, and had kernel 14.3-RELEASE-p4 running. After that, I ran freebsd-update install and it installed 14.3-RELEASE-p3. This should not happen

fmc000 · Wednesday at 3:50 PM

Mixing pkgbase and freebsd-update is not supported.

rootbert · Wednesday at 5:31 PM

I know, but the fact that both work and interfere baffles me. freebsd-update is kept to continue to be able to update jails - Lexi Winter in the mailing list told me

Erichans · Wednesday at 5:46 PM

rootbert said:
[...] so you have two ways to update [...]

I agree, that is somewhat annoying on the 14 branch, but there pkgbase is labelled experimental. Relevant for remaining use in a pkgbasified 14.x environment: message #39 of this thread.

Currently, after an upgrade from 14.2-R to 15.0-BETA1 and having run pkgbasify:

Code:

[1-0] # freebsd-update fetch
freebsd-update is incompatible with the use of packaged base.  Please see
https://wiki.freebsd.org/PkgBase for more information.
[2->1<] #

The ML thread I previously mentioned: freebsd-update and pkgbase; I don't know where development of that currently stands.
Edit: A more recent (Sat, 11 Oct 2025) message: Re: About the upcoming changes to pkgbase

victort · Thursday at 2:56 AM

rootbert said:
I know, but the fact that both work and interfere baffles me. freebsd-update is kept to continue to be able to update jails - Lexi Winter in the mailing list told me

Question on that. How will this work if we can’t download the src/base.txz archives anymore?

Erichans · Thursday at 8:47 AM

Erichans said:
Furthermore, it seems that at the moment no FreeBSD-ports-kmods repository is set up for releng/15, https://pkg.freebsd.org/FreeBSD:15:amd64/:

https://pkg.freebsd.org/FreeBSD:15:amd64/ now shows the addition of a quarterly 'kmods' repository, now we have:

kmods_latest_0 - populated
kmods_quarterly_0 as of 2025-Oct-15 - populated

Any install of 15.0-BETA1 has now access to all quarterly and latest repositories from the ports tree for the releng/15 branch.

fmc000 · Friday at 8:16 AM

fmc000 said:
In short, if you want to track 15.0-STABLE right now there are a few modules that are not ready yet (i.e. virtualbox-ose-kmod-72-7.2.2 and possibly others). If you want to track releng/15.0 you have to disable the FreeBSD-ports-kmods repository because it still doesn't exist. However, the FreeBSD-ports repository has all the previous ALPHA kmods and they work just fine with BETA1, or at least on my installation I have:

Code:

drm-66-kmod-6.6.25.1500066_5 Direct Rendering Manager GPU drivers gpu-firmware-intel-kmod-tigerlake-20230625.1500066 Firmware modules for tigerlake Intel GPUs virtualbox-ose-kmod-72-7.2.2.1500066 VirtualBox kernel module for FreeBSD wifi-firmware-iwlwifi-kmod-ax210-20241017.1500066_2 Firmware modules for the iwlwifi (ax210) WiFi NIC driver

and all of them work. I tried to track 15.0-STABLE but I went back to releng/15.0 when I noticed that I couldn't use my VMs (and, BTW, the situation is actually worse as even when I compiled the kmod from the ports it wouldn't load despite being at the correct OSVERSION).

Just as a heads-up: virtualbox-ose-kmod-72-7.2.2 is still not available in 15.0-STABLE but can be compiled from ports and it loads and works just fine. I suspect that when I tried it earlier I did not have set up my kernel sources correctly: now I'm tracking stable/15.0 and everything works as expected.