Future development of archzfs

[johnramsden]

There have been no new packages in months, even for the lts. Should people look for alternative solutions, or is something holding back a release?

[fryfrog]

I was just coming here to ask if @minextu was on a long vacation. Might be time to try the aur/zfs-dkms package again. :|

[jrudess]

Yes, at this point, unless someone has the bandwidth to fork this repo and take over ownership, I would consider it done.

[n0xena]

well - building the packages works smoothly
currently there seems an issue with fakeroot or something like this as the building for 6.10.5 works but the final packaging fails with some weird depmod related issue which also fails for LTS - so it's unrelated to 6.10.x but rather to something in the toolchain that got pushed along with 6.10.5 - have a look at #542 (comment)
so it's not so much a problem of using this repo to build the packages your own - currently just the automated buildbot doesn't work - but that was already the case several times in the past and at least until now the maintainer usually fixed it rather fast
I wouldn't call this repo dead - as pretty much all arch source refer to it - even the wiki just links here with no information how to build a pkg from source your own - which is all this repo here does: a few shell scripts to build complete pkgs so one can use pacman to keep them consistent
you also could go yolo and just run the usual
./configure
make
make install
but this will likely fail according to what I understand from the scripts as they also use autogen and quite a lot of configure options
so - if at all - it's not this repo which may require a takeover or for - but rather the archwiki to get extended with a section on how to build the packages "by hand" and maybe even without clean-chroot or such

[jbrodriguez]

i've also gone the linux-lts route, which openzfs will very likely support without major issues

as for bulding zfs-linux-lts, in addition to using this repo, i've also found some other ways, including the one i settled for: a docker to build them (https://jbrio.net/posts/5-ways-archlinux-zfs/)

but, hopefully minextu can get back in the game, maybe he's no longer into archlinux or openzfs, maybe he has no bandwidth for this or has other life priorities 🤷‍♂️

[soi1uhtgnei2urtonwe4u]

There have been no new packages in months, even for the lts. Should people look for alternative solutions, or is something holding back a release?

but, hopefully minextu can get back in the game, maybe he's no longer into archlinux or openzfs, maybe he has no bandwidth for this or has other life priorities

v2.2.5 came out on the 6th, that's more than 2 weeks now. AFAIK nothing is holding the release back (the recent kmod issue looks fixed now too (commit reverted)). No v2.2.5 release for lts could mean the maintainer was afk for the usual holiday length of 10-14 days (no commits indeed in that time). The alternative solution would be to use the AUR.

@minextu Did no commits for 10 days, but then has been doing every day commits from 19.08 to 22.08 into a private repo again. If he no longer maintains then he should mention it.

I think he was afk a bit and I expect the 2.2.5 release within the next days/week.
PS: Yesterday Linux 6.10 compat was pushed, but v2.2.5 officially supports only Linux 6.9.

[rearden888]

I hope not. I think the framework for this works well, it just needs someone to continue shepherding it as versions update. Not sure if @minextu had other requirements going on, but maybe they'd be willing to add other committers to the repository to help out if they aren't available?

[ArnCo]

I have proposed to help multiple times here... I will probably switch back to the AUR if this repo dies.

[rearden888]

I'm hoping to move the conversation on the state of this project and possible avenues forward to this topic, vice in the current PR for OepnZFS 2.2.6. If we were to want to actually fork this, it's probably important to note that the archzfs.com domain would definitely not come along. We'd definitely need to ask to mark the project orphaned per here from the Arch Wiki. Once it's marked Orphan, another AUR user can ask to adopt it and thereby upload a new PKGBUILD. The Arch Wiki Page zfs will need to be updated, along with the definition for the archzfs user repository entry here .

Finally, the infrastructure would need to be updated. Now in this case, we're talking about forking on github, updating the package signing key, ensuring it's distributed and linked, starting an alternative CI server, as well as seed mirror for the repository.

Anyway, I think it's worth seeing if @minextu is still wiling to potentially bring on a subset of active users as maintainers to help speed up updates. I think it's worth waiting a few more days to get some response.

[fryfrog]

I actually emailed @minextu at the address I found via (I think?) the AUR, but haven't gotten a reply. :(

This isn't an AUR package, so really "forking" it would just be cloning the repo and getting it all setup and working again and then updating all the wiki details. Maybe waiting for archzfs.com domain to expire and not renew?

[rearden888]

I actually emailed @minextu at the address I found via (I think?) the AUR, but haven't gotten a reply. :(
So have I, haven't heard anything, either.

This isn't an AUR package, so really "forking" it would just be cloning the repo and getting it all setup and working again and then updating all the wiki details. Maybe waiting for archzfs.com domain to expire and not renew?

I certainly agree that I think most people access this through the unofficial repo. There is a AUR PKGBUILD though, so it's probably worth keeping it updated. It appears to mostly be a matter of changing version numbers.

We could certainly also wait for the archzfs.com domain to expire, but who knows if it's on auto renewals or something similar. Also, it doesn't expire until March of 2025, and I think most people would like to see some resolution this before that.

[fryfrog]

Are you talking about aur/zfs-dkms for example? That is a different package from archzfs's package. If you're not, what are you talking about?

And to be clear, I mean roughly fork it now and then if the domain expires some time in the future, take it over to help everyone who doesn't know it changes. I wouldn't hold a fork off for the domain. Could maybe even get archzfs.org or net or something if available. :)

[endreszabo]

Fortunately, I asked for delegation of kernels.archzfs.com so I can change the records for that anytime. Sadly, it is not the case for the apex archzfs.com itself of course. I can still "publish" the dependant kernel packages under kernels.archzfs.com. Or any other domains we may come up with later on.

…

On Mon, Sep 09, 2024 at 21:00:46-0700, Donald Webster wrote: Are you talking about [aur/zfs-dkms](https://aur.archlinux.org/packages/zfs-dkms) for example? That is a different package from archzfs's package. If you're not, what are you talking about? And to be clear, I mean roughly fork it *now* and then if the domain expires some time in the future, take it over to help everyone who doesn't know it changes. I wouldn't hold a fork off for the domain. Could maybe even get archzfs.org or net or something if available. :) -- Reply to this email directly or view it on GitHub: #545 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[rearden888]

Are you talking about aur/zfs-dkms for example? That is a different package from archzfs's package. If you're not, what are you talking about?

And to be clear, I mean roughly fork it now and then if the domain expires some time in the future, take it over to help everyone who doesn't know it changes. I wouldn't hold a fork off for the domain. Could maybe even get archzfs.org or net or something if available. :)

While I don't think it's used much, there is a PKGBUILD listed and served under the zfs-linux package in the AUR here Probably not the biggest deal to change, but it is listed there.

Also, yes, I understand this project is intended to be used as a user Pacman repository, which is what archzfs-ci builds and deploys.

[rearden888]

Fortunately, I asked for delegation of kernels.archzfs.com so I can change the records for that anytime. Sadly, it is not the case for the apex archzfs.com itself of course. I can still "publish" the dependant kernel packages under kernels.archzfs.com. Or any other domains we may come up with later on.
…
On Mon, Sep 09, 2024 at 21:00:46-0700, Donald Webster wrote: Are you talking about aur/zfs-dkms for example? That is a different package from archzfs's package. If you're not, what are you talking about? And to be clear, I mean roughly fork it now and then if the domain expires some time in the future, take it over to help everyone who doesn't know it changes. I wouldn't hold a fork off for the domain. Could maybe even get archzfs.org or net or something if available. :) -- Reply to this email directly or view it on GitHub: #545 (comment) You are receiving this because you are subscribed to this thread. Message ID: @.***>

I personally feel bad forking this without at least some answer from @minextu If you have already discussed and achieved delegation on subdomain from him, do you have any better way to get ahold of him? I've only rarely received responses.

[aereaux]

Are you talking about aur/zfs-dkms for example? That is a different package from archzfs's package. If you're not, what are you talking about?
And to be clear, I mean roughly fork it now and then if the domain expires some time in the future, take it over to help everyone who doesn't know it changes. I wouldn't hold a fork off for the domain. Could maybe even get archzfs.org or net or something if available. :)

While I don't think it's used much, there is a PKGBUILD listed and served under the zfs-linux package in the AUR here Probably not the biggest deal to change, but it is listed there.

Also, yes, I understand this project is intended to be used as a user Pacman repository, which is what archzfs-ci builds and deploys.

Just chiming in to say that I do use the PKGBUILD for zfs-linux-lts. I have been manually updating the versions when linux-lts gets updated, and this project provides value for me for the tests that are run to validate each version.

[endreszabo]

missing the hooks to allow unlocking an encrypted root pool via ssh

As a side note, let me introduce you guys to the excellent zfsbootmenu project, which also supports remote unlocking via SSH and has many, many more ZFS features while still being a bootloader. I use this to remote-unlock my bare-metal headless server running at Hetzner.

[lightdot]

@ArnCo I see that this hook is a part of the zfs-utils package in AUR. I'm not familiar with its usage, what changes are needed for the zfs-linux package in AUR?

[n0xena]

@endreszabo would be cool if the one responsible for publishing the releases could include the versions of zfs and supported linux kernels - and think about versioning, as the 2.3.0 release suggest that it uses zfs 2.3.0, which isn't released yet and the text doesn't mention any zfs or kernel version

[stevleibelt]

Other topic,

could @johnramsden maybe rename this issue to something like "future development of archzfs"?
This is more a marketing move unleashed from a person who is bad in marketing :-D.

[kerberizer]

could @johnramsden maybe rename this issue to something like "future development of archzfs"? This is more a marketing move unleashed from a person who is bad in marketing :-D.

I've been thinking about converting this to a discussion. Maybe a general discussion topic about ArchZFS development.

Thoughts? Objections?

Meanwhile, I must apologize for being so slow with archzfs/archzfs-keyring#1, but it isn't terribly critical right now and I'd prefer to err on the side of caution with it (and time has been tight recently).

[Soulsuke]

@kerberizer I'd say make it a discussion and maybe write somewhere we're in the middle of a little overhaul? Like on the main page and/or the wiki. I'd also close issues like #543 adding a ling to the discussion

Also... Thanks for your work on the keyring, and for kickstarting back this project to life :p

[johnramsden]

could @johnramsden maybe rename this issue to something like "future development of archzfs"? This is more a marketing move unleashed from a person who is bad in marketing :-D.

I've been thinking about converting this to a discussion. Maybe a general discussion topic about ArchZFS development.

Thoughts? Objections?

Meanwhile, I must apologize for being so slow with archzfs/archzfs-keyring#1, but it isn't terribly critical right now and I'd prefer to err on the side of caution with it (and time has been tight recently).

There was some discussion that we should hold off before "advertising" that the repository is ready which is why I did not update the wiki. If the consensus is we should notify of the experimental repo I can update

[rearden888]

could @johnramsden maybe rename this issue to something like "future development of archzfs"? This is more a marketing move unleashed from a person who is bad in marketing :-D.

I've been thinking about converting this to a discussion. Maybe a general discussion topic about ArchZFS development.

Thoughts? Objections?

Meanwhile, I must apologize for being so slow with archzfs/archzfs-keyring#1, but it isn't terribly critical right now and I'd prefer to err on the side of caution with it (and time has been tight recently).

I definitely think we should convert/move this to a discussion. That's certainly more appropriate for what is being discussed.

[johnramsden]

Converted to discussion.

The experimental repository has been available for a few weeks, is it time to advertise it as ready - at least by putting updated information in Unofficial user repositories#archzfs - noting that it is ready for testing with a warning that it is still experimental? I personally have only been using the LTS, i'm not sure what the status of the stable kernel is (it was previous discussion of instability) or if we should only recommend LTS?

[SebastianS90]

I would like to repeat my concerns from here.

It looks like the build process fetches the latest linux package from the official repository and attempts to build the zfs version configured in this project against it. So when Arch publishes Linux 6.12, the CI will attempt to build against it.

Afaik, it might be possible that the compilation succeeds, but when actually using zfs 2.2.6 together with the 6.12 kernel, it corrupts the pool. This would be the worst-case scenario and we should make sure that users are aware that they must not blindly update to a new kernel version. They manually have to check release notes of zfs for the supported kernel versions. This strong note must be present in the wiki when adding the new archzfs repository, otherwise big trouble will eventually happen.

For the long term, a stable repository would be preferable where we configure the supported kernel version range in conf.sh. Then the build could just skip kernels that are out of the officially supported range.

[predmijat]

Any manual check will result in corrupted pools at some point.

[johnramsden]

Sounds like if there is concern for corruption it might be a mistake even to update it as experimental

[rearden888]

I will say this, the old Buildbot process would do exactly this until the upstream ZFS project put an explicit version block in place. So, many times, we'd build and install (at least I would because I didn't explicitly check) minor kernel version numbers that eventually became unsupported (I think it was in the 6.10 line, we got to 6.10.5ish before OpenZFS explicitly listed 6.10 as unsupported). Not saying this is a GOOD thing, just saying it definitely happened in the past.

[johnramsden]

Would it make sense to modify the pkgbuild to explicitly only allow supported kernels?

[Soulsuke]

Right now it builds zfs 2.2.6 on kernel 6.11.x, although there shouldn't be many breakages it should be pointed out 6.11 isn't officially supported... I'd say recommend LTS until 2.3 is out (hopefully it shouldn't be long now)

[n0xena]

Currently the further development of ZFS releaes is a bit unclear to me: Looking at openzfs/zfs#16675 it seems that we will get at least a 2.3.0-RC3 as next - but but this doesn't give any information about possible additional releases on the 2.2.x or even 2.1.x branches - as it happened with 2.1.15 which was released between 2.2.3 and 2.2.4.
Maybe a coordination with upstream ZFS is a good idea to figure out: Are 2.1.x and 2.2.x are stale and will 2.3.0 the next proper release - or are there more releases for 2.1.x or 2.2.x planed/to be expected?
And: Can we expect 6.12 support soon?
If ZFS keeps its current pace being at least one minor version late LTS should be the recommended one with any combination of newer kernel clearly marked as unstable or something similar.
As for 2.2.6 on 6.11: Works fine so far for me - yet it's a not official suppoted config.
As for 2.3.0-RC2 on 6.11: It "works" - but as I only test it in a VM I can't say anything about performance or stability.

[LunarLambda]

I think either preventing people from updating their mainline kernels by means of version requirements on the package(s) or even just restricting the provided modules to LTS kernels are both totally fine policies to enforce on the repo. Nobody is helped by being given access to untested, not officially supported module builds.

These policies could easily be weakened or changed later if communication with upstream ZFS brings additional support or clarity to the matter, but until then it would be counterproductive if not worse to try and force mainline builds anyway.

[rearden888]

I think the appropriate way to handle this it to only explicitly state and support linux-lts as being stable. I think we should continue the "Live Dangerously" path for the vanilla Arch Kernel, but state that there can/will be breakages or put the onus on the user to only update mainline when they are sure OpenZFS supports the Arch kernel version. This would need to be communicated to users both in the Arch Wiki listing of the user repository, as well as on the archzfs web page/wiki.

[Soulsuke]

I don't think shipping zfs packages that may target an unsupported kernel is a good idea... Besides, using openzfs on non-lts kernel wasn't really a dangerous thing outside of a few rare scenarios, this would be a whole new level of "dangerous", more akin to "don't trust this repo at all"...

Imho the vanilla kernel should be targeted as long as it's supported by an official openzfs release. It does mean people may be stuck with an older kernel for a while, but it's far less dangerous than shipping an unsupported module which may break the system/pool for good.

[lightdot]

I also suggest:

the stable repo, with zfs-linux-lts, zfs-linux, zfs-linux-zen, zfs-linux-hardened, but only built and updated for kernels officially marked as compatible with the latest stable ZFS release (currently, linux 6.10.10 would be used for ZFS 2.2.6, not linux 6.11.x).

zfs-dkms and zfs-utils would be in stable and experimental.

So the experimental repo could stay as is, building the latest and letting users occasionally nuke their... er... test the latest developments, possibly providing the upstream with bug reports, fixes and flame wars.

Optionally, an archzfs-release package could install the repo config file(s) in /etc/pacman.d.

[n0xena]

is it possible to use said archzfs-release package to also deal with the key and local signing or is this something the user still has to do manual?