Re-arm the OpenZFS kernel-compatibility gate for the main flavor - #2
Conversation
Sets zfs.main.linux_experimental back to false, matching zfs.default.
This was set true so zfs-aurora-complex could build ZFS against the Fedora
`main` kernel in aurora-dx:latest (7.1.x on F44), which is ahead of the newest
kernel OpenZFS 2.4.3 will configure against (7.0). That consumer now builds
from aurora-dx:stable (kernel 7.0.12-201.fc44), inside the supported range, so
the override is no longer needed there.
Leaving it set would be worse than unused. The flag disables OpenZFS's own
refusal to build against an unvalidated kernel, so the next time a tracked
kernel moves past the supported ceiling, the akmod would silently build against
a kernel upstream declines to support rather than failing. Consumers gate on
that failure and surface it as an upstream-compat signal; with the flag set,
that signal never fires.
coreos-testing keeps linux_experimental: true. That flavor intentionally rides
ahead of stable kernels, which is the case the exception exists for.
Known consequence: this fork's own scheduled build-main_{43,44}_zfs jobs build
against the current main kernel rather than a pinned one, so they will fail at
configure until OpenZFS supports the 7.1 line. That failure is accurate rather
than spurious -- it means upstream has not caught up yet. It does not affect
zfs-aurora-complex, which clones this fork and builds its own cache against an
explicitly pinned KERNEL_RELEASE.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 795fd0cf0f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| main: | ||
| minor_version: "2.4" | ||
| linux_experimental: true | ||
| linux_experimental: false |
There was a problem hiding this comment.
Setting this to false retires the main-flavor experimental override, but FORK-PATCHES.md:83-105 still records zfs.main.linux_experimental: true as an active temporary patch and instructs maintainers to preserve it until OpenZFS supports the current main kernel. During the repository's documented upstream-merge process, that guidance can reintroduce the override this change deliberately removes; delete or revise T2 alongside this configuration change.
Useful? React with 👍 / 👎.
1 participant
Sets
zfs.main.linux_experimentalback tofalse, matchingzfs.default.Why it was true
It was added so
zfs-aurora-complexcould build ZFS against the Fedoramainkernel shipped inaurora-dx:latest(7.1.x on F44), which is ahead of the newest kernel OpenZFS 2.4.3 will configure against:Why it can come out now
That consumer now builds from
aurora-dx:stable, which carries kernel 7.0.12-201.fc44 — inside OpenZFS's supported range. The override is no longer doing any work there. (See Danathar/zfs-aurora-complex#36.)Why leaving it set would be worse than unused
--enable-linux-experimentaldisables OpenZFS's own refusal to build against an unvalidated kernel. Left set, the next time a tracked kernel moves past the supported ceiling, the akmod would silently build anyway rather than failing — producing a module compiled against a kernel upstream declines to support, with no signal that anything changed.Consumers gate on that configure failure and surface it as an upstream-compat signal. With the flag set, that signal never fires. Re-arming restores the tripwire.
coreos-testingkeepslinux_experimental: true— that flavor intentionally rides ahead of stable kernels, which is the case the exception exists for.Known consequence — and why it is wanted
This fork's own scheduled
build-main_43_zfs/build-main_44_zfsjobs run daily (01 0 * * *) withkernel_flavor: mainand no pinned kernel release, so they build against whatever the current main kernel is. With this change they will fail at configure until OpenZFS supports the 7.1 line.Do not silence these. They are an inverted canary: red means "OpenZFS still does not support the current Fedora main kernel", and the day they turn green, that is the signal that 7.1 became viable and
aurora-dx:latestis worth reconsidering as a base. Withlinux_experimental: truethat signal can never fire, because the build always succeeds regardless of upstream support.Two caveats for anyone relying on it:
minor_version: "2.4"). It resolves the newest 2.4.x release. If 7.1 support lands in 2.4.x, this works as intended — but if it lands only in 2.5.0, these jobs keep failing against 2.4.x and never report the good news. Bumpminor_versionwhen a new ZFS minor line ships, or the canary silently stops meaning anything.maximum supported kernel versionto confirm the compat case. (zfs-aurora-complexclassifies this automatically viaclassify-akmods-failure; this repo does not.)zfs-aurora-complexis unaffected either way. It clones this fork and builds its own cache against an explicitly pinnedKERNEL_RELEASE; it does not consume this fork's published akmods images.Verification
No workflow regeneration needed — the Justfile reads this value from
images.yamlat build time (zfs_linux_experimental, line 25), it is not baked into the generated workflows.Suggested sequencing
Merge after Danathar/zfs-aurora-complex#36 lands and a
:stable-based build is confirmed green, so a:stableproblem and a flag problem can't be in flight at once.