Description of problem: Clean install of F37 Beta 1.5 and performing and update performed. Reboot after update performed and successful Installing package dkms causes a downgrade of several kernel and module components that prevents the system from further booting. Version-Release number of selected component (if applicable): 6.0.5-300.fc37.aarch64 How reproducible: Consistently reproducible on all attempts Steps to Reproduce: 1. Clean install of aarch64 F37 Beta 1.5 2. Update performed (via Gnome 4.3 Software) 3. Reboot to verify update 4. install dkms (sudo dnf install dkms) 5. Attempt to reboot Actual results: dkms does not install correct modules or kernel headers and breaks links to current correct modules and headers which in turn ... Prevents dkms from building/compiling modules and ... Prevents the system from booting Expected results: The correct version of dkms that supports 37 that does not prevent booting and also is capable of building compiling modules. Additional info: Also tested on F37 beta 1.5 X64_64. DKMS package is correct and does not prevent system from booting and allows correct module builds/compilations.
Which drivers is dkms building on aarch64? You need to rule out that this is a driver problem.
You do not need to build any. You just need to install dkms. So two problems. The first is after installing dkms it fails to build any module. The second problem (not booting problem) does not require a module to be built. It only requires dkms to be installed. This is why the steps to recreate the problem do not provide instruction to do build anything. But out of interest the first time this failed I was attempting to build rtl8821cu (wifi adapter module). However the build script made it quite apparent that it was not going to do anything due to missing header files. The second time I did not not attempt to build any module as I suspected the install of dkms was at fault because of the volume of downgrading messages displayed when installing it. None of these downgrade messages are displayed on an equivalent X86_64 system Which by the way successfully builds the module with error. I wanted to eliminate it was not the module software itself. (I should have been more clear on that point) After attempting the second time I mounted the broken system (SD card) into another system to take a look at some of the damage caused on the boot partition. The problem appears that the dkms is built against kernel 5.19 where F37 beta 1.5 is has kernel 6.05.
Appologies from my previous comment should have read "builds the module withOUT error"
So further testing. I assumed wrongly that the update was installing kernel 6.05. The install comes with 5.19.300. The update upgrades to 5.19.301 It is the install of the dkms package that partially installs kernel 6.05. I get the impression the dkms for 6.05 has slipped into the 5.19 repo and because it has dependencies for 6.05 it downloads and installs them. On the x86_64 platform installing dkms installs the version of dkms that matches the currently installed and active version of the kernel. I would have assumed this should always be the case.
These are the relevant dependencies required by DKMS: $ rpm -q --requires dkms | grep kernel (kernel-debug-devel-matched if kernel-debug-core) (kernel-devel-matched if kernel-core) (kernel-lpae-devel-matched if kernel-lpae-core) So it matches with one of those. In a normal case, kernel-devel-matched gets installed, which just pulls in kernel-devel, skipping kernel-debug-devel which provides kernel-devel as well: $ rpm -q --requires kernel-devel-matched kernel-core = 6.0.5-200.fc36 kernel-devel = 6.0.5-200.fc36 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 If you have kernel updates pending and you also want to install DKMS, the RPM dependencies will pull in the latest kernel-devel package which MIGHT be newer than what you have installed. I don't see any wrong behaviour here. Did I understood your problem correctly?
I can not reproduce the problem I have tried on aarch64 f37 rc 1.5, the kernel is 6.0.5-300.fc37.aarch64 rebooting basic install is ok yum install of dkms pulls in the correct kernel-devel reboot once dkms is installed is ok Can you double check the reproducing instructions ?
I'm not sure what version your kernel is but after the update my installed kernel is : uname -a Linux fedora 5.19.16-301.fc37.aarch64 #1 SMP PREEMPT_DYNAMIC Fri Oct 21 15:22:13 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux So why does (dnf dowload dkms -- resolve) pull : . . . (14/19): kernel-headers-6.0.5-300.fc37.aarch64. 81 kB/s | 1.5 MB 00:18 . . . When I don't have kernel 6.05 installed and I have no updates pending: sudo dnf update [sudo] password for wallyz: Copr repo for PyCharm owned by phracek 138 B/s | 341 B 00:02 Errors during downloading metadata for repository 'phracek-PyCharm': - Status code: 404 for https://copr-be.cloud.fedoraproject.org/results/phracek/PyCharm/fedora-37-aarch64/repodata/repomd.xml (IP: 52.44.175.77) Error: Failed to download metadata for repo 'phracek-PyCharm': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried Fedora 37 - aarch64 - Updates 2.0 kB/s | 3.1 kB 00:01 Fedora Modular 37 - aarch64 - Updates 2.4 kB/s | 3.1 kB 00:01 RPM Fusion for Fedora 37 - Nonfree - Steam 6.6 kB/s | 107 kB 00:16 Errors during downloading metadata for repository 'rpmfusion-nonfree-steam': - Status code: 404 for https://mirrors.rpmfusion.org/metalink?repo=nonfree-fedora-steam-37&arch=aarch64 (IP: 78.47.223.143) Error: Failed to download metadata for repo 'rpmfusion-nonfree-steam': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.rpmfusion.org/metalink?repo=nonfree-fedora-steam-37&arch=aarch64 (IP: 78.47.223.143) Ignoring repositories: phracek-PyCharm, rpmfusion-nonfree-steam Dependencies resolved. Nothing to do. Complete! So I tested specifically on version : https://download.fedoraproject.org/pub/fedora/linux/releases/test/37_Beta/Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-37_Beta-1.5.iso If your version has updated to kernel 6.05 then why? When as a regular user mine hasn't!
When I do this of Fed37 x86_64 installing dkms does not install version 6.05 of the kernel headers it installs the same version of the headers that matches my currently running kernel # On F37 x86_64 system $ uname -a $ dnf list --installed | grep dkms dkms.noarch 3.0.6-3.fc37 @fedora Linux fedora 5.19.16-301.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 21 15:55:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux $ dnf list --installed | grep headers glibc-headers-x86.noarch 2.36-7.fc37 @updates-testing kernel-headers.x86_64 5.19.4-300.fc37 @anaconda So on X86_64 dkms 3.0.6-3.fc37 installs kernel-headers.x86_64 5.19.4-300.fc37 but on aarch64 it installs kernel-headers 6.0.5-300.fc37.aarch64. Why? Installing the incorrect (partial) kernel headers causes new boot images in the /boot partition to be generated without any links to the relevant kernel modules which prevents booting.
(In reply to Tom Rix from comment #6) > I can not reproduce the problem > > I have tried on aarch64 f37 rc 1.5, > the kernel is 6.0.5-300.fc37.aarch64 > rebooting basic install is ok > yum install of dkms pulls in the correct kernel-devel > reboot once dkms is installed is ok > > Can you double check the reproducing instructions ? Your system should not have kernel 6.0.5-300.fc37.aarch64. The available image only comes with kernel 5.19.16-300.fc37.aarch64 and updates to kernel 5.19.16-301.fc37.aarch64. I have double check the issuse and is completely repeatable. Instructions Step 1 : install aarch64 F37 from https://download.fedoraproject.org/pub/fedora/linux/releases/test/37_Beta/Workstation/aarch64/images/Fedora-Workstation-37_Beta-1.5.aarch64.raw.xz Step 2 : Perform system update (either via Gnome 4.3 Software app or cli $ sudo dnf update; sudo dnf upgrade ) Step 3 : reboot to apply update and confirm kernel is at 5.19.16-301.fc37.aarch64. Step 4 : install dkms (sudo dnf install dkms) Step 5 : attempt to reboot (failure should occur)
Hi, I have similar problem. I'm using F37 with copr Kernel 5.15 Latest dkms packet won't install. systemctl status dkms × dkms.service - Builds and install new kernel modules through DKMS Loaded: loaded (/usr/lib/systemd/system/dkms.service; enabled; preset: enabled) Active: failed (Result: exit-code) since Fri 2023-02-03 11:51:38 CET; 14min ago Docs: man:dkms(8) Process: 681 ExecStart=/usr/sbin/dkms autoinstall --verbose --kernelver 5.15.90-200.fc37.x86_64 (code=exited, status=11) Main PID: 681 (code=exited, status=11) CPU: 10.976s févr. 03 11:51:44 localhost.localdomain dkms[7453]: exactly matches what is already found in kernel 5.15.90-200.fc37.x86_64. févr. 03 11:51:44 localhost.localdomain dkms[7453]: DKMS will not replace this module. févr. 03 11:51:44 localhost.localdomain dkms[7453]: You may override by specifying --force. févr. 03 11:51:44 localhost.localdomain dkms[7540]: Error! Installation aborted. févr. 03 11:51:44 localhost.localdomain dkms[7541]: Error! One or more modules failed to install during autoinstall. févr. 03 11:51:44 localhost.localdomain dkms[7541]: Refer to previous errors for more information. févr. 03 11:51:38 localhost.localdomain systemd[1]: dkms.service: Main process exited, code=exited, status=11/n/a févr. 03 11:51:38 localhost.localdomain systemd[1]: dkms.service: Failed with result 'exit-code'. févr. 03 11:51:38 localhost.localdomain systemd[1]: Failed to start dkms.service - Builds and install new kernel modules through DK> févr. 03 11:51:38 localhost.localdomain systemd[1]: dkms.service: Consumed 10.976s CPU time. If i Downgrade to : dkms noarch 3.0.6-3.fc37 fedora 58 k All is working well How to correct/debug this ?
I don't think any of the stuff that is listed in this bug is actually a bug. (In reply to knossos456 from comment #10) > févr. 03 11:51:44 localhost.localdomain dkms[7453]: exactly matches what is > already found in kernel 5.15.90-200.fc37.x86_64. > févr. 03 11:51:44 localhost.localdomain dkms[7453]: DKMS will not replace > this module. > févr. 03 11:51:44 localhost.localdomain dkms[7453]: You may override by > specifying --force. This message is all you need, you already have the kernel module built at the same version, if you want, you need to pass --force. Previous DKMS (3.0.6) was not checking this. If you are also rolling out your own modules, beware of allowing weak-modules in the specific DKMS build, that's only supported on EL.(In reply to Walter Zambotti from comment #8) > So on X86_64 dkms 3.0.6-3.fc37 installs kernel-headers.x86_64 > 5.19.4-300.fc37 > > but on aarch64 it installs kernel-headers 6.0.5-300.fc37.aarch64. Why? The relevant part is kernel-devel, not kernel-headers. kernel-headers might be at a lower version/release than the current kernel along with some other packages. This has no impact on kernel module builds. For example, on my system: # dnf list kernel* Last metadata expiration check: 1:56:12 ago on Wed 08 Feb 2023 05:57:18 AM CET. Installed Packages kernel.x86_64 6.1.9-200.fc37 @updates kernel-core.x86_64 6.1.9-200.fc37 @updates kernel-devel.x86_64 6.1.9-200.fc37 @updates kernel-devel-matched.x86_64 6.1.9-200.fc37 @updates kernel-headers.x86_64 6.1.5-200.fc37 @updates <--- older than 6.1.9-200.fc37, which is fine kernel-modules.x86_64 6.1.9-200.fc37 @updates kernel-modules-extra.x86_64 6.1.9-200.fc37 @updates kernel-srpm-macros.noarch 1.0-15.fc37 @fedora Available Packages kernel-cross-headers.x86_64 6.1.5-200.fc37 updates <--- older than 6.1.9-200.fc37, which is fine kernel-debug.x86_64 6.1.9-200.fc37 updates kernel-debug-core.x86_64 6.1.9-200.fc37 updates kernel-debug-devel.x86_64 6.1.9-200.fc37 updates kernel-debug-devel-matched.x86_64 6.1.9-200.fc37 updates kernel-debug-modules.x86_64 6.1.9-200.fc37 updates kernel-debug-modules-extra.x86_64 6.1.9-200.fc37 updates kernel-debug-modules-internal.x86_64 6.1.9-200.fc37 updates kernel-doc.noarch 6.1.9-200.fc37 updates kernel-headers.i686 6.0.5-300.fc37 fedora kernel-modules-internal.x86_64 6.1.9-200.fc37 updates kernel-rpm-macros.noarch 205-15.fc37 fedora kernel-tools.x86_64 6.1.5-200.fc37 updates <--- older than 6.1.9-200.fc37, which is fine kernel-tools-libs.x86_64 6.1.5-200.fc37 updates <--- older than 6.1.9-200.fc37, which is fine kernel-tools-libs-devel.x86_64 6.1.5-200.fc37 updates <--- older than 6.1.9-200.fc37, which is fine kernelshark.x86_64 1:2.1.0-2.fc37 fedora
Hi, thanks for the answer. As explained above, I don't use the main stock Kernel, but the Copr LST one : https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-5.15/ Does it means that the latest dkms is not compatible with it ? I repeat: It's the service that diden't load. The modules are compiled with success.
HI, I'll switched back to dkms-3.0.6, but cant keep this version, signature seems to be wrong with it, I must disable secure boot (signature error) Whith version dkms-3.0.10, service is not running. I compile on Linux via dkms since years, for Fedora I'll add always NO_WEAK_MODULES="true" in all dkms.conf don't worry. First time I encounter this problem. my dnf list kernel* : My installed packages : kernel-devel.x86_64 6.1.10-200.fc37 @updates kernel-longterm.x86_64 5.15.92-200.fc37 @copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-core.x86_64 5.15.90-200.fc37 @copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-core.x86_64 5.15.92-200.fc37 @copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-debug-devel.x86_64 5.15.90-200.fc37 @copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-debug-devel.x86_64 5.15.92-200.fc37 @copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-devel.x86_64 5.15.90-200.fc37 @copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-devel.x86_64 5.15.92-200.fc37 @copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-headers.x86_64 5.15.4-200.fc37 @copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-modules.x86_64 5.15.90-200.fc37 @copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-modules.x86_64 5.15.92-200.fc37 @copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-srpm-macros.noarch 1.0-15.fc37 @fedora Available Packages kernel.x86_64 6.1.10-200.fc37 updates kernel-core.x86_64 6.1.10-200.fc37 updates kernel-cross-headers.x86_64 6.1.5-200.fc37 updates kernel-debug.x86_64 6.1.10-200.fc37 updates kernel-debug-core.x86_64 6.1.10-200.fc37 updates kernel-debug-devel.x86_64 6.1.10-200.fc37 updates kernel-debug-devel-matched.x86_64 6.1.10-200.fc37 updates kernel-debug-modules.x86_64 6.1.10-200.fc37 updates kernel-debug-modules-extra.x86_64 6.1.10-200.fc37 updates kernel-debug-modules-internal.x86_64 6.1.10-200.fc37 updates kernel-devel-matched.x86_64 6.1.10-200.fc37 updates kernel-doc.noarch 6.1.10-200.fc37 updates kernel-headers.i686 6.0.5-300.fc37 fedora kernel-headers.x86_64 6.1.5-200.fc37 updates kernel-longterm.src 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-cross-headers.x86_64 5.15.4-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-debug.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-debug-core.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-debug-debuginfo.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-debug-devel-matched.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-debug-modules.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-debug-modules-extra.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-debug-modules-internal.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-debuginfo.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-debuginfo-common-x86_64.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-devel-matched.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-headers.src 5.15.4-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-modules-extra.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-longterm-modules-internal.x86_64 5.15.92-200.fc37 copr:copr.fedorainfracloud.org:kwizart:kernel-longterm-5.15 kernel-modules.x86_64 6.1.10-200.fc37 updates kernel-modules-extra.x86_64 6.1.10-200.fc37 updates kernel-modules-internal.x86_64 6.1.10-200.fc37 updates kernel-rpm-macros.noarch 205-15.fc37 fedora kernel-tools.x86_64 6.1.5-200.fc37 updates kernel-tools-libs.x86_64 6.1.5-200.fc37 updates kernel-tools-libs-devel.x86_64 6.1.5-200.fc37 updates kernelshark.x86_64 1:2.1.0-2.fc37 fedora Bug was always reported here : https://forums.fedoraforum.org/showthread.php?329740-Fedora-37-error-with-dkms-service And here : https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-5.15/
(In reply to knossos456 from comment #13) > I compile on Linux via dkms since years, for Fedora I'll add always > NO_WEAK_MODULES="true" in all dkms.conf don't worry. Well, for Fedora you SHOULD NOT add NO_WEAK_MODULES="true", as the Fedora kernel does not have a stable kernel ABI like RHEL. Besides this, have you checked this message? it's pretty clear what the issue is, that the module can not be installed: (In reply to knossos456 from comment #10) > févr. 03 11:51:44 localhost.localdomain dkms[7453]: exactly matches what is already found in kernel 5.15.90-200.fc37.x86_64. > févr. 03 11:51:44 localhost.localdomain dkms[7453]: DKMS will not replace this module. > févr. 03 11:51:44 localhost.localdomain dkms[7453]: You may override by specifying --force. > févr. 03 11:51:44 localhost.localdomain dkms[7540]: Error! Installation aborted. > févr. 03 11:51:44 localhost.localdomain dkms[7541]: Error! One or more modules failed to install during autoinstall. Try to build and load the module by hand to see what is the issue, or just edit the dkms file and add a "-x" on the shell line to see the debug output, it's a shell script after all. From what I see from all the issues reported here, none of the problems seems to be a DKMS problem.
The build process is ok without errors under 3.0.6 and service is loading OK, problem is signature. My 4 dkms are done to replace original dvb modules that are buggy. My github: https://github.com/enigma131?tab=repositories I think that I must done is to clear all the Dkms stuff, restore loading original modules from kernel, then start from scratch with 3.0.10 I don't want to reinstall F37. I never done it, how to proceed ? And why I don't have problems with dkms 3.0.6 and problem only if I upgrade to 3.0.10 ?
I have found the way to upgrade to 3.0.10 First remove the old one (3.0.6) reboot Install the new one (without upgrade) reboot then : systemctl status dkms ● dkms.service - Builds and install new kernel modules through DKMS Loaded: loaded (/usr/lib/systemd/system/dkms.service; enabled; preset: enabled) Active: active (exited) since Wed 2023-02-15 11:33:16 CET; 2min 28s ago Docs: man:dkms(8) Process: 702 ExecStart=/usr/sbin/dkms autoinstall --verbose --kernelver 5.15.92-200.fc37.x86_64 (code=exited, status=0/SUCCESS) Main PID: 702 (code=exited, status=0/SUCCESS) CPU: 321ms févr. 15 11:33:07 localhost.localdomain systemd[1]: Starting dkms.service - Builds and install new kernel modules through DKMS... févr. 15 11:33:16 localhost.localdomain systemd[1]: Finished dkms.service - Builds and install new kernel modules through DKMS. now checking secure boot by enabling it in bios. Reboot, modules are not loaded Check : sudo modprobe -v lnbp21 insmod /lib/modules/5.15.92-200.fc37.x86_64/extra/lnbp21.ko.xz modprobe: ERROR: could not insert 'lnbp21': Key was rejected by service <----------------- Rebuild the module from /usr/src/lnbp21-enigma13 dkms remove lnbp21/enigma13 --all Module lnbp21-enigma13 for kernel 5.15.92-200.fc37.x86_64 (x86_64). Before uninstall, this module version was ACTIVE on this kernel. lnbp21.ko.xz: - Uninstallation - Deleting from: /lib/modules/5.15.92-200.fc37.x86_64/extra/ - Original module - Archived original module found in the DKMS tree - Moving it to: /lib/modules/5.15.92-200.fc37.x86_64/kernel/drivers/media/dvb-frontends/ depmod....... Removing original_module from DKMS tree for kernel 5.15.92-200.fc37.x86_64 (x86_64) Rebuild + reinstall it with 3.0.10: dkms install lnbp21/enigma13 Sign command: /lib/modules/5.15.92-200.fc37.x86_64/build/scripts/sign-file Signing key: /var/lib/dkms/mok.key Public certificate (MOK): /var/lib/dkms/mok.pub Building module: Cleaning build area... make -j4 KERNELRELEASE=5.15.92-200.fc37.x86_64 -C /lib/modules/5.15.92-200.fc37.x86_64/build M=/var/lib/dkms/lnbp21/enigma13/build...... Signing module /var/lib/dkms/lnbp21/enigma13/build/lnbp21.ko Cleaning build area... lnbp21.ko.xz: Running module version sanity check. Module version for lnbp21.ko.xz exactly matches what is already found in kernel 5.15.92-200.fc37.x86_64. DKMS will not replace this module. You may override by specifying --force. Error! Installation aborted. It found the same binary, force the install: dkms install lnbp21/enigma13 --force lnbp21.ko.xz: Running module version sanity check. - Original module - Found /lib/modules/5.15.92-200.fc37.x86_64/kernel/drivers/media/dvb-frontends/lnbp21.ko.xz - Storing in /var/lib/dkms/lnbp21/original_module/5.15.92-200.fc37.x86_64/x86_64/ - Archiving for uninstallation purposes - Installation - Installing to /lib/modules/5.15.92-200.fc37.x86_64/extra/ depmod.... Reboot, then the module is still not loaded, retrying: sudo modprobe -v lnbp21 insmod /lib/modules/5.15.92-200.fc37.x86_64/extra/lnbp21.ko.xz modprobe: ERROR: could not insert 'lnbp21': Key was rejected by service <-------------- modinfo lnbp21 filename: /lib/modules/5.15.92-200.fc37.x86_64/extra/lnbp21.ko.xz license: GPL author: Oliver Endriss, Igor M. Liplianin, Enigma13 description: Driver for lnb supply and control ic lnbp21, lnbh24 depends: retpoline: Y name: lnbp21 vermagic: 5.15.92-200.fc37.x86_64 SMP mod_unload sig_id: PKCS#7 signer: DKMS module signing key sig_key: 30:6A:97:EF:29:57:61:5F:1C:3C:78:2E:A7:94:56:8E:91:D3:67 sig_hashalgo: sha512 signature: 92:26:43:BD:C0:84:DF:FB:5E:13:97:89:2B:C1:77:09:82:20:0D:9B: 00:F0:DB:8C:C3:7F:C4:00:4D:A0:0C:22:F9:57:A8:DA:F7:55:08:30: CD:B3:93:68:CF:0D:E3:12:42:9E:36:21:99:FB:EA:EB:F6:92:A9:D0: 52:23:3B:55:A9:13:2D:E9:29:3F:D4:CE:B4:46:41:40:3D:04:3E:DE: 03:AF:7B:4A:60:D9:85:C8:94:6D:D2:1E:CC:4A:0A:5C:59:73:89:27: 29:C4:FF:0D:C8:8F:F9:97:E6:5D:42:8D:DA:5F:15:E1:3D:6D:E8:6B: 4C:E8:2F:11:8F:73:CF:06:B1:6D:67:F3:18:CB:1E:19:00:AF:59:69: 5C:47:6E:D0:C4:BB:04:D7:DF:3F:6C:9E:DF:66:50:9F:78:10:ED:13: 26:81:29:8E:70:DC:10:A6:E4:52:3E:92:7C:28:55:BE:86:16:5F:0B: 25:5F:BF:10:10:E0:BC:96:FB:5F:80:8B:62:6A:19:46:87:46:A6:A3: C3:F2:CD:F0:9D:F5:C6:3B:D2:BB:AA:2F:BD:C1:31:E8:BA:A2:A3:FB: D8:03:BB:C5:12:E6:73:31:3A:56:70:61:10:A0:A4:EB:27:A9:CC:80: 39:1C:58:AA:12:FA:4D:8C:99:FC:3B:93:E7:AF:BC:E6 Module is signed with sha512, on other partition Redhat8 and Debian11 on same computer, signature is sha256 .... Regarding the commit from version 3.0.9: https://github.com/dell/dkms/commit/81ae9d1f638c5333100e8cce323028df44bfab14 CONFIG_MODULE_SIG_HASH is taken in .config file from kernel_longterm 5.15 and is sha512. Is the signature error coming from here ?
Upgrading kernel, still same error: sudo modprobe -vvv lnbp21 modprobe: INFO: libkmod/libkmod.c:367 kmod_set_log_fn() custom logging function 0x55d36959ac50 registered modprobe: DEBUG: libkmod/libkmod-index.c:757 index_mm_open() file=/lib/modules/5.15.95-200.fc37.x86_64/modules.dep.bin modprobe: DEBUG: libkmod/libkmod-index.c:757 index_mm_open() file=/lib/modules/5.15.95-200.fc37.x86_64/modules.alias.bin modprobe: DEBUG: libkmod/libkmod-index.c:757 index_mm_open() file=/lib/modules/5.15.95-200.fc37.x86_64/modules.symbols.bin modprobe: DEBUG: libkmod/libkmod-index.c:757 index_mm_open() file=/lib/modules/5.15.95-200.fc37.x86_64/modules.builtin.alias.bin modprobe: DEBUG: libkmod/libkmod-index.c:757 index_mm_open() file=/lib/modules/5.15.95-200.fc37.x86_64/modules.builtin.bin modprobe: DEBUG: libkmod/libkmod-module.c:579 kmod_module_new_from_lookup() input alias=lnbp21, normalized=lnbp21 modprobe: DEBUG: libkmod/libkmod.c:597 kmod_search_moddep() use mmaped index 'modules.dep' modname=lnbp21 modprobe: DEBUG: libkmod/libkmod.c:405 kmod_pool_get_module() get module name='lnbp21' found=(nil) modprobe: DEBUG: libkmod/libkmod.c:413 kmod_pool_add_module() add 0x55d369fab1c0 key='lnbp21' modprobe: DEBUG: libkmod/libkmod-module.c:202 kmod_module_parse_depline() 0 dependencies for lnbp21 modprobe: DEBUG: libkmod/libkmod-module.c:584 kmod_module_new_from_lookup() lookup=lnbp21 found=1 modprobe: DEBUG: libkmod/libkmod.c:502 lookup_builtin_file() use mmaped index 'modules.builtin' modname=lnbp21 modprobe: DEBUG: libkmod/libkmod-module.c:1817 kmod_module_get_initstate() could not open '/sys/module/lnbp21/initstate': No such file or directory modprobe: DEBUG: libkmod/libkmod-module.c:1827 kmod_module_get_initstate() could not open '/sys/module/lnbp21': No such file or directory modprobe: DEBUG: libkmod/libkmod-module.c:1461 kmod_module_get_options() modname=budget_ci mod->name=lnbp21 mod->alias=(null) modprobe: DEBUG: libkmod/libkmod-module.c:1461 kmod_module_get_options() modname=dvb_usb_af9035 mod->name=lnbp21 mod->alias=(null) modprobe: DEBUG: libkmod/libkmod-module.c:1461 kmod_module_get_options() modname=b43 mod->name=lnbp21 mod->alias=(null) modprobe: DEBUG: libkmod/libkmod-module.c:1461 kmod_module_get_options() modname=bonding mod->name=lnbp21 mod->alias=(null) modprobe: DEBUG: libkmod/libkmod-module.c:1461 kmod_module_get_options() modname=dummy mod->name=lnbp21 mod->alias=(null) modprobe: DEBUG: libkmod/libkmod-module.c:1461 kmod_module_get_options() modname=vhost mod->name=lnbp21 mod->alias=(null) modprobe: DEBUG: libkmod/libkmod-module.c:1817 kmod_module_get_initstate() could not open '/sys/module/lnbp21/initstate': No such file or directory modprobe: DEBUG: libkmod/libkmod-module.c:1827 kmod_module_get_initstate() could not open '/sys/module/lnbp21': No such file or directory modprobe: DEBUG: libkmod/libkmod-module.c:802 kmod_module_get_path() name='lnbp21' path='/lib/modules/5.15.95-200.fc37.x86_64/extra/lnbp21.ko.xz' modprobe: DEBUG: libkmod/libkmod-module.c:802 kmod_module_get_path() name='lnbp21' path='/lib/modules/5.15.95-200.fc37.x86_64/extra/lnbp21.ko.xz' insmod /lib/modules/5.15.95-200.fc37.x86_64/extra/lnbp21.ko.xz modprobe: DEBUG: libkmod/libkmod-module.c:802 kmod_module_get_path() name='lnbp21' path='/lib/modules/5.15.95-200.fc37.x86_64/extra/lnbp21.ko.xz' modprobe: INFO: libkmod/libkmod-module.c:949 kmod_module_insert_module() Failed to insert module '/lib/modules/5.15.95-200.fc37.x86_64/extra/lnbp21.ko.xz': Key was rejected by service modprobe: ERROR: could not insert 'lnbp21': Key was rejected by service modprobe: DEBUG: libkmod/libkmod-module.c:469 kmod_module_unref() kmod_module 0x55d369fab1c0 released modprobe: DEBUG: libkmod/libkmod.c:421 kmod_pool_del_module() del 0x55d369fab1c0 key='lnbp21' modprobe: INFO: libkmod/libkmod.c:334 kmod_unref() context 0x55d369faa4b0 released
Seems that the copr kernel need a patch , see https://github.com/dell/dkms/issues/305 I've done a comment on https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-5.15/ But not sure kwizart is reading there. How to reach kwizart else the link above ?
Hi, last Copr version from yesterday is working after patching, thanks to you.
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. 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 '37'. 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. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 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.
Fedora Linux 37 entered end-of-life (EOL) status on None. Fedora Linux 37 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.