Development status?

[guyest]

Based on the stale pull request and lack of commits in this repo despite the owner being active on Github, it appears that sd-zfs is not being actively maintained. Is that correct?

This would be a shame because as I understand the current state of ZFS on root for linux, this is my only option for booting from a ZFS pool that is composed of a set of mirrored LUKS encrypted drives. If development has indeed stalled, please indicate that on the README so that users directed here (e.g. from the Arch Wiki) can easily reach that conclusion. If there is a different project that has superceded this one then you can point to that one. If there is no active development simply because everything is running swimmingly, then I suppose your indicate as such in response to this issue will document that.

[dasJ]

Yes, I am not actively maintaining this anymore as I'm not using it anymore. However, if there is a person that seems competent, I am willing to add them as a co-maintainer.

[dasJ]

If that person needs help for getting into the code, I can also help them

[guyest]

OK, thanks for clarifying. I am not aware of any other tool that fills this specific gap. It looks like mkinitcpio-systemd-tool may provide the infrastructure needed to implement a similar solution but it does not do so explicitly and it comes at what I see as unnecessary cost.

sd-zfs, on the other hand, solves a specific problem and appears to do so well based on my initial experience in a UEFI booted arch-vm. All indications are that it will also work for a similar use case I have booting from BIOS system with two encrypted drives. After I manage to get that going successfully and can verify that the sd-zfs and sd-zfs-shutdown hooks are not causing any other immediate issues, then I would consider coming aboard if you would have me. The codebase looks manageable enough that even though I don't have direct experience in this area, my personal investment, interest, and general facility with software development should be sufficient. All that I would want to avoid is unnecessarily re-inventing the wheel or investing undue effort developing a tool whose usefulness lifetime has a foreseeable end.

One of the things I would be most interested in arranging longer term is to have the pkg hosted on a community repo. This one may even make sense to bundle with archzfs if that host is amenable, but that may be out of scope. The main benefit here is better integration with pacman when installing to a new system from archiso. My current approach will be to embed aurutils along with archzfs in a custom archiso and install mkinitcpio-sd-zfs from the AUR with aursync. For something central to my initramfs build following each kernel upgrade, I would be more comfortable having an explicit local repo from the get-go.

[dasJ]

Let's see what will happen :)

[lnicola]

I just noticed that the AUR package is gone, did you remove it?