There is an issue with 4.8.1 that cryptsetup won’t work out of the box:
root@GL-MT3000:~# cryptsetup --type plain --cipher=aes-xts-plain64 open /dev/sda1 ssd
device-mapper: reload ioctl on ssd (254:0) failed: Invalid argument
dmesg:
[ 101.933612] dm_mod: exports duplicate symbol dm_consume_args (owned by kernel)
[ 101.965748] device-mapper: table: 254:0: crypt: unknown target type
[ 101.972031] device-mapper: ioctl: error adding target to table
While looking into this I found a similar topic without an answer: cryptsetup not working on MT3000 (the error examples above are taken from that post; I was seeing similar messages), so I decided to post this quick writeup.
Diagnosis
It appears that the kernel is now compiled with a built-in dm core, whereas dm-crypt (and other dm target modules) are compiled assuming it is a module, so dm-crypt.ko lists dm-mod.ko as a dependency. modprobeand kmodloaderwill honor this dependency information and attempt to load dm-mod.ko first, which is the cause of the ‘duplicate symbol’ message in dmesg. When this fails, they will refuse to load dm-crypt.
insmod, however, ignores the dependency information, so inserting dm-crypt explicitly succeeds and allows the original cryptsetup test to pass.
Evidence
root@GL-MT3000:~# modinfo /lib/modules/5.4.211/dm-crypt.ko | grep depends
depends: dm-mod
root@GL-MT3000:~# zcat /proc/config.gz | grep DEV_DM
CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=y
Workaround
This setup is working for me so far, but, strictly speaking, there is no guarantee the dm-crypt module is compatible with the current kernel, seeing as it must have been compiled with a different kernel .config.
I would not recommend using it for accessing important data, especially for writing.
This is what I ended up doing:
#!/bin/sh /etc/rc.common
START=15
start() {
local moddir="/lib/modules/$(uname -r)"
insmod "$moddir/dm-crypt.ko"
}
Save it as, let’s say /etc/init.d/force-load-modules. (A generic name just in case more such modules are discovered… be prepared, that’s the boy scout’s marching song!)
Then:
/etc/init.d/force-load-modules enable
/etc/init.d/force-load-modules start
This should survive firmware updates, and should not cause any conflicts when GL-iNET fixes the issue properly.