Hello, This is my first Gentoo bug report, any feedback welcome :) I found that after enabling zstd module compression in the kernel (gentoo-sources 6.1.31, amd64), attempting to open Virtualbox 6.1.44 gave: ERROR: could not insert 'vboxdrv': Invalid argument ERROR: could not insert 'vboxnetadp': Invalid argument ERROR: could not insert 'vboxnetflt': Invalid argument I tried the usual emerge @module-rebuild, rebooting, rebuilding the kernel, but no luck. With virtualbox and modules 7.0.8, this issue did not occur. There was no secure boot/forced module signing enabled, and zstd support was enabled in the kernel. GENTOO_KERNEL_SELF_PROTECTION_COMMON had been recently enabled, so there may be a connection there. make.conf flags: COMMON_FLAGS="-march=native -O2 -pipe" CFLAGS="${COMMON_FLAGS} CXXFLAGS="${COMMON_FLAGS} FCFLAGS="${COMMON_FLAGS} FFLAGS="${COMMON_FLAGS}
Do you have USE=zstd enabled on sys-apps/kmod? Typically you should given it's default. If not, that would be any modules, not just virtualbox-modules though.
Yes, it's enabled.
Oh, if it's the same kernel, do you have old modules in /lib/modules? As in the old non-compressed variant existing alongside the compressed one.
(In reply to Ionen Wolkens from comment #3) > Oh, if it's the same kernel, do you have old modules in /lib/modules? As in > the old non-compressed variant existing alongside the compressed one. By same, I meant same version. Disregarding rebuilds. It may be mismatching with old modules given portage doesn't cleanup these.
...if it's that, maybe could consider a non-destructive postinst warning to detect same-directory duplicates for compression. Originally thought to do this for different directories too but felt scanning this potentially large directory would be too expensive.
>With virtualbox and modules 7.0.8, this issue did not occur Also by not occur, did you mean with compression too? The eclass changed, but 7.0.8 also compressed modules the same way 7.0.8-r1 does if it's enabled.
What is the output of find /lib/modules/`uname -r` -name vbox\* Also are you using app-emulation/virtualbox-modules-6.1.44 or app-emulation/virtualbox-modules-6.1.44-r1?
(In reply to Ionen Wolkens from comment #3) > Oh, if it's the same kernel, do you have old modules in /lib/modules? As in > the old non-compressed variant existing alongside the compressed one. That does seem to be the issue. On a different computer with Virtualbox 7, I had a similar issue after switching to zstd compression that I solved by removing the module files and then rebuilding.
(In reply to Viorel Munteanu from comment #7) > What is the output of > find /lib/modules/`uname -r` -name vbox\* > > Also are you using app-emulation/virtualbox-modules-6.1.44 or > app-emulation/virtualbox-modules-6.1.44-r1? At the time it was 6.1.44.
(In reply to Joseph McElroy from comment #9) > (In reply to Viorel Munteanu from comment #7) > > What is the output of > > find /lib/modules/`uname -r` -name vbox\* > > > > Also are you using app-emulation/virtualbox-modules-6.1.44 or > > app-emulation/virtualbox-modules-6.1.44-r1? > > At the time it was 6.1.44. Here is the output: /lib/modules/6.1.46-gentoo-x86_64/misc/vboxnetadp.ko /lib/modules/6.1.46-gentoo-x86_64/misc/vboxnetflt.ko /lib/modules/6.1.46-gentoo-x86_64/misc/vboxdrv.ko /lib/modules/6.1.46-gentoo-x86_64/kernel/drivers/gpu/drm/vboxvideo /lib/modules/6.1.46-gentoo-x86_64/kernel/drivers/gpu/drm/vboxvideo/vboxvideo.ko
