drscheme Posted October 26, 2015 Share Posted October 26, 2015 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! Link to comment Share on other sites More sharing options...
Igor Posted October 26, 2015 Share Posted October 26, 2015 It seems that you made an kernel upgrade (or was done auto if turned on) but you haven't rebooted yet. Link to comment Share on other sites More sharing options...
drscheme Posted October 26, 2015 Author Share Posted October 26, 2015 Unfortunately is is not so easy to solve I rebooted several times since that problem occurred... Link to comment Share on other sites More sharing options...
Igor Posted October 26, 2015 Share Posted October 26, 2015 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 Link to comment Share on other sites More sharing options...
drscheme Posted October 26, 2015 Author Share Posted October 26, 2015 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. Link to comment Share on other sites More sharing options...
Igor Posted October 26, 2015 Share Posted October 26, 2015 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. Link to comment Share on other sites More sharing options...
drscheme Posted October 26, 2015 Author Share Posted October 26, 2015 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! 1 Link to comment Share on other sites More sharing options...
Recommended Posts