precompiled kmod packages unavailable for kernel 4.18.0-372.16.1 #35
Assignees
Labels
bug
Something isn't working
Comments
|
Hi @michaelbarkdoll You can monitor the status page for when we have kmod packages compiled for RHEL8 kernel |
|
Any update on this issue? |
|
Release testing completed successfully, it should be available tomorrow around 9am (UTC -0800). |
|
I don't see a release for the 515 driver branch. |
|
I see the kmod package for |
|
@michaelbarkdoll please verify if it is showing up for you or not. |
|
Still trying to figure out exactly where it is messing up: |
|
Debating trying: |
|
This is the latest kernel I see from
Are you using the "vanilla" RHEL 8 kernel or on something like EUS ? Can you please share output from and RPM info from installed |
|
I'm using Rocky Linux 8 which this has worked on in the past. |
|
Ummm okay that didn't narrow it down, you are still on Yeah there is a difference between available kernels for vs |
|
Odd, thanks for catching that. Not sure why it doesn't show on my machine (the 4.18.0-372.16.1.el8_6.0.1). Looks like this is a Rocky Linux issue in this case. |
|
Ohhhh, okay now I understand the discrepancy. The And yes, it seems that Rocky Linux has a kernel version ahead of RHEL. Unfortunately, we only officially support RHEL kernels for this precompiled kmod project. I think the workaround for now, would be to upgrade your kernel to and then should be able to install the latest precompiled kmod |
|
Thanks, yes that works. |
|
Hi folks, Just wanted to quickly jump in related to this issue. Current Rocky Linux kernel is not ahead of RHEL, but the
I'm not sure if there is a good way to make this work with kmods. Thankfully though we do keep all published artifacts so users can generally use the first released version using the Thanks, |
|
Okay, great to hear, glad that worked! For future reference, you can get some debug output from the plugin |
|
I realize the issue is much larger, so I don't want to distract too much from your efforts there so ignore this if needed. However, I wanted to note the following command Looks like a dependency issue to me, which seems to be expected. On a separate machine, I'm trying to get nvidia-smi working with a prior kernel as well to avoid the issue. It appears I tried to versionlock the old kernel prior to the install: Sorry, just have one particular end-user that had their machine off for the last few nvidia-driver releases and they don't have a kernel they can boot to do some machine learning programming. Any tips are appreciated. |
|
|
Just a personal update on the issue I was facing.. I had a typo in an /etc/modprobe.d/nvidia-gpu-performance.conf file for enabling performance counters that was preventing the nvidia driver from working. Fixing the typo allowed things to work as they previously were with a newer kernel. |
|
Okay please let me know if there are any remaining issues. Otherwise keeping this issue closed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Not sure why, but this one also appears to be delayed. I had previously updated the GPG key:
The text was updated successfully, but these errors were encountered: