docs: fork README; stop building the main-flavor zfs artifact

.github/workflows/build-akmods-main.yml

@@ -82,30 +82,12 @@ jobs:
       kernel_cache_key: ${{ needs.cache_kernel_main_44.outputs.KCKEY }}
       kernel_flavor: main
       version: 44
-  build-main_44_zfs:
-    name: Build zfs main (44)
-    uses: ./.github/workflows/reusable-build.yml
-    secrets: inherit
-    permissions:
-      actions: read
-      attestations: write
-      artifact-metadata: write
-      contents: read
-      id-token: write
-      packages: write
-    needs: cache_kernel_main_44
-    with:
-      akmods_target: zfs
-      architecture: '["x86_64"]'
-      kernel_cache_key: ${{ needs.cache_kernel_main_44.outputs.KCKEY }}
-      kernel_flavor: main
-      version: 44
   check-main_44:
     name: Check main (44)
     permissions:
       actions: read
       contents: read
-    needs: [build-main_44_common,build-main_44_nvidia-lts,build-main_44_nvidia-open,build-main_44_zfs]
+    needs: [build-main_44_common,build-main_44_nvidia-lts,build-main_44_nvidia-open]
     runs-on: ubuntu-24.04
     if: always()
     steps:
@@ -181,30 +163,12 @@ jobs:
       kernel_cache_key: ${{ needs.cache_kernel_main_43.outputs.KCKEY }}
       kernel_flavor: main
       version: 43
-  build-main_43_zfs:
-    name: Build zfs main (43)
-    uses: ./.github/workflows/reusable-build.yml
-    secrets: inherit
-    permissions:
-      actions: read
-      attestations: write
-      artifact-metadata: write
-      contents: read
-      id-token: write
-      packages: write
-    needs: cache_kernel_main_43
-    with:
-      akmods_target: zfs
-      architecture: '["x86_64"]'
-      kernel_cache_key: ${{ needs.cache_kernel_main_43.outputs.KCKEY }}
-      kernel_flavor: main
-      version: 43
   check-main_43:
     name: Check main (43)
     permissions:
       actions: read
       contents: read
-    needs: [build-main_43_common,build-main_43_nvidia-lts,build-main_43_nvidia-open,build-main_43_zfs]
+    needs: [build-main_43_common,build-main_43_nvidia-lts,build-main_43_nvidia-open]
     runs-on: ubuntu-24.04
     if: always()
     steps:

FORK-PATCHES.md

@@ -26,6 +26,9 @@ stated condition under which it should be deleted).
 - **Why:** every image name in `images.yaml` is assembled as `<registry>/<org>/<name>`. Left at
   `ublue-os`, `just push` from this fork targets `ghcr.io/ublue-os/...` and the registry returns 403,
   because the fork's `GITHUB_TOKEN` has no write access to the upstream org.
+- **Currently inert.** Every build workflow is disabled, so nothing pushes anywhere and this value is
+  never exercised. It is kept so the destination is already correct if publishing is ever switched back
+  on. Note it has *never* run against a real registry — see the operational state section.
 - **Merge note:** upstream touches this anchor whenever it adds a field. Keep `org`, take everything else.
 
 ### P2 — Image name comes from `images.yaml`, not the target name
@@ -40,20 +43,22 @@ stated condition under which it should be deleted).
 - **Merge note:** this is the single most load-bearing patch in the fork. If an upstream merge silently
   reverts it, `zfs-aurora-complex` starts publishing to the wrong image name.
 
-### P3 — README: Supply-chain scorecard section
+### P3 — Fork README
 
 - **Files:** `README.md`
-- **What:** one added section, "Supply-chain scorecard", documenting how to read the Scorecard results
-  produced by P4. This is the *entire* committed README delta against upstream.
-- **Merge note:** upstream owns the rest of this file. On conflict, take upstream's version and re-apply
-  this section.
-
-> **Not yet applied — do not treat as existing state.** A fork-identity README rewrite (fork banner in
-> place of the `# ublue-os akmods` heading, a "Why This Fork Exists" section, and `ghcr.io/danathar/...`
-> pull examples replacing `ghcr.io/ublue-os/...`) exists as an **uncommitted working-tree change** and is
-> not in the repository. As of this writing the committed README still carries upstream's heading and
-> upstream's image examples. When that work is committed, promote it into P3 above. Until then, an
-> upstream merge has no fork README content to preserve beyond the Scorecard section.
+- **What:** four changes against upstream's README:
+  1. `# ublue-os akmods` → `# akmods (Danathar fork)`, and the per-flavor build badges dropped (they
+     pointed at upstream's workflow runs, which say nothing about this fork).
+  2. A "Why This Fork Exists" section — what this fork feeds and which patches are load-bearing.
+  3. A "Supply-chain scorecard" section documenting how to read the results produced by P4.
+  4. A "This fork publishes no images" callout above "How it's organized".
+- **Deliberately *not* changed:** the `COPY --from=ghcr.io/ublue-os/...` and
+  `cosign verify ... ghcr.io/ublue-os/akmods:...` examples still point at **upstream's** registry. They
+  were briefly rewritten to `ghcr.io/danathar/...`, which was wrong: this fork publishes nothing, so
+  those refs pointed at images that do not exist, and the checked-in `cosign.pub` is upstream's key.
+  Do not "fix" them back to the fork's namespace unless publishing is actually turned on.
+- **Merge note:** conflicts on nearly every upstream README change. Keep the fork's framing and the
+  no-images callout; fold in upstream's substantive content.
 
 ### P4 — OpenSSF Scorecard workflow
 
@@ -66,43 +71,48 @@ stated condition under which it should be deleted).
 
 ## Temporary
 
-### T1 — ZFS akmod for the `main` kernel flavor
+### T1 — `zfs.main` block pinning the kernel-compatibility gate
 
-- **Added:** 2026-07-26
-- **Files:** `images.yaml` (`images.43.main`, `images.44.main` merge in `*server-build-group-only-x86`),
-  `.github/workflows/build-akmods-main.yml` (generated)
-- **What:** upstream builds `zfs` only for the server flavors (`centos`, `coreos-*`, `longterm-*`). This
-  fork also builds and publishes `ghcr.io/danathar/akmods-zfs:main-43` and `:main-44`.
-- **Why:** `zfs-aurora-complex` targets Aurora DX, which rides the Fedora `main` kernel. Until this
-  existed, that repo had to rebuild the ZFS akmod from this repo's source on every run.
-- **Remove when:** upstream adds a `zfs` target under `main` (then take upstream's), or
-  `zfs-aurora-complex` stops consuming a published ZFS cache image.
-- **Merge note:** if upstream restructures the build-group anchors, re-derive this rather than taking the
-  merge result verbatim, then re-run `just generate-workflows`.
-
-### T2 — `--enable-linux-experimental` for the `main` flavor
-
-- **Added:** 2026-07-26
-- **Files:** `images.yaml` (`zfs.main.linux_experimental: true`)
-- **What:** passes `--enable-linux-experimental` to the OpenZFS `configure` for `main` builds only,
-  the same override `coreos-testing` already carries.
-- **Why:** OpenZFS 2.4.3 refuses to configure against a kernel newer than 7.0:
+- **Files:** `images.yaml` (`zfs.main`)
+- **What:** an explicit `zfs.main` block setting `minor_version: "2.4"` and
+  `linux_experimental: false`. Upstream has no `zfs.main` key at all.
+- **Why it is not redundant:** the values are identical to `zfs.default`, so this is *behaviourally* a
+  no-op — it exists to carry a warning at the point of temptation. `zfs-aurora-complex` injects its own
+  `images.<ver>.main.zfs` target at build time and the `Justfile` reads `.zfs.main.linux_experimental`
+  when building it, so this block is the knob a future maintainer would reach for when a `main` ZFS build
+  goes red. The comment there explains why flipping it to `true` is the wrong fix.
+- **Background:** it *was* `true` briefly (2026-07-26 → 2026-07-27). OpenZFS 2.4.3 refuses to configure
+  against a kernel newer than 7.0, and `aurora-dx:latest` had moved to Fedora 44's 7.1.x kernel:
 
   ```
   configure: error:
       *** Cannot build against kernel version 7.1.4-202.fc44.x86_64.
       *** The maximum supported kernel version is 7.0.
   ```
 
-  Fedora 44's `main` kernel is 7.1.x, so without this flag every `main` ZFS build fails at configure.
-  This is the same failure that broke `zfs-aurora-complex`'s nightly (runs 30148339311, 30192096209).
-- **Risk:** the flag disables an upstream compatibility gate. The module may build and still misbehave
-  against a kernel OpenZFS has not validated. Treat `main` ZFS builds as unvalidated until OpenZFS
-  declares support.
-- **Remove when:** an OpenZFS release in the configured `minor_version` line raises its maximum supported
-  kernel to at or above the Fedora `main` kernel. Check `META`'s `Linux-Maximum` in the OpenZFS tag being
-  built; when it covers the current `main` kernel, delete the `zfs.main` block and let it inherit
-  `zfs.default`.
+  `--enable-linux-experimental` got past it, but the consumer then switched to `aurora-dx:stable`
+  (kernel 7.0.12-201.fc44), inside the supported range, so the override was re-armed to `false`. The
+  flag suppresses OpenZFS's own refusal to build against an unvalidated kernel; with it set, a future
+  kernel bump past the ceiling silently produces an unvalidated module instead of failing loudly, and
+  consumers that gate on that failure lose their upstream-compat signal.
+- **Remove when:** never, unless upstream adds an equivalent. Set to `true` only as a deliberate,
+  temporary, documented exception — not to turn a red build green.
+
+### T2 — *(retired 2026-07-30)* ZFS akmod for the `main` kernel flavor
+
+Between 2026-07-26 and 2026-07-30 this fork added a `zfs` target to `images.43.main` / `images.44.main`
+(by merging in `*server-build-group-only-x86`) and configured it to publish as
+`ghcr.io/danathar/akmods-zfs:main-43` and `:main-44`. It has been **reverted** — the build-matrix
+entries are gone and `build-akmods-main.yml` is byte-identical to its pre-change state. `images.yaml`
+is not fully byte-identical to the pre-target tree: the `zfs.main` block and the `org: danathar`
+namespace change were both introduced in the same commit as this target, but they survive the revert
+on their own merits (see T1 and P1) rather than as leftovers of it. No image was ever actually
+published under this target — see operational state below.
+
+Kept as a note rather than deleted because the idea recurs: `zfs-aurora-complex` builds the ZFS akmod
+from this repo's *source* on every run, and publishing a prebuilt cache here looks like an obvious
+saving. It was dropped because that consumer builds fine without it, and an unconsumed daily image is
+pure cost. If you revisit it, the build itself is proven to work — see run 30206124460.
 
 ### T3 — Hardened OpenZFS release discovery
 
@@ -147,12 +157,40 @@ stated condition under which it should be deleted).
 
 ## Operational state (not a patch, but easy to lose)
 
-- The fork's build workflows were disabled by hand after the 2026-07-05 scheduled runs failed on a
-  transient `kojipkgs` truncation (`curl (18) end of response with ... bytes missing`) — a flake, not a
-  config fault. `Build MAIN akmods` has since been re-enabled; `CENTOS`, `COREOS-STABLE`,
-  `COREOS-TESTING`, `LONGTERM-6.18`, `OGC`, and `Cleanup Old Images` remain `disabled_manually`
-  deliberately, since nothing here consumes them.
-- No repository secrets are configured. `KERNEL_PRIVKEY` / `AKMOD_PRIVKEY_20230518` are absent, so
-  `build-prep.sh` falls back to the **test signing key** (`certs/*.priv.test`) and logs
-  `WARNING: Using test signing key.` `SIGNING_SECRET` is absent too, so pushed images are not
-  cosign-signed. Anything consuming these images must enroll the test key or not verify at all.
+### This fork builds and publishes nothing
+
+As of 2026-07-30, **all six `Build * akmods` workflows and `Cleanup Old Images` are
+`disabled_manually`.** No image has ever been pushed to `ghcr.io/danathar` — that namespace is empty.
+The fork is consumed as *source* by `zfs-aurora-complex`, which clones it and builds its own cache.
+
+`Build MAIN akmods` was briefly enabled (2026-07-26 → 2026-07-30) while testing the retired T2 target,
+then switched back off. This state lives in GitHub repository settings, not in any file here, so `git
+log` will never show it changing — which is exactly why it is written down.
+
+### Scheduled builds cannot succeed without the signing secrets
+
+This one costs an hour to rediscover. No repository secrets are configured, and the failure mode differs
+by trigger:
+
+- On **`pull_request`**, the `Retrieve Signing Key` step in `reusable-build.yml` is skipped. The
+  committed `certs/private_key.priv` stays 0 bytes, `build-prep.sh`'s `[[ ! -s ... ]]` test fires, and
+  the build falls back to the test key and succeeds with `WARNING: Using test signing key.`
+- On **`schedule`** / `workflow_dispatch` / `merge_group`, that step *runs* and writes an empty
+  `secrets.KERNEL_PRIVKEY` into `certs/private_key.priv` — producing a **1-byte** file. `-s` now passes,
+  so the test-key fallback never triggers, and the run dies in `fetch-kernel` with:
+
+  ```
+  OSSL_DECODER_from_bio:unsupported:...:No supported data to decode. Input type: PEM
+  error: Recipe `fetch-kernel` failed with exit code 1
+  ```
+
+  This kills the *kernel cache* job, before any akmod is built. Observed on runs 30318357041,
+  30412211886, 30503677867 (~2 min each).
+
+So a green PR check does **not** predict a green nightly. Enabling any scheduled build requires setting
+`KERNEL_PRIVKEY` and `AKMOD_PRIVKEY_20230518` first, or patching the `-s` guard to also reject
+whitespace-only key files. `SIGNING_SECRET` is absent too, so pushed images would not be cosign-signed
+either.
+
+Note the 2026-07-05 disabling had a *different* cause — a transient `kojipkgs` truncation
+(`curl (18) end of response with ... bytes missing`), a flake rather than a config fault.

README.md

@@ -1,9 +1,22 @@
-# ublue-os akmods
+# akmods (Danathar fork)
 
-[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/ublue-os/akmods/badge)](https://scorecard.dev/viewer/?uri=github.com/ublue-os/akmods)[![Build CENTOS akmods](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-centos.yml/badge.svg)](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-centos.yml)[![Build COREOS-STABLE akmods](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-coreos-stable.yml/badge.svg)](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-coreos-stable.yml)[![Build COREOS-TESTING akmods](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-coreos-testing.yml/badge.svg)](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-coreos-testing.yml)[![Build LONGTERM-6.18 akmods](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-longterm-6.18.yml/badge.svg)](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-longterm-6.18.yml)[![Build OGC akmods](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-ogc.yml/badge.svg)](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-ogc.yml)[![Build MAIN akmods](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-main.yml/badge.svg)](https://github.com/ublue-os/akmods/actions/workflows/build-akmods-main.yml)
+[![OpenSSF Scorecard](https://api.scorecard.dev/projects/github.com/ublue-os/akmods/badge)](https://scorecard.dev/viewer/?uri=github.com/ublue-os/akmods)
 
 OCI images providing a set of cached kernel RPMs and extra kernel modules to Universal Blue images. Used for better hardware support and consistent build process.
 
+## Why This Fork Exists
+
+This is a personal fork of [`ublue-os/akmods`](https://github.com/ublue-os/akmods), kept in sync with upstream. It exists to feed [`zfs-aurora-complex`](https://github.com/Danathar/zfs-aurora-complex), which builds a signed Aurora DX image with ZFS kernel modules.
+
+`zfs-aurora-complex` doesn't consume a published image from here — its CI clones this repo's source at a resolved commit (by default it floats on this repo's `main`; it can pin to an exact commit in its own `ci/defaults.json` to freeze against an upstream regression or reproduce a past build) and builds the shared ZFS akmods cache directly from this repo's `Justfile` and `build_files/zfs` scripts. That means any commit pushed to this fork's `main` becomes the source for that repo's next build, so beyond mirroring upstream this fork carries a couple of load-bearing local patches:
+
+- `Justfile`: derive the published cache image name from `images.yaml`'s `.name` field (upstream hardcodes `akmods-<target>`), so the consuming repo controls the cache image name without patching the `Justfile` at build time
+- `build_files/zfs/build-kmod-zfs.sh`: hardened OpenZFS release discovery (GitHub token plumbing, xtrace/JSON-array guards) so the release lookup doesn't flake under CI
+
+See `zfs-aurora-complex`'s [`docs/akmods-fork-maintenance.md`](https://github.com/Danathar/zfs-aurora-complex/blob/main/docs/akmods-fork-maintenance.md) for the full sync and pin process.
+
+Everything else about how this repo works (kmod groups, kernels built, usage) matches upstream and is documented below.
+
 ## Supply-chain scorecard
 
 OpenSSF Scorecard runs on pushes to `main`, on a weekly schedule, and when branch protection changes. The workflow uploads SARIF for GitHub code scanning and writes a readable Markdown summary directly into the workflow run, so readers do not need to download or inspect the SARIF artifact.
@@ -14,7 +27,13 @@ The Scorecard badge above tracks the public OpenSSF result for `ublue-os/akmods`
 
 ## How it's organized
 
-The [`akmods` images](https://github.com/orgs/ublue-os/packages?repo_name=akmods) are built and published daily. However, there's not a single image but several, given various kernels we now support.
+> **This fork publishes no images.** Every `Build * akmods` workflow here is disabled, so nothing is
+> built or pushed to `ghcr.io/danathar`. The sections below describe upstream's images, and the
+> `ghcr.io/ublue-os/...` references in them are correct as written — pull those. This fork is consumed as
+> *source*, not as a registry. See [Why This Fork Exists](#why-this-fork-exists) and
+> [`FORK-PATCHES.md`](FORK-PATCHES.md).
+
+The [`akmods` images](https://github.com/orgs/ublue-os/packages?repo_name=akmods) are built and published daily by upstream. However, there's not a single image but several, given various kernels we now support.
 
 The akmods packages are divided up for building in a few different "groups":
 

images.yaml

@@ -167,12 +167,8 @@ images:
         - *server-build-group
   43:
     main:
-      # Fork customization: upstream builds no zfs akmod for `main`. This fork
-      # publishes one so zfs-aurora-complex can consume a ready-made cache image
-      # instead of rebuilding it from this repo's source on every run.
       !!merge <<:
         - *desktop-build-group-only-x86
-        - *server-build-group-only-x86
     ogc:
       !!merge <<:
         - *ogc-desktop-build-group-only-x86
@@ -182,10 +178,8 @@ images:
         - *server-build-group
   44:
     main:
-      # Fork customization: see the note on 43.main above.
       !!merge <<:
         - *desktop-build-group-only-x86
-        - *server-build-group-only-x86
     ogc:
       !!merge <<:
         - *ogc-desktop-build-group-only-x86