dell / dkms Goto Github PK
View Code? Open in Web Editor NEWDynamic Kernel Module Support
License: GNU General Public License v2.0
Dynamic Kernel Module Support
License: GNU General Public License v2.0
When is the next version release planned? I'm particularly interested in #38 ...
Hi,
dkms mkdeb
seems to not include the .ko module files (binaries).
Either this is a bug, or preferably this is just the good way to go, but usage and man page should be fixed so that --source-only is de facto, an --binaries-only is not an option.
Also note that if mkdeb
could actually produce a deb with binaries inside, it should not be _all.deb
, but an architecture specific deb package (e.g. amd64.deb
).
My proposal would be to take the approach chosen in Debian's dkms version (fork):
mkdeb
command to create the dkms source package, all.deb
mkbmdeb
command to create the dkms binary modules package (arch specific package)mkbmdeb
, and fixing mkdeb
usage.This is something discussed in Debian bug tracking system here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832558#100
When I updated kernel version , old dkms package will not be rebuilt ,just link old dkms modules to weak-update directory . But I need to rebuild it for new kernel image . I got several similar issues reported in the past years . so I need to record it here ,and find a workable solution to fix this .
[root@localhost 3.10.0-514.el7.x86_64]# yum update kernel kernel-headers kernel-devel
\Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
Dependencies Resolved
Installing:
kernel x86_64 3.10.0-514.2.2.el7 updates 37 M
kernel-devel x86_64 3.10.0-514.2.2.el7 updates 13 M
Updating:
kernel-headers x86_64 3.10.0-514.2.2.el7 updates 4.8 M
Install 2 Packages
Upgrade 1 Package
Total size: 55 M
Is this ok [y/d/N]: y
Is this ok [y/d/N]: yt
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : kernel-devel-3.10.0-514.2.2.el7.x86_64 1/4
Installing : kernel-3.10.0-514.2.2.el7.x86_64 2/4
Updating : kernel-headers-3.10.0-514.2.2.el7.x86_64 3/4
Cleanup : kernel-headers-3.10.0-514.el7.x86_64 4/4
Good news! Module version 367.44 for nvidia.ko
exactly matches what is already found in kernel 3.10.0-514.2.2.el7.x86_64.
DKMS will not replace this module.
You may override by specifying --force.
Error! Module version 6BE4B82009EDF06D87F035E for nvidia-uvm.ko
is not newer than what is already found in kernel 3.10.0-514.2.2.el7.x86_64 (367.44).
You may override by specifying --force.
Good news! Module version 367.44 for nvidia-modeset.ko
exactly matches what is already found in kernel 3.10.0-514.2.2.el7.x86_64.
DKMS will not replace this module.
You may override by specifying --force.
Good news! Module version 367.44 for nvidia-drm.ko
exactly matches what is already found in kernel 3.10.0-514.2.2.el7.x86_64.
DKMS will not replace this module.
You may override by specifying --force.
modinfo: ERROR: Module /lib/modules/3.10.0-514.el7.x86_64/weak-updates/ not found.
modinfo: ERROR: Module /lib/modules/3.10.0-514.2.2.el7.x86_64/nvidia.ko not found.
modprobe: FATAL: Module /lib/modules/3.10.0-514.2.2.el7.x86_64/nvidia.ko not found.
Warning: Module nvidia.ko from kernel has no modversions, so it cannot be reused for kernel 3.10.0-514.el7.x86_64
modinfo: ERROR: Module /lib/modules/3.10.0-514.el7.x86_64/weak-updates/ not found.
modinfo: ERROR: Module /lib/modules/3.10.0-514.2.2.el7.x86_64/nvidia-uvm.ko not found.
modprobe: FATAL: Module /lib/modules/3.10.0-514.2.2.el7.x86_64/nvidia-uvm.ko not found.
Warning: Module nvidia-uvm.ko from kernel has no modversions, so it cannot be reused for kernel 3.10.0-514.el7.x86_64
modinfo: ERROR: Module /lib/modules/3.10.0-514.el7.x86_64/weak-updates/ not found.
modinfo: ERROR: Module /lib/modules/3.10.0-514.2.2.el7.x86_64/nvidia-modeset.ko not found.
modprobe: FATAL: Module /lib/modules/3.10.0-514.2.2.el7.x86_64/nvidia-modeset.ko not found.
Warning: Module nvidia-modeset.ko from kernel has no modversions, so it cannot be reused for kernel 3.10.0-514.el7.x86_64
modinfo: ERROR: Module /lib/modules/3.10.0-514.el7.x86_64/weak-updates/ not found.
modinfo: ERROR: Module /lib/modules/3.10.0-514.2.2.el7.x86_64/nvidia-drm.ko not found.
modprobe: FATAL: Module /lib/modules/3.10.0-514.2.2.el7.x86_64/nvidia-drm.ko not found.
Warning: Module nvidia-drm.ko from kernel has no modversions, so it cannot be reused for kernel 3.10.0-514.el7.x86_64
Verifying : kernel-headers-3.10.0-514.2.2.el7.x86_64 1/4
Verifying : kernel-3.10.0-514.2.2.el7.x86_64 2/4
Verifying : kernel-devel-3.10.0-514.2.2.el7.x86_64 3/4
Verifying : kernel-headers-3.10.0-514.el7.x86_64 4/4
Installed:
kernel.x86_64 0:3.10.0-514.2.2.el7 kernel-devel.x86_64 0:3.10.0-514.2.2.el7
Updated:
kernel-headers.x86_64 0:3.10.0-514.2.2.el7
Complete!
[root@localhost 3.10.0-514.el7.x86_64]# dkms status
nvidia, 367.44, 3.10.0-514.2.2.el7.x86_64, x86_64: installed (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!) (WARNING! Diff between built and installed module!)
nvidia, 367.44, 3.10.0-514.el7.x86_64, x86_64: installed
[root@localhost 3.10.0-514.el7.x86_64]#
Similar issue reported :
openzfs/zfs#3801
https://www.centos.org/forums/viewtopic.php?t=56627
http://lists.us.dell.com/pipermail/dkms-devel/2007-May/000562.html
According to: https://github.com/dell-oss/dkms/blob/master/dkms#L267-L283
An old initrd is saved with the "old-dkms" suffix at every rebuild, to revert to the previous initrd in case of problems. This is fine, but it can lead to a full /boot partition after a few update, as old initrd images are never deleted (ref: https://bugzilla.redhat.com/show_bug.cgi?id=1251602).
What is the best approach here? Is it ok if I create a patch that deletes all "old-dkms" images prior to starting a new initird build? If a new initird build is triggered, this basically means that the user is updating the kernel or the module, and in both cases it ensures us that the "current boot" is fine and there is no need to revert.
What do you think?
Thanks,
--Simone
It seems that commands like e.g. dkms install mydriver/1.0.0 --all
only work for kernels on which the module is already built (which would render dkms build ... --all
useless). I would expect that --all
would e.g. go through /lib/modules and try to build the module for all the kernels listed there. Instead, it iterates through an old kernel which I don't even have installed anymore (but had the module built back then), and the current kernel (which already has the module built).
Every time I try to use a POST_INSTALL script, I get the following:
Warning: The post_install script is not executable.
This is because of this.
In updating the README to use Markdown on Github I noticed it was missing documentation about how DKMS debs work. This should probably be added when convenient.
This code https://github.com/dell/dkms/blob/master/dkms#L1849-L1858 has a problematic side effect.
When upgrading a kernel (I am using debian), the kernel packages prerm script (https://github.com/dell/dkms/blob/master/kernel_prerm.d_dkms#L12) will call 'dkms remove'. If this was the only installed kernel, all dkms modules are not only uninstalled and removed, but also completely purged.
Then the new kernel is installed and the dkms autoinstaller won't find any modules to reinstall.
I see a few options:
Any thoughts?
On RPM-based systems which have dpkg installed for some reason (e.g. using alien), trying to install a dkms-based RPM shows the following:
sudo rpm -i mydriver-0.7.2-1dkms.noarch.rpm
Loading tarball for mydriver-0.7.2
Loading /var/lib/dkms/mydriver/0.7.2/4.13.9-300.fc27.x86_64/x86_64...
DKMS: ldtarball completed.
Creating symlink /var/lib/dkms/mydriver/0.7.2/source ->
/usr/src/mydriver-0.7.2
DKMS: add completed.
dpkg: warning: version '3.10.0-862.11.6.el7.x86_64' has bad syntax: invalid character in revision number
dpkg: warning: version '3.10.0-862.14.4.el7.x86_64' has bad syntax: invalid character in revision number
dpkg: warning: version '3.10.0-862.14.4.el7.x86_64' has bad syntax: invalid character in revision number
dpkg: warning: version '3.10.0-862.14.4.el7.x86_64' has bad syntax: invalid character in revision number
dpkg: warning: version '3.10.0-862.el7.x86_64' has bad syntax: invalid character in revision number
dpkg: warning: version '3.10.0-862.14.4.el7.x86_64' has bad syntax: invalid character in revision number
Building for 3.10.0-862.14.4.el7.x86_64 3.10.0-862.el7.x86_64
Building initial module for 3.10.0-862.14.4.el7.x86_64
Done.
...
This happens because of this:
# Get the newest kernel on Debian and Rhel based systems.
get_newest_kernel() {
NEWEST_KERNEL=
# Try Debian first as rpm can be installed in Debian based distros
if [ -e /usr/bin/dpkg ]; then
# If DEB based
...
I suppose I could ignore those warnings, though they certainly look awful, and I don't know what else might be breaking due to this.
Hello all,
I'm trying to build debian dkms for several in-tree modules that require patches.
I'm looking to a way to do the following in DKMS.conf :
SELECTED_KERNEL=$kernelver | cut -d- -f1
In order to use it later as
BUILT_MODULE_LOCATION[0]="$SELECTED_KERNEL/drivers/media/..."
So for instance with $kernelver=4.4.0-112_generic
I would get SELECTED_KERNEL=4.4.0
I tried to change the DKMS.conf to bash script by adding '#!/bin/sh' and chmod
ing accordingly, but still, the new variable is not being calculated.
Any comments will be helpful
In postinst, ARCH is init to dpkg --print-architecture
, then passed to common.postinst. In common.postinst, ARCH is intended to be the argument for -a
, which is system architecture according to the manual.
So, there are two architecture, dpkg architecture and system architecture. These two are not always the same. In common.postinst, dpkg architecture amd64
is translate to system architecture x86_64
, and dpkg architecture i?86
is translate to system architecture i686
.
Then I doubt these two architecture can be mixing used.
In the context of postinst, not specific -a
and use the default is enough. And architecture translate can be removed too.
Another reason not use ARCH is that it's an important variable in kernel module building.
Installing the openvswitch datapath modules via DKMS fails on redhat/centos 7 because the original modules are tagged with a checksum in the srcversion field:
# modinfo /lib/modules/3.10.0-514.el7.x86_64/kernel/net/openvswitch/openvswitch.ko
filename: /lib/modules/3.10.0-514.el7.x86_64/kernel/net/openvswitch/openvswitch.ko
license: GPL
description: Open vSwitch switching datapath
rhelversion: 7.3
srcversion: B31AE95554C9D9A0067F935
depends: nf_conntrack,nf_nat,libcrc32c,nf_nat_ipv6,nf_nat_ipv4,nf_defrag_ipv6
intree: Y
vermagic: 3.10.0-514.el7.x86_64 SMP mod_unload modversions
signer: CentOS Linux kernel signing key
sig_key: D4:88:63:A7:C1:6F:CC:27:41:23:E6:29:8F:74:F0:57:AF:19:FC:54
sig_hashalgo: sha256
Resulting failure:
#dkms autoinstall openvswitch/2.6.2
openvswitch:
Running module version sanity check.
Error! Module version 2.6.2 for openvswitch.ko
is not newer than what is already found in kernel 3.10.0-514.el7.x86_64 (B31AE95554C9D9A0067F935).
You may override by specifying --force.
Quick hack which resolves the issue for me:
--- /usr/sbin/dkms.orig 2016-12-20 11:31:59.368461247 +0100
+++ /usr/sbin/dkms 2016-12-20 11:32:03.059461265 +0100
@@ -723,7 +723,7 @@
res[2]=${vals[2]}
;;
srcversion:)
- res[1]=${vals[1]}
+ #res[1]=${vals[1]}
;;
esac
done < <(modinfo $1)
Hi there,
We have a need for a very recent version of DKMS that includes commit 193d339. Can you create a new official release?
Hello,
The latest dkms release (v2.2.0.3) is 5 years old, and a good number of bug fixes and new features
have been integrated in the master branch since this tag.
Is it planned to tag a new dkms release?
Regards,
Julien
I noticed that the date and version number in the manpage dkms.8 are not updated with the release version of dkms.
Is there sense in inserting the current date/version in the tarball/install targets in the Makefile? If so I could provide a patch later.
The 2.4.0 release references 2.3.0 in the Makefile which eventually results in a tarball named dkms-2.3.0.0.tar.gz.
[ec2-user@ip-10-7-81-120 dkms-2.4.0]$ cat Makefile
RELEASE_DATE := "22-September-2014"
RELEASE_MAJOR := 2
RELEASE_MINOR := 3
RELEASE_SUBLEVEL := 0
RELEASE_EXTRALEVEL := .0
RELEASE_NAME := dkms
RELEASE_VERSION := $(RELEASE_MAJOR).$(RELEASE_MINOR).$(RELEASE_SUBLEVEL)$(RELEASE_EXTRALEVEL)
RELEASE_STRING := $(RELEASE_NAME)-$(RELEASE_VERSION)
DIST := unstable
SHELL=bash
The release date is quite old as well. I am running this on RHEL 7. Notably, if I update the RELEASE_MINOR var to 4 and run make tarball, I still get an error:
[ec2-user@ip-10-7-81-120 dkms-2.4.0]$ make tarball
mkdir -p /home/ec2-user/dkms-2.4.0/dist
tmp_dir=`mktemp -d --tmpdir dkms.XXXXXXXX` ; \
cp -a ../dkms ${tmp_dir}/dkms-2.4.0.0 ; \
sed -e "s/\[INSERT_VERSION_HERE\]/2.4.0.0/" dkms > ${tmp_dir}/dkms-2.4.0.0/dkms ; \
sed -e "s/\[INSERT_VERSION_HERE\]/2.4.0.0/" dkms.spec > ${tmp_dir}/dkms-2.4.0.0/dkms.spec ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name .git -type d -exec rm -rf \{\} \; ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name dist -type d -exec rm -rf \{\} \; ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name \*~ -type f -exec rm -f \{\} \; ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name dkms\*.rpm -type f -exec rm -f \{\} \; ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name dkms\*.tar.gz -type f -exec rm -f \{\} \; ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name dkms-freshmeat.txt -type f -exec rm -f \{\} \; ; \
rm -rf ${tmp_dir}/dkms-2.4.0.0/debian ; \
sync ; sync ; sync ; \
tar cvzf /home/ec2-user/dkms-2.4.0/dist/dkms-2.4.0.0.tar.gz -C ${tmp_dir} dkms-2.4.0.0; \
rm -rf ${tmp_dir} ;
cp: cannot stat ‘../dkms’: No such file or directory
bash: line 2: /tmp/dkms.pRQJuzSF/dkms-2.4.0.0/dkms: No such file or directory
bash: line 3: /tmp/dkms.pRQJuzSF/dkms-2.4.0.0/dkms.spec: No such file or directory
find: ‘/tmp/dkms.pRQJuzSF/dkms-2.4.0.0’: No such file or directory
find: ‘/tmp/dkms.pRQJuzSF/dkms-2.4.0.0’: No such file or directory
find: ‘/tmp/dkms.pRQJuzSF/dkms-2.4.0.0’: No such file or directory
find: ‘/tmp/dkms.pRQJuzSF/dkms-2.4.0.0’: No such file or directory
find: ‘/tmp/dkms.pRQJuzSF/dkms-2.4.0.0’: No such file or directory
find: ‘/tmp/dkms.pRQJuzSF/dkms-2.4.0.0’: No such file or directory
tar: dkms-2.4.0.0: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
I obtained this release directly from gitlab's release page. The top level dir in the zip is 'dkms-2.4.0'. If I rename this to simply 'dkms' it works:
[ec2-user@ip-10-7-81-120 ~]$ mv dkms-2.4.0 dkms/
[ec2-user@ip-10-7-81-120 ~]$ vim dkms/Makefile
[ec2-user@ip-10-7-81-120 ~]$ cd dkms
[ec2-user@ip-10-7-81-120 dkms]$ make tarball
mkdir -p /home/ec2-user/dkms/dist
tmp_dir=`mktemp -d --tmpdir dkms.XXXXXXXX` ; \
cp -a ../dkms ${tmp_dir}/dkms-2.4.0.0 ; \
sed -e "s/\[INSERT_VERSION_HERE\]/2.4.0.0/" dkms > ${tmp_dir}/dkms-2.4.0.0/dkms ; \
sed -e "s/\[INSERT_VERSION_HERE\]/2.4.0.0/" dkms.spec > ${tmp_dir}/dkms-2.4.0.0/dkms.spec ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name .git -type d -exec rm -rf \{\} \; ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name dist -type d -exec rm -rf \{\} \; ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name \*~ -type f -exec rm -f \{\} \; ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name dkms\*.rpm -type f -exec rm -f \{\} \; ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name dkms\*.tar.gz -type f -exec rm -f \{\} \; ; \
find ${tmp_dir}/dkms-2.4.0.0 -depth -name dkms-freshmeat.txt -type f -exec rm -f \{\} \; ; \
rm -rf ${tmp_dir}/dkms-2.4.0.0/debian ; \
sync ; sync ; sync ; \
tar cvzf /home/ec2-user/dkms/dist/dkms-2.4.0.0.tar.gz -C ${tmp_dir} dkms-2.4.0.0; \
rm -rf ${tmp_dir} ;
dkms-2.4.0.0/
dkms-2.4.0.0/AUTHORS
dkms-2.4.0.0/COPYING
dkms-2.4.0.0/README.md
dkms-2.4.0.0/TODO
dkms-2.4.0.0/dkms
dkms-2.4.0.0/dkms-freshmeat.txt.in
dkms-2.4.0.0/dkms.8
dkms-2.4.0.0/dkms.bash-completion
dkms-2.4.0.0/dkms.service
dkms-2.4.0.0/dkms.spec
dkms-2.4.0.0/dkms_apport.py
dkms-2.4.0.0/dkms_autoinstaller
dkms-2.4.0.0/dkms_common.postinst
dkms-2.4.0.0/dkms_dbversion
dkms-2.4.0.0/dkms_find-provides
dkms-2.4.0.0/dkms_framework.conf
dkms-2.4.0.0/dkms_mkkerneldoth
dkms-2.4.0.0/dkms_upgrade_add_arch_support.sh
dkms-2.4.0.0/kernel_postinst.d_dkms
dkms-2.4.0.0/kernel_prerm.d_dkms
dkms-2.4.0.0/lsb_release
dkms-2.4.0.0/sample-suse-10-mkkmp.spec
dkms-2.4.0.0/sample-suse-9-mkkmp.spec
dkms-2.4.0.0/sample.conf
dkms-2.4.0.0/sample.spec
dkms-2.4.0.0/template-dkms-mkdeb/
dkms-2.4.0.0/template-dkms-mkdeb/Makefile
dkms-2.4.0.0/template-dkms-mkdeb/debian/
dkms-2.4.0.0/template-dkms-mkdeb/debian/README.Debian
dkms-2.4.0.0/template-dkms-mkdeb/debian/changelog
dkms-2.4.0.0/template-dkms-mkdeb/debian/compat
dkms-2.4.0.0/template-dkms-mkdeb/debian/control
dkms-2.4.0.0/template-dkms-mkdeb/debian/copyright
dkms-2.4.0.0/template-dkms-mkdeb/debian/dirs
dkms-2.4.0.0/template-dkms-mkdeb/debian/postinst
dkms-2.4.0.0/template-dkms-mkdeb/debian/prerm
dkms-2.4.0.0/template-dkms-mkdeb/debian/rules
dkms-2.4.0.0/template-dkms-mkrpm.spec
dkms-2.4.0.0/template-dkms-redhat-kmod.spec
dkms-2.4.0.0/test/
dkms-2.4.0.0/test/README
dkms-2.4.0.0/test/dkms_test-1.0/
dkms-2.4.0.0/test/dkms_test-1.0/Makefile
dkms-2.4.0.0/test/dkms_test-1.0/dkms.conf
dkms-2.4.0.0/test/dkms_test-1.0/dkms_test.c
dkms-2.4.0.0/template-dkms-mkdsc
dkms-2.4.0.0/Makefile
So in addition to the Makefile being wrong, there is something messed up with the top-level dir in either the github release artifact or the Makefile's expecting it to simply be 'dkms'.
Symptoms are the same as for #53. This issue isn't present in DKMS 2.4, but is in 2.6.
Hello,
I have an RPM that uses dkms with --rpm_safe_upgrade in its %post and %preun sections, and it uses them essentially the same way as in dkms's sample.spec:
%post
dkms add -m modname -v %{modver} --rpm_safe_upgrade
dkms build -m modname -v %{modver}
dkms install -m modname -v %{modver}
%preun
dkms remove -m modname -v %{modver} --all --rpm_safe_upgrade
As far as I can tell, though, this doesn't work when upgrading from one release of the package to the next, without the module version changing. dkms add
with --rpm_safe_upgrade
exits out with a complaint that the module version is already added, but it exits before writing the rpm_safe_upgrade lock file. When dkms remove
is called later in the%preun section, it sees no lock file and so uninstalls the module.
Shouldn't add_module() write the rpm_safe_upgrade lock file before exiting due to an existing module with the same version? I hacked my /usr/sbin/dkms to do this and it all worked as expected.
Thanks!
-lars
Hi.
i've build a vmware modules dkms rpm for SUSE
But dkms.service here and on software.opensuse.com have "[Install] WantedBy=multi-user.target" and opensuse sources also have "[Unit] Before=display-manager.service".
Problem is that vmware workstation 12.5 /etc/init.d/vmware service seems to run parallel with dkms build (because of vmnet dhcp service) and won't start because module build is not finished.
After boot is complete you can restart the failed vmware service without a problem.
Question is: Is there any reason for the systemd target in dkms.service ? Can i change service file safely to ??:
[Unit] section:
Before=network-pre.target
Wants=network-pre.target
And what is the first safe run target in systemd for dkms ?
Best regards
I have observed an inconsistency in the behavior of DKMS regarding the substitution of the variables $kernelver
and $arch
in build scripts.
It is documented that $kernelver
within dkms.conf
will be substituted with the version of the kernel the module is being built for. This appears to extend to build scripts (PRE_BUILD
, POST_BUILD
, etc.) specified within the conf file: guides such as this one use it within their own build scripts, as part of a setup that presumably works for them.
I confirmed this behavior when initially performing a dkms install
for a module on my current kernel: my script was executed with the proper values filled in for the variables. It was during a later kernel update that I noticed my modules weren't being signed automatically. After some digging, I discovered that the dkms autoinstall
command run by the kernel update script was not substituting these variables in my script, naturally causing the signing to fail. (The module was otherwise built correctly.)
For now, I've rewritten my script to take these variables as command-line parameters rather than relying on substitution by DKMS. (dkms autoinstall
still performs substitutions in dkms.conf
; the line POST_BUILD="sign.sh $kernelver $arch"
behaves as expected.)
I observed this behavior with DKMS version 2.6 on Fedora 29.
As a side note, I greatly appreciated the quantity of comments present in the scripts comprising DKMS itself; they were quite helpful in tracing the control flow involved, even though I never discovered the root cause. 😅
Hi there, thank you for DKMS, I absolutely appreciate that tool!
Have you ever thought about an automated way for signing DKMS modules?
Like described here:
https://gist.github.com/dop3j0e/2a9e2dddca982c4f679552fc1ebb18df
Cheers, Flo
In https://bugs.debian.org/931017 I reported how "dkms install" of virtualbox-guest modules breaks the running debian installer by loading the newly built modules but also other unrelated modules that were not loaded by debian-installer.
The rationale given in f5bfb12 which added this problematic modprobe call does not apply to Debian at all since the "dkms install" happens at package installation time and not on the next reboot...
So it would be nice to be able to disable this module loading feature... for the installer, where the calls to "dkms install" are embedded behind package installations, it would be best if we could set an environment variable that would disable this feature. But I imagine that an entry in the configuration file would also be useful so that the Debian package maintainer can opt to disable this entirely... a command line switch would also seem logical.
I'm looking at the documentation for mkbmdeb, and it looks quite useful. I was wondering, however, why there isn't an analogous option for RPMs. Is there a technical reason for this?
Hi folks,
I have a simple kernel module that I need to distribute to CentOS 7.3 and 7.4 hosts. I've created a DKMS RPM to facilitate this and added a requirement on kernel-devel
.
Requires: kernel-devel
This seemed to work at first. However, some of our 7.3 hosts have a newer kernel version installed than the stock 7.3 kernel
~% yum list installed | grep ^kernel
kernel.x86_64 3.10.0-514.el7 @anaconda/7
kernel.x86_64 3.10.0-514.26.2.el7 @tbs-server
kernel-devel.x86_64 3.10.0-514.el7 @anaconda/7
kernel-headers.x86_64 3.10.0-514.el7 @anaconda/7
~% uname -r
3.10.0-514.26.2.el7.x86_64
So kernel-devel-3.10.0-514.26.2.el7
is required for compiling the kernel module I'm distributing, but the RPM's requirement is satisfied by the installed kernel-devel-3.10.0-514.el7
. Due to this the dkms build
step fails.
I cannot simply add a requirement on a specific kernel version because the 7.4 hosts have a newer version of the kernel, and this would defeat the purpose of the DKMS RPM.
How can I ensure the same kernel-devel
package as the currently running kernel is installed? Or is there a canonical way of handling such problems? Should I check for this during RPM's %install
and fail installation?
As mentioned here (#12) but closed by the OP.
It is still the same problem.
Hello,
Preparing the package of the last release of dkms (2.6.1), I noticed that rmdir errors are displayed during modules removal. This happens with modules built with 2.6.1 and previous.
The following example shows the issue with virtualbox modules.
# ls /usr/lib/modules/4.9.79-seblu/kernel/misc
vboxdrv.ko.xz vboxnetadp.ko.xz vboxnetflt.ko.xz vboxpci.ko.xz
# dkms remove vboxhost/5.2.12_OSE -k 4.9.79-seblu
-------- Uninstall Beginning --------
Module: vboxhost
Version: 5.2.12_OSE
Kernel: 4.9.79-seblu (x86_64)
-------------------------------------
Status: Before uninstall, this module version was ACTIVE on this kernel.
vboxdrv.ko.xz:
- Uninstallation
- Deleting from: /usr/lib/modules/4.9.79-seblu/kernel/misc/
rmdir: failed to remove 'kernel/misc': Directory not empty
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
vboxnetflt.ko.xz:
- Uninstallation
- Deleting from: /usr/lib/modules/4.9.79-seblu/kernel/misc/
rmdir: failed to remove 'kernel/misc': Directory not empty
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
vboxnetadp.ko.xz:
- Uninstallation
- Deleting from: /usr/lib/modules/4.9.79-seblu/kernel/misc/
rmdir: failed to remove 'kernel/misc': Directory not empty
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
vboxpci.ko.xz:
- Uninstallation
- Deleting from: /usr/lib/modules/4.9.79-seblu/kernel/misc/
rmdir: failed to remove directory 'kernel': Directory not empty
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
depmod...
DKMS: uninstall completed.
# ls /usr/lib/modules/4.9.79-seblu/kernel/misc
ls: cannot access '/usr/lib/modules/4.9.79-seblu/kernel/misc': No such file or directory
Despite the several error messages, the misc directory is finally removed.
In a regular Arch Linux updates, it looks like that:
:: Do you want to remove these packages? [Y/n]
:: Running pre-transaction hooks...
(1/2) Remove DKMS modules
==> dkms remove vboxhost/5.2.12_OSE -k 4.9.79-seblu
rmdir: failed to remove 'kernel/misc': Directory not empty
rmdir: failed to remove 'kernel/misc': Directory not empty
rmdir: failed to remove 'kernel/misc': Directory not empty
rmdir: failed to remove directory 'kernel': Directory not empty
(2/2) kernel-install remove
:: Processing package changes...
Hi!
I try to make a DKMS for the linux media drivers.
The problem is, that the media build systems builds the modules depending on the Kernel version.
If I specify all possible modules in the dkms.conf file, the build will fail if the media build system does not built all the modules do to the currently built Kernel version and modules not supported for it.
Do you see any chance how I can realize a DKMS supporting this?
I thought to generate the dkms.conf dynamically depending on the Kernel version, but this requires a kind of DKMS chaining because DKMS reads the configuration only once.
Any further help is very welcome.
BR,
Jasmin
Hi,
In order to build one module, I need to have the complete kernel source tree.
I'm trying to use DKMS on CentOS7 to build it.
However, using the option --kernelsourcedir
seems to have no effect. And indeed, since kernel headers are already installed in /usr/src
and linked into /lib/modules/<kernel_version>/build
, the dkms build
uses it instead of my custom parameter.
Is there anything I missed from the documentation?
If one has set its env var POSIXLY_CORRECT (which is default for all our users and admins), DKMS fails and prevents proper kmod compilation/installation and screws up installation of packages, which depend on in (direct or indirect). E.g.:
# apt-get install --no-install-recommends nvidia-384 nvidia-settings libcuda1-384 nvidia-opencl-icd-384 fakeroot
Reading package lists... Done
...
Loading new nvidia-384-384.66 DKMS files...
/usr/sbin/dkms: line 193: syntax error near unexpected token `<'
/usr/sbin/dkms: line 193: ` done < <(module_status_built "$module" "$module_version")'
dpkg: error processing package nvidia-384 (--configure):
subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of libcuda1-384:
libcuda1-384 depends on nvidia-384 (>= 384.66); however:
Package nvidia-384 is not configured yet.
...
I'm not sure, why such an obscure syntax like while read line; do : ; done < <($cmd)
is used.
IMHO all such occurences should be replaced by the POSIX compatible ($cmd) | while read line; do : ; done
syntax.
Version = 2.3-3ubuntu9
Distrib = Ubuntu 18.04
I had a issue with a nvidia module in dkms tree (maybe incorrect uninstall), the directory was missing
dkms.conf file.
dkms ends brutally saying dkms.conf file missing, but without checking other directories.
Feature Requested : Script should warn user which module is broken, and continue applying others modules.
dkms currently supports a flag to run in quiet mode, -q
. The problem with this mode is that it is so quiet that it actually doesn't output anything at all, even errors are silenced. This is a problem for example in the dkms hooks in Arch Linux, where -q
used to be used but got finally replaced with > /dev/null
to avoid silencing errors (see [1], [2]).
I think that a less quiet mode would be more useful. I don't think it is expected of a program like dkms to silence error messages even in quiet mode, so the semantics of -q
could be modified. Otherwise, a new option might be added, I think both options make sense.
[1] : https://bugs.archlinux.org/task/49080
[2] : https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/dkms&id=71ad07ba08fa92023219e54ba44867fd2833046d
I have a module (a fork of RecalBox's mk_arcade_joystick_rpi for a RetroPie handheld, the Freeplay CM3) that I have been fiddling with the the past few days, trying my hardest to get DKMS to reinstall the module whenever the kernel and kernel headers are updated, but to no avail. I have tried the following:
Editing the Makefile and dkms.conf to get the Kernel version, as demonstrated in this bug report
Various things in the AUTOINSTALL field of the dkms.conf file, all referenced in different online resources. This includes:
AUTOINSTALL=YES
AUTOINSTALL="YES"
AUTOINSTALL=yes
AUTOINSTALL="yes"
AUTOINSTALL=Y
And I have verified that I am installing the module as multiple online resources have shown:
sudo dkms add -m mk_arcade_joystick_rpi -v VERSION_NUMBER
sudo dkms build -m mk_arcade_joystick_rpi -v VERSION_NUMBER
sudo dkms install -m mk_arcade_joystick_rpi -v VERSION_NUMBER
# To verify installation
dkms status
# And activate
sudo modprobe mk_arcade_joystick_rpi
The module works as intended after the modprobe, but as soon as I update the kernel and headers with apt update and apt upgrade, the module is no longer installed. I'd like to get this figured out since it affects all the users of the handheld and so it can be implemented in other modules that we use.
I'm not sure if this is a bug. If a DKMS module/module-version has been added, built and installed for a single kernel/arch, and is then removed for that kernel/arch it is removed completely and cannot be built and installed for another kernel/arch until it is added again manually.
The relevant part of the dkms script is:
# Delete the $module_version part of the tree if no other $module_version/$kernel_version dirs exist
if ! find $dkms_tree/$module/$module_version/* -maxdepth 0 -type d 2>/dev/null | egrep -qv "(build|tarball|driver_disk|rpm|deb|source)$"; then
echo $""
echo $"------------------------------"
echo $"Deleting module version: $module_version"
echo $"completely from the DKMS tree."
echo $"------------------------------"
rm -rf "$dkms_tree/$module/$module_version"
echo $"Done."
fi
This looks as if the module/version should not be removed completely if $dkms_tree/$module/$module_version/source
is a directory. It is usually a symbolic link, and the above find
command will not find it in that case. Perhaps the above find
command should use the -H
or -L
option so that it finds the source
symlink. Or perhaps the module version should not be removed completely unless the --all
option is given.
When the system '/bin/sh' points to zsh shell, the script is run
with zsh in sh compatibility mode; this requires functions end
with either a semicolon or a newline.
In that case, the script fails with a parse error in function log_end_msg.
Hi!
While testing my new media-build-dkms (https://github.com/jasmin-j/media_build/tree/dkms-master), I discovered several issues concerning the install/uninstall commands.
First of all dkms uses the version got from command modinfo to decide, if a newly built module is newer or equal than the existing one. I am not sure if this is really sufficient.
In my case there are several drivers which didn't increase the version, but the underlying media-core has been changed heavily. So they haven't been installed, although they should. When I want to solve this, I would need "--force". But the "dkms_common.postinst" has no possibility to add "--force" by e.g. an environment variable.
Even more, "template-dkms-mkdeb/debian/postinst", prefer the system wide installed "common.postinst" script. So there is no possibility for a package maintainer to add the "--force" option, other than writing his own postinst script.
I would suggest to add a possibility to add options to the dkms commands used in "common.postinst" preferably by environment variables, because they can be easily set in the package "debian/postinst" file or even at the command line of the "apt-get ..." command.
When it comes to package removing, dkms checks if the installed module and the one from the dkms module directory (/var/lib/dkms/////module) are the same. In case when the module was not installed, "find_actual_dest_module_location" will return an empty string which will let variable "real_dest_module_location" empty, which will then lead to an error of the "rm -f ..." command:
cx24117.ko:
- Uninstallation
- Deleting from: /lib/modules/3.13.0-117-generic/
rmdir: failed to remove ‘’: No such file or directory
- Original module
- No original module was found for this module on this kernel.
- Use the dkms install command to reinstall any previous module version.
I see here some problems.
a) It is not a good idea to check the module version when installing, but the whole file when uninstalling. This is inconsistent. I don't know if it would be possible to diff the modules at the install step also, instead of checking the version. This would also solve the problem mentioned in the beginning. On the other hand, the modules might be always different, if there is a date or time stored in the module .ko file, which I don't know.
Another possibility would be to check in the uninstall function also the versions from modinfo, but this would not uninstall the module, if it was installed with "--force". So this is no solution.
b) When "real_dest_module_location" is empty, no module was installed, so it would be the best to simply do nothing (doing a continue).
BR,
Jasmin
Building every module fails with similar error:
DKMS make.log for sysdig-0.24.1 for kernel 4.20.0-rc2 (x86_64)
make: Entering directory '/usr/lib/modules/4.20.0-rc2/build'
CC [M] /var/lib/dkms/sysdig/0.24.1/build/main.o
CC [M] /var/lib/dkms/sysdig/0.24.1/build/dynamic_params_table.o
CC [M] /var/lib/dkms/sysdig/0.24.1/build/fillers_table.o
CC [M] /var/lib/dkms/sysdig/0.24.1/build/flags_table.o
Assembler messages:
Error: can't open arch/x86/kernel/macros.s for reading: No such file or directory
make[1]: *** [scripts/Makefile.build:293: /var/lib/dkms/sysdig/0.24.1/build/dynamic_params_table.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Assembler messages:
Error: can't open arch/x86/kernel/macros.s for reading: No such file or directory
make[1]: *** [scripts/Makefile.build:293: /var/lib/dkms/sysdig/0.24.1/build/flags_table.o] Error 1
Assembler messages:
Error: can't open arch/x86/kernel/macros.s for reading: No such file or directory
make[1]: *** [scripts/Makefile.build:293: /var/lib/dkms/sysdig/0.24.1/build/fillers_table.o] Error 1
Assembler messages:
Error: can't open arch/x86/kernel/macros.s for reading: No such file or directory
./arch/x86/include/asm/atomic.h:167: Error: no such instruction: `lock_prefix xaddl %r12d,44(%rbx)'
./arch/x86/include/asm/atomic.h:110: Error: no such instruction: `lock_prefix decl 44(%rbx)'
./arch/x86/include/asm/atomic.h:110: Error: no such instruction: `lock_prefix decl 44(%rbx)'
./arch/x86/include/asm/bitops.h:76: Error: no such instruction: `lock_prefix orb $16,g_events_mask+18(%rip)'
./arch/x86/include/asm/bitops.h:76: Error: no such instruction: `lock_prefix orb $32,g_events_mask+18(%rip)'
./arch/x86/include/asm/bitops.h:81: Error: no such instruction: `lock_prefix btsq %r12,g_events_mask(%rip)'
./arch/x86/include/asm/bitops.h:118: Error: no such instruction: `lock_prefix btrq %r12,g_events_mask(%rip)'
make[1]: *** [scripts/Makefile.build:293: /var/lib/dkms/sysdig/0.24.1/build/main.o] Error 1
make: *** [Makefile:1568: _module_/var/lib/dkms/sysdig/0.24.1/build] Error 2
make: Leaving directory '/usr/lib/modules/4.20.0-rc2/build'
DKMS make.log for wireguard-0.0.20181018 for kernel 4.20.0-rc2 (x86_64)
Mon Nov 12 14:57:31 CET 2018
make: Entering directory '/usr/lib/modules/4.20.0-rc2/build'
CC [M] /var/lib/dkms/wireguard/0.0.20181018/build/main.o
CC [M] /var/lib/dkms/wireguard/0.0.20181018/build/noise.o
CC [M] /var/lib/dkms/wireguard/0.0.20181018/build/device.o
CC [M] /var/lib/dkms/wireguard/0.0.20181018/build/peer.o
Assembler messages:
Error: can't open arch/x86/kernel/macros.s for reading: No such file or directory
make[1]: *** [scripts/Makefile.build:293: /var/lib/dkms/wireguard/0.0.20181018/build/main.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Assembler messages:
Error: can't open arch/x86/kernel/macros.s for reading: No such file or directory
./arch/x86/include/asm/atomic64_64.h:160: Error: no such instruction: `lock_prefix xaddq %rax,peer_counter(%rip)'
./arch/x86/include/asm/bitops.h:76: Error: no such instruction: `lock_prefix orb $32,1600(%rbx)'
./arch/x86/include/asm/bitops.h:114: Error: no such instruction: `lock_prefix andb $-2,1600(%rbx)'
./arch/x86/include/asm/bitops.h:114: Error: no such instruction: `lock_prefix andb $-9,1600(%rbx)'
./arch/x86/include/asm/jump_label.h:23: Error: no such instruction: `static_branch_nop l_yes=".L15"key="descriptor.64810+40"branch="0"'
./include/linux/netdevice.h:515: Error: no such instruction: `asm_bug ins=".byte 0x0f, 0x0b"file=.LC0 line=515 flags=0 size=12'
./include/linux/netdevice.h:515: Error: no such instruction: `annotate_unreachable counter=83'
./arch/x86/include/asm/jump_label.h:23: Error: no such instruction: `static_branch_nop l_yes=".L40"key="descriptor.64844+40"branch="0"'
./arch/x86/include/asm/jump_label.h:23: Error: no such instruction: `static_branch_nop l_yes=".L59"key="descriptor.64844+40"branch="0"'
make[1]: *** [scripts/Makefile.build:293: /var/lib/dkms/wireguard/0.0.20181018/build/peer.o] Error 1
Assembler messages:
Error: can't open arch/x86/kernel/macros.s for reading: No such file or directory
./arch/x86/include/asm/jump_label.h:23: Error: no such instruction: `static_branch_nop l_yes=".L6"key="descriptor.66172+40"branch="0"'
./arch/x86/include/asm/jump_label.h:23: Error: no such instruction: `static_branch_nop l_yes=".L32"key="descriptor.66236+40"branch="0"'
/var/lib/dkms/wireguard/0.0.20181018/build/device.c:396: Error: no such instruction: `asm_bug ins=".byte 0x0f, 0x0b"file=.LC11 line=396 flags=2305 size=12'
/var/lib/dkms/wireguard/0.0.20181018/build/device.c:396: Error: no such instruction: `annotate_reachable counter=169'
./arch/x86/include/asm/bitops.h:76: Error: no such instruction: `lock_prefix orb $32,328(%rax)'
make[1]: *** [scripts/Makefile.build:293: /var/lib/dkms/wireguard/0.0.20181018/build/device.o] Error 1
Assembler messages:
Error: can't open arch/x86/kernel/macros.s for reading: No such file or directory
./arch/x86/include/asm/atomic64_64.h:160: Error: no such instruction: `lock_prefix xaddq %rax,keypair_counter(%rip)'
make[1]: *** [scripts/Makefile.build:293: /var/lib/dkms/wireguard/0.0.20181018/build/noise.o] Error 1
make: *** [Makefile:1568: _module_/var/lib/dkms/wireguard/0.0.20181018/build] Error 2
make: Leaving directory '/usr/lib/modules/4.20.0-rc2/build'
As someone who regularly remove/install dkms, I found specifying the module version is redundant in most cases.
I'd like to use dkms install <module>
instead of dkms install <module>/<version>
, if there's only one version of the module.
If this new behavior is acceptable and does not break scripts that already depend on DKMS, I can make a patch for this.
Can't remove dkms on centos 6.
see following:
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
/var/tmp/rpm-tmp.fXOK7F: line 3: fg: no job control
error: %preun(dkms-2.2.0.3-30.1.noarch) scriptlet failed, exit status 1
Error in PREUN scriptlet in rpm package dkms
dkms-2.2.0.3-30.1.noarch was supposed to be removed but is not!
Verifying : dkms-2.2.0.3-30.1.noarch 1/1
Failed:
dkms.noarch 0:2.2.0.3-30.1
Complete!
[root@applied-db2prod-1 ~]#
Hi!
My DKMS installs/uninstalls 617 modules.
The install step is pretty fast (appr. 40..60 seconds), but the uninstalling takes 40 minutes.
I tracked this down to this code in "do_uninstall":
echo $" - No original module was found for this module on this kernel."
echo $" - Use the dkms install command to reinstall any previous module version."
# Remove modules_conf entries from /etc/modules.conf if remake_initrd is set or if this is last instance removed
if [[ $remake_initrd ]] || (do_status $module $module_version | grep -q "installed"); then
echo $""
moduleconfig_remove "$1"
fi
This gets executed for each "*.ko" module. It calls "do_status" and this calls "is_module_built" resulting in reading dkms.conf and checking if the modules exists in the file system.
Is this part really required to be executed for each module in dkms.conf?
The time required for this is a quadratic function of the installed modules.
I did a test with putting this code in front of the loop:
if (do_status $module $module_version | grep -q "installed"); then
was_installed="true"
fi
And checking it after the loop:
if [[ $remake_initrd && $was_installed ]]; then
echo $""
moduleconfig_remove "$1"
fi
This worked on my Ubuntu machine really fast now (20..30 sec).
I suggest to modify "do_uninstall" either the way I did or to find another solution which doesn't traverse the whole modules for each uninstall module (quadratic effort).
BR,
Jasmin
Here I resize the xterm in the middle of remove and install, crashing both.
:: Running pre-transaction hooks...
(1/1) Remove DKMS modules
==> dkms remove perle-serial/3.9.2_4 -k 4.9.106-1-lts49
==> dkms remove perle-serial/3.9.2_4 -k 4.4.135-1-lts44
==> dkms remove perle-serial/3.9.2_4 -k 4.16.13-2-dosemu
error: command terminated by signal 13: Broken pipe
:: Processing package changes...
(1/1) reinstalling perle-serial [##] 100%
:: Running post-transaction hooks...
(1/5) sync all file systems
(2/5) Install DKMS modules
==> dkms install perle-serial/3.9.2_4 -k 4.9.106-1-lts49
==> dkms install perle-serial/3.9.2_4 -k 4.4.135-1-lts44
error: command terminated by signal 13: Broken pipe
(3/5) Reloading system manager configuration...
(4/5) Arming ConditionNeedsUpdate...
(5/5) sync all file systems
$ pacman -Q dkms gnome-terminal xterm
dkms 2.5-3
gnome-terminal 3.28.2-1
xterm 333-1
DKMS will complete so long as I don't resize the xterm.
This seems to be recent behavior because I've fidgeted with windows while waiting for a long time and I've only noticed this recently.
Though I realise this may be unusual to be required, I was hoping that a compile order could be implemented. I have been running ZFS on Linux using Arch Linux and have found that the two modules required for ZFS to work have a compile order dependency. If DKMS installs the ZFS module before the SPL module the ZFS module will fail to install. It then becomes necessary to trigger the ZFS module install again the first attempt has completed and the remake the kernel images. I have found that over several kernel updates I have had several times where the compile order is okay and others where it is not. All works fine as long as SPL is installed before ZFS by DKMS. I am requesting that a feature be added to allow for module dependencies or at the very least be able to specify in a config file any modules that you wish to have compiled in a specific order. If this is already a feature, could you please tell me how to configure it. Thanks.
When uninstalling dkms does not move original_module back to it's original location but puts it in /updates. This leads to orphaned directory trees in /lib/modules because package managers don't know the files in /updates.
pacman warning when upgrading package:
warning: could not get file information for usr/lib/modules/4.19.0-rc8-r1540570303-g18d0eae30-1-c0/kernel/drivers/platform/x86/hdaps.ko
dkms output:
[c0d3@z3r0 linux-c0]$ sudo dkms install tp_smapi-dkms/0.42 -k 4.19.0-rc8-r1540570303-g18d0eae30-1-c0
[...]
hdaps.ko:
Running module version sanity check.
- Original module
- Found /usr/lib/modules/4.19.0-rc8-r1540570303-g18d0eae30-1-c0/kernel/drivers/platform/x86/hdaps.ko
- Storing in /var/lib/dkms/tp_smapi-dkms/original_module/4.19.0-rc8-r1540570303-g18d0eae30-1-c0/x86_64/
- Archiving for uninstallation purposes
- Installation
- Installing to /usr/lib/modules/4.19.0-rc8-r1540570303-g18d0eae30-1-c0/updates/
[...]
DKMS: install completed.
[c0d3@z3r0 linux-c0]$ sudo dkms uninstall tp_smapi-dkms/0.42 -k 4.19.0-rc8-r1540570303-g18d0eae30-1-c0
[...]
hdaps.ko:
- Uninstallation
- Deleting from: /usr/lib/modules/4.19.0-rc8-r1540570303-g18d0eae30-1-c0/updates/
- Original module
- Archived original module found in the DKMS tree
- Moving it to: /usr/lib/modules/4.19.0-rc8-r1540570303-g18d0eae30-1-c0/updates/
[...]
DKMS: uninstall completed.
IMHO dkms should not touch original kernel modules at all. Just leave them where they are and put the update module to /update. The only case in which a module should be moved is a module with the same name already being in /updates.
Hi all,
apart from kernel modules, I would like to install device tree overlays using DKMS.
The key differences here are:
(1) file extension, *.dtbo instead of *.ko
(2) installation destination, for example, /boot/overlays/ instead of /lib/modules//kernel/
What would be a clean way to do it?
Any hints are highly appreciated.
Best regards
Sergej
Starting with Linux 5.2-rc1, the option Enable kernel header artifacts through /proc/kheaders.tar.xz (IKHEADERS_PROC)
is available in the kernel configuration. I think it would be good to use this, if available.
Module compression was added to set_module_suffix. An errant set_module_suffix that was harmless before the compression update gets the suffix for the currently running kernel $(uname -r) rather than the -k specified kernel. Installation fails on kernels where the module is built as a .gz appropriate for the specified kernel version but copied as an .xz appropriate for the running kernel version.
How to reproduce.
The module to the xz kernel will compile and copy. The module to the gz kernel will compile but copy will fail with cp cannot stat " no such file or directory
. dkms status
reports (WARNING! Diff between built and installed module!)
.
I installed a patch for alx.ko module and i noticed the original module is alx.ko.gz, but DKMS puts alx.ko into /lib/modules/4.13.12-1-ARCH/kernel/drivers/net/ethernet/atheros/alx/ thus kernel is loading the wrong module!
How can i make DKMS create and replace the alx.ko.gz module?
I'm running Arch Linux.
Is there some way to make auto install always --force from dkms.conf? Or perhaps, some way to skip the version check? If the module is using the git hash as its module version, then it is not comparable in any regular way.
I tried to use PRE_INSTALL="true", as the man page said that PRE_INSTALL could be used for a custom version check, and that did not work. Also, I tried PRE_INSTALL="dkms install --force -m ..." in an attempt to just hack around the version check, but it didn't work either.
This is the attempted use of DKMS that fails when the kernel package is updated, for reference: https://github.com/groeck/it87/commit/6c1e48b4f16b65b6e2ff95d950b250581b0cbe91
The man page for dkms says the following of dkms mkdeb:
It uses a template debian directory found in /etc/dkms/template-dkms-mkdeb as the basis for the package. Alternatively, if DKMS finds a file called /usr/src/<module>-<module-version>/<module>-dkms-mkdeb it will use that folder instead.
That seems to be wrong. The dkms script actually uses "$dkms_tree/$module/$module_version/source/$module-dkms-mk${create_type}"
. The ${module}-dkms-mkdeb dir
should be placed in the source dir (i.e. what gets passed to dkms build --sourcetree
).
I presume the same applies for all the other dkms mk* variants.
Fedora compresses it's kernel modules as xz since version 21 of the distribution.
This results in kernel modules having a .ko.xz suffix.
DKMS' set_module_suffix function does not handle this case. Therefor previously installed modules in the kernel tree are not found.
This problem surfaces when replacing a module that lives in Fedora's kernel-modules-extra package. Those kernel modules are installed into /extra and thus they override even their DKMS installed and updated version.
Example: batman-adv
Lives in the kernel-modules-extra package: /lib/modules/4.8.6-300.fc25.x86_64/extra/net/batman-adv/batman-adv.ko.xz
DKMS installs it's version as: /lib/modules/4.8.6-300.fc25.x86_64/extra/batman-adv.ko
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.