From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id dlg5MhE59F+9awAA0tVLHw (envelope-from ) for ; Tue, 05 Jan 2021 10:01:53 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id mDN/LRE59F9rFwAAB5/wlQ (envelope-from ) for ; Tue, 05 Jan 2021 10:01:53 +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 7076E9402A0 for ; Tue, 5 Jan 2021 10:01:53 +0000 (UTC) Received: from localhost ([::1]:39660 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwjA0-0000Wb-6g for larch@yhetil.org; Tue, 05 Jan 2021 05:01:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwj9j-0000U2-A5 for guix-devel@gnu.org; Tue, 05 Jan 2021 05:01:35 -0500 Received: from mail-02.mail-europe.com ([51.89.119.103]:46718) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwj9f-0006Ly-MS for guix-devel@gnu.org; Tue, 05 Jan 2021 05:01:34 -0500 Date: Tue, 05 Jan 2021 10:01:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1609840871; bh=/3qwTnwPnTnePk+YOehigtB9mlVVEZAGbnVK0LkI9LM=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=s0EIaq4bxbnWJojilCNNRxE+6+9CRuA2TMx1axFxPyezNN4PqcksaUcwWdJbmNDrU 3ym0IfqPSM87CCcJlDuF5X51l63a13IBR3fl4KXaLqAAoxmiVmBscMJohNV6J1t6ym 2DwQvYWBkFSAiXrNJdUmWHN0mumaGJwtrcq3OjjQ= To: Carlo Zancanaro From: raid5atemyhomework Subject: Re: A new paradigm for modifying operating system declarations Message-ID: In-Reply-To: <87o8i39ak0.fsf@zancanaro.id.au> References: <87b59430-b53e-47ec-32d5-abbd3be42ce7@gmail.com> <87o8i39ak0.fsf@zancanaro.id.au> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=51.89.119.103; envelope-from=raid5atemyhomework@protonmail.com; helo=mail-02.mail-europe.com 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, SPF_HELO_NONE=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 Cc: "guix-devel@gnu.org" Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -3.04 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail header.b=s0EIaq4b; 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: 7076E9402A0 X-Spam-Score: -3.04 X-Migadu-Scanner: scn1.migadu.com X-TUID: XPzO7VqmSSz7 Hi Carlo, > In principle, I think this should all be handled by a service. > Services have a number of extension points where they can impact > the operating system being declared, by extending other services. > For example, adding a package into the global profile is done by > extending profile-service-type (which you can find in > gnu/services.scm). Adding a shepherd service to manage a process > is done by extending shepherd-root-service-type (in > gnu/services/shepherd.scm). > > This is how many services work. As an example, sddm-service-type > extends services to: (a) start a process on the running system, > (b) put files in /etc, (c) install some pam services, (d) add an > account on the system, and (e) install packages in the global > profile. > > As far as I can tell, the only thing missing for a > zfs-service-type to do what you want is that services can't > currently add new kernel modules (although they can load them via > kernel-module-loader-service-type). I may have missed a mechanism > for this, though. If we added the ability to do this, then it > should be possible to add zfs support by adding a single (service > zfs-service-type) to your services list. > > The approach of using services in this way has some advantages > which are outlined in a blog post from 2015[1]. For me the most > compelling advantage is that an zfs-service-type is more > restricted in what it can do, and must be more explicit. An > install-zfs procedure has free-reign over the entire > operating-system definition that it gets passed, which makes it > harder to reason about the composition of such procedures. Thank you for this, this is certainly something I would prefer to simplify = installing ZFS onto the operating system! I wasn't aware of the `profile-s= ervice-type`. I already have a `zfs-loader-service-type` here: https://issues.guix.gnu.or= g/45643#1 These are the things that the service has to do: * Get a kernel module compiled and added to the set of kernel modules that = can be loaded. * From what I understand of what you describe, this is non-existent for n= ow. How difficult would this be? Where do I start in getting this impleme= nted? * Load the kernel module. * Execute `zpool import -a -l` to import all ZFS pools, mount those that ar= e marked automount, and request for passwords if encrypted. * This has to occur after kernel module loading `(requirements '(kernel-m= odule-loader))`. * This has to occur before `file-systems`. In https://issues.guix.gnu.or= g/45643#2 I made `file-systems` into a target similar to `user-processes` (= i.e. it has a `file-systems-service-type` that can be extended with a list = of `requirements`, just like `user-procesess`) so that the `zpool import` s= ervice is a dependency of `file-systems`. * This is needed in order to get `/home` on ZFS, since `user-homes` can= race with this and populate `/home` before the ZFS module is loaded and th= e pools are imported, and ZFS will refuse to mount on top of a non-empty di= rectory. We need to make sure that ZFS gets to mount before `file-systems`= is started, since `file-systems` will also trigger `user-homes`. * Add the compiled ZFS on the profile. * Add ZFS module configuration into an `/etc/modprobe.d/zfs.conf`. The above would not get us `/` on ZFS, since we would need to have the ZFS = kernel module inside the `initrd`, have the kernel load the module before l= aunch, probably import pools early, and then look for root pool and so on. = The problem is getting the ZFS configuration inside the `initrd` as well, = in addition to the userspace tools. So, here's a sketch: ```scheme (operating-system (kernel linux-libre-5.4) ;... (services (cons* (service zfs-service-type (zfs-configuration ; we need to compile for a specific kernel, the alternative = here ; would be (operating-system this-operating-system) but the = below ; is a good bit shorter, despite the DRY violation... (kernel linux-libre-5.4) (options '(("zfs_arc_max" 5000000000))))) ;... %desktop-services)) #;...) ``` Thanks raid5atemyhomework