I am on Debian 7.9, kernel 4.1.6-sunxi. Since a couple of days I get an error message when I want to open a LUKS container (e.g. cryptsetup luksOpen ...).

/dev/mapper/control: open failed: Kein passendes Gerät gefunden --> no device found
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Kann die Gerätezuordnung nicht initialisieren. Ist das Kernelmodul dm_mod geladen? --> is dm_mod really loaded?

I tried to manually load dm_mod and get another error message:

> modprobe dm_modlibkmod: ERROR ../libkmod/libkmod.c:554 kmod_search_moddep: could not open moddep file '/lib/modules/4.1.6-sunxi/modules.dep.bin'

This one is a little more helpful...

 

When I navigate to /lib/modules/ I won't find the 4.1.6-sunxi directory but a 4.2.3-sunxi directory (which contains the missing file). This is a little odd, as I am on the 4.1.6 kernel, right...? So what is the correct way of solving this issue? I read that you might use depmod to recreate the missing structures in that missing directory but when I try to invoke depmod there is - of cause - another error:

ERROR: could not open directory /lib/modules/4.1.6-sunxi: No such file or directory
FATAL: could not search modules: No such file or directory

I guess other people here came across this problem in the last couple of weeks as well (though I didn't find a post here) ... Any suggestions are welcome...

 

Regards!

It seems that you made an kernel upgrade (or was done auto if turned on) but you haven't rebooted yet.

Unfortunately is is not so easy to solve I rebooted several times since that problem occurred... 

Unfortunately is is not so easy to solve I rebooted several times since that problem occurred... 

 

OK, have you done any extraordinary modifications and can you post a content of a boot directory and a boot.cmd

I think I did not do anything 'extraordinary'. I installed the CubieTruck using your image and moved the system to a SATA harddrive using the script you provide some weeks ago. The last couple of days I only upgraded some packages and installed a new piece of software (some python wrappers for Spotify) from a non-standard repository. But I do not think that this is the reason for my problem...

 

In my /boot directory I find the following files and directories:

drwxr-xr-x 2 root root    4096 Okt 18 11:27 bin
-rw-r--r-- 1 root root  115484 Okt 11 14:12 config-4.2.3-sunxi
drwxr-xr-x 2 root root   12288 Okt 18 11:25 dtb
drwxr-xr-x 2 root root    4096 Sep 30 21:21 dtb.old
-rw-r--r-- 1 root root 1955569 Okt 11 14:12 System.map-4.2.3-sunxi
-rwxr-xr-x 1 root root 5468416 Okt 11 14:12 vmlinuz-4.2.3-sunxi
lrwxrwxrwx 1 root root      25 Okt 18 11:27 zImage -> /boot/vmlinuz-4.2.3-sunxi

Oddly there's also files for the 4.2.3-kernel... The content of /media/mmc/boot/boot.cmd is the following:

setenv bootargs console=tty1 root=/dev/sda1 rootwait rootfstype=ext4 sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=16 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 enforcing=0 loglevel=1
#--------------------------------------------------------------------------------------------------------------------------------
# Boot loader script to boot with different boot methods for old and new kernel
#--------------------------------------------------------------------------------------------------------------------------------
if ext4load mmc 0 0x00000000 /boot/.next || fatload mmc 0 0x00000000 .next
then
# sunxi mainline kernel
#--------------------------------------------------------------------------------------------------------------------------------
ext4load mmc 0 0x49000000 /boot/dtb/${fdtfile} || fatload mmc 0 0x49000000 /dtb/${fdtfile}
ext4load mmc 0 0x46000000 /boot/zImage || fatload mmc 0 0x46000000 zImage
env set fdt_high ffffffff
bootz 0x46000000 - 0x49000000
#--------------------------------------------------------------------------------------------------------------------------------
else
# sunxi android kernel
#--------------------------------------------------------------------------------------------------------------------------------
ext4load mmc 0 0x43000000 /boot/script.bin || fatload mmc 0 0x43000000 script.bin
ext4load mmc 0 0x48000000 /boot/zImage || fatload mmc 0 0x48000000 zImage
bootz 0x48000000
#--------------------------------------------------------------------------------------------------------------------------------
fi
# Recompile with:
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr #

I did not modify any of these files manually.

 

It seems like apt updated some parts of the system to 4.2.x kernel but did not install the kernel itself. Now I remember that the automatic updater sends error reports via mail since a couple of days:

/etc/cron.daily/apt:
Traceback (most recent call last):
 File "/usr/bin/unattended-upgrade", line 1016, in <module>
   main(options)
 File "/usr/bin/unattended-upgrade", line 798, in main
   allowed_origins=allowed_origins)
 File "/usr/bin/unattended-upgrade", line 75, in __init__
   self.adjust_candidate_versions()
 File "/usr/bin/unattended-upgrade", line 92, in adjust_candidate_versions
   if is_allowed_origin(pkg.candidate, self.allowed_origins):
 File "/usr/bin/unattended-upgrade", line 364, in is_allowed_origin
   if match_whitelist_string(allowed, origin):
 File "/usr/bin/unattended-upgrade", line 272, in match_whitelist_string
   what, token))
__main__.UnknownMatcherError: Unknown whitelist entry for macher 'n' (token 'n=wheezy')

Maybe that was the cause for this problem. But what caused apt to fail? Interestingly, manual updates work just fine.

The only problem regarding updating (that I am aware) was a week or two ago when one of servers crashed. But that's a network issue.

 

/boot must be a bind mount to SD card's /boot

 

Boot loader and a kernel are loaded from SD, the rest is from hard drive. Check /boot on the SD if it's the same.

Oh boy, ... I accidentally commented out the line that mounts /media/mmc/boot to /boot. So apt updated /boot on the harddrive (not on the mmc) and several other locations on the harddrive, like the modules directory.

 

After the reboot, I still had the old kernel/settings but on the harddrive everything was updated to match the new kernel... That won't work, of cause.

 

So I moved the new kernel and settings from /boot to /media/mmc/boot and everything is back to normal. 

 

Thanks for you help, Igor!