Re: Status of ZFS support on Guix

[Kaelyn]

On Wednesday, October 2nd, 2024 at 5:18 PM, Ian Eure <ian@retrospec.tv> wrote:

> 
> 
> Hi Kaelyn, Morgan,
> 
> Kaelyn kaelyn.alexi@protonmail.com writes:
> 
> > On Tuesday, October 1st, 2024 at 1:23 PM, Morgan Arnold
> > morgan.arnold@proton.me wrote:
> > 
> > I'd love to know where any opposition may be at as well. At this
> > point
> > I have a private channel which actually replaces much of the
> > bootloader and initrd functionality (in part to support ZFS in
> > the
> > initrd using https://issues.guix.gnu.org/55231). In the past
> > year, I
> > actually took advantage of having basically replicated much of
> > the
> > initrd functionality in my channel to create a simple bootloader
> > based
> > on the Linux kernel (with the EFI stubloader) and a custom
> > initrd that
> > uses kexec to boot the actual system. It still needs a lot of
> > polish,
> > but has been good enough that combined with a few other small
> > hacks
> > and workarounds, I have several systems now booting with ZFS
> > roots
> > (some unencrypted, some using native encryption). I have done
> > little
> > to upstream most of it, or even to share what I've done, because
> > of
> > the seeming resistance to ZFS.
> 
> 
> I don’t think there’s resistance to ZFS. I do think there are
> some legitimate open questions around licensing[1], but the main
> issue seems to be that the contributor of #45692 chose to express
> their frustration with the slow pace of Guix patch review[2] in
> counterproductive and borderline abusive ways[3][4].

I'd like to believe there isn't resistance to ZFS, but at least part of my 
perception that there is from #55231 with the discussion over a documentation 
patch about how to use "kernel-loadable-modules" in an operating-system to 
include out-of-tree modules in the initrd starting 
https://issues.guix.gnu.org/55231#14 (the original comment about ZFS being a 
bad example in the documentation over potential code issues was 
https://issues.guix.gnu.org/55231#4). There was a bit of back and forth over 
the example was a bad one because of potential ZFS licensing issues and 
"#:substitutable #f" mixing poorly with initrds, such that it is theoretical 
possible for a substitute with the compiled ZFS kernel module to be downloaded 
from another user/server and that it would count as distributing the ZFS module 
precompiled. The patch series was then updated to remove the reference to ZFS 
in the documentation, and the overall conversation (and forward progress on the 
patch series) seemed to completely stall e.g. with no further responses from 
the person who raised the issue about using ZFS in the example.

> 
> Personally, I’d very much like to see improved support for ZFS in
> Guix. I have one machine with a cobbled-together Guix ZFS setup,
> but proper support is a blocker for moving my primary ZFS-using
> system off Debian.

I feel the same way, despite a lot of my local work and workarounds to have ZFS 
roots on most of my Guix systems.

Cheers,
Kaelyn

> 
> Thanks,
> 
> — Ian
> 
> [1]: https://issues.guix.gnu.org/45692#75
> [2]: Which I extremely sympathize with.
> [3]: https://issues.guix.gnu.org/45692#72
> [4]: https://issues.guix.gnu.org/45692#78