RHEL 9.1 - openZFS (Error after fresh-install)

[ArchMatt-GraveKeeper]

Yo everybody :) i hope there is somebody who will solved my problem after fresh install of openzfs
https://openzfs.github.io/openzfs-docs/Getting%20Started/RHEL-based%20distro/index.html#

as root user i applied these commands:

dnf install https://zfsonlinux.org/epel/zfs-release-2-2$(rpm --eval "%{dist}").noarch.rpm
subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

dnf install https://dl.fedoraproject.org/pub/epel/epel-next-release-latest-9.noarch.rpm

dnf install -y epel-release

dnf install -y kernel-devel

dnf install -y zfs

after these commands i want to create raidz pool of my sda,sdb,sdc,sdd disks

zpool create afterlife raidz1 sda sdb sdc sdd -f

but i got error which is:

The ZFS modules are not loaded.
Try running '/sbin/modprobe zfs' as root to load them.

so i type it the problem to the terminal then:

/sbin/modprobe zfs
modprobe: FATAL: Module zfs not found in directory /lib/modules/5.14.0-162.12.1.el9_1.x86_64

yea i made it research but didn't find nothing to be helpful :)

Thanks for advice's :)

[quartsize]

The version of your kernel suggests to me that you are not using CentOS Stream 9, in which case I don't think you're supposed to be using EPEL Next, just regular EPEL by itself. I don't see a newer DKMS in Next currently, but that could result in some weirdness.

Your steps look like a DKMS install -- did DKMS succeed in building kernel modules? What do dkms status and rpm -qa name=\*zfs\* say?

[ArchMatt-GraveKeeper]

You can temporarily disable that with mount -o remount,exec /var and try the DKMS install again, but you'd have this problem every time you update your kernel or ZFS. On hosts where I have a noexec /var, I have a separate /var/lib/dkms without noexec. Alternatively, you could avoid having to provide DKMS a place to build by using the kABI-tracking kmods instead of DKMS.

so best option is to create new mount point as /var/lib/dkms without noexec and then dkms is usable ? I tried before kABI but also same problem.

[quartsize]

I just about always use kmods for ZFS, so I can only speak from having had this experience with a different, non-ZFS package that only has the DKMS option, but a separate /var/lib/dkms mount-point without noexec is how I resolved it, yes. Simpler would be to remove noexec from /var, so you do not get bitten in the future by other software that assumes /var will be mounted exec. Likewise with /tmp: one can spend a silly amount of time trying to figure out why some vendor-provided program isn't running the way the vendor says it should, only to discover it's because they were expecting to be able to extract into and run in /tmp. Mounting /var noexec is an unusual configuration, and may continue to cause you trouble following documentation.

But if you're committed (or required) to do that, and to using DKMS instead of kmods, then you need a work-around. I shared the one I've used; supposedly DKMS can also be configured (in /etc/dkms/framework.conf) to do the compilation elsewhere, so you could change that to a directory that is not on a noexec filesystem, but I've never tried that.

[ArchMatt-GraveKeeper]

I just about always use kmods for ZFS, so I can only speak from having had this experience with a different, non-ZFS package that only has the DKMS option, but a separate /var/lib/dkms mount-point without noexec is how I resolved it, yes. Simpler would be to remove noexec from /var, so you do not get bitten in the future by other software that assumes /var will be mounted exec. Likewise with /tmp: one can spend a silly amount of time trying to figure out why some vendor-provided program isn't running the way the vendor says it should, only to discover it's because they were expecting to be able to extract into and run in /tmp. Mounting /var noexec is an unusual configuration, and may continue to cause you trouble following documentation.

But if you're committed (or required) to do that, and to using DKMS instead of kmods, then you need a work-around. I shared the one I've used; supposedly DKMS can also be configured (in /etc/dkms/framework.conf) to do the compilation elsewhere, so you could change that to a directory that is not on a noexec filesystem, but I've never tried that.

sorry for waiting i didnt have time for now, but results are these:
After removing noexec on /var also /tmp to exec even to nothing i got the result move forward looks like:

/sbin/modprobe zfs
modprobe: FATAL: Module zfs not found in directory /lib/modules/5.14.0-162.12.1.el9_1.x86_64

i search for the destiny which modprobe says and the modules are here, they are visible.

[root@rhel modules]# cd 5.14.0-162.12.1.el9_1.x86_64
[root@rhel 5.14.0-162.12.1.el9_1.x86_64]# ls
System.map config modules.alias modules.block modules.builtin.alias.bin modules.builtin.modinfo modules.dep.bin modules.drm modules.networking modules.softdep modules.symbols.bin symvers.gz updates vmlinuz build kernel modules.alias.bin modules.builtin modules.builtin.bin modules.dep modules.devname modules.modesetting modules.order modules.symbols source systemtap vdso weak-updates

[quartsize]

After removing noexec on /var also /tmp to exec even to nothing

Such a change made to fstab does not take effect until the filesystem is remounted -- to do that without rebooting, mount -o remount,exec /var. You would then need to re-run the dkms install zfs/2.1.9 and confirm that you are no longer getting the

Warning: The pre_build script is not executable.

message and that dkms status says the modules are installed. What you've listed at the end of your message does not show the ZFS modules. Kernel modules themselves usually end with .ko or .ko.xz, and the one that modprobe is saying is not found has the basename zfs. There is no zfs in what you listed.

[ArchMatt-GraveKeeper]

Asnwer inside https://github.com/openzfs/zfs/issues/14447