Call for testing: pkgbase support in 15.0

T-Aoki · Friday at 9:51 AM

For nvidia things in FreeBSD[-ports]-kmods repo, luckily I could have some discussion with bapt@ on Matrix, and opened a review D 53136 as per his request.
Once it is accepted and lands, remaining issue would be another one he is investigating. Please be patient for a while.

Erichans · Friday at 12:35 PM

fmc000 said:
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.

Hmm, using the appropriate stable/15 config settings, I get:

Rich (BB code):

[0-0] # date -u; pkg -v
Fri Oct 17 11:15:26 UTC 2025
2.3.1
[1-0] # pkg -vv | sed -nE -e '/(OSVERSION|ABI|DEBUG_LEVEL)/ p' -e '/^Repositories:/,$ p'
DEBUG_LEVEL = 0;
IGNORE_OSVERSION = true;
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"
  }
[2-0] # pkg rquery -e '%n !~ virtualbox-ose-nox11*' -x '[%R] %o %n %v' '^virtualbox.*' | column -t | nl
     1  [FreeBSD-ports]  emulators/virtualbox-ose                         virtualbox-ose                         6.1.50_16
     2  [FreeBSD-ports]  emulators/virtualbox-ose-70                      virtualbox-ose-70                      7.0.26_5
     3  [FreeBSD-ports]  emulators/virtualbox-ose-71                      virtualbox-ose-71                      7.1.12_1
     4  [FreeBSD-ports]  emulators/virtualbox-ose-72                      virtualbox-ose-72                      7.2.2_1
     5  [FreeBSD-ports]  emulators/virtualbox-ose-additions               virtualbox-ose-additions               6.1.50.1500067_2
     6  [FreeBSD-ports]  emulators/virtualbox-ose-additions-legacy        virtualbox-ose-additions-legacy        5.2.44.1500067_8
     7  [FreeBSD-ports]  emulators/virtualbox-ose-additions-nox11         virtualbox-ose-additions-nox11         6.1.50.1500067_1
     8  [FreeBSD-ports]  emulators/virtualbox-ose-additions-nox11-legacy  virtualbox-ose-additions-nox11-legacy  5.2.44.1500067_7
     9  [FreeBSD-ports]  emulators/virtualbox-ose-kmod                    virtualbox-ose-kmod                    6.1.50.1500067_1
    10  [FreeBSD-ports]  emulators/virtualbox-ose-kmod-70                 virtualbox-ose-kmod-70                 7.0.26.1500067
    11  [FreeBSD-ports]  emulators/virtualbox-ose-kmod-71                 virtualbox-ose-kmod-71                 7.1.12.1500067
    12  [FreeBSD-ports]  emulators/virtualbox-ose-kmod-72                 virtualbox-ose-kmod-72                 7.2.2.1500067
    13  [FreeBSD-ports]  emulators/virtualbox-ose-kmod-legacy             virtualbox-ose-kmod-legacy             5.2.44.1500067_7
    14  [FreeBSD-ports]  emulators/virtualbox-ose-legacy                  virtualbox-ose-legacy                  5.2.44_33
[3-0] #

So, there is a virtualbox-ose-kmod-72 version 7.2.2 present, but:

it is in FreeBSD-ports
it is version tagged with 1500067

It looks like this particualr version is build against BETA1 (OSVERSION = "1500067"), I think that shouldn't have happened.
Tracking stable/15 means you're on 1500500 and up; a virtualbox-ose-kmod-72 should be version tagged with 1500066 (old version from ALPHA4) or 1500500 (from ALPHA5).

monwarez · Friday at 12:51 PM

Erichans said:
So, there is a virtualbox-ose-kmod-72 version 7.2.2 present, but:

it is in FreeBSD-ports

it is version tagged with 1500067

It looks like this particualr version is build against BETA1 (OSVERSION = "1500067"), I think that shouldn't have happened.
Tracking stable/15 means you're on 1500500 and up; a virtualbox-ose-kmod-72 should be version tagged with 1500066 (old version from ALPHA4) or 1500500 (from ALPHA5).

We don't have separate build for minor release on the same major releng version, this applies to stable too.
So for amd64 there is only 13.x, 14.y, 15.z and 16.w build, where x,y,z,w are the latest supported minor version respective to the major version.
Maybe there would be a FreeBSD-kmods repository that is separate from 15.0-RELEASE and 15.0-STABLE.

T-Aoki · Friday at 1:24 PM

Erichans said:
It looks like this particualr version is build against BETA1 (OSVERSION = "1500067"), I think that shouldn't have happened.

My understanding is it's correct.

As BETA1 is built using releng/15.0 branch, which 15.0-Release is going to be built after several planned BETA and RC.

On the other hand, stable/15 should now be considered as "branch for preparaion of next 15.1" after releng/15.0 is branched from it, thus, having OSVERSION 1500500.

And main repo for ports (FreeBSD-ports for 15.0 and FreeBSD for 14 and before) use oldest supported minor version of each major version.

fmc000 · Friday at 1:45 PM

Erichans said:

Hmm, using the appropriate stable/15 config settings, I get:

Rich (BB code):

[0-0] # date -u; pkg -v
Fri Oct 17 11:15:26 UTC 2025
2.3.1
[1-0] # pkg -vv | sed -nE -e '/(OSVERSION|ABI|DEBUG_LEVEL)/ p' -e '/^Repositories:/,$ p'
DEBUG_LEVEL = 0;
IGNORE_OSVERSION = true;
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"
  }
[2-0] # pkg rquery -e '%n !~ virtualbox-ose-nox11*' -x '[%R] %o %n %v' '^virtualbox.*' | column -t | nl
     1  [FreeBSD-ports]  emulators/virtualbox-ose                         virtualbox-ose                         6.1.50_16
     2  [FreeBSD-ports]  emulators/virtualbox-ose-70                      virtualbox-ose-70                      7.0.26_5
     3  [FreeBSD-ports]  emulators/virtualbox-ose-71                      virtualbox-ose-71                      7.1.12_1
     4  [FreeBSD-ports]  emulators/virtualbox-ose-72                      virtualbox-ose-72                      7.2.2_1
     5  [FreeBSD-ports]  emulators/virtualbox-ose-additions               virtualbox-ose-additions               6.1.50.1500067_2
     6  [FreeBSD-ports]  emulators/virtualbox-ose-additions-legacy        virtualbox-ose-additions-legacy        5.2.44.1500067_8
     7  [FreeBSD-ports]  emulators/virtualbox-ose-additions-nox11         virtualbox-ose-additions-nox11         6.1.50.1500067_1
     8  [FreeBSD-ports]  emulators/virtualbox-ose-additions-nox11-legacy  virtualbox-ose-additions-nox11-legacy  5.2.44.1500067_7
     9  [FreeBSD-ports]  emulators/virtualbox-ose-kmod                    virtualbox-ose-kmod                    6.1.50.1500067_1
    10  [FreeBSD-ports]  emulators/virtualbox-ose-kmod-70                 virtualbox-ose-kmod-70                 7.0.26.1500067
    11  [FreeBSD-ports]  emulators/virtualbox-ose-kmod-71                 virtualbox-ose-kmod-71                 7.1.12.1500067
    12  [FreeBSD-ports]  emulators/virtualbox-ose-kmod-72                 virtualbox-ose-kmod-72                 7.2.2.1500067
    13  [FreeBSD-ports]  emulators/virtualbox-ose-kmod-legacy             virtualbox-ose-kmod-legacy             5.2.44.1500067_7
    14  [FreeBSD-ports]  emulators/virtualbox-ose-legacy                  virtualbox-ose-legacy                  5.2.44_33
[3-0] #

So, there is a virtualbox-ose-kmod-72 version 7.2.2 present, but:

it is in FreeBSD-ports
it is version tagged with 1500067

It looks like this particualr version is build against BETA1 (OSVERSION = "1500067"), I think that shouldn't have happened.
Tracking stable/15 means you're on 1500500 and up; a virtualbox-ose-kmod-72 should be version tagged with 1500066 (old version from ALPHA4) or 1500500 (from ALPHA5).

That's exactly my point. I was expecting to find 1500500 in the repos (it is not there) and building from ports, with the appropriate kernel sources, I now have a functioning kernel module.

fmc000 · Friday at 1:49 PM

T-Aoki said:
My understanding is it's correct.

As BETA1 is built using releng/15.0 branch, which 15.0-Release is going to be built after several planned BETA and RC.

On the other hand, stable/15 should now be considered as "branch for preparaion of next 15.1" after releng/15.0 is branched from it, thus, having OSVERSION 1500500.

And main repo for ports (FreeBSD-ports for 15.0 and FreeBSD for 14 and before) use oldest supported minor version of each major version.

In case I wasn't clear, I tried tracking stable/15 to chase a nvme-related bug that crashes the system after the second suspend/resume cycle. The virtualbox module is the only one that I use which doesn't have a version 1500500 in the repos, whilst iwlwifi and drm do.

T-Aoki · Friday at 1:58 PM

fmc000 said:
In case I wasn't clear, I tried tracking stable/15 to chase a nvme-related bug that crashes the system after the second suspend/resume cycle. The virtualbox module is the only one that I use which doesn't have a version 1500500 in the repos, whilst iwlwifi and drm do.

I think fixes for such kind of fatal bug should be MFS'ed to releng/15.0.

And not 100% sure, but FreeBSD[-ports]-kmods repo is basically for minor versionup releases of oldest supported minor release, not for stable nor main.

If you prefer tracking stable/15, you can use FreeBSD-ports repo, but kernel module (kmod) ports should be better built and installed locally.

This is because, in many cases of non-Release base, pkg builders (both for regular FreeBSD[-ports] and FreeBSD[-ports]-kmods) would NOT be at the same commit as yours. (Even __FreeBSD_version, used for OSVERSION could differ).

fmc000 · Friday at 3:09 PM

T-Aoki said:
And not 100% sure, but FreeBSD[-ports]-kmods repo is basically for minor versionup releases of oldest supported minor release, not for stable nor main.

I'm afraid you're wrong:

Code:

[16:07][fmc000@tu45b-freebsd ~]$ pkg search -r FreeBSD-ports-kmods kmod|grep 1500500|wc -l
     193
[16:07][fmc000@tu45b-freebsd ~]$ pkg search -r FreeBSD-ports kmod|grep 1500500|wc -l
       0
[16:07][fmc000@tu45b-freebsd ~]$

As you can see 15.0-STABLE kmods are only available in FreeBSD-ports-kmods.

fmc000 · Saturday at 8:49 AM

FWIW, I'm leaving this thread as I'm back to 14.3-STABLE because of PR 290265.

T-Aoki · Saturday at 9:53 AM

fmc000 said:
I'm afraid you're wrong:

Yes, it's my mistake. In reverse. For "non-oldest minor versions" is correct.

Erichans · Saturday at 1:31 PM

fmc000 said:
FWIW, I'm leaving this thread as I'm back to 14.3-STABLE because of PR 290265.

We now have two branches 15.0-BETA1 (~ releng/15), with BETAx and RC-y in the future, and 15.x-STABLE; these are diverging.

In general: perhaps consider for 15-STABLE opening a separate thread when and if appropriate?

T-Aoki · Saturday at 1:37 PM

Erichans said:
We now have two branches 15.0-BETA1 (~ releng/15), with BETAx and RC-y in the future, and 15.x-STABLE; these are diverging.

In general: perhaps consider for 15-STABLE opening a separate thread when and if appropriate?

Maybe.
Now (and every *.0-Release cycles) is the worst timing that make users confusing.

Erichans · Saturday at 3:48 PM

cracauer@ said:
So does pkgbase have a separate database from ports pkg?

Erichans said:
From what I've read, no. [...]

All in the db /var/db/pkg/local.sqlite in the packages table. On my package based 15.0-BETA1:

Rich (BB code):

[1-0] % pkg query -x -e '%o ~ base/*' '[%R] %o %n %v' '.*'| wc -l    --> all base packages
     490
[2-0] % pkg query -x -e '%o !~ base/*' '[%R] %o %n %v' '.*'| wc -l   --> all non-base packages
    1077
[3-0] % sqlite3 /var/db/pkg/local.sqlite "SELECT origin,name FROM packages;"| sed -n '/^base/ p' | wc -l   --> all base packages
     490
[4-0] % sqlite3 /var/db/pkg/local.sqlite "SELECT origin,name FROM packages;"| sed -n '/^base/! p' | wc -l  --> all non-base packages
    1077

ralphbsz · Saturday at 4:14 PM

Erichans said:
All in the db /var/db/pkg/local.sqlite in the packages table.

Is /var the correct place for the package database? Maybe not.

Here's my thinking. On one hand, if the package database is lost, the system can not be upgraded, meaning it becomes unmaintained, meaning it will need to be reinstalled soon. One could de-facto call it a temporary install.

On the other hand, /var is not required to be persistent. If all of /var is wiped out and empty directories created, the system will function again after the next reboot, except with some print jobs and mail messages lost.

Jose · Saturday at 5:14 PM

ralphbsz said:
Here's my thinking. On one hand, if the package database is lost, the system can not be upgraded, meaning it becomes unmaintained, meaning it will need to be reinstalled soon. One could de-facto call it a temporary install.

Good catch. According to hier(7).

/var/ log, temporary, transient, and spool files

fmc000 · Saturday at 6:39 PM

Erichans said:
We now have two branches 15.0-BETA1 (~ releng/15), with BETAx and RC-y in the future, and 15.x-STABLE; these are diverging.

In general: perhaps consider for 15-STABLE opening a separate thread when and if appropriate?

Maybe I wasn't clear but I'm leaving 15.0 for good, both branches have this bug that's just too critical for me.

cracauer@ · Saturday at 6:42 PM

/var is never wiped. I have never seen a Unix like do that.

/var/run is.

All the SQL databases are in /var/db for crying out loud. The only way that makes /var special is that the amount of space needed can var considerably, and it needs to be writeable during multi luser mode.

T-Aoki · Saturday at 7:45 PM

cracauer@ said:
/var is never wiped. I have never seen a Unix like do that.

varmfs. Splitted out from diskless at commit 3e091039ee9b.
If I recall correctly, I've very surprized when var became volatile on upgrade, and found the new option, then, explicitly disabling it with setting "NO" fixed it.

cracauer@ · Saturday at 8:13 PM

T-Aoki said:
varmfs. Splitted out from diskless at commit 3e091039ee9b.
If I recall correctly, I've very surprized when var became volatile on upgrade, and found the new option, then, explicitly disabling it with setting "NO" fixed it.

Why isn't my /var cleared?

T-Aoki · Saturday at 8:28 PM

cracauer@ said:
Why isn't my /var cleared?

Not sure. I've failed to track changes via commit logs, but would be fixed at some point.
What make tracking hard is that related files are first existed under /usr/src/etc/, then /usr/src/sbin/init/, and now under /usr/src/libexec/rc/.

My prediction is that the behavior of varmfs=AUTO is modified. When I've bitten, it would be defaulted to YES.

ralphbsz · 2025-10-19T04:37:15+0100

cracauer@ said:
/var is never wiped. I have never seen a Unix like do that.
...
All the SQL databases are in /var/db for crying out loud.

All I was saying was: /var was traditionally not required to be persistent. Other than the spool directories, losing all content from /var could be cured by a reboot. That doesn't mean that wiping it is a good idea: in the old days, when mail delivery was slow and unreliable, and printing was commonly used and also slow, losing /var would be quite inconvenient to users.

But much has changed. I didn't check how many databases are stored in /var these days; losing all of them would be much worse than the inability to upgrade the system. So I think we can now assume that /var is actually persistent, and a vital part of the system.

bakul · 2025-10-19T05:07:16+0100

IIRC right from the start /var was host specific but a lot of it persistent (account, crash, cron, log, mail, preserve, spool, ...). /etc is also host specific but it changes far less, once set up. Actually very little in /etc is host specific and prob. should be factored out. Then the standard system can be mounted readonly or remote. But I guess at this stage people would be resistant to such changes.

ralphbsz · 2025-10-19T16:55:57+0100

bakul said:
IIRC right from the start /var was host specific but a lot of it persistent (account, crash, cron, log, mail, preserve, spool, ...). /etc is also host specific but it changes far less, once set up. Actually very little in /etc is host specific and prob. should be factored out. Then the standard system can be mounted readonly or remote. But I guess at this stage people would be resistant to such changes.

When diskless workstations were a big thing, there was a lot of work on splitting host-specific stuff from generic stuff, because they needed separate NFS mounts. I don't know the history of the file system hierarchy well enough to know when things moved, and when /var started being used.