NextBSD: executing the releng/15.1 bump & drm-kmod 6.12

The per-repo runbook for issues #336 (base 15.0→15.1) and #337 (graphics kexts 6.6→6.12 + firmware) — from a six-agent scope of the whole build chain, June 2026.

1. The four headline findings (verified during scoping)

2. The build chain & dispatch topology

Six repos, wired by repository_dispatch. The bump must propagate in dependency order; each arrow is an automatic cross-repo dispatch (on a real upstream change, not PRs). Your manual checkpoint sits right after the sync.

freebsd-src (fork)        sync-fork.yml  ──upstream-updated──▶  toolchain
   releng/15.1                                                     │
        ▲                                                          ├──toolchain-updated──▶  nextbsd-kernel
   [YOU VERIFY HERE]                                               └──toolchain-updated──▶  nextbsd-freebsd-compat
                                                                          │                        │
   nextbsd-kernel ──kernel-updated──▶ nextbsd-kernel-modules             │                        │
        │  publishes kernel-obj + nextbsd-kernel to  ◀── continuous ──┐  │                        │
        ▼                                                             │  ▼                        ▼
   (continuous: kernel-obj-*.tar.gz, nextbsd-kernel-*.tar.gz)         (continuous: graphics-kexts.tar.gz)   (continuous: nextbsd-base-*.tar.gz)
        └──────────────────────────────┬───────────────────────────────────────────┬───────────────────────┘
                                        ▼  base-updated / latest-continuous pull
                                   nextbsd (ISO assembler)  ── boot-test ──▶  image

Note the toolchain fans out to both nextbsd-kernel and nextbsd-freebsd-compat in parallel. The ISO repo pulls all three upstream artifacts (kernel, modules, compat) from their rolling continuous tags — no pins — so 15.1 artifacts flow in automatically once published.

3. Per-repo scope

Pills mark which ticket each edit serves: #336 base bump, #337 drm 6.12. “Decoy” = a FREEBSD_BRANCH env that looks like the pin but is never dereferenced (the real source version arrives baked in the toolchain image).

3.1  nextbsd-redux/freebsd-src — the sync fork #336

Pure upstream mirror, no NextBSD-local commits on the releng branches (confirmed: fork releng/15.0 is byte-identical to upstream; this upholds the “never touch freebsd-src” rule). releng/15.1 already exists in the fork but is stale — sitting at 15.1-RC2, ~18 commits behind upstream releng/15.1 HEAD (96841ea0, 2026-06-12). The sync is fast-forward-only (GitHub merge-upstream API), so it cannot lose work or force-push.

A global releng/15.0→releng/15.1 replace in this one file is correct (0 other refs anywhere in the repo). Decision for you: replace 15.0 entirely (clean bump, the issue’s intent) vs. sync both branches through a transition window.

3.2  nextbsd-redux/nextbsd-kernel-toolchain — the container #336

Clones the fork at ${FREEBSD_BRANCH} into /usr/src and bakes a kernel-toolchain stage; the GHCR image is the source artifact downstream builds inside. This is the first repo to actually change after the fork. Clang/LLVM stays 19 for 15.1 (both cut from stable/15) — do not bump it. __FreeBSD_version is not baked here; it rides in the cloned tree.

3.3  nextbsd-redux/nextbsd-kernel — patches + config + overlay #336 #337

The small patch repo (not a source fork). Corrected headline (§1.1, §7.5): 5 of 7 patches are clean on 15.1; 0001 and 0004 needed a mechanical rebase. The FREEBSD_BRANCH env here is a decoy (never read — the branch lives in the toolchain Dockerfiles).

Edits: build.yml:15 FREEBSD_BRANCH→15.1 (decoy, cosmetic) and build.yml:323 vmactions release: '15.0'→'15.1' (real — the smoke-test VM that md-mounts/injects the kernel; keep aligned for KBI hygiene). The build also appends mach_knote_enqueue to stock kern_event.c at build.yml:135 — depends on knote_enqueue staying static-callable (kqueue unchanged on 15.1, low risk). Verify config(8) accepts every config/NEXTBSD device name (em, ig4, ietp, iichid, the h* HID leaves) against 15.1’s GENERIC on the first build.

If 6.12 had needed a new baked dep (it does not — §1.2): config-level deps go next to the graphics block at config/NEXTBSD:41-42; an option-less helper module mirrors files.linuxkpi_video (new src-overlay/conf/files.<mod> + a cat >> conf/files wire-in step). Kept here for the record.

3.4  nextbsd-redux/nextbsd-kernel-modules — where both tickets land #336 #337

The repo that builds the graphics kexts. The DRM version lives in exactly one literal; the 15.1-ness arrives via the ingested kernel-obj, not a local pin.

Firmware size: bundling is whole-vendor cp -RL (build.yml:687), no per-GPU subsetting; amdgpu alone is “hundreds of MB” (the workflow says so at :663) and a newer FW_TAG only grows it, inflating graphics-kexts.tar.gz and the ISO. Subsetting to matched ASICs, or splitting firmware into a non-ISO asset, is a design change — out of scope for the one-line flip but flagged.

3.5  nextbsd-redux/nextbsd-freebsd-compat — the curated base #336

The FREEBSD_BRANCH: releng/15.0 at build.yml:18 is vestigial (never dereferenced; /usr/src comes baked in the toolchain image). So there is no load-bearing pin here — but this repo carries the migration’s sharpest runtime-not-CI risks:

• Lever B is the #1 silent failure. The -DSTANDARD_LIBRARY_PATH append (build.yml:101-104, scoped via .if ${.CURDIR:M*/libexec/rtld-elf}) is what puts /System/Library/Libraries + /usr/local/lib on rtld’s compiled-in path. If 15.1 renames the macro or moves the rtld dir, it compiles clean and silently produces a stock rtld — the whole GNUstep desktop stops resolving libs. Verify post-build: strings .../ld-elf.so.1 | grep -F '/System/Library/Libraries'. (There is no ldconfig boot job to fall back on, by design.)
• krb5 closure is the most fragile compile. The build leans on 15.0 specifics: MK_KERBEROS=no/MK_MITKRB5 defaults, the compile_et header-staging dance (build.yml:128-164), and the libkrb5.so.122 soname. A 15.1 MIT-krb5 bump or MK_* flip needs KRBFLAGS/staging rework, and downstream curl/git/pkg linkage re-pointed.
• C++ trio vs ports clang. libc++/libcxxrt/libcompiler_rt assume “matches ports clang 19” (srclist.txt:50-55). If 15.1 ships libc++ 20, revisit that invariant.
• libc / libthr / rtld must move as a unit — shared private __libc_interposing[] table; never mix 15.1 rtld/libthr with 15.0 libc.
• No-clobber-Apple-libs. A new transitive DT_NEEDED in any 15.1 component could stage a FreeBSD lib that shadows an Apple-provided one. Diff the 15.1 /stage lib set vs the Apple inventory on root@1/root@2 before shipping. Reconcile the setuid re-apply guard (build.yml:209) against srclist setuid entries.

Edits: build.yml:18 → 15.1 (documentary) + comment refresh (build.yml:130,223, srclist.txt:53,185,240,242). The substance is the post-build verification list above, gated before the continuous cascade to the ISO.

3.6  nextbsd-redux/nextbsd — the ISO assembler #336

Net: near-zero substantive change. Pure “latest continuous” pass-through — base, kernel, and kexts are pulled by version-agnostic patterns, so 15.1 artifacts flow in the moment upstream publishes them. PKG_ABI is FreeBSD:${MAJOR}:${ARCH} (build.sh:31) → FreeBSD:15:amd64 for all 15.x — must not be hardcoded to a minor. The image’s displayed identity is a build timestamp, not a FreeBSD version. IGNORE_OSVERSION=yes everywhere means a 15.0 build host can run a 15.1 assembly — but see the correction in §7.1: the build VM also gap-fills the rootfs with its own binaries, so its release does end up in the shipped image. The matrix bump below is required, not optional.

3.7  Deep dive: the i915 6.12 personality generator fix #337

An empty match table is a non-shipper, so this gets its own fully-scoped fix. The breakage, the trap, and the implementation:

What broke. tools/gen-i915-personalities.sh:48-52 extracts IDs with grep -oE 'INTEL_VGA_DEVICE\(0x[0-9A-Fa-f]+' over i915_pciids.h. On 6.12 that header has zero such literal rows — IDs moved into MACRO__(0x….) entries inside per-platform INTEL_<PLAT>_IDS(MACRO__, …) macros — so IDS is empty and the script trips its own [ -n "$IDS" ] guard. The output contract it must preserve: an IOKitPersonalities dict whose IOPCIPrimaryMatch is space-separated 0x<device><vendor> words (e.g. 0x59168086), vendor hardcoded 8086, IOProbeScore=10000. Consumed verbatim by ko2kext.sh -p into the kext Info.plist.

The fix — let the C preprocessor expand the driver’s own list. Redefine the INTEL_VGA_DEVICE callback to emit a tagged id, replay i915_pci.c’s INTEL_<PLAT>_IDS(INTEL_VGA_DEVICE, …) rows, and scrape. This resolves all nesting (MTL→ARL) for free, auto-excludes anything not in pciidlist, and tracks future drm-kmod bumps. The generator takes a new i915_pci.c arg; only the extraction block changes, output stays byte-identical:

REFS=$(grep -E 'INTEL_[A-Z0-9_]+_IDS[[:space:]]*\(INTEL_VGA_DEVICE' "$PCI_C" | sed -E 's@/\*.*@@')
IDS=$(
  {
    printf '#include "%s"\n'              "$SRC"
    printf '#undef INTEL_VGA_DEVICE\n'
    printf '#define INTEL_VGA_DEVICE(id, info) @@id@@\n'
    printf 'int nbkm_i915_ids[] = {\n%s\n};\n' "$REFS"
  } | "${CC:-cc}" -E -P -xc - 2>/dev/null \
    | grep -oE '@@0x[0-9A-Fa-f]+@@' | grep -oE '0x[0-9A-Fa-f]+' \
    | tr 'A-F' 'a-f' | sort -u
)
[ -n "$IDS" ] || { echo "i915 pciidlist expansion produced no ids" >&2; exit 1; }

The host runner (drm-kmod job, build.yml:271) has cc/clang; the header is self-contained (no -I needed). The build step gains a locator and passes it — and tighten the find to the moved path:

I915H=$(find /tmp/drm-kmod -path '*drm/intel/i915_pciids.h' | head -1)
I915C=$(find /tmp/drm-kmod -path '*gpu/drm/i915/i915_pci.c'   | head -1)
"$T/gen-i915-personalities.sh" "$I915H" "$I915C" org.nextbsd.kext.intelgraphics IntelGraphics > pers/IntelGraphics.iokitpersonalities

CI gate — close the hole that hid this. The current selftest (tests/personalities-selftest.sh) feeds the generator a synthetic old-form INTEL_VGA_DEVICE(0x….) fixture, so it would have stayed green against the real 6.12 break. Three layers:

1. Update the fixture to 6.12 shape (a MACRO__(0x…) header + a tiny i915_pci.c stub), asserting MTL→ARL expansion lands and an xe-only id does not.
2. Real-source count band after generation: N=$(grep -oE '0x[0-9a-f]{8}' pers/IntelGraphics.iokitpersonalities | sort -u | wc -l); [ "$N" -ge 300 ] && [ "$N" -le 450 ] (~364 expected). This alone would have caught the empty table.
3. Driver cross-check in the FreeBSD VM (build.yml:528+): kldxref/pnpinfo the built i915kms.ko (its LKPI_PNP_INFO table), normalise to 0x<dev>8086, and assert set-equality with the generated match words — ground-truth parity that fails loudly on any future header drift.

Fallback if a compiler is ever absent: a pure-shell recursive macro-expansion seeded from the pciidlist macro names (must replicate the preprocessor’s fixpoint nesting — more fragile, kept only as a backstop). When NextBSD later adds an xe kext, LNL/BMG/standalone-ARL get their own generator off xe’s pciidlist — not this one.

4. Ordered runbook

Follow the dependency chain. Each step has a gate — do not cascade until it’s green.

gh api "repos/nextbsd-redux/freebsd-src/compare/freebsd:releng%2F15.1...nextbsd-redux:releng%2F15.1" \
  --jq '{status, ahead_by, behind_by}'      # expect {"status":"identical","ahead_by":0,"behind_by":0}

gh api repos/nextbsd-redux/freebsd-src/contents/sys/sys/param.h?ref=releng/15.1 \
  --jq '.content' | base64 -d | grep __FreeBSD_version   # expect 1501000  (≥ 1500509)

5. Risk register (ranked)

6. Acceptance — mapped to the tickets

• #336 Full chain (toolchain→kernel→modules→compat→ISO) builds green on releng/15.1; booted image reports kern.osreldate ≥ 1500509; launchd boot, kexts (incl. graphics 6.6 pre-#337), networking still work; pkg install works (FreeBSD:15:amd64).
• #337 On the 15.1 image, IOGraphics/IntelGraphics/AMDGraphics/RadeonGraphics load against the 6.12 drm.ko, firmware is found, and a supported GPU brings up KMS. (Reminder from the decision plan: 6.12 still has no Intel xe — Lunar Lake / Battlemage stay unsupported.)

7. Execution addendum — corrections & extra steps from the live bump (20 June 2026)

The bump was executed end-to-end on 20 June 2026 (kernel PR #47, compat PR #27, ISO-matrix PR #341). Four findings corrected or extended the scoping above — including a wrong “zero patch drift” prediction (§7.5) — recorded here so the next minor bump (15.1→15.2) is mechanical.

7.1  The build VM is a load-bearing source — the matrix bump is REQUIRED, not optional

§3.6 originally rated the matrix.freebsd:'15.0' pin “optional, build-host only.” That was wrong. build.sh (~line 202) gap-fills the rootfs from the VM’s /bin /sbin /usr/bin with cp -RpPn (no-clobber) for everything the curated from-source base omits — which includes init, uname, and freebsd-version (the last removed from the base in #300). So a 15.0 VM bakes 15.0 userland binaries into a 15.1 image.

Fix: bump matrix.freebsd 15.0→15.1 and variant 15.0-RELEASE→15.1-RELEASE in all three matrix blocks (PR #341). The plan’s “only if vmactions offers a 15.1 image” conditional is resolved: 15.1-RELEASE is present on the mirror (.../releases/amd64/15.1-RELEASE/base.txz → HTTP 200) and accepted by vmactions/freebsd-vm. The job name: labels were also made version-agnostic (build (${{ matrix.arch }})) so they stop drifting each bump — variant still drives the distfiles cache key + FREEBSD_VARIANT.

7.2  workflow_dispatch builds but never publishes/cascades — use repository_dispatch

Every repo gates its publish-to-continuous and downstream cascade on github.event_name == 'push' || 'repository_dispatch' — never workflow_dispatch. So a manual run (or a PR merge in a repo with no push trigger) builds and validates but leaves continuous stale. This bit the bump three times before it was understood.

Rule of thumb: a manual dispatch is for validation; a repository_dispatch (or the toolchain re-cascade) is for shipping.

7.3  Cache purge — optional hygiene, not a fix

No cache caused any version skew. ccache is content-addressed (a 15.1 source compile yields 15.1 objects every time — it cannot emit a stale-version binary); the distfiles cache is keyed on variant (build.yml:121), so it auto-invalidates when variant flips to 15.1-RELEASE. The stale binaries came from the VM image, which we don’t cache. For a clean-slate rebuild guarantee only:

for r in nextbsd-kernel-toolchain nextbsd-kernel nextbsd-kernel-modules nextbsd-freebsd-compat nextbsd; do
  gh cache delete --all -R nextbsd-redux/$r
done
# then re-cascade the whole chain from the top:
gh workflow run "Build Toolchain Containers" -R nextbsd-redux/nextbsd-kernel-toolchain --ref main

7.4  Verification on a booted image

• uname -K == uname -U == 1501000 (kernel and userland both 15.1) — the single sharpest check; a split here is the §7.1 gap.
• sysctl kern.osreldate == 1501000 (the #336 acceptance floor ≥ 1500509).
• freebsd-version is gone (preferred, per #300) or reports 15.1; nextbsd-version reports the build timestamp.
• Not ldd — it lists a binary’s shared-lib deps, it cannot report kernel version. Use uname -K / kern.osreldate.

7.5  The patch stack did drift — headline §1.1 was wrong

The scoping’s biggest claimed de-risk — “all 7 patch targets byte-identical, zero rebase” — did not hold. It was caught by the live Apply patches CI step failing, then confirmed against a clean releng/15.1 tree. Two of seven patches drifted (PR #47); the other five applied unchanged.

Lesson: “same last-touch SHA on 15.0” does not imply identical on 15.1 — a releng minor can touch any file. The reliable gate is the Apply patches CI step itself (strict + cumulative, in order), not a pre-scan of file SHAs. Both edits were mechanical (no new logic), so the “minimal patch authoring” spirit held even though “zero” did not.

Sources & method

Scope produced by six parallel read-only agents over the NextBSD build chain (June 2026), each reporting file:line edits, rebase risk, and runtime-vs-CI failure surfaces. Cross-repo facts verified directly against GitHub:

• Patch-stack parity: last-touch commit SHAs of all 7 target files identical on nextbsd-redux/freebsd-src releng/15.0 vs releng/15.1; __FreeBSD_version 1500068 vs 1501000 from sys/sys/param.h.
• drm.ko deps: MODULE_DEPEND(drmn, …) in freebsd/drm-kmod 6.12-lts drivers/gpu/drm/drm_os_freebsd.c (01682db0, 2026-06-14).
• i915 restructure: include/drm/intel/i915_pciids.h on 6.12-lts — MACRO__(0x….) form, INTEL_<PLAT>_IDS() macros, 0 INTEL_VGA_DEVICE(0x….) literals; amdgpu amdgpu_drv.c (308 rows), radeon drm_pciids.h (699 rows).
• Decision context: nextbsd-drm612-upgrade-plan.html; tickets #336, #337.