Status of ZFS support on Guix

Status of ZFS support on Guix

[Morgan Arnold]

I asked around on the IRC channel a while ago about the status of ZFS support on Guix, and it was suggested that I ask here. I am aware of efforts made in the past to bring some rudimentary ZFS support to Guix (namely, https://issues.guix.gnu.org/45692, which appears to be quite dead), but was wondering if any new efforts have been considered. This is something which I would be very open to contributing to, as the lack of ZFS support is currently the only thing preventing me from using Guix as my main distro. It looks like there has is some general interest for better ZFS support on Guix, as evidenced by, say, https://issues.guix.gnu.org/73035.

Based on the response to 45692, I would also like to know if there is opposition to adding support for Guix, be it for philosophical or legal reasons. Assuming that no such opposition exists, 45692 seems to provide a very substantial chunk of the work which needs to be done for supporting ZFS on Guix, in particular automatic loading of the ZFS kernel module and automatic mounting of datasets. Ultimately, I would love to see support for `/' on ZFS, but based on discussions around 45692, it seems like this would be quite a bit more effort, although I must admit that I don't really understand why, other than that it involves modifying the behaviour of Shepherd earlier in the boot process.

Other than examining the patches which were submitted for 45692, I assume that it would be worth looking more closely at how other filesystems are managed on Guix, although the treatment of ZFS probably necessarily differs, if just for the loading of the kernel module. As for `/' on ZFS, would a deep dive into the documentation for Shepherd be valuable in terms of understanding how to load the ZFS kernel module as early as possible? Alternatively, are there other modules in Guix that are sometimes loaded early (maybe GPU drivers? I know that they are loaded early sometimes) which might be worth examining to understand how to go about it?

Thanks,

Morgan

Re: Status of ZFS support on Guix

[Kaelyn]

Hi,

On Tuesday, October 1st, 2024 at 1:23 PM, Morgan Arnold <morgan.arnold@proton.me> wrote:

> 
> 
> I asked around on the IRC channel a while ago about the status of ZFS support on Guix, and it was suggested that I ask here. I am aware of efforts made in the past to bring some rudimentary ZFS support to Guix (namely, https://issues.guix.gnu.org/45692, which appears to be quite dead), but was wondering if any new efforts have been considered. This is something which I would be very open to contributing to, as the lack of ZFS support is currently the only thing preventing me from using Guix as my main distro. It looks like there has is some general interest for better ZFS support on Guix, as evidenced by, say, https://issues.guix.gnu.org/73035.

Thank you for sharing those two issues; 45692 IIRC was the source/basis for the ZFS services in my private local channel that I've using for several years now.  I hadn't noticed 73035 yet, so I'll be looking at that soon.

There is also a couple of other issues that bring improvements related--at least tangentially-- to ZFS that are pending:

1) https://issues.guix.gnu.org/71482 which splits the ZFS userspace tools into a separate package and provides a helper function for creating a ZFS package for a specific kernel package.

2) https://issues.guix.gnu.org/55231 which adds support for including out-of-tree kernel modules in the initrd. This isn't strictly related to ZFS other than the documentation referencing ZFS in its example. The documentation patch had later been updated to include a different example of an out-of-tree module that is already packaged in Guix. I've also commented on it that I have essentially been using those patches for a number of years now.

> 
> Based on the response to 45692, I would also like to know if there is opposition to adding support for Guix, be it for philosophical or legal reasons. Assuming that no such opposition exists, 45692 seems to provide a very substantial chunk of the work which needs to be done for supporting ZFS on Guix, in particular automatic loading of the ZFS kernel module and automatic mounting of datasets. Ultimately, I would love to see support for `/' on ZFS, but based on discussions around 45692, it seems like this would be quite a bit more effort, although I must admit that I don't really understand why, other than that it involves modifying the behaviour of Shepherd earlier in the boot process. Other than examining the patches which were submitted for 45692, I assume that it would be worth looking more closely at how other filesystems are managed on Guix, although the treatment of ZFS probably necessarily differs, if just for the loading of the kernel module. As for` /' on ZFS, would a deep dive into the documentation for Shepherd be valuable in terms of understanding how to load the ZFS kernel module as early as possible? Alternatively, are there other modules in Guix that are sometimes loaded early (maybe GPU drivers? I know that they are loaded early sometimes) which might be worth examining to understand how to go about it?

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.

Cheers,
Kaelyn

> 
> Thanks,
> 
> Morgan

Re: Status of ZFS support on Guix

[Ian Eure]

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].

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.

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

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