The patch is attached.

What is does is to change the Makefile to install dkms_autoinstaller as /etc/rc.d/rc.dkms_autoinstaller. That file then needs to be invoked from somewhere, however rc.local is too late for some modules to be rebuilt & loaded; best place to invoke it is rc.S just before modules have dependencies updated and are loaded. However we don't want to mess lightly with rc.S so the patch has a doinst.sh which creates an rc.S.new file - an exact copy of rc.S but including the call to rc.dkms_autoinstaller in the usual way. If a sys admin really wants it, they can mv /etc/rc.d/rc.S.new /etc/rc.d/rc.S so that the rc.dkms_autoinstaller script (if executable) will run at the next reboot.

chris

Attached Files

dkms-autoinstaller.diff.txt (4.0 KB, 37 views)

3 members found this post helpful.

That is often the case with Debian or Red Hat based init scripts.

To throw more sand in the gears: if this DKMS thingie starts working in Slackware, does DKMS create a new package or only rebuilds the respective kernel module? For example, if DKMS only rebuilds the module, then reinstalling the original VirtualBox or Nvidia packages will overwrite the rebuilt module. If DKMS only rebuilds the module, then are we losing "administrative control" or "configuration management" of what is actually installed on a system because of the mismatch between the rebuilt module and original package?

No, I don't know how this DKMS process actually works in other distros. Only that I have seen the process automatically kick in often when doing updates.

Just a note: the VirtualBox, when it is installed from their shipped installer at least, auto-compile the kernel modules, when a new kernel is installed and those VirtualBox modules are not found.

It just rebuilds the module.

In the nvidia case, I user the raw installer which includes an option to add itself to dkms and I'm sure that option could be included in the SBo version too. Same for Virtual Box I imagine - it's not very hard to add dkms support.

chris

I understand. The challenge is this option is disabled in the slackbuilds.org rc.d script.

It's been a while since I played with it, and I didn't do much other than figure out how to get the amdgpu-pro driver to compile with it. With that in mind, here's my thoughts (some of which may be wrong).

Depending on how the SlackBuild/package handles things, you can have the module built and installed during the package creation (which means that particular module is in pkgtool's database). Others may just install the source and have the module created later. But the modules (at least how I had it set up) would go under /lib/modules/$KERNEL_VERSION/, so if a new kernel was added, and the module was rebuilt, it should keep the old and new versions (which can be beneficial if you need to revert to the older kernel). However, any modules built after the initial package creation will not be removed if you uninstall that package, because they won't be tracked by pkgtool (and Slackware doesn't support running scripts when uninstalling a package).

I think any time you leave something to be automated, you lose some "administrative control", but sometimes that loss is made up for by the convenience of the automation. It is up to the individual on whether the benefits of that convenience outweighs the loss of some administrative control.

Although, this did get me thinking... I wonder if you could tweak dkms to add any new modules created to the package's entry in /var/log/packages/ which could allow them to be removed later. But it probably wouldn't be worth the effort to do so...

The module to be deleted needs to be removed from dkms' "database" too (not just from the file system). That is typically done with a command like 'dkms remove -m MODULE_NAME -v NODULE_VERSION --all' but Slackware doesn't run any scripts at package removal time (like doinst.sh at package installation time). Without that, a new module would be built at next reboot with a new kernel.

Maybe one could do like you suggest (add an entry in /var/log/packages/package_entry) and then something could run in rc.local_shutdown which checks if any module in dkms' database has disappeared from /var/log/packages/package_entry (or even just whether package_entry itself still exists) and if there's a discrepancy, run 'dkms remove ...'. Then by the time the system reboots, dkms won't try to rebuild the module.

chris

1 members found this post helpful.

I know with the way I had amdgpu-pro's dkms stuff set up, the SlackBuild would create the directory within /var/lib/dkms/, so it would be tracked by pkgtool (and would be removed if the package was removed). It would also compile the module during the SlackBuild process, so all resulting files from that initial compilation would be tracked. But I never went through any kernel changes after I installed the package, so I'm not sure how much a new kernel would change those files, nor what additional untracked files might be added...

And it's likely handled differently by different SlackBuild maintainers...

I understand your point. I think configuration management remains important. Most admins, even many home user "admins," want to know for certain what is installed and when. As DKMS is common and popular among other distros, I presume maintainers have a way to provide configuration management. Possibly that management is provided through the DKMS database rather than traditional package management. I have an Ubuntu MATE system running VMs and I know DKMS is used. I will look at system to see if I notice anything.

The Ubuntu MATE system (16.04.2) has a package named virtualbox-dkms. Basically the source code for building the kernel module. Looks like the packages installs to /var/lib/dkms/virtualbox. I did not look into how the process triggers or whether the package is recreated and updated in /var/cache/apt/archives.

It is likely just the source and the actual modules aren't tracked with the package. It might have some post-installation script to start the dkms building, or it could just occur semi-automatically when dkms detects new source being added.