dell/dkms

dkms built modules may be compressed in a way unsupported by the kernel

Closed this issue · 4 comments

anbe42 commented

from https://bugs.debian.org/1061427

dkms compresses some of the packages it builds. I guess this depends on the
kernel config that it builds for.
With xz compression, it compresses it in a way that's not compatible with
kernel's xz. The difference seems to be the CRC:

file kernel/drivers/misc/isl29020.ko.xz: XZ compressed data, checksum CRC32

  • mainline driver, works

file updates/dkms/ddcci.ko.xz: XZ compressed data, checksum CRC64

  • dkms driver, fails to load
evelikov commented

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?

anbe42 commented

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?

anbe42 commented

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
evelikov commented

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.