Do we need to have rc.d/zfs kldload zfs as-needed in case someone's implicitly relying on this and running ZFS strictly for data pools rather than root? I think that would make this a non-event for 98%+ of our users if it wasn't already.

It was determined that zpool status and zfs list are not the commands used in the original context. Instead:

zpool upgrade -v
and:
zfs upgrade -v

An upstream change has been proposed:

https://github.com/openzfs/zfs/pull/18694/changes/3c971d9b219ac135767802c5c014fdd687dacf5b

Because, unlike FreeBSD, the Linux zpool upgrade -v does depends on some kernel module results ( /sys/module/zfs/features.pool ), that part of the proposed change is FreeBSD OS specific and Linux would still load its kernel module.

Linux does not use kernel module results for zfs upgrade -v and, so, that part is more general.

In D57657#1323400, @markmi_dsl-only.net wrote:

It was determined that zpool status and zfs list are not the commands used in the original context. Instead:

zpool upgrade -v
and:
zfs upgrade -v

An upstream change has been proposed:

https://github.com/openzfs/zfs/pull/18694/changes/3c971d9b219ac135767802c5c014fdd687dacf5b

Because, unlike FreeBSD, the Linux zpool upgrade -v does depends on some kernel module results ( /sys/module/zfs/features.pool ), that part of the proposed change is FreeBSD OS specific and Linux would still load its kernel module.

Linux does not use kernel module results for zfs upgrade -v and, so, that part is more general.

Either way, running zpool status should ALSO not load zfs.ko automatically.

In D57657#1321988, @kevans wrote:

Do we need to have rc.d/zfs kldload zfs as-needed in case someone's implicitly relying on this and running ZFS strictly for data pools rather than root? I think that would make this a non-event for 98%+ of our users if it wasn't already.

Need to do more tests to confirm, but it looks like the required_modules="zfs" in rc.d/zpool that it should get taken care of that way