[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of ZFS support on Guix
From: |
Ian Eure |
Subject: |
Re: Status of ZFS support on Guix |
Date: |
Wed, 02 Oct 2024 17:18:50 -0700 |
User-agent: |
mu4e 1.8.13; emacs 28.2 |
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