[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A new paradigm for modifying operating system declarations
From: |
raid5atemyhomework |
Subject: |
Re: A new paradigm for modifying operating system declarations |
Date: |
Tue, 05 Jan 2021 10:01:04 +0000 |
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