Intel NUC Hardware WatchDog Enabling ERROR fixdep

I would like to enable watchdog services on my Intel NUC.

Start Watchdog Services

RUN modprobe i2c-i801
RUN modprobe i2c-smbus
RUN modprobe iTCO-wdt

When trying to activate I get this:

[main] Step 23/26 : RUN modprobe i2c-i801
[main] —> Running in bbb2103a4165
[main] modprobe: ERROR: …/libkmod/libkmod.c:586 kmod_search_moddep() could not open moddep file ‘/lib/modules/4.14.11-coreos/modules.dep.bin’
[main] modprobe: FATAL: Module i2c-i801 not found in directory /lib/modules/4.14.11-coreos
[main] Removing intermediate container bbb2103a4165
[main] The command ‘/bin/sh -c modprobe i2c-i801’ returned a non-zero code: 1

What can I do? Do I have to build kernel modules and how do I obtain these? On Ubuntu 16.04 LTS non-resin/balea it works. Thanks

– Error Message is below —

Hi @rquant, It looks like you are running your modprobes in the RUN commands, which are executed in a non-privileged container on our build servers. To properly check that the modprobe is working, you would need to run the modprobe from a script or from your CMD so that it runs on the device rather than on the cloud build server. Another way to test this is to use the webterminal into your running container and then run modprobe i2c-i801 etc from the webterminal to check that they are available.

Great thanks for the answer will use it in my device script not on build servers.

I tried to run it in my file. Can I somehow build this using:

GitHub - balena-os/kernel-module-build: Example project for building an OOT kernel module in balena

Tried to build with the balena kernel sample:
I created a folder called iTCO-wdt and placed the iTCO-wdt.c,``iTCO_vendor.h, iTCO_vendor_support.c file inside there with the Makefile:

KERNEL_TREE_PATH?=/lib/modules/$(shell uname -r)/build


all: iTCO_wdt.ko

iTCO_wdt.ko: iTCO_wdt.c
	make -C $(KERNEL_TREE_PATH) M=$(PWD) modules

	make -C $(KERNEL_TREE_PATH) M=$(PWD) clean

.PHONY: all clean

and calling


in my dockerfile.

2018-11-21 22:35:58 (68.2 MB/s) - ‘kernel_modules_headers.tar.gz’ saved [10331481/10331481]
[main]     make: Entering directory '/tmp/tmp.BPRxUQjNfP'
[main]       CC [M]  /usr/src/app/
[main]     /bin/sh: 1: scripts/basic/fixdep: not found
[main]     scripts/ recipe for target '/usr/src/app/' failed
[main]     make[1]: *** [/usr/src/app/] Error 127
[main]     Makefile:1515: recipe for target '_module_/usr/src/app/' failed
[main]     make: Leaving directory '/tmp/tmp.BPRxUQjNfP'
[main]     make: *** [_module_/usr/src/app/] Error 2

I saw some threads similar with fixdep issues:

kernel_modules_headers/scripts/basic$ file fixdep
fixdep: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 3.2.0, BuildID[sha1]=31dcb0219bb5a2f2113663344ca3543804d082ee, not stripped

I tried with nearly every yocto kernel version, but always get fixdep error. Does anyone know how to solve it?

Hi @rquant,

I looked at kernel module headers in detail last week and found a few bugs. I’ve merged a PR with fixes that will reach future versions of balenaOS in due course. [1]

For past versions, there are workarounds.
Please correct me if I’m wrong, you are using balenaOS v2.13.6 on an Intel NUC? each version/device requires a different workaround

For that version on that device, the tools inside the header tarball such as fixdep have the following dynamic interpreter path /lib/ which is the balenaOS baselib path. However, the intel-nuc-debian image uses /lib64/ as the baselib path. The issue manifests as fixdep file not found. We need a symlink from /lib64/ to /lib/ This lets the tools find the right library and continue working.

ln -s /lib64/  /lib/

This workaround probably should be applied inside somewhere (and probably committed too before building)

Check out the following snippet where I can’t run the tool before the symlink and can after the symlink

root@5e4a1ab8b9ad:/usr/src/app# file kernel_modules_headers/scripts/basic/fixdep
kernel_modules_headers/scripts/basic/fixdep: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/, for GNU/Linux 3.2.0, BuildID[sha1]=31dcb0219bb5a2f2113663344ca3543804d082ee, not stripped
root@5e4a1ab8b9ad:/usr/src/app# ./kernel_modules_headers/scripts/basic/fixdep
bash: ./kernel_modules_headers/scripts/basic/fixdep: No such file or directory
root@5e4a1ab8b9ad:/usr/src/app# ln -s /lib64/  /lib/
root@5e4a1ab8b9ad:/usr/src/app# ./kernel_modules_headers/scripts/basic/fixdep
Usage: fixdep [-e] <depfile> <target> <cmdline>
 -e  insert extra dependencies given on stdin



Thank you very much for the answer.
I will try using symlinking.
I am using balenaOS 2.26.0+rev1 with ubuntu 16.04 on Intel NUC.
Is the command the same as you mentioned?

Hi @rquant,

That version has a tool missing. objtool.

Fix is in the same PR I linked earlier.

but I don’t have an easy workaround to share at the moment.

Hi @rquant,

I’ve uploaded a build of kernel-module-headers tarball with my fixes. That should let you build your module.

Have a look at the last commit in the zlk/nuc branch in the repo.

It has the symlink workaround and references my build which has objtool as well.

This should let you proceed with your work at least.


1 Like