From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id GAr3DmPK/WZHWQEAe85BDQ:P1 (envelope-from ) for ; Wed, 02 Oct 2024 22:34:11 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id GAr3DmPK/WZHWQEAe85BDQ (envelope-from ) for ; Thu, 03 Oct 2024 00:34:11 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=BTqXPIxA; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1727908451; a=rsa-sha256; cv=none; b=ECt++Mh6Yk1zjenN/tVkHk71jgCtgUh6UjhzXj/Xa2ys3qCxPQz2kxlVcxN0EgbjjEwOog su9DFSHfootg36rAYXSXjZ0a0jap4gEqQQV3Uky7BYvOAMY+BOSa4eFciWqbF5iyD61l7s KnMiS9i00HiJh5mxBg6lrHPSRGeJqyU/QoUwqKMgfmp/KwhDI/qOwmjZf8dAgthHjloI2V Ls0ZspxYn9eN2lQ9c2E4QghaHyuiXtgQHPB3EnuG+AAg6qQUZMj+rhWRGF9dOmyIYlfaYQ E49+0aECAfVgnbF356cDZ1lXb9AQ1GAEjDM8R0vZJq/AerbWS5pTIew24klD/A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=BTqXPIxA; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1727908451; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=GGq2q2ojgIkip7bpOdbKasnBSgqJHYfvqrNFWl6ZJB4=; b=Offnk8jy8F8ZPm7YMAkcIlcRsVNvUEmPA8gBEvJuT5L5DMoN6KUzC6HNYRiLMsJ1nBzYr4 8en8uZsrHBpT5TVPysVH6bWIyT/kyv+74eqJPLD7rJiqHIwWIsoRiRgspb6W8wmD4B1zhQ ZXNWatJbnd57yTJmR4H2GPwpVVm+mV0umyGS3OF7gAeDxnzTkfqwpEnFeGw5jQTUs1Zary EHeQxPaxdZwKL3WMbrow2gODptx9ev/cp5SgJkqYcEJD+v2yMhB5yrNmK1v7VH4ZOgJGAw qtjHp3clpyqwM5uWfqvG0/SHc5Smux5jqtRQN7YfJT+muusdYSKLDtxPo/2edw== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 13FC986BFC for ; Thu, 03 Oct 2024 00:34:10 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sw7V3-0002zF-Dx; Wed, 02 Oct 2024 18:07:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sw7V0-0002z5-2G for guix-devel@gnu.org; Wed, 02 Oct 2024 18:07:10 -0400 Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sw7Ux-0005K4-NK for guix-devel@gnu.org; Wed, 02 Oct 2024 18:07:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1727906824; x=1728166024; bh=GGq2q2ojgIkip7bpOdbKasnBSgqJHYfvqrNFWl6ZJB4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=BTqXPIxAoLQB0eiUlhCas8iiMWtkRdvK2/mkS2Usqsj8MDtY/K/jG/5405xVSPHYZ GxNWfLlG/c4ApkuMj0K53TQ/v6Lfwz6/FLR0bW7y2UaXzGXwFFGEi/D0Qa9N+liezB /D4MArLTtYY4nUkIXos8qU2F+vVwc5PgmI6VXcJg2Os+JjNSs/RuPaRFq1IJC/crI0 39CAKEHA0G8awu0t19jPITrqjqKEoVjSCtojtYSE6Oy38jfEnkslmbo0aGm992xfCE dSDGqiWbS4rmg43fp7viilQHvkbqwLzgbtSyg9wX6cRaJs44DykqAUHA1rZ3T/Y2Bd 13hLZgZRweaSQ== Date: Wed, 02 Oct 2024 22:07:00 +0000 To: Morgan Arnold From: Kaelyn Cc: "guix-devel@gnu.org" Subject: Re: Status of ZFS support on Guix Message-ID: In-Reply-To: <1Mf47p_itnKEwds_VcYBV9aLFb3hFNvpo7mAmlDX_F0ybwguolX_1BDAff46RZ1QDIDfvl1QsZkn_hWQj-g49y-VEYksiZvsq0r8-JblNYc=@proton.me> References: <1Mf47p_itnKEwds_VcYBV9aLFb3hFNvpo7mAmlDX_F0ybwguolX_1BDAff46RZ1QDIDfvl1QsZkn_hWQj-g49y-VEYksiZvsq0r8-JblNYc=@proton.me> Feedback-ID: 34709329:user:proton X-Pm-Message-ID: 86cd0747796311a64650f7622e4fa8a82fd3a82e MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.131; envelope-from=kaelyn.alexi@protonmail.com; helo=mail-40131.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -1.69 X-Spam-Score: -1.69 X-Migadu-Queue-Id: 13FC986BFC X-Migadu-Scanner: mx12.migadu.com X-TUID: LP2sK/2EDbIq Hi, On Tuesday, October 1st, 2024 at 1:23 PM, Morgan Arnold wrote: >=20 >=20 > I asked around on the IRC channel a while ago about the status of ZFS sup= port on Guix, and it was suggested that I ask here. I am aware of efforts m= ade in the past to bring some rudimentary ZFS support to Guix (namely, http= s://issues.guix.gnu.org/45692, which appears to be quite dead), but was won= dering if any new efforts have been considered. This is something which I w= ould be very open to contributing to, as the lack of ZFS support is current= ly 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 y= ears 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 i= nto a separate package and provides a helper function for creating a ZFS pa= ckage for a specific kernel package. 2) https://issues.guix.gnu.org/55231 which adds support for including out-o= f-tree kernel modules in the initrd. This isn't strictly related to ZFS oth= er than the documentation referencing ZFS in its example. The documentation= patch had later been updated to include a different example of an out-of-t= ree 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. >=20 > Based on the response to 45692, I would also like to know if there is opp= osition to adding support for Guix, be it for philosophical or legal reason= s. Assuming that no such opposition exists, 45692 seems to provide a very s= ubstantial chunk of the work which needs to be done for supporting ZFS on G= uix, in particular automatic loading of the ZFS kernel module and automatic= mounting of datasets. Ultimately, I would love to see support for `/' on Z= FS, but based on discussions around 45692, it seems like this would be quit= e a bit more effort, although I must admit that I don't really understand w= hy, 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 oth= er 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 valuabl= e in terms of understanding how to load the ZFS kernel module as early as p= ossible? Alternatively, are there other modules in Guix that are sometimes = loaded early (maybe GPU drivers? I know that they are loaded early sometime= s) 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 ha= ve a private channel which actually replaces much of the bootloader and ini= trd functionality (in part to support ZFS in the initrd using https://issue= s.guix.gnu.org/55231). In the past year, I actually took advantage of havin= g basically replicated much of the initrd functionality in my channel to cr= eate 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 n= eeds a lot of polish, but has been good enough that combined with a few oth= er 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 se= eming resistance to ZFS. Cheers, Kaelyn >=20 > Thanks, >=20 > Morgan