From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id CBK2G2bxIGDcGQAA0tVLHw (envelope-from ) for ; Mon, 08 Feb 2021 08:08:06 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id aKo1F2bxIGCmFQAAbx9fmQ (envelope-from ) for ; Mon, 08 Feb 2021 08:08:06 +0000 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 8787D9403D2 for ; Mon, 8 Feb 2021 08:08:05 +0000 (UTC) Received: from localhost ([::1]:38212 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l91aP-0005zV-3u for larch@yhetil.org; Mon, 08 Feb 2021 03:07:59 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:59848) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8zo0-0008Or-Q7 for guix-devel@gnu.org; Mon, 08 Feb 2021 01:13:52 -0500 Received: from mail-40137.protonmail.ch ([185.70.40.137]:28207) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8znx-00010N-RM for guix-devel@gnu.org; Mon, 08 Feb 2021 01:13:52 -0500 Date: Mon, 08 Feb 2021 06:13:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1612764826; bh=2vXroDlUlagnqe9NAjfasqK34yfMqJ2jd2ZzQobeUo8=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=vsKzgKExq3/+cZMUuNAnAUjVzpVf/bXfnl5fvJFafU0cVkGqt5TiuglcuZenzoZWg hOaaHX1Kwldpk6hWhlOEl2WSrFOyQ9ewMIKBjLO1ibXVCkAHQzb0tQD39W3/ijRPV6 XGayxq87TzyXCCCEKjApQWg5w0PUUy14gV4j0RHM= To: "guix-devel@gnu.org" From: raid5atemyhomework Subject: Re: ZFS on Guix Message-ID: In-Reply-To: References: =?us-ascii?Q?<=5F1CLe9QSGsoMlu5WxBMXm4CbFLM=5FM9iRG1XQF9GDsK0GP208jpngdymfix4tAfoLP94mhMTt-Tx6OP2xN=5Fn78Jhx5KQzkiqPpIci=5F44C9OI=3D@protonmail.com>_<87lfd698xq.fsf@zancanaro.id.au>__<5DEAAAD8-1D08-4489-9AEC-675618F8E388@zancanaro.id.au>____<07kwAFNpjhGFe7ArkjjAtRhr564wvMPGhHFyjGb=5FXdmmPNddKTmT9Swky1NbbUxHBC4xw3p-m=5F3JyW16Ql9J7PLyk6UdhCsA2cdkHehdti8=3D@protonmail.com>__?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.137; envelope-from=raid5atemyhomework@protonmail.com; helo=mail-40137.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_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: raid5atemyhomework Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -3.06 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail header.b=vsKzgKEx; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 8787D9403D2 X-Spam-Score: -3.06 X-Migadu-Scanner: scn1.migadu.com X-TUID: j8sXFpf1gLCS Hi guix-developers and users, Here are some notes I made about how to get `/` on ZFS, maybe someone else = can think about it. ------- Most importantly, it seems for this style we need to consider first `/boot` ***not*** on ZFS, and have `/` on ZFS. I presume grub has some way to read ZFS pools in order to get at the `/boot` if `/boot` is on ZFS, since `/`-on-ZFS for Ubuntu is able to put even `/boot` on ZFS, however note that even there the `/boot` is on a different pool from the `/`. When this works (*cough*) it should be possible to create a ZFS pool (with `mountpoint=3Dlegacy`) from a ZFS-enabled boot of Guix, then create a `configuration.scm` that we would then `sudo guix system init` onto a temporary mountpoint. I would strongly suggest putting `/boot` elsewhere though. Here are a bunch of things we need for `/` on ZFS: * ZFS module installing into `initrd`. * ZFS module loading while in `initrd` before the pivot to the "real" `/`. * ZFS `import` of the pool containing `/` mount. ## `initrd` module installation We need a facility to add modules to the `initrd` that are not part of the kernel. Currently `raw-initrd`/`base-initrd` will only get `.ko` files from the given `linux` package. We need to modify the `initrd` interface to add say a `#:module-packages` list of packages whose `.ko` files we will also add to the `initrd`. This translates to modifying `flat-linux-module-directory` in `gnu/system/linux-initrd.scm` to additionally accept a list of packages all of whose `.ko` and/or `.ko.gz` files will be added to the module directory. Then somewhere over in `raw-initrd` we would: (define kodir (flat-linux-module-directory linux linux-modules module-packages)) We also need an extensible service type that will eventually lead to adding new entries in the `#:module-packages`. We need a "root" `initrd` extensible service type that will construct the `= initrd` via the `operating-system-initrd` field. This service type will accept additional arguments to pass to the `initrd` function. Then the `initrd-kernel-loadable-module-service-type` would accept lists of package specifications, then provide a `#:module-packages` argument to the root `initrd` service type. Rough sketch: (define initrd-arguments-service-type (service-type #;...)) (define initrd-kernel-loadable-module-service-type (service-type (name 'initrd-kernel-loadable-module-service-type) (extensions (list (service-extension initrd-arguments-service-type (lambda (module-packages) (if (null? module-packages) '() (list #:module-packages module-packages))= )))) (compose concatenate) (extend append) (default-value '()))) ## `initrd` module explicit loading Normally modules are loaded "as needed" but ZFS needs to be explicitly load= ed. The `base-initrd` already accepts a list of `linux-modules` to load, we jus= t need some way to hook into adding `#:linux-modules`. This probably means modifying how `operating-system-initrd-file` in `(gnu system)` works (which would probably be needed by the `initrd-arguments-service-type` anyway). We could try hooking into the currently-deprecated `extra-modules` instead, here's a sketch: (define initrd-kernel-module-loader-service-type (service-type (name 'initrd-kernel-module-loader-service-type) (extensions (list (service-extension initrd-arguments-service-type (lambda (modules) (if (null? modules) '() (list #:extra-modules modules)))))) (compose concatenate) (extend append) (default-value '()))) ## `initrd` additional pre-mount actions Before a `/` on ZFS can be mounted, ZFS has to be told to scan for the ZFS pool containing the `/`. We could add yet another argument to `raw-initrd`/`base-initrd`, `#:premoun= t-actions`, a list of gexpressions. Then the `#:pre-mount` argument to `boot-system` would become something lik= e: #:pre-mount (lambda () (and #$@device-mapping-commands #$@premount-actions)) As usual a service type can be created which extends `initrd-arguments-serv= ice-type`. For root-on-ZFS specifically we would need to know the root pool and execut= e something like this: #~(begin (invoke/quiet #$(file-append zfs/static "/sbin/zpool") "-a" "-N" #$= root-pool)) Then, "normal" root specification would be done, with the root pool name gi= ven as the device name of the `/` mountpoint, and with the ZFS mountpoint set to `lega= cy`.