dkms built modules may be compressed in a way unsupported by the kernel about dkms HOT 4 CLOSED

The only thing that comes off the top of my head is the --ultra compressionsoption.

Kernel supports up-to level 14 (or was it 20), where for 20+ you need to use zstd --ultra, which in itself requires more RAM, as far as decompression is concerned, which is perhaps why the kernel does not support it.

IIRC newer versions of kmod will pass the compressed module directly to the kernel. Older ones will decompress it before hand.

Perhaps kmod could (or should?) callback and uncompress if the kernel cannot load the compressed module?

from dkms.

this is about xz not zstd

the relevant option here should be --check=crc32

but then again, why can't module compression be delegated to kbuild? the kernel probably knows best how it wants its modules ... does dkms really have to reinvent that?

from dkms.

in the Linux git master as of today:

$ grep -r -e --check=crc .
./Documentation/staging/xz.rst:--check=crc32.
./Documentation/staging/xz.rst: xz --check=crc32 --lzma2=dict=512KiB inputfile
./arch/powerpc/boot/wrapper:        xz --check=crc32 -f -6 "$vmz.$$"
./scripts/Makefile.modinst:      cmd_xz = $(XZ) --check=crc32 --lzma2=dict=1MiB -f $<
./scripts/Makefile.lib:      cmd_xzmisc = cat $(real-prereqs) | $(XZ) --check=crc32 --lzma2=dict=1MiB > $@
./scripts/xz_wrap.sh:exec $XZ --check=crc32 $BCJ --lzma2=$LZMA2OPTS,dict=32MiB

from dkms.

Right - turns out both of our xz and zstd commands needed a tweak. The issue should be resolved with #390

You are right though - ideally we'll be using the upstream modules_install. There' s task for that already #319, although I haven't checked if it'll have any caveats.

For the short term, I think we can fix our cmdline args. If anyone want to pursue the modules_install please be my guest.

from dkms.