FFE: Use dkms for openafs-modules

This should not be a problem as far as I see. Someone who knows how the OpenAFS module is built could easily write the necessary dkms.conf file (using an existing file as template,e.g. from the nvidia or virtualbox modules).
I've so far always used module-assistant and don't know how to build the module by hand.

As building kernel modules is a major mystery for new users, I strongly support moving as many modules as possible to an automatic build system.

I managed to get this working (somewhat) with dkms, but it needs to be moulded into a package (openafs-modules-dkms or so). I have no experience with creating deb packages.

1. Dkms expects to find the source code in /usr/src/<module>-<version>/

If you have openafs-modules-source installed, the source is located in /usr/src/modules/<module>/
You have to symlink or copy this the source tree to the right location:
 sudo ln -sf /usr/src/modules/openafs /usr/src/openafs-1.4.7.dfsg1-6

2. Install the dkms.conf file in /usr/src/openafs-1.4.7.dfsg1-6 (attached, taken from the fedora package)

3. Add this source to the dkms tree:
 sudo dkms add -m openafs -v 1.4.7.dfsg1-6

4. Restart the dkms_autoinstaller
 sudo /etc/init.d/dkms_autoinstaller restart
This will be busy quietly compiling for a while. After it's done you will find the new module installed as /lib/modules/2.6.27-10-generic/updates/dkms/openafs.ko

5. Openafs tries to find the module in <moduledir>/fs, but it's not possible to install it there. Therefore you have to append the following lines to /etc/openafs/afs.conf:
 MODULEROOT=/lib/modules/`uname -r`
 MODULEDIR=$MODULEROOT/updates/dkms

6. Restart the openafs-client
 sudo /etc/init.d/openafs-client restart

I think this could be included in the openafs-modules-dkms package as follows:
- openafs-modules-dkms should install the source tree into /usr/src/openafs-<version>
- openafs-modules-dkms should automatically run 'dkms add' for this version (and 'dkms remove' on package removal or update)
- the openafs-client startup script should be modified to also search in the dkms module directory, or the afs.conf file should get some lines appended
- on next boot the dkms_autoinstaller will then compile and install the module, and openafs-client will find that module and load it

florib <email address hidden> writes:

> This should not be a problem as far as I see. Someone who knows how the
> OpenAFS module is built could easily write the necessary dkms.conf file
> (using an existing file as template,e.g. from the nvidia or virtualbox
> modules).

I'm happy to include this in the next revision of the package if someone
feels inspired to do it. That will make it much faster than if I have to
go research it myself, although I will do that eventually since I do want
it to work. But realistically it's going to be a little while before I
can get to it, so I'd welcome contributions.

The debian/rules file in openafs-modules-source does say everything that
one needs to know about how the module is built, although alas you have to
be able to untangle make syntax to figure it out.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

Russ Allbery <email address hidden> writes:

> I'm happy to include this in the next revision of the package if someone
> feels inspired to do it. That will make it much faster than if I have
> to go research it myself, although I will do that eventually since I do
> want it to work. But realistically it's going to be a little while
> before I can get to it, so I'd welcome contributions.

And I see someone already did that before I sent my last message. Thank
you! I'll take a look.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

Maybe some interest, I have well tested openafs packages (1.4.8 + dfsg) with dkms support in my ppa. Work fine, but the compilation (so an upgrade) needs some time. Maybe it's possible to build a static library of some kernel version independent code and only build the "glue-code" by dkms? Has someone already tried this?

Robert Gerlach <email address hidden> writes:

> Maybe some interest, I have well tested openafs packages (1.4.8 + dfsg)
> with dkms support in my ppa. Work fine, but the compilation (so an
> upgrade) needs some time. Maybe it's possible to build a static library
> of some kernel version independent code and only build the "glue-code"
> by dkms? Has someone already tried this?

I think you'll have a hard time finding enough truly version-independent
code in the OpenAFS kernel module to save a substantial amount of time,
although I could be wrong.

Much of the time in a build for me is taken by configure, and much of the
configure time is all the probes of the Linux kernel API.

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>

I'd say that the benefit of not having to manually recompile the kernel outweighs having to wait during dkms rebuild at bootup. Even more since a manual rebuild will take exactly the same amount of time PLUS the time I need to spend initiating the rebuild (and wondering about why afs suddenly isn't working...)

Users who update their kernel (which they don't do every day) expect everything else to just continue working (afs, nvidia etc), so a few minutes wait during startup is way better than telling them to "recompile their afs module".

@Robert Gerlach: Could you post the address for your ppa, please?

You are right, it's nearly impossible.

https://launchpad.net/~khnz/+archive

openafs 1.4.8.dfsg1-2, which was just synced from Debian, contains an implementation of DKMS support that is commented out (because Debian does not yet have a dkms package). I have worked with the Debian maintainer to resolve some bugs in this implementation. These fixes have been committed to the Debian Git tree <git://git.debian.org/git/pkg-k5-afs/openafs.git>.

Here is a debdiff that includes these fixes, and uncomments the new openafs-modules-dkms package from the control file.

The new package is also available in my PPA:
<http://launchpad.net/~anders-kaseorg/+archive/ppa>

I think this will need an FFe at this point in the cycle. Please feel free to seek one following the process at [0] and resubscribe the sponsors if and when we can sponsor something. Thanks.

https://wiki.ubuntu.com/FreezeExceptionProcess

Now that openafs 1.4.8.dfsg1-3, which includes all of the necessary changes, is in Jaunty, only the control file entry for the new openafs-modules-dkms binary package needs to be uncommented. (It is commented in Debian because the Debian dkms package is still in the NEW queue.) Therefore, I request a FFE for this change.

The attached debdiff bumps the version to 1.4.8.dfsg1-3+ubuntu1, updates the maintainer to ubuntu-motu, and uncomments openafs-modules-dkms from debian/control.

(Why -3+ubuntu1 instead of -3ubuntu1? The openafs-modules-source package is built with module-assistant and results in a binary package named openafs-modules-2.6.28-11-generic with version 1.4.8.dfsg1-3+2.6.28-11.38. As it turns out, 1.4.8.dfsg1-3ubuntu1+2.6.28-11.38 would actually be a lower version. The Debian maintainer says that -3+ubuntu1 is consistent with the versioning scheme they use for Debian security updates.)

Risk of regression is very low because this only adds a new binary package and does not change the existing packages. The existing openafs-modules-source package still works with module-assistant as before, so users who do not choose to install openafs-modules-dkms will be unaffected.

As soon as the Debian dkms package enters unstable and openafs-modules-dkms is enabled in Debian, this Ubuntu patch can be dropped.

This package has been built and tested in my PPA. I verified that the openafs-modules-dkms package works correctly. Previous versions of it have been tested across kernel and openafs upgrades.
<https://launchpad.net/~anders-kaseorg/+archive/ppa>
(It is currently rebuilding with the new version number.)

This bug was fixed in the package openafs - 1.4.9.dfsg1-0+ubuntu2

---------------
openafs (1.4.9.dfsg1-0+ubuntu2) jaunty; urgency=low

  [ Anders Kaserog ]
  * Reenable DKMS support, which was commented out of 1.4.8.dfsg1-1.
    (LP: #288743)

 -- Mario Limonciello <email address hidden> Mon, 20 Apr 2009 10:19:38 -0500

The package is uninstallable. I get:

Errors were encountered while processing:
 openafs-modules-dkms
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
Setting up openafs-modules-dkms (1.4.9.dfsg1-0+ubuntu2) ...

Error! Could not find module source directory.
Directory: /usr/src/openafs-1.4.9 does not exist.
dpkg: error processing openafs-modules-dkms (--configure):
 subprocess post-installation script returned error exit status 2

Wow, I was not expecting my 1.4.8 debdiff to be applied to 1.4.9, especially so late in the release cycle. Here is a fix that should make it actually work on 1.4.9.

I built and tested my openafs-modules-dkms 1.4.9.dfsg1-0+ubuntu2 patch on my own machine, and it works fine. As a warning, openafs-modules-dkms 1.4.9.dfsg1-0+ubuntu2 does not uninstall or upgrade cleanly without a lot of forcing, so please avoid installing that.

I hope there’s still time to upload this easy fix.

I built and tested my openafs-modules-dkms 1.4.9.dfsg1-0+ubuntu3 patch on my own machine, and it works fine. As a warning, openafs-modules-dkms 1.4.9.dfsg1-0+ubuntu2 does not uninstall or upgrade cleanly without a lot of forcing, so please avoid installing that.

I hope there’s still time to upload this easy fix.

This bug was fixed in the package openafs - 1.4.9.dfsg1-0+ubuntu3

---------------
openafs (1.4.9.dfsg1-0+ubuntu3) jaunty; urgency=low

  * Fix the version number in the path to the DKMS tree. (LP: #288743)

 -- Anders Kaseorg <email address hidden> Mon, 20 Apr 2009 16:43:46 -0400