6

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?

1
  • Did you run depmod afterwards?
    – heemayl
    Sep 9, 2016 at 14:16

2 Answers 2

6

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
  • 1
    Yes, I ended up running depmod 4.4.19-37.56+. Sep 9, 2016 at 18:23
1

You need a depmod with lzma support to map and allow loading .xz compreesed kernel modules

Some depmod ship without it, so you may require a binary made by custom build flags, like --with-xz

2
  • Of course. However, that was not the issue: depmod is part of the kmod package which I had already patched to enable xz/LZMA support when I wrote the question (as you can see). Jun 12, 2020 at 13:01
  • Sorry, for it was TLDR; and I believed you had failed on that
    – Marcelo
    Jun 13, 2020 at 21:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .