4

I would like to use LZMA-compressed kernel modules on my system. Unfortunately Canoncial leaves that feature disabled both in kernel and user-space tools. Here's what I did so far:

  1. Compile and install the current 14.04.05-LTS kernel (v4.4.19) with:

    CONFIG_MODULE_COMPRESS=y
    CONFIG_MODULE_COMPRESS_XZ=y
    

    After installation I can now see a bunch of .ko.xz files in /lib/modules/4.4.19-37.56+/kernel/.

  2. Backport the kmod_22 package from Xenial (16.04) to Trusty (14.04) configured with the --with-xz option. This seems to work too.

  3. Run update-initrams -u -k 4.4.19-37.56+.

What works so far:

  • arbitrary operations on uncompressed modules (like those built by DKMS):

    $ modinfo nvidia_370
    filename:       /lib/modules/4.4.19-37.56+/updates/dkms/nvidia_370.ko
    […]
    
  • showing compressed modules by their full path:

    modinfo /lib/modules/4.4.19-37.56+/kernel/fs/jfs/jfs.ko.xz
    
  • loading compressed modules without (missing) dependencies by their full path:

    insmod /lib/modules/4.4.19-37.56+/kernel/fs/jfs/jfs.ko.xz
    
  • unloading such modules:

    rmmod jfs
    

What doesn't work:

  • Unloading with modprobe -r.

  • Any other operation with just a package name but no path, e. g.:

    # insmod jfs
    insmod: ERROR: could not load module jfs: No such file or directory
    # modprobe jfs
    modprobe: FATAL: Module jfs not found in directory /lib/modules/4.4.19-37.56+
    

So, for modules without dependencies like jfs there's a work-around where I can just specify the full module file path to insmod, but this is both annoying and doesn't perform dependency resolution like modprobe.

I suppose that the kernel module directory somehow doesn't pick up compressed module files. How can I load compressed kernel modules by their name with modprobe?

  • Did you run depmod afterwards? – heemayl Sep 9 '16 at 14:16
2

You need to run depmod.

depmod (by default) reads the modules under /lib/modules/$(uname -r), finds which symbols they export and also what they need themselves, then using these info creates the symbol (module) dependencies between modules, and saves it in the file /lib/modules/$(uname -r)/modules.dep and also creates a binary hash /lib/modules/$(uname -r)/modules.dep.bin.

It also creates two other files:

  • /lib/modules/$(uname -r)/modules.symbols (and it's binary hash /lib/modules/$(uname -r)/modules.dep.bin): contains the symbols each module exports

  • /lib/modules/$(uname -r)/modules.devname: contains the /dev entry that needs to be created for necessary modules, contains the module name, name of the /dev entry and the major, minor numbers

Just to note, you can also run depmod for a specific kernel version or on a specific module, check man depmod.

  • 1
    Yes, I ended up running depmod 4.4.19-37.56+. – David Foerster Sep 9 '16 at 18:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.