Unkown symbols during dkms driver, module install

[andy53]

We are experimenting with porting over a custom storage blockio driver from Ubuntu 14_04 to Proxmox VE4.1. The driver is using dkms and successfully compiles/runs on kernels up to 4.3 on Ubuntu, CentOS and Fedora.

After installing dkms and the pve-headers (using a test pve-no-subscription config), the package successfully compiles and installs using dpkg -i pkg.deb but when attempting to load, modprobe complains it cannot load with entries in the syslog as follows:

Mar 10 22:41:06 pve kernel: [ 1548.612254] en_block: disagrees about version of symbol blk_queue_logical_block_size
Mar 10 22:41:06 pve kernel: [ 1548.612257] en_block: Unknown symbol blk_queue_logical_block_size (err -22)
... (several other similar lines for add_disk, bio_clone_bioset, put_disk, etc).

Same happens if we load the full source and compile natively.

Is there an issue with attempting to do this with the non-subscription repo option?

Very much appreciate any pointers. Thank you!

 

[andy53]

Update: I was able to successfully install the Enmotus FuzeDrive Ubuntu dkms drivers after performing an upgrade to the latest version 4.2.8-1-pve with a full subscription license. Commands used were:

$ apt-get update
$ apt-get dist-upgrade
$ apt-get install dkms pve-headers-$(uname -r)

 

[fabian]

Just as a note for the future: that error message usually occurs when you try to load a module that was compiled for a different kernel then the one you are currently running (for example, when you install a kernel update, DON'T reboot, then compile the module and try to load it).

 

[andy53]

Yes, but in this case we are using dkms which compiles source on the local host before installing the kernel module. I also tried with our full source tree which compiles locally but fails in the same manner (see my original post).

As best we can tell, the issue would appear to be with the headers pulled down by apt-get install pve-headers-4.2.6-1-pve unless we've missed something. The 4.2.8-1-pve kernel and pve-headers-4.2.8-1-pve appear to have resolved this issue.

 

[fabian]

Yes, but in this case we are using dkms which compiles source on the local host before installing the kernel module. I also tried with our full source tree which compiles locally but fails in the same manner (see my original post).

As best we can tell, the issue would appear to be with the headers pulled down by apt-get install pve-headers-4.2.6-1-pve unless we've missed something. The 4.2.8-1-pve kernel and pve-headers-4.2.8-1-pve appear to have resolved this issue.

You can easily compile your module for the wrong kernel version with DKMS if you have more than one installed.. If you are running the 4.2.8-1 kernel, but only have the 4.2.6-1 headers installed, the module will build successfully, but fail to load (unless you reboot with the 4.2.6-1 kernel, or install the 4.2.8-1 headers and recompile the module).