Created attachment 1791686 [details] Failed log for akmod-v4l2loopback Created attachment 1791686 [details] Failed log for akmod-v4l2loopback Description of problem: akmods build tasks from kernel-install posttrans script does not pass through the environment variables needed for certain conditions (kernels built using LLVM with LTO), making akmods fail to build the kmods required for the kernel. However, the variables correctly get passed on the DKMS hook, and manual `akmods` command works Version-Release number of selected component (if applicable): 0.5.6-27 How reproducible: Always Steps to Reproduce: 0. Install an akmod (e.g.: akmod-v4l2loopback) 1. Install the required LLVM toolchain (Clang, LLD, and LLVM) ``` # dnf install clang lld llvm ``` 2. Add the rmnscnce/kernel-xanmod Copr repo 3. Install `kernel-xanmod-exptl` >= 5.12.11-xm1.0e20210611 and its devel package ``` # dnf install kernel-xanmod-exptl kernel-xanmod-devel ``` 4. Check the /var/cache/akmods/*/ for build logs Actual results: akmod failed to build due to unknown flag error in GCC, whilst it should have used the LLVM tools, resulting in a fail logfile Expected results: akmod successfully completed the build and built the kmod rpm Additional info: I'm the Copr maintainer and I think this problem originates from akmods, so I'm reporting it here
Successful akmods build log upon manual env variable invocation can be seen here: https://paste.centos.org/view/5b1b424b
Line that sets the required env variable inside the kernel-xanmod-exptl spec file: https://pagure.io/kernel-xanmod/blob/edge/f/rpmsrc/kernel-xanmod-exptl.spec#_330 Line that applies the env variable: https://pagure.io/kernel-xanmod/blob/edge/f/rpmsrc/kernel-xanmod-exptl.spec#_338
I'm not interested in supporting non-default tool chain, it works fine with gcc.
How are you setting the env variable needed to pass the compiler ? is it system wide variable or user defined variable ? akmods uses a dedicated user to build so you obviously have to propagate the variable to this user. This is basic sysadmin skill. The correct fix would be to set a rpm macro. So this environment would be purposely propagated, but so far this is only targeted for fedora 35: https://fedoraproject.org/wiki/Changes/CompilerPolicy If the f35 way of doing doesn't work. You will have to send the patch.
I see. There's a mistake on my end to how I set the environment variables. I will close this ticket now. Thank you for the responses ``` rmnscnce
I'm not expert on clang kernel/kmod building. But I think the best way is probably to enforce the CC to default to clang into the kernel-devel makefile as soon as the kernel is built with clang. (so the module would also). That way you will build the kmod with clang without enforcing others compilations work to clang.
As Fedora is targeting to (optionally) build the kernel with clang, maybe it would worth to defer the question to the fedora kernel team... (I let you raise the issue, please mention it there as relevant).
Reopening this ticket since apparently it still doesn't work even after changing the environment variable invocation method to the 'sh' standard. (`VARIABLE=value ; export VARIABLE`) (Log file: https://paste.centos.org/view/811aa553) Using akmods from terminal and having environment variable set using `env` or exporting to the session works as usual (https://paste.centos.org/view/737066eb) I suspect the problem lies within `/usr/lib/kernel/install.d/95-akmodsposttrans.install` (provided by package `akmods`), but I haven't figured out the problem (yet...) >maybe it would worth to defer the question to the fedora kernel team I don't think I will since I use a different kernel RPM spec than the one written by the Fedora kernel team. But maybe if the issue raises some general (in context of RPM packaging as a whole) concerns, I will raise the issue then ``` rmnscnce
Please refrain from re-opening As already explained, the problem lies with your method to set the compiler in post kernel install. Doing so will miss the situation where the given akmod is updated. There it will miss the temporary environment variable in such context. Instead I would suggest to patch the top level kernel-devel Makefile to default to clang instead of gcc. But as I said, please forward the question to fedora kernel team. I'm not going to comment until it's done.