I’m pasting this here as well as consider removing ZFS for Fedora 45 release in Fall 2026 · Issue #1765 · ublue-os/aurora · GitHub in case there are people here interested in this.
I think I’m ready to share this 
Danathar/zfs-aurora-complex | DeepWiki (because its does a CRAZY cool job explaining a repo!)
GitHub - Danathar/zfs-aurora-complex: Native Containerfile-based Aurora + ZFS image build · GitHub + GitHub - Danathar/akmods: A caching layer for pre-built Fedora akmod RPMs · GitHub
This is my attempt at vibe coding / hand editing — mostly vibe coding — a fairly complex repo that takes Aurora without ZFS and builds a ZFS-enabled image on top of it.
I started this as an experiment on a Friday afternoon after @renner0e first posted about ZFS going away back in February. At the time I was not really planning to use it in production on my own box. It was more of a “let’s see how far I can get with this” project. But honestly, it has gotten good enough that I think I might actually do it. I generally have a crooked eye toward vibed code..but..it’s been rock solid for months with only a few issues to iron out and edge cases thus far.
The repo tracks the Aurora base image, currently ghcr.io/ublue-os/aurora-dx:latest, because ZFS is not included there. On each build it resolves the base image to a digest, detects the installed kernel version from the image, resolves the OpenZFS/akmods source it should use, and checks whether there is a matching ZFS akmods cache for that kernel.
It also uses a slightly modified fork of the akmods build logic. That fork is used to build and publish the ZFS akmods cache this image consumes, while the main image repo handles the base-image resolution, compatibility checks, signing, promotion, and fail-closed behavior.
If the kernel/ZFS pairing is compatible, it builds a candidate image, signs it, and only then promotes it to latest. If the pairing is not compatible, it fails closed before promotion and writes a clear GitHub Actions summary explaining why.
The goal is that I do not have to manually babysit the kernel/ZFS pairing. Each run re-checks the current Aurora base and the current OpenZFS source. When OpenZFS releases support for the newer kernel, the repo should stop failing at the akmods step and proceed through the normal build/sign/promote flow automatically.
The big test was when Aurora latest moved to kernel 7.0.4. The repo detected that OpenZFS 2.4.1 only declares support up to Linux 6.19, so it failed closed and skipped image promotion, with a step message explaining the mismatch. The next real test will be when OpenZFS releases a version with Linux 7 support — maybe 2.4.2, depending on upstream — at which point the repo should automatically pick it up and build again.
If anyone wants to try this or fork it, the main thing to know is that there are really two repos involved:
- the image repo, which builds the final Aurora + ZFS image
- the modified akmods repo, which builds the ZFS akmods cache image
You really should fork both. If you only fork the image repo but leave it pointing at my akmods fork, then you are still depending on my akmods build pipeline and GHCR namespace. That might be fine for reading/testing, but it is not what you want for a real setup.
So the intended path would be: fork both repos, update the image repo defaults so it points at your akmods fork, and make sure both the akmods cache and final image publish under your own GHCR namespace. You will also need your own signing setup/secrets if you want to boot it with strict signature verification enabled.
Also, this is not something I would treat as a generic turnkey template yet. It is very much built around my own use case and my own risk tolerance. Its VERY complex, so that’s a risk you take for the convenience of being able to sit back not do anything. The important thing is to understand the fail-closed behavior: if the current Aurora kernel and OpenZFS do not match, the repo should refuse to promote a new image rather than publishing something broken.
So if you fork it, I would recommend watching the first few builds carefully, checking the generated GitHub Actions summaries/artifacts, and making sure the GHCR image names, signing policy, and akmods cache repo all point where you expect before trying to boot it on anything important.
Anyway, at the very least some of you might find it interesting. I know I do! I’ll continue to bug fix, and harden it over the next 6 months before ZFS is removed for good from Aurora. Also, this thing works with other Fedora Atomic images as well, I’ve not tested it with Bluefin (though it should work, no reason why it wouldn’t), but I have with Kinoite and it works, so the system is agnostic in that way.
Oh, and it also has a branch-build workflow, so I can test changes on a branch — including signed branch images — without touching main’s latest image or promotion flow.