All the DKMS-managed kernel modules started to fail during loading on my Ubuntu 18.04 machine. I noticed it with acpi_call so let me use that to demonstrate:

# uname -r

# modinfo acpi_call.ko 
filename:       /lib/modules/4.15.0-99-generic/updates/dkms/acpi_call.ko
license:        GPL
srcversion:     72B6FB9451F0D2139482F11
retpoline:      Y
name:           acpi_call
vermagic:       4.15.0-99-generic SMP mod_unload 
signat:         PKCS#7
sig_hashalgo:   md4

# modprobe acpi_call
modprobe: ERROR: could not insert 'acpi_call': Exec format error

I have tried reinstalling it with DKMS, to no avail:

# dkms status acpi-call
acpi-call, 1.1.0, 4.15.0-99-generic, x86_64: installed

# dkms remove acpi-call/1.1.0 --all

-------- Uninstall Beginning --------
Module:  acpi-call
Version: 1.1.0
Kernel:  4.15.0-99-generic (x86_64)

Status: Before uninstall, this module version was ACTIVE on this kernel.

 - Uninstallation
   - Deleting from: /lib/modules/4.15.0-99-generic/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


DKMS: uninstall completed.

Deleting module version: 1.1.0
completely from the DKMS tree.

# dkms install acpi-call/1.1.0

Creating symlink /var/lib/dkms/acpi-call/1.1.0/source ->

DKMS: add completed.

Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j8 KERNELRELEASE=4.15.0-99-generic -C /lib/modules/4.15.0-99-generic/build M=/var/lib/dkms/acpi-call/1.1.0/build...
Signing module:
 - /var/lib/dkms/acpi-call/1.1.0/4.15.0-99-generic/x86_64/module/acpi_call.ko
Nothing to do.
cleaning build area...

DKMS: build completed.

Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.15.0-99-generic/updates/dkms/


DKMS: install completed.

# modprobe acpi_call
modprobe: ERROR: could not insert 'acpi_call': Exec format error

Other modules in /lib/modules/4.15.0-99-generic/updates/dkms exhibit the exact same problem.

I have also tried modprobe -f, leading to a different error message:

# modprobe -f acpi_call
modprobe: ERROR: could not insert 'acpi_call': Required key not available

This led me down the MOK rabbit hole but even after enrolling a new MOK and sign-file-ing the .ko files, I am still getting the Required key not available error. If I disable validation, then modprobe -f still fails with Exec format error.

Also, I have noticed this line in dmesg:

[  617.320431] module: x86/modules: Skipping invalid relocation target, existing value is nonzero for type 1, loc 0000000057734886, val ffffffffc0d56a43

What is going wrong here and how do I fix it?

  • Well, something is broken in your system. I can't guess.
    – Pilot6
    May 2, 2020 at 11:26
  • 1
    Ah ha! It seems that the problem is that it is built with GCC 9. If I build with GCC 7, it seems to work.
    – Cactus
    May 2, 2020 at 11:31
  • That's a good catch!
    – Pilot6
    May 2, 2020 at 11:31
  • Default gcc in bionic is 7. So you changed the default and got this problem. Please write an answer, this may be useful.
    – Pilot6
    May 2, 2020 at 11:33

1 Answer 1


It turns out the problem was that the default GCC on my system got changed to GCC-9 (due to a botched freehdl upgrade, but whatever). This resulted in a different (and apparently, not ABI-compatible?) GCC version used for building modules with DKMS compared to the GCC version used to build the Ubuntu kernel.

After downgrading back to GCC-7 (and rebuilding all DKMS modules), everything now works as before, including Secure Boot support.

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.