This really depends on how this module was installed. The mechanism of DKMS is specifically created for automatic recompiling against the new kernel installed.
Plain kernel modules are only built for very version they were compiled for and keep working when updates do not break the ABI. However, the Ubuntu updates appear to break the ABI quite frequently and require kernel modules to be recompiled. As this is a very much boring and repetitive task, DKMS was invented to overcome this. It inserts hooks in APT to trigger compiling and installing the new version.
To view the current kernel modules installed using DKMS (example):
dkms status
nvidiabl, 0.79, 3.5.0-22-generic, x86_64: installed
nvidiabl, 0.79, 3.7.5-030705-generic, x86_64: installed
nvidia-current, 313.09, 3.5.0-22-generic, x86_64: installed
nvidia-current, 313.09, 3.7.5-030705-generic, x86_64: installed
vboxhost, 4.2.6, 3.5.0-22-generic, x86_64: installed
vboxhost, 4.2.6, 3.7.5-030705-generic, x86_64: installed
Here you can see I have installed some kernel modules into DKMS, only the nvidiabl
one myself, the others were installed by the Nvidia driver package and Virtualbox package.
The modules are located (installed) in a specific directory for each kernel version:
/lib/modules/
├── 3.5.0-22-generic
│ ├── build -> /usr/src/linux-headers-3.5.0-22-generic
│ ├── initrd
│ ├── kernel
│ │ ├── arch
│ │ ├── crypto
│ │ ├── drivers
│ │ ├── fs
│ │ ├── lib
│ │ ├── net
│ │ ├── sound
│ │ └── ubuntu
│ └── updates
│ └── dkms
└── 3.7.5-030705-generic
├── build -> /usr/src/linux-headers-3.7.5-030705-generic
├── initrd
├── kernel
│ ├── arch
│ ├── crypto
│ ├── drivers
│ ├── fs
│ ├── lib
│ ├── mm
│ ├── net
│ └── sound
└── updates
└── dkms
In order to get a custom kernel module with no support provided for DKMS, it needs some "packaging" you'll have to do yourself, of you'll have to recompile it yourself everytime. In other words, a "typical" ./configure; make; sudo make install
will just install one specific kernel module and requires you to recompile it every time.
If you fail to do so, the kernel module will simply not be found after an update. It will not look in the old directory and if you would force to load it, it would fail to insert probably. In case the installation overwrote a system default one, it might also load the non-custom one.
I'm not going to include the DKMS packaging here, as I think I've answered your question by now.
You're asking if you install an updated mainline kernel today, will this be replaced in future by official kernel if there is a release with kernel version greater than this mainline kernel?
The answer is NO. Because each kernel is packaged independently and kernel's version number is part of the package name. That is why you can run multiple kernels in the same system. So, when I install kernel-3.23, It won't be replaced when kernel-3.24 is available in update path. I have to manually install the later/updated one.
But Ubuntu partially handles this problem by using an empty linux-image-generic
package. This package's description says
This package will always depend on the latest generic kernel image
available.
So, when you update this package, this will bring newer 3-24 kernel in my system. But the older one will still be there. And those will accumulate until you removed them manually. That's why so many people have insufficient space problem in /boot
.
This is true only for Ubuntu maintained generic kernel only. Mainline kernels don't even have this kind of upgrade mechanism. So, You're the person responsible for maintaining the versions.
Best Answer
Updates should still work normally once a newer version of the kernel is available from any of your defined software sources.
If you are interested you can see which version apt considers newer with this command:
The exit status will be 0 if apt considers version1 newer or 1 otherwise.