Details
-
Improvement
-
Resolution: Fixed
-
Blocker
-
None
-
5847
Description
dkms is a cross distro mechanism for the building and maintenance of out-of-tree kernel modules.
(http://linux.dell.com/dkms/) The attached patch adds dkms support to the debian/ubuntu packaging infrastructure.
The current debian/ubuntu kernel module package uses module-assistant, which produces a deb which is tied to a specific kernel version, requiring the user to manually rebuild packages when the kernel is changed.
The dkms package allows modules for multiple kernel versions to be packaged together into a single deb. Once installed, the package contains triggers so that when a new kernel is installed for which no pre-built lustre modules exists, dkms will automatically build and install them. This reduces maintenance overhead on client machines.
dkms also works on redhat and sles; it should be possible to fold dkms support into the rpm build process.
Attachments
Issue Links
- is duplicated by
-
-
- Resolved
-
- is related to
-
LU-5465 Enhancements to Lustre DKMS RPM
-
- Resolved
-
- is related to
-
-
- Resolved
-
Activity
Ugh. So dkms-2.2.0.3-28.git.7c3e7c5.fc20.noarch doesn't work either now? Is there a version that is known to work? Do we know of a patch to dkms-2.2.0.3-28.git.7c3e7c5.fc20.noarch that will make it work?
I suppose we could just apply the reversion of http://linux.dell.com/cgi-bin/cgit.cgi/dkms.git/commit/dkms?id=2ea43f6108558849125cc1d66902d6992ee3fe39 and take advantage of the bug they fixed until this is more properly fixed.
Interesting. OK, thanks for letting me know of getting it fixed. Unfortunately, it seems to have another problem as of today. There was recently an upstream patch merged which broke things by removing the builds directory. Here's the new ticket https://bugzilla.redhat.com/show_bug.cgi?id=1151123
Brian,
Your update reminds me that I forgot (sorry!) to let you aware of a problem I have found in the "DKMS inter-modules dependencies feature" implementation (ie, BZ #1023598) during our testing of the Lustre DKMS RPM install/build. I reported it as part of FC/RHEL BZs #1140812 / #1143051, which ended in dkms-2.2.0.3-28.
As of dkms-2.2.0.3-20 for EPEL/Fedora we got support merged to allow reliable building of the SPL and ZFS code. The updated version has been in their repository for a while now and we've been able to drop our custom build. See https://bugzilla.redhat.com/show_bug.cgi?id=1023598.
@bruno: Yes, of course ultimately having upstream maintain those packages is the ultimate goal, but where are our customers, running EL6 systems, going to get dkms-2.2.0.3-28 binaries, today? That is the gap that I am proposing we need to fill.
For me the (big?) difference is that we don't need to maintain+build it on our own now!
And we can now make specific dkms-2.2.0.3-28 version a >= Required for our Lustre-DKMS RPM.
Hi bfaccini,
But that's roughly the same thing. The point though is that we are not actively building a working DKMS for our users to use, right?
Hello Brian,
No I am not aware that something has been done to ship a DKMS tool RPM including my patch.
But on the other hand, seems that upstream integration of my fix is done and we need to now use dkms-2.2.0.3-28 RPM/version from Fedora FC[19-21]/EPEL[5-7] distros.
bfaccini: there was mention at one point that we needed a patch in DKMS and that while we wait for upstream to ship that we'd build our own DKMS RPM for EL6 and ship that. Did anything ever come of that?
We should be able to sort this out on our side. It would be best for everyone if we relied on the version of DKMS shipped by the distributions. We're sorting out a reasonable fix now, there's a proposed patch in https://github.com/zfsonlinux/zfs/pull/2776. You'll likely need to make a similar tweak for Lustre.