Page MenuHomeFreeBSD

release: Ship firmware from kmods repo on DVD
ClosedPublic

Authored by cperciva on Sep 16 2025, 6:50 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Feb 1, 4:02 PM
Unknown Object (File)
Sat, Jan 31, 4:00 PM
Unknown Object (File)
Wed, Jan 28, 7:33 AM
Unknown Object (File)
Wed, Jan 28, 7:25 AM
Unknown Object (File)
Dec 10 2025, 9:38 AM
Unknown Object (File)
Nov 8 2025, 11:09 PM
Unknown Object (File)
Oct 25 2025, 1:04 PM
Unknown Object (File)
Oct 21 2025, 1:37 AM
Subscribers

Details

Summary

The packages for X.Y-RELEASE are a snapshot of the quarterly branch
for stable/X, i.e. typically built on X.(Y-1)-RELEASE. (The case of
Y=0 is an exception for obvious reasons.) This works for most ports
but not for kernel modules, which may need to be built on the release
in question; this is why we have a separate "kmods" repository.

Make sure that we put the packages from the kmods repository onto the
mini-pkg-repo on the DVD rather than shipping unusable firmware.

(Note that this is not necessary for FreeBSD 15.0, but may be
necessary for 14.4.)

MFC after: 1 month
Sponsored by: https://www.patreon.com/cperciva

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

cperciva added a subscriber: bapt.

@bz @bapt I think you're more familiar with the whole "release-specific kmod builds" thing than anyone else -- can you take a look at this? I don't want to ship the 14.4-RELEASE dvd with wifi kmods from 14.3.

I do not understand our package repositories and what goes into the releases anymore.
There's two branches in ports: main and quarterly; quarterly is almost certainly always outdated but I do not know how the "kmod" ports are dealt with in terms for that.
Is there one-repo-fits both main and quarterly or are they separate and we are building the full matrix?

Apart from file changes for wifi firmware it doesn't matter anymore as none of that is .ko; it's all plain firmware files, so they would at least still load though one occasionally missing the latest revisions.
14.4 has not seen wireless driver updates (yet) and given I didn't get any feedback on my LinuxKPI etc MFCs despite asking for it I have no intentions to change the status-quo for 14 anymore before 14.4 unless there's a missing bug fix.

In D52581#1255798, @bz wrote:

I do not understand our package repositories and what goes into the releases anymore.
There's two branches in ports: main and quarterly; quarterly is almost certainly always outdated but I do not know how the "kmod" ports are dealt with in terms for that.
Is there one-repo-fits both main and quarterly or are they separate and we are building the full matrix?

If this commit reaches releng/14.4, at that point it would point to release_4 and kmods_release_4, which would be copies of quarterly and kmods_quarterly_4 made at the appropriate time. So we're talking about packages built from the quarterly (in this case 2026Q1) branch of the ports tree; the difference between the "kmod" repo and the non-kmod repo is that the kmod repo only has kmod packages and is built with a newer src tree.

Apart from file changes for wifi firmware it doesn't matter anymore as none of that is .ko; it's all plain firmware files, so they would at least still load though one occasionally missing the latest revisions.
14.4 has not seen wireless driver updates (yet) and given I didn't get any feedback on my LinuxKPI etc MFCs despite asking for it I have no intentions to change the status-quo for 14 anymore before 14.4 unless there's a missing bug fix.

Ok, maybe it doesn't matter for 14.4. Is it possible that in the future we'll need wifi packages built on the most recent minor release? Or if, as you say, it's all plain firmware would wifi firmware packages built on say 15.0 work just fine on 15.1?

We definitely need built-on-the-right-minor-release packages for *graphics* but I don't think we're currently shipping any of those packages on the DVD so maybe this change won't be relevant until/unless that changes.

In D52581#1255798, @bz wrote:

I do not understand our package repositories and what goes into the releases anymore.
There's two branches in ports: main and quarterly; quarterly is almost certainly always outdated but I do not know how the "kmod" ports are dealt with in terms for that.
Is there one-repo-fits both main and quarterly or are they separate and we are building the full matrix?

If this commit reaches releng/14.4, at that point it would point to release_4 and kmods_release_4, which would be copies of quarterly and kmods_quarterly_4 made at the appropriate time. So we're talking about packages built from the quarterly (in this case 2026Q1) branch of the ports tree; the difference between the "kmod" repo and the non-kmod repo is that the kmod repo only has kmod packages and is built with a newer src tree.

Too many repos for me. But so be it. So if your change is taking packages for the DVD for firmware ("kmod") from kmods_release_4 resp. kmods_quarterly_4 then that sounds good to me.
From most of the shell bits I get that looks good as well. I assume the release-dvd.conf will need to change repos then in the release branch but that's a re@ task?

Apart from file changes for wifi firmware it doesn't matter anymore as none of that is .ko; it's all plain firmware files, so they would at least still load though one occasionally missing the latest revisions.
14.4 has not seen wireless driver updates (yet) and given I didn't get any feedback on my LinuxKPI etc MFCs despite asking for it I have no intentions to change the status-quo for 14 anymore before 14.4 unless there's a missing bug fix.

Ok, maybe it doesn't matter for 14.4. Is it possible that in the future we'll need wifi packages built on the most recent minor release? Or if, as you say, it's all plain firmware would wifi firmware packages built on say 15.0 work just fine on 15.1?

Modulo firmware version changes. So it's good to have the right ones. In theory that package no longer is a "kmod" but cleaning that up I will wait until 13.5 is EoL.

We definitely need built-on-the-right-minor-release packages for *graphics* but I don't think we're currently shipping any of those packages on the DVD so maybe this change won't be relevant until/unless that changes.

I have firm plans to make the gpu-firmware pain go away once 13.5 is EoL if no one else will beat me to it. As then they can be shipped as plain firmware files as well and all the .ko version matching will vanish over night.

This revision is now accepted and ready to land.Wed, Jan 28, 10:14 PM

this is very simple how the kmods are built:
kmods are built for every arches, every release (and stable)
FreeBSD:X:arch/kmods_quarterly are the kmods from the quarterly ports branch for the X branch (X being stable or main) of the source tree (using the weekly pkgbase repo which are always published in a predictable manner)
FreeBSD:X:arch/kmods_latest are the kmods from the main ports branch for the X branch (X being stable or main) of the source tree (using the weekly pkgbase repo)
FreeBSD:X:arch/kmods_quarterly_Y are the kmods from the quarterly ports branch for the X.Y releng branch of the source tree (using the releng pkgbase repo)
FreeBSD:X:arch/kmods_latest_Y are the kmods from the main ports branch for the X.Y releng branch of the source tree (using the releng pkgbase repo)

In D52581#1256002, @bz wrote:

I assume the release-dvd.conf will need to change repos then in the release branch but that's a re@ task?

Yes, the release-dvd.conf file is a bit weird in that it is different between main, stable, and releng branches, but we only ever use it on releng branches (since we don't build DVDs for the weekly snapshots). Theoretically someone *could* build DVD images earlier though, so it's worth making the adjustments during MFCs.

We definitely need built-on-the-right-minor-release packages for *graphics* but I don't think we're currently shipping any of those packages on the DVD so maybe this change won't be relevant until/unless that changes.

I have firm plans to make the gpu-firmware pain go away once 13.5 is EoL if no one else will beat me to it. As then they can be shipped as plain firmware files as well and all the .ko version matching will vanish over night.

Ok, but that's just firmware right? There's still actual graphics driver code which is shipped as kmods in the ports tree, separate from the firmware packages?

I have firm plans to make the gpu-firmware pain go away once 13.5 is EoL if no one else will beat me to it. As then they can be shipped as plain firmware files as well and all the .ko version matching will vanish over night.

Ok, but that's just firmware right? There's still actual graphics driver code which is shipped as kmods in the ports tree, separate from the firmware packages?

Yes.