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-service-type`. I already have a `zfs-loader-service-type` here: https://issues.guix.gnu.org/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 now. How difficult would this be? Where do I start in getting this implemented? * Load the kernel module. * Execute `zpool import -a -l` to import all ZFS pools, mount those that are marked automount, and request for passwords if encrypted. * This has to occur after kernel module loading `(requirements '(kernel-module-loader))`. * This has to occur before `file-systems`. In https://issues.guix.gnu.org/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` service 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 the pools are imported, and ZFS will refuse to mount on top of a non-empty directory. 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 launch, 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
