Hi,
On Tuesday, October 1st, 2024 at 1:23 PM, Morgan Arnold <morgan.arn...@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
