dkms conquered?

I found the problem. I don’t understand the rationale for the way DKMS is behaving, but here’s what it does…

Let’s say you are running kernel B, and you have kernels A & C also sitting around. And then you install an updated schmegadriver. During the install, the old schmegadriver gets saved off somewhere safe, and the updated schmegadriver gets compiled for kernel B. So far so good! But then, dkms will create links in a “weak-updates” directory from the updated schmegadriver for each of kernels A & C.

Now these weak updates are completely useless, as far as I can see, except to cause pain and suffering. They won’t get used, because your kernels A & C already have the distro schmegadriver installed (the evil one, that causes an endless loop at bootup and occasionally sets local orphanages on fire out of sheer spite) and the weak-updates are links to a schmegadriver that is incompatible with kernels A & C anyway (since it was specifically compiled for kernel B).

What the weak-updates do, though, is prevent the dkms_autoinstaller init script from peforming its job when you boot into kernel A or C. It says, “Oh-ho, there’s a weak update here, no need to build a proper kernel module, let’s burn up all the orphans!” and away you go in a handbasket.

The easiest fix was to hack the dkms_autoinstaller script to delete all “weak updates” automatically. It’s like a anti-feature.

I suppose a proper fix would be to either prevent the weak update links from being created in the first place, or make –autoinstall stop turning itself off when it sees one. I wonder what purpose they were actually intended for? I’m pretty sure the linux guys at Dell don’t hate orphans. Well, reasonably sure.