Bug 2012209

please attach /var/cache/akmods/nvidia/470.74-1-for-5.15.0-rust+.failed.log

(In reply to Sergio Basto from comment #1)
> please attach /var/cache/akmods/nvidia/470.74-1-for-5.15.0-rust+.failed.log

Those logs are already attached as "Akmod Nviidia Log"
Here is the link https://bugzilla-attachments.redhat.com/attachment.cgi?id=1830884

I don't think it's the purpose of akmod/dkms to be compiler gnostic. akmod will pick whatever is set from its environement with no respect to whatever is set from the developper env perspective.

The correct fix for this would be to somehow insert or "hardcode" the required compiler on kernel-devel. And there is no way around.

(In reply to Nicolas Chauvet (kwizart) from comment #3)
> I don't think it's the purpose of akmod/dkms to be compiler gnostic. akmod
> will pick whatever is set from its environement with no respect to whatever
> is set from the developper env perspective.
> 
> The correct fix for this would be to somehow insert or "hardcode" the
> required compiler on kernel-devel. And there is no way around.

I know, it's just that the error log isn't clear if the build fails because of the different compiler or something else entirely.
Also, I don't know about akmods but dkms kinda resets the environment variables to defaults before starting the build. So even changing the environment variables has no effect on a dkms build (there are some hacks I think, but personally haven't tried them).

(In reply to Nicolas Chauvet (kwizart) from comment #3)
> I don't think it's the purpose of akmod/dkms to be compiler gnostic. akmod
> will pick whatever is set from its environement with no respect to whatever
> is set from the developper env perspective.
> 
> The correct fix for this would be to somehow insert or "hardcode" the
> required compiler on kernel-devel. And there is no way around.

I know, it's just that the error log isn't clear if the build fails because of the different compiler or something else entirely.
Also, I don't know about akmods but dkms kinda resets the environment variables to defaults before starting the build. So even changing the environment variables has no effect on a dkms build (there are some hacks I think, but personally haven't tried them).

> akmods ... kinda resets the environment variables to defaults before starting the build. 
How comes ? How have you set the compiler in the first step ?

error: Package has no %description: kmod-nvidia-5.15.0-rust+

(In reply to Nicolas Chauvet (kwizart) from comment #6)
> > akmods ... kinda resets the environment variables to defaults before starting the build. 
> How comes ? How have you set the compiler in the first step ?

As I said, that's the case for dkms. I'm not really sure if akmods does the same thing or not.
Here is the thread about dkms with clang: https://github.com/dell/dkms/issues/124

1/ Can you try to build a kmod-nvidia directly (without using akmods ?)
See also https://rpmfusion.org/Packaging/KernelModules/Kmods2

2/ Error is that error: Package has no %description: kmod-nvidia-5.15.0-rust+

Can you attach the output of on your system ?
kmodtool --target x86_64 --repo rpmfusion --kmodname nvidia-kmod  --akmod --for-kernels 5.15.0-rust+

I was having similar issues and this is what I get when I run the mod tool command:

```
/usr/bin/kmodtool: line 200: 5.12.19-zen2+: syntax error: invalid arithmetic operator (error token is ".12.19-zen2+")
```

Seems like we have an issue with parsing your kernel name

Hello,

The shell script of rawhide kmodtool branch seems to work correctly.

As an attempt to fix locally this issue, maybe you should replace 
line 200 of /usr/bin/kmodtool (make a copy of this file before as 
root) from:

local kernel_uname_r_rel_plus_one=$(( kernel_uname_r_rel+1 ))

to these lines:

if $(echo "${kernel_uname_r_rel}" | grep -qE '^[0-9]+$') ; then
	kernel_uname_r_rel_plus_one=$(( kernel_uname_r_rel+1 ))
else
	kernel_uname_r_rel_plus_one=""
fi

It is also possible to comment line 200 of /usr/bin/kmodtool file then
just add after this line the replacement suggested above.
Note: the suggested replacement is taken from rawhide branch of kmodtool.

Any comment are welcome,

Cordially,


-- 
NVieville

@Nicolas
Basically this is a non-kabi kernel where kernel_uname_r_rel_plus_one doesn't need to be computed. Can we just whitelist the kernel from rhel that we know to support kABI for sure ? and stop computing the variable that aren't relevant for non-kabi cases ?


I think that's the way forward.

(In reply to Nicolas Chauvet (kwizart) from comment #13)
> @Nicolas
> Basically this is a non-kabi kernel where kernel_uname_r_rel_plus_one
> doesn't need to be computed. Can we just whitelist the kernel from rhel that
> we know to support kABI for sure ? and stop computing the variable that
> aren't relevant for non-kabi cases ?
> 
> 
> I think that's the way forward.

Hello Nicolas,

Thank you for your comment.
For the record, the proposed fix in comment #12 is already in rawhide (main 
branch) of kmodtool. 
See https://src.fedoraproject.org/rpms/kmodtool/c/4852d351abeb85341ec90af552ff7e9cb0fce4e2?branch=rawhide

I think that this commit (#4852d35) already does what you suggested, even
if the distinction between kABI vs non-kABI kernels is not made directly 
by the kmodtool shell script. Here we hit the difficulty of the separate 
computation of values between the shell script and the rpm instructions or
macros.

For the moment, I don't see how to implement correctly your suggestion: 
dealing with kABI vs non-kABI kernels at the shell script level. Have to 
think about it a while before any attempt. If you have any suggestion on 
this point, feel free to comment.

Cordially,


-- 
NVieville

This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

still need to be reviewed

*** This bug has been marked as a duplicate of bug 1729460 ***