Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rpm kmod build is too version-specific #16889

Open
clhedrick opened this issue Dec 19, 2024 · 2 comments
Open

rpm kmod build is too version-specific #16889

clhedrick opened this issue Dec 19, 2024 · 2 comments
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)

Comments

@clhedrick
Copy link

System information

Type Version/Name
Distribution Name RHEL
Distribution Version 9.5
Kernel Version 5.14.0-503.16.1.el9_5.x86_64
Architecture x64
OpenZFS Version 2.2.7

Describe the problem you're observing

I built kmod rpms following instructions in the web documentation. The build was on a system with kernel 5.14.0-503.16.1.el9_5.x86_64. I saved the rpm's in our repository for later use.

Yesterday I installed a system with kernel 5.14.0-503.16.1.el9_5.x86_64. zfs.ko and spl.ko installed in /lib/modules/5.14.0-503.16.1.el9_5.x86_64/extra/zfs, not the current kernel. Thus the system came up without ZFS

The whole point of kmod is that it is valid for the whole minor release, in this case 9.5. It should install in the current kernel. The current setup makes it difficult to automate installs. I was able to recover manually by copying zfs.ko and spl.ko to the right place and running depmod. But if I install on a system that doesn't have the right old kernel in /lib/modules, I conjecture that I wouldn't get those files anywhere.

Describe how to reproduce the problem

Include any warning/errors/backtraces from the system logs

@clhedrick clhedrick added the Type: Defect Incorrect behavior (e.g. crash, hang) label Dec 19, 2024
@n0xena
Copy link

n0xena commented Dec 21, 2024

either I have to get my eyes checked or you have to re-check this report - as I can't spot any issues
the versions of your post in order (done by not copy each at a time but just deleting everyting else from your post):
5.14.0-503.16.1.el9_5.x86_64
5.14.0-503.16.1.el9_5.x86_64
5.14.0-503.16.1.el9_5.x86_64
5.14.0-503.16.1.el9_5.x86_64
I can't spot any mismatch - please re-check on your end

@clhedrick
Copy link
Author

clhedrick commented Dec 21, 2024

sorry, I was looking at the system on which the rpm was originally built. It was built on a system running 16.1. The rpm wa installed on a system running 19.1, but it installed into the 16.1 /lib/modules, which was there because Redhat typically keeps several old kernels. So on a reboot ZFS didn't work.

I checked the rpm with rpm2cpio. zfs.ko and spl.ko were in /lib/modules/5.14.0-503.16.1.el9_5.x86_64. Unfortunately I think they need to go into a version-independent place and then get copied or symlinked into either the most recent kernel or all 9.5 kernels. Once it's put in the current or most recent kernel (I'm not sure which), Redhat will symlink it into new kernels as they are downloaded and installed, as long as they are consistent with the ABI of the new kernel.

I'm in the process of adding a script to my ansible setup that reads the rpm directly with rpm2cpio and puts the files into the most recent kernel. But that doesn't seem like something I should have to do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Defect Incorrect behavior (e.g. crash, hang)
Projects
None yet
Development

No branches or pull requests

2 participants